テスト対象を調査します。
どういった品質を確認すべきか(どういったテストをすべきか)を考えるために、テストベースや製品企画書を精読します。開発の背景や競合製品、類似製品についてできるだけ広範囲に調査します。
テストの位置づけを認識します。
テストレベル、テストサイクルにおけるこのテストの割り当て、テストチームの役割を定義します。
ステークホルダーを認識し、成果物についてステークホルダーの理解が得られるようテスト設計を進めます。
テスト対象の機能一覧を作成します。
テストベースに記載されている機能、実物の画面や動作から機能を洗い出します。
調査結果や自らの知見から「こういう製品ならこういう機能がいるはず」といった発想も盛り込みます。
調査する中で生じたテストベースへの指摘や疑問を取りまとめ、誤解を解消します。
調査結果から、どういった品質を確認したいのかを考え、そのテスト要求に基づいて分析を行います。
テスト要求によって分析方法はさまざまですが、業務分析、リスク分析、ユースケース、ペルソナ、SWOT分析などが代表的です。
分析結果に重み付けをしておくことで、後のテストアーキテクチャ設計でバランスを取る際や、限られたリソース下での優先順位付けに活用します。
分析結果からテスト観点を洗い出します。
テスト観点が思いつかない場合には、品質特性など既存のセットを糸口に考えます。
異なる分析結果から共通するテスト観点が洗い出される場合もあります。
テスト観点は、階層的ツリー図や、一覧表、マトリクス表などで書き表します。
テスト観点には「○○テスト」といった(テスト技法の名称ではない)名付けをして、後工程で扱いやすくします。
テスト詳細設計、テスト実装、テスト実施をやりやすくするために、テスト観点を整理し、このテストにおけるテストレベル、テストサイクルを考え、設計するテストの種類を抽出します。
実際には、テスト観点に対応して、以下の事柄が俯瞰して読み取れる図表を作成します。
・機能(やユースケース)とその網羅性
・テスト対象・非対象とその理由
・厚み、バランス、順序(分析結果の重み付けを利用)
・実現方法(テストの種類)
テスト観点ごとに以下について考えます。
・用いるテスト技法
・必要なテスト条件(環境、項目と値)
・自動化の対象・非対象(とその理由)
テスト詳細設計に基づき、テスト実装を行います。
・テストケース(具体的な期待結果の記述)
・テスト環境(入力元、実行環境、出力先)
・テスト手順(自動化の場合はテストスクリプトコード)
テスト実施の際にその意図が理解できるよう、どのテスト観点のために作成されたテストケースであるかが分かるようにしておきます。
テスト手順は、複数のテスト観点で共通化できていると効率的なテスト実施が可能になります。