【DAIJOBU流！】QAプロセスの基本：テスト計画から設計までを徹底解説
はじめに
どうも、DAIJOBUのQAエンジニアのラコンマンです！
今回の記事では、案件を受注した後の【テスト計画→設計→実施→テスト報告書の作成】のうち、【テスト計画→設計】の部分にフォーカスして、DAIJOBUのQA進行方法を紹介します。
1.計画書の作成
DAIJOBUでQAを請け負った際の最もベーシックなテストは対象プロダクトの「機能テスト」とシステム全体の「シナリオテスト」です。 なお、計画書より前のヒアリング等の段階で、テストの方針が定まっていることが多いため、テスト計画書ではその具体的な内容について言及しております。
計画の際には下記の順で作成していきます。
①枠組みの作成
②機能テストの観点出し
③シナリオテストの観点出し
（④機能テスト・シナリオテスト以外のテストの観点出し）
⑤レビュー
①枠組みの作成
必須で記載するものは、テスト対象、テストスコープ、スケジュール、対象プロダクト、対象端末、実施開始・中断・終了条件、コミュニケーション方法、不具合管理方法、そしてテスト内容になります。（案件によって項目はさらに増えます）
上記項目を客先にヒアリングしながら埋めていきます。
テストの要である「テスト内容」には、観点・対象機能・シナリオ一覧を記載し、今回テストする方針と概要がわかるようにします。 具体的な「観点」「機能」は②、「シナリオ」は③で洗い出したものになります。
②機能テストの観点出し
【機能一覧】
対象機能と、その機能でできること・確認することをざっくり記載します。 項目としては「機能名」「確認内容」「対象可否」を設定します。
例えばログインの場合、
機能名：ログイン 確認内容：ログイン可否（タイムアウト、同時排他制御）
上記のような感じで機能一覧を作成し、今回のテスト対象の可否をつけます。
多くは全てが「対象」になりますが、「対象外」とした場合はその理由を記載し、必要であれば端末ごと（例：スマートフォンの場合、Android、iOSのどちらかorそれぞれで確認など）の対象可否も明示します。
【観点一覧】
上記の機能で確認する観点を列挙していきます。 項目としては「観点名」「観点内容詳細」「対象可否」を設定します。
例えば画面表示の場合は、
観点名：画面表示 観点内容：表示崩れがないこと・違和感がないこと
上記のような感じ。 観点内容は確認する粒度も意識して記載しましょう。
画面表示を例にあげると、
ざっくりと確認する場合 →表示崩れがないこと
細かく確認する場合 →画面の表示が仕様書と完全一致（文言も含める）していること
ーーとなります。
※なお、シナリオテストにももちろん「観点」が存在しますが、多くの場合は「機能」をユーザーシナリオに沿って正しく挙動を確認するものになりますので、ここでは便宜上「機能一覧」に対する「観点」としています。
③シナリオテストの観点出し
【シナリオテスト一覧】
ユーザーシナリオに沿ったシナリオテストの一覧を作成します。 この段階ではシナリオの「目的」だけわかればOKなので、厳密には「シナリオテストの目的一覧」となります。条件分岐など細かいフローも書きたくなるのですが、ここではぐっと我慢し「目的」のみを記載するようにしましょう。（もちろん必要な場合は記載する）
なぜなら、条件分岐はテスト計画の段階で「完璧に分岐を網羅した！」と思っていても、実際にテストケースに落とし込むと抜け漏れが判明することが非常に多いからです。テスト計画書への反映が大変なため、テスト計画書→テストケースに落とし込む前に、「シナリオテスト詳細」といった別途資料を作成し、そちらの資料で具体的な条件分岐・フローを記載すると効率が良いです。
シナリオテスト詳細も開発側にレビューを通すと◎ 。「目的」の認識さえ合っていれば、あとは条件分岐などの粒度の問題なので、そこまで大きな手戻りは発生しない確率が高いです。
④機能テスト・シナリオテスト以外のテストの観点出し
追加実装の機能にフォーカスしたテストや、非機能テストなどの場合も、やること自体は同じ。
確認する観点・粒度を明記するようにしましょう。
⑤レビュー
①②③④でテスト計画書の作成が完了したら、QAチームはもちろん、開発側も巻き込んだレビューを行ってください。 この段階でテスト対象・機能・観点の認識を合わせることで、テストケース化する際の手戻りや質問をグッと減らすことができます。
特に、追加実装部分に関しては開発側の理解度が高いため、追加実装資料に記載のない細かい仕様や、テストのための前提条件や開発依頼が必要な項目が判明することがあります。また、影響範囲が広がることでより不具合の検出をしやすくなることもしばしば。
想像以上に開発側から有益な指摘を頂戴できますので、説明が多く大変な面もありますが、ここは必ず開発側も巻き込んでレビューすることを推奨します。
2.テストケースの設計
さて、テストの計画・方針が決まったので、いよいよテストケースに落とし込んでいきます。機能確認テストの場合は、「1.計画書の作成②機能テストの観点出し」で洗い出した機能一覧×観点一覧でマトリクスを作成し、そのマトリクス準拠に設計をすると抜け漏れなく、全ての機能を一定の水準で確認することができます。
しかし、マトリクス作成のリソース、メンテナンスのリソース（実際に設計するとマトリクスに不足していた観点が見つかることがある）がかかるので、機能観点表の作成は状況に応じて検討してください。 テスト内容を可視化したい時や、設計を複数人で分担したい時などに作成すると費用対効果が大きいです。
シナリオテストの場合は、「1.計画書の作成③シナリオテストの観点出し」で列挙した目的に沿って、因子と水準（条件分岐）を明確にし、目的ごとにシナリオの流れがわかるフローを別途資料にまとめます。それが前述した「シナリオテスト詳細」資料になります。 シナリオテスト詳細が完成してからテストケースに落とし込むようにしましょう。
なかなかテストケース化までの道のりが長いですね……。 もちろん、全ての案件でこの通りに資料を作成する必要はなく、頭の中にさえあればいきなりテストケース化しても問題はありません。ただ、ドキュメント化することで属人化が防げる・抜け漏れや手戻りを減らすことができるというメリットはあります。
3.ナレッジの蓄積
新たな観点があった場合は、忘れずにナレッジを蓄積し、メンバーに展開するようにしましょう。（観点に限らずですが！）
例えば、弊社はweb3に特化した第三者検証会社のため、web3に関する観点を例に挙げると
同じブロックを利用した送信/受信 →2つのアカウントから同時にNFT/トークンを送信する 例）PCでアカウント1,SPでアカウント2から同時に送信ボタン押下
消費アイテムNFTのBurn →消費アイテムNFTを使用（＝消費）した場合、該当のNFTが誰も管理していないアドレスに転送されていること（＝burn）を確認する
※プロダクトの仕様にもよるので要確認
ーーといった感じです。
おわりに
コンサルティングの有無や、案件（アジャイル開発など）によってやり方は様々ありますが、今回は最もベーシックなやり方を紹介してみました。
DAIJOBUのQA進行紹介②に続く…かも！
DAIJOBU株式会社ではQAエンジニアのマネージャークラス〜メンバーまで幅広く募集をしております。
▼カジュアル面談はこちら！！
https://pitta.me/matches/UMidcjrFmWvK
▼詳しい募集要項はこちら！！
https://docs.google.com/spreadsheets/d/1ShH-KamzE8JPT8d1PlVpNarpzw9d3o0vWtKejSzqKks/edit?usp=sharing
▼応募はこちらから！！
https://daijobuinc.notion.site/DAIJOBU-b37f8f71542e4b0996a4dbe8f005e6ee
▼お問い合わせはこちらから！
https://daijobu.io/contact
▼DAIJOBUについて（コーポレートサイト）はこちらから！
https://daijobu.io