なぜテストケースの優先順位付けができると嬉しいか
- テストはテストケースを用いて実施する。テストケースには、入力と出力を定義するだろう。
- 例として、入力に10種類の変数があり、それぞれは2値(TRUE または FALSEのみ)をとるとする。
このとき、全ての変数の値の組み合わせは2の10乗すなわち1024通りをとる。 - テスト自動化などの工夫が困難な場面では、全ての変数の値の組み合わせをテストするのは難しくなる。そのため、優先度の高いテストケースを選択することが必要となる。
- それでは、どのようにしてテストケースの優先度付けをするのか？
方法は2つある。
- リスクベースドテスト
- 要件ベースドテスト
1.リスクベースドテストの方法は、拙文だが以下にて紹介済みなので、ここでは割愛させていただく。
ここでは、2.を主に紹介する。
要件ベースドテスト
- 要件ベースドテストとは、要件をどのぐらい網羅しているかに基づきテストケースを作成し、優先度付けするテスト。すなわち、テストケースや条件、データはシステムの要件から抽出される。そのもとで、品質リスクの高い要件やビジネス上重要な要件と紐づいたテストケースに高い優先順位を割り当てる、などを行う。
方法
方法は1つではないが、一例をあげる。
以下の3ステップを行う。
1.要件の妥当性を確認する
2.テスト条件を分析する
3.原因結果グラフからテストケースを作成する
1.要件の妥当性を確認する
- 前提として、要件の妥当性を確認しておくことが必要。つまり、曖昧でないか、プロジェクトの目的と整合しているかなどを確認する
- そのための手法が曖昧性レビュー
これは、よくある要件の欠陥をまとめたチェックリストを使うことで、要件に潜む曖昧な記述を発見し、取り除くという手法。 - 曖昧な記述の例を以下に挙げる。このような点が見つかったら、まずは修正が必要。
- プロジェクトの目標が定義されていない
- プロジェクトの目標にとって不要な要件がある/必要な要件が漏れている
- 重要なステークホルダが要件の定義に参加していない
- 非機能要件が抜けている
- 要件の記述に使われる言葉の意味が曖昧である。記述に対して解釈が複数通りありうる。
- 要件の詳細が書かれていない
- 要件同士が矛盾している
2.テスト条件を分析する
- 要件の定義されたドキュメントを読み、テスト条件を決定する。
- すでに要件に優先度がついているならば、それに沿ってテスト条件とそこから作成されるテストケースの優先度を定義する。
- 優先度がついていない場合は、要件の重要度をつける。この時にリスクベースドテストを併用するとよい。
3.原因結果グラフからテストケースを作成する
-
原因結果グラフとは、デシジョンテーブルを作成する補助的に使うテスト技法。デシジョンテーブルとは、お互いに作用する変数同士の値の組み合わせを網羅するための表である。デシジョンテーブルでは変数の値の組み合わせの数が膨大になるため、テストケースの意図が分からなくなる場合がある。その時、原因結果グラフを作成し、それをもとにデシジョンテーブルを生成することで組み合わせの数を減らすことができる。
-
原因結果グラフの構成要素
- ノードとリンクからなる。ノードには、原因ノード、結果ノードがある。
さらに、制約という要素もある。
以下の画像は筆者が作成した原因結果グラフ。電子マネーしか使えない自動販売機で、飲料を買うという要件を表現してみた。(非現実的な設定だが..)
- ノードとリンクからなる。ノードには、原因ノード、結果ノードがある。
-
作成方法
簡単に説明する。もっと具体的な方法を知りたい方はこちらが参考になる。
- 要件書などのドキュメントから、動作の原因と結果の因果関係を抽出する。
- 複数の原因を論理式で結び付けた結果を結果ノードに記載する。(論理式とは、AND, OR, など)
- さらに、それらに制約を付加する。制約の例としては、REQという前提条件を定義する制約やONEという排他的論理和の制約がある。
- 最後に、デシジョンテーブルを作成する。
このデシジョンテーブルから、テストケースを抽出する。
原因結果グラフをデシジョンテーブルに簡単に変換するために、原因結果グラフの作成にはCEGTestという無料で公開されているツールを使うのがよい。(手動でやるのは困難)
以下の画像は筆者がCEGTestを用いて原因結果グラフとデシジョンテーブルを作成した例。
※原因結果グラフは、「世界で最も難しいテスト技法」らしい。
『ソフトウェアテスト技法ドリル【第2版】テスト設計の考え方と実際』より
参考資料
曖昧性レビュー
『ソフトウェアテスト技法ドリル【第2版】テスト設計の考え方と実際』