Zenn
💭

QAエンジニアになるために

2024/02/20に公開
初心者
Test
初心者向け
#
テスト
#
テスト自動化
idea

テスト分野について、思うところを書いていこうと思います。
JSTQBとかPMBOKとかみたいに体系的ではなく、「人」によった形（愚痴）という考察です。
そして、もちろん結論はありませんっ！笑

個人的には、カジュアルなテストフレームワーク的なものがあれば、色々と楽ちんなんですが、広く一般の会社には存在しないのが現状なのかなと感じてます。
それを提供・啓示（言い過ぎ？笑）しているのが、JSTQBとかPMBOKだったりすると思っているんですが、いざ現場に落とし込んだ時に敷居が高かったり、アンマッチだったりとぶっちゃけ導入しにくいのかなと感じてます。

自社サービスを運営していたり、大手とかはフレームワーク化してたりするのですが、QAコンサルってそういったノウハウを提供するんでしょうか。
テスターさんたちのスキルアップと現場が少しでも楽になって、単価アップできる方法を考えていきたいです。

テストの課題

テストの課題感として「マンパワー系」人に起因するものと、「プロジェクト系」プロジェクトや場所ごとに課題になりそうなものを大分類として、それに紐づくような形で詳細を分割してみました。

  • マンパワー系
  1. テスト設計者が少ない
  2. 他端末テスト
  3. ゴッドハンド
    a. 何故かレアな不具合を摘出できる人（笑）
    b. ニュータイプテスター（バグが見える人）
  • プロジェクト系
  1. 網羅性
  2. テスト期間
  3. 開発スキル
  4. 品質を評価するための基準値を探す日々
  5. テストケースの作り方

マンパワー系

テスト設計者が少ない

テスト設計できる方が引っ張りだこみたいなんですよね。
これは個人的な意見ですが、「テスト設計ができる＝システム設計ができる」くらいの勢いだと思っています。
V字モデルや、W字モデルといったもので表現されている通り、各工程で必要なものがわかっているハズ。
知識としてはあって困るものでもないので、覚えておくといいと思います！

工程ごとに「何をインプット」として、「何をアウトプット」するのかを簡単に書いてみます。
といっても、単体テストはホワイトボックステストが前提かと思いますので、ブラックボックスで実施可能な「システム / 受け入れテスト」と、「結合テスト」が対象になる想定です。

システム / 受け入れテスト

  • Input：要件定義 / 要求定義
  • Output：ユースケースシナリオ
    • これは、システムの使用者を想定してテスト設計しますよね。
      システムに新規登録して買い物ができる～的な。

結合テスト

  • Input：基本設計書 / 機能設計書
  • Output：結合テストケース（画面やFunction単位の結合）
    • データを軸にしてテスト設計するのかなと。
      なので、登録した値が次の画面でどう表示されるか。や、メールアドレスの形式が守られていないと登録できない（バリデーションチェック）とか。

網羅性の前に、テスト設計で絶対考えるのは、このシステムは何ができなきゃいけないのか。 と 何ができたらいけないのか。 を突き詰めるところから始めるのがいいかと思います。

他端末テスト

スマホの普及によって、Webサイトやスマホアプリのテストは、画面サイズと機種依存との戦いです。そう戦なのです。

WEBサイトはレスポンシブが標準くらいの勢いです。
「/sp/」みたいなスマホ専用URLは見なくなりました、ガラケーの時は「/mb/」的なのよく見ましたけど・・・笑
ということなので、絶妙な画面サイズの時にレイアウトが崩れる可能性があるんです。

スマホアプリ・・・特にAndroidです。
Androidはいろいろな会社がスマホ端末を発売していますね。
不思議なことに「XXが発売しているAndroidだけで発生する」なんてこともあるんです。

だもんで、人件費もスマホを購入する備品費用も必要なんですよ。
これは意外と重くのしかかってきます。

解決 / 改善案として、上がるであろう自動化（E2E）テストです。
しかし、実際自動化してもテストにかかる工数・費用は削減できません。
長期的に見れば削減できると考えていますが、短期的に見た場合は厳しいと思います。

では、なぜ削減できないのか。

  • テスト設計者の単価
  • 自動化の実装者の単価
  • 自動化に使用するサービスの料金
  • 自動化コードのメンテナンス

などの費用がかかります。
設計・実装（＆デバッグ）などするので日にちもかかります。
ですので、1開発サイクル中の品質が安定しないうちは手動テストの工程は自動テストに置き換わりません。
むしろ、置き換えない方がいいでしょう。
テストコードのメンテナンスコストがかかります。

一方で、長期的にみた場合、自動化もシステム開発と同様にベースができてくれば、費用が軽減されるかもしれません。

ゴットハンド

いるんですよ。
何故か不具合にたどり着いちゃう方が・・・笑

この"特殊な属人化"を極力埋めるためにスキルアップを促したいですね！
強化人間ダメ、絶対×

プロジェクト系

網羅性

とても大事なんですけどね。なかなか難しいんですよ。
テスト設計をやり始めの方は、先述の通りに、このシステムは何ができなきゃいけないのか。 と 何ができたらいけないのか。 を考えること始めるのがいいかと思います。
そこから考えることで、ユースケースシナリオなどが見えてくると考えています。
あとは、箇条書きでもいいので書き出してみることですかね。

慣れてきたら、デシジョンテーブルとか使ったりして抜け漏れを防止する。とかステップアップするでよいのではと思います。

テスト期間

これは開発が押すと、後工程のテストの工期が縮まるんですよね（笑
リリース日は変えられない。って言われるので。

これは、テスト視点でいくと「開発が・・・」とか思うんですが、開発を擁護させてもらうと。
蓋を開けたら、「あれ、これもいるそれもいる」とか「意外と複雑やんけ・・・」なんてことはザラにあって、突き詰めていくと、見積・要件定義が～とかなるんですよ。

これは、テストも同じで蓋を開けたら以外と見積通りにいかないことはあります。
この辺で一番NGなのは。「言わない（調整しない）」ことかなと思います。
すでに見積済みでテストが走り出していると仮定して、どんなことが調整できるか考えてみましょう。

  • 開発工程で遅延が発生した
    • リリーススコープの見直し
    • リリース日の調整
    • テスト範囲の縮小
    • 増員
  • テスト工程で遅延が発生した
    • テスト範囲の縮小
    • 増員

当然ですが、後工程に行くほど取れる選択肢は減ります。さらに突貫感が増します。
リリース関連の調整事項は、比較的でかいことですが早期であれば顧客などへの調整ができますし受け入れてもらえる余地はあると思います。
（でも、「ただ遅れます」は絶対ダメです。代替案を提示するようにしましょう。）

増員ですが、スペシャルな人が案件の途中でポッと参画することは、まず稀なことだと思います。なので、増員したらテストケースの消化はできますが、品質は確保できませんよ。
操作続行不可能になるなどのクリティカルな不具合はします。など品質の確保ラインは決めましょう。

あと、PMとかリーダーの方が「自分が入れるんでリカバリーできます！」は、あんまり信用してないです（自分で確認済み）笑

開発スキル

あったら、尚よしです。
なくても設計はできますよ。

あると何がやりやすいのか。

  • 結合テストに深み増す
    • バリデーションとか想定しやすい
    • DBの型定義を想像してみる
  • プログラム言語ごとのクセがわかる
  • 初期化漏れなど見落としがちになっているところが想定できる
  • 自動化テストで細かなテストコードが書けるようになる

品質を評価するための基準値を探す日々

リリースするためや、次の工程に進めるために的な基準値を指してます。
最近も求めている人はいるんでしょうか。
遥か昔に、ステップ数中の不具合数などから作り込み率的なものを数値化して、それを基準にして品質判定をしたりしてたこともありました。
ただ、これって色々と課題があるんですよねぇ。

改修の規模感だったり、フレームワークのコード対象にしないようにしたりとかとか。
テストケースあたりの摘出率とかがテスト視点から見るといいのかなと思ったりしてます。
ただ規模感は定義しないとダメそうですよね。
誰か教えていただきたいです。

テストケースの作り方

僕がテストケースを作成するとき、フォーマットは↓でだいぶ固定されています。

  • No
  • 観点
  • 画面 / 機能
  • 前提条件
  • 手順
  • 期待値
  • 検証結果
  • 検証日
  • 実施者
  • チケットURL
  • 備考

「前提条件」、「手順」が「条件1, 2, 3」みたいになる時はありますね。
自分以外の方に手伝っていただいたり、実施はお任せすることが多かったので、ここ数年は「手順」を記載することが多いです

あと、この辺は個人の経験や感性で判断にブレが出てしまうので、「期待値」は具体的に記載するように心掛けてます。

そして、ファイル的には、スプレッドシートですね。
その前はExcelちゃん一択でした。

ファイルで作成するときにいつも迷うのは、以下です。

  • NG → OKになった時などの履歴
  • 他端末検証におけるファイル or シートの分割（複製）
  • 進捗管理
    ファイルを分割したら、あら大変。

ファイルで作成していると、このあたりの課題感は常に付きまといます。
（某社の猫ちゃんシステムはこの課題をクリアしているっぽいですが・・・。）

あとがき

テスト界隈を安定させたいですね。
システムが高度化してきているので、技術的なことはどうしても必要になってしまうので自身の付加価値を付けたいと思っている方は、是非ともプログラムを勉強してもいいと思います。

オンライン講座やら、技術書を最初からやるもよし！
みんなで安心安全安定したテストをやりましょう！笑

関連記事

参考

Discussion