想定読者
・テストケースを作ろうとしているが、何から始めればよいか分からない人
・「テスト分析って何？」という人
本記事のゴール
・テスト分析のゴールを知る
・テスト分析の進め方を知る
前提
ソフトウェア開発プロセスにおける単語の意味を確認する。
インプットとアウトプット、という用語ピンとこない人は
以下のリンク先で説明があります。ご参照ください。
まずはテスト分析の前後の成果物を俯瞰
以下の図に大まかなテスト分析の前後の成果物をまとめている。
各用語は図の下で説明する。
テストベース
テストするシステムやアプリなどの要件を定義した資料がある。これをテストベースという。これは、テスト分析のインプットとなる。(※1)
テスト条件
テスト分析のアウトプットである。何をテストするか、の記述。ただし、テストケースよりも漠然としており、テスト計画のテスト対象よりも限定的に記述される。
例：「ユーザーが正しい資格情報を入力した場合にシステムがログインを許可する。」ことをテストする。(※2)
さらに、テスト条件がテストケース作成時のインプットとなる。
つまり、テスト分析のゴールはテスト条件を導くことといえる。
テスト分析のプロセス
さて、本題のテスト分析の中身の詳細を見ていこう。
以下の図にまとめている。なと、テスト分析のアウトプットを赤色にしている。
テストベースの欠陥を発見する
↓
テスト対象となる機能とテスト条件を導く
↓
テストベースの要素とテストする機能との間に、双方向のトレーサビリティを明記する
テストベースの欠陥を発見する
テストベースの欠陥の例：要件定義書の文章が曖昧。行間を読ませる前提の文章。1000より値が小さい時にAする。→境界値1000は含む?含まない?
(※3)
テスト対象となる機能とテスト条件を導く
テスト条件を特定し、それらをテストする優先度を設定する
テスト条件を導きだすために、テストベースはテスト目的とともに分析する。
テスト目的の例：システムが業界の規制を遵守していることを確認する。機能が正常に動くことを確認する。(※4)
テストベースの要素とテストする機能との間に、双方向のトレーサビリティを明記する
- トレーサビリティとは
個々の成果物がお互いにどのように影響し合っているかを把握できるかどうかのこと。(※5)
例：要件定義の中の要件A--テスト計画のテスト対象A--テストケースNo.15~20 のように対応づけられていること。 - トレーサビリティを明記して何がうれしいのか？
テストケースNo.1でバグが発見された際に、それに紐づいたテスト条件がわかり、それがどの要件に紐づいているのかが分かる。それにより、バグの重大性やビジネスレベルでの影響範囲などが判断できる。
テスト分析の開始基準
- テストベースはレビューに合格済みである。かつ、必要に応じて更新されている。
- 残りのテスト関連の作業を完了するための予算とスケジュールが確保されている。
テスト分析のテクニック
テスト技法を用いる
技法を使うことでテスト条件を特定しやすい。
技法の例：リスクベースドテスト
これにより、重要なテスト条件が省略される可能性を低減する。
さらに、より明確で正確なテスト条件の定義をできる。
テスト条件をステークホルダと一緒にレビューする
それにより、テストの目指すところについて共通認識を持てる。また、テストがプロジェクトのゴールと一致する作業だと理解してもらえる。
テスト条件の詳細度は階層化する
以下は詳細度の階層化を示した図。
このメリットは、抽象度の高い機能に対して、テスト範囲を十分に網羅できること。
品質リスクを参照する
品質リスクが定義済みであれば、それに対処するために必要なテスト条件を定義する。そのテスト条件とリスク項目を紐づけておき、テスト条件からリスク項目を参照できるようにする。
品質リスクとは、開発したソフトウェアを利用する際に、利用者の想定通りにソフトウェアが機能しないというリスク。(※6)
テスト分析完了後の状態
以下の状態になっているのが望ましい。
テスト分析の担当者が、そのテスト条件に対してどのようなテストケースを設計するのがよいか、分かるようになっていること。
参考資料
※1
テストベース（test Basis） | ISTQB Glossary
※2
テスト条件
※3
事例3：要件定義ドキュメントの漏れや 曖昧性の低減
※4
https://www.jasst.jp/symposium/jasst12tokai/pdf/S01.pdf
※5
トレーサビリティ確保におけるソフト開発データからの 効果検証 実施報告書
※6
品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い