想定読者

テスト技法の選定の手がかりを知りたい人
同値分割法、状態遷移テスト、境界値分析など技法の用語の意味を知っている人
(あまり丁寧に説明していないため、知らない方にはわかりにくい記事になります。ググっていただけると幸いです)

本記事のゴール

テスト技法の選定の手がかりを提供する
11種類のテスト技法の強み・弱み・強みが発揮される場面・使いにくい場面を紹介する

テスト技法とは何か？

テストケースを作成する際に、その形式を決める技法。
例えば、あなたはアカウント登録をするためのウェブページのテストケース作成を任されたとします。
- あなたは、そのページの中の生年月日の入力項目をテストしようと思いました。ここで1900年以前の生年月日はエラーが出るという仕様だったとします。
- 境界のずれをテストしたいなら、境界値分析という技法が有効です。
- 一方、月と日という2つのパラメータの値の組み合わせに関するバグがないかテストしたいならば、ペアワイズテストという技法が有効です。
- さらに、そもそも仕様がまとめられたドキュメントすら手に入らない場合は、探索的テストという技法が役に立つかもしれません。
このように、目的やシチュエーションごとに、適切なバグの発見方法は異なります。すなわち、技法ごとにバグを発見する効率性と有効性が異なります。そのため、最適なテスト技法を選択することが大切です。
では、どの技法がどのようなシチュエーションで適切なのでしょうか？
まずは大まかに2種類に技法を分類し、それぞれの性質を見ていきましょう。そうすることで、後にそのカテゴリ内の技法に適合するシチュエーションを想像しやすくなると思います。

テスト技法の大分類

2種類に分かれます。

ブラックボックステスト技法
経験ベースのテスト技法

2つのテスト技法を1つずつ説明します。

ブラックボックステスト技法

特徴

ソフトウェアを表現するモデルをテスト設計時に作成する。
例：デシジョンテーブルや状態遷移図
これらのモデルからテスト条件を体系的に導き出す。
※テスト条件とは、システムやコンポーネントのテスト対象になりうる要素。
引用元

インプット

仕様ドキュメント(例：要件定義書)

テスト対象

システムの振る舞いに対するテスト

経験ベースのテスト技法

インプット

テスト担当者のスキルと直感
テスト対象に類似したアプリケーションや技術を触った経験

例

計画なしのクイックテスト
テストチャーターを使う計画ありのテストセッション
手順がきちんと定義されたテストセッション

特徴

ドメインナレッジをテストに適用できる
(例：ビジネスの目線でバグが出てほしくない機能を重点的にテストする)
開発者に早期にフィードバックを返せる
作成するソフトウェアについて、チームが理解を深めることに役立つ。
(例：バグが出そうな機能を探してシステムをいじることで、理解が深まる)
多様なテスト技法を適用できる
事象の再現性が低くなりがち
(例：いじってたらたまたまバグが出た！→再現手順をメモしていないので再現困難)
テストカバレッジを測定しにくい
(例：)
テストケースを自動化しにくい

適切な場面

システムの仕様に関するドキュメントが少ない場合に有効。
構造化されたアプローチが使えないケースで、その代替となりうる。
テスト時間が厳しく制限されている場合

不適な場面

詳細なドキュメントが必要なシステムでは有効性が低い場合がある。

テスト技法の選択の基準

2種類の併用がおすすめ

ブラックボックステスト技法と経験ベースのテスト技法は合わせて使うのが最も効果的です。なぜなら、これらの技法はお互いのテストで扱えない部分を補いあえるからです。
(下図参照)
-
あわせて、技法とカバレッジの関連にまつわる注意点が1つあります。上図にあるように、技法ごとに、テストケースのカバーするシステムの要素の範囲が決定されます。そのもとで、カバレッジ基準を満たすことは、システムにありうる全ての要素をテストできていることを意味しません。単にその範囲内では、その技法に基づいて追加する他のテストの要素が存在しないことを意味するだけです。

技法同士の比較の観点

技法の強みと弱み
技法を適用するプロジェクトの種類 (アジャイルorウォーターフォールor...)
情報へのアクセス (例：最新の仕様書は用意されているか？)
テスト担当者のスキル
- 経験ベースのテスト技法の場合、埋め込まれやすいバグなどについて知見のあるテストチームが必要な場合がある。

検出したいバグの種類からテスト技法を絞りこもう

ブラックボックステスト技法の絞り込み

下図で、中央に検出したいバグの種類を記しています。
その外側に技法を配置しています。
そのさらに外側に、その技法を使うために必要な情報を対応づけています。
ここから、バグの種類から技法を選び、必要な情報を用意できそうかを考えることで、技法を絞り込めるでしょう。

各技法の詳細

技法	適用できるテストレベル	併用すると良い技法	不適な場合
同値分割法	全て(特にサニティテストに役立つ)	境界値分析	×
境界値分析法	全て	同値分割法	×
デシジョンテーブルテスト	統合テスト、システムテスト、受け入れテスト	×	×
状態遷移テスト	全て	×	状態遷移テスト用ツールを使えない時
ペアワイズテスト		同値分割法などで各パラメータごとの値の数を減らす。そのあと、クラシフィケーションツリーによって、パラメータと値を特定する。	ツールを使えない時
ユースケーステスト	システムテスト、受け入れテスト。システムの振る舞いがユースケースで指定されている場合は、統合テストにも使用される	フローチャート、デシジョンテーブル	×

技法	強み	弱み
同値分割法	基本的な機能が動作していることを素早く判断する。	×
境界値分析法	×	×
デシジョンテーブルテスト	テスト対象をフローチャートやビジネスルールの形式で仕様化している場合や要件定義にてデシジョンテーブルが使用されている場合に強い	条件の組み合わせの数が膨大になる
状態遷移テスト	組み込み、web, あらゆるトランザクションソフトウェア、制御システムに適用できる	Nスイッチのカバレッジ達成のためのテストケース数が膨大になる
ペアワイズテスト	複数の値をとりうるパラメータが複数ある。それらパラメータを組み合わせてソフトウェアをテストする必要がある。だがすべての組み合わせを時間内にテストできない時に強い	少数のテストケースが全てのテストケースを代表していると仮定すること。想定されていない変数間の依存関係があると、その依存関係に潜むバグを検出できない。エンジニアでない人に、テストを削減する妥当性を説明するのが難しい。3つ以上の変数による依存関係がある場合、欠陥を検出できないリスクがある。

~~(ユースケーステストはTBD)~~

無駄なテストケースを省略するための技法

クラシフィケーションツリー図

引用元

テストケースは作れないが、テストデータの組み合わせを作成できる技法。
関心のあるパラメータと同値クラスを発見できる。つまり、重要な入力値や、無視できる入力の組み合わせを特定できる。
それにより、無駄なテストケースを省略することができる。
弱みとして、パラメータまたは同値クラスの数が増えるにつれ、図が大きくなり使いにくくなる。

経験ベースのテスト技法の絞り込み

技法	適用できるテストレベル	検出したい欠陥の種類	強み
エラー推測テスト	全て。特に統合システム、システムテスト	(推測したエラー次第で決まる。)	既存のテストケースのカバレッジを拡張できる。一般的な欠陥をテストできる。
チェックリストベーストテスト	全て。リグレッションテスト、スモークテストも含む。	(チェックリスト次第で決まる)	ソフトウェアのリリースと変更が頻繁なプロジェクトでも、テストドキュメントの準備とメンテナンスの両方の時間を削減できる
探索的テスト	シナリオベースの問題、機能境界間に存在する欠陥、ワークフロー関連の問題。性能問題、セキュリティ問題も含む。	×	"テスト対象の仕様のドキュメントを入手できない場合、他のテスト技法では十分でない状況で強い。他のテスト技法と併せて使い、追加のテストケースを作成できる。
欠陥ベース	全て。特にシステムテスト	(採用した欠陥分類法次第)	×

参考資料

ISTQBテスト技術者資格制度
Advanced Level シラバス日本語版テストアナリスト Version 3.1.1.J03