テスト技法は、テスト分析（何をテストするか）とテスト設計（どのようにテストするか）において、テスト担当者をサポートする。テスト技法は、比較的少ないながらも十分なテストケースのセットを体系的に開発するのに役立つ。また、テスト技法は、テスト担当者がテスト分析やテスト設計の際に、テスト条件を定義し、カバレッジアイテムを識別し、テストデータを識別するのに役立つ。テスト技法と対応する手段に関するさらなる情報は、ISO/IEC/IEEE 29119-4 標準、そして（Beizer 1990, Craig 2002,Copeland 2004, Koomen 2006, Jorgensen 2014, Ammann 2016, Forgács 2019）にて見つけられる。

本シラバスでは、テスト技法をブラックボックス、ホワイトボックス、経験ベースに分類している。

1.ブラックボックステスト技法（仕様ベース技法とも呼ばれる）

ブラックボックステスト技法（仕様ベース技法とも呼ばれる）は、テスト対象の内部構造を参照することなく、仕様上の振る舞いの分析に基づくものである。したがって、テストケースは、ソフトウェアの実装方法とは無関係である。結果的に実装が変わったとしても、求められる振る舞いが同じであれば、テストケースは依然として有用である。

2.ホワイトボックステスト技法（構造ベース技法とも呼ばれる）

ホワイトボックステスト技法（構造ベース技法とも呼ばれる）は、テスト対象の内部構造や処理の分析に基づくものである。テストケースはソフトウェアの設計方法に依存するため、テスト対象の設計や実装が終わってからでないと作成できない。

3.経験ベースのテスト技法

経験ベースのテスト技法は、テストケースの設計と実装にテスト担当者の知識と経験を効果的に利用するものである。これらの技法の有効性は、テスト担当者のスキルに大きく依存する。経験ベースのテスト技法は、ブラックボックスやホワイトボックスのテスト技法では見逃してしまうような欠陥も検出することができる。したがって、経験ベースのテスト技法は、ブラックボックスやホワイトボックスのテスト技法を補完するものである。

本節で説明する一般的に使用するブラックボックステスト技法は以下である：

　・同値分割法
　・境界値分析
　・デシジョンテーブルテスト
　・状態遷移テスト

1.同値分割法

同値分割法(EP)は、ある特定のパーティションのすべての要素がテスト対象によって同等に処理されることを想定して、データをパーティション（これを同値パーティションと呼ぶ）に分割する。この技法の背景にある理論は、同値パーティションから 1 つの値をテストするテストケースが欠陥を検出した場合、この欠陥は同じパーティションから他の値をテストするテストケースでも検出されるはずだというものである。したがって、各パーティションに対して 1 つのテストがあれば十分である。

同値パーティションは、入力、出力、構成アイテム、内部値、時間関連の値、インターフェースパラメーターなど、テスト対象に関連するあらゆるデータ要素について識別できる。パーティションは、連続または離散、順序性ありまたは順序性なし、有限または無限のいずれでもよい。パーティションは、重複してはならず、空でない集合でなければならない。

単純なテスト対象であれば EP は簡単だが、実際には、異なる値をテスト対象がどのように扱うのかを理解することは、困難なことが多い。そのため、パーティションに分割するのは慎重に行うべきである。

有効な値を包含するパーティションを有効パーティションと呼ぶ。無効な値を包含するパーティションは、無効パーティションと呼ぶ。有効な値と無効な値の定義は、チームや組織によって異なる場合がある。例えば、有効な値は、テスト対象が処理すべきもの、また仕様書に処理が定義されているものと解釈できる。無効な値は、テスト対象が無視または拒絶すべきもの、あるいはテスト対象の仕様書に処理が定義されていないものと解釈できる。

EP では、カバレッジアイテムは同値パーティションである。カバレッジ 100％を達成するために、この技法では、テストケースは、識別されたすべてのパーティション（無効パーティションを含む）を、少なくとも 1 回はカバーするように通過しなければならない。カバレッジは、少なくとも 1 つのテストケースによって通したパーティションの数を、識別されたパーティションの総数で割った値として測定し、パーセンテージで表す。

多くのテスト対象は複数のパーティションセットを含んでおり（例えば、複数の入力パラメーターを持つテスト対象）、テストケースはさまざまなパーティションセットからパーティションをカバーすることになる。複数のパーティションセットがある場合の最も単純なカバレッジ基準は、イーチチョイスカバレッジ（Ammann 2016）と呼ぶ。イーチチョイスカバレッジは、テストケースが各パーティションセットから各パーティションを少なくとも 1 回は通すことを要件とする。イーチチョイスカバレッジでは、パーティションの組み合わせは考慮しない。

2.境界値分析

境界値分析（BVA）は、同値パーティションの境界を確認することに基づいた技法である。したがっ
て、BVA は順序性のあるパーティションにのみ使用できる。1 つのパーティションの最小値と最大値はその境界値となる。BVA の場合、2 つの要素が同じパーティションに属している場合、それらの間にあるすべての要素もそのパーティションに属していなければならない。

BVA では、パーティションの境界値に着目する。これは、開発者が境界値に関するエラーを起こしやすいためである。BVA で発見される欠陥の代表的なものは、実装された境界が意図した位置より上や下にずれていたり、完全に省略されていたりするものである。

本シラバスでは、2 値 BVA と 3 値 BVA の 2 つのバージョンの BVA を扱っている。両者は、100%のカバレッジを達成するために通す必要がある境界ごとのカバレッジアイテムという点で異なっている。

2 値 BVA（Craig 2002、Myers 2011）では、境界値ごとに 2 つのカバレッジアイテムがある。2 つのカバレッジアイテムとは、この境界値と、隣接するパーティションに属するその最も近い隣接値である。2値 BVA で 100%のカバレッジを達成するには、テストケースですべてのカバレッジアイテム、つまり識別したすべての境界値を通過しなければならない。カバレッジは、通した境界値の数を識別した境界値の総数で割ったものとし

知名度とわかりやすさから、この節では、コードに関連する 2 つのホワイトボックステスト技法に焦点を当てる。

　・ステートメントテスト
　・ブランチテスト

一部のセーフティクリティカル、ミッションクリティカル、または高い完全性が求められる環境で使用する、より徹底したコードカバレッジを実現するためのより厳密な技法が存在する。また、より高いテストレベル（例えば、API テスト）で使用するホワイトボックステスト技法や、コードに関係ないカバレッジ（例えば、ニューラルネットワークテストにおけるニューロンカバレッジなど）もある。これらの技術については、本シラバスでは説明しない。

1.ステートメントテストとステートメントカバレッジ

ステートメントテストでは、カバレッジアイテムは実行可能なステートメントである。その狙いは、許容できるレベルのカバレッジを達成するまで、コード内のステートメントを通すテストケースを設計することである。カバレッジは、テストにより通過したステートメント数を、コードの実行可能ステートメントの総数で割った値で計測し、パーセンテージで表す。

ステートメントカバレッジが 100%になると、コード内のすべての実行可能なステートメントを少なくとも一度は通過したことになる。これは、特に欠陥のある各ステートメントを実行することを意味し、欠陥の存在を証明する故障が発生する可能性がある。しかし、あるテストケースを用いてステートメントを実行しても、すべてのケースで欠陥が検出されるわけではない。例えば、データに依存する欠陥（例えば、分母が 0 に設定された場合にのみ失敗するゼロ除算）は検出されないかもしれない。また、ステートメントカバレッジが 100%であっても、判定ロジックをすべてテストしていることは確認できない。例えば、コード内のすべてのブランチ（4.3.2 節参照）を通過していない可能性がある。

2.ブランチテストとブランチカバレッジ

ブランチとは、制御フローグラフの 2 つのノード間の制御の遷移のことで、テスト対象においてソースコードのステートメントが実行されうるシーケンスを示すものである。各制御の遷移は、無条件（つまり、直列のコード）または条件付き（つまり、判定結果）のいずれかになる。

ブランチテストでは、カバレッジアイテムはブランチであり、その狙いは、許容できるレベルのカバレッジを達成するまで、コード内のブランチを通過するテストケースを設計することである。カバレッジは、テストケースによって通したブランチの数をブランチの総数で割った値で計測し、パーセンテージで表す。

ブランチカバレッジが 100%になると、コード内のすべてのブランチ（無条件および条件付き）をテストケースで通すことになる。条件ブランチは、通常、「if...then」判定による真偽の結果、switch/case ステートメントによる結果、ループ内の終了または継続の判定に対応する。しかし、テストケースでブランチを通過しても、すべてのケースで欠陥が検出されるわけではない。例えば、コード内の特定のパスの実行を必要とする欠陥は検出されない可能性がある。

ブランチカバレッジはステートメントカバレッジを包含する。つまり、ブランチカバレッジ 100％を達成した一連のテストケースは、100%のステートメントカバレッジも達成する（しかし、その逆は成立しない）。

3.ホワイトボックステストの価値

ホワイトボックステスト技法に共通する基本的な強みは、テスト時にソフトウェアの実装そのものを考慮することで、ソフトウェアの仕様が曖昧であったり、古かったり、不完全であったりしても、欠陥の検出を容易にすることである。一方、弱点としては、ソフトウェアが 1 つまたは複数の要件を実装していない場合、ホワイトボックステストでは、結果として生じる欠落を欠陥として検出できない可能性がある（Watson 1996）。

ホワイトボックステスト技法は、（例えば、コードのドライランの際の）静的テストに使用できる。それらは、制御フローグラフでモデル化できる疑似コードやその他のハイレベルまたはトップダウンのロジックのように、まだ実行可能な状態にないコードのレビューに適している（Hetzel 1988）。

ブラックボックステストだけを実施しても、実際のコードカバレッジを測定することはできない。ホワイトボックステストは、カバレッジを客観的に測定し、テストを追加で作りカバレッジを向上

以降の項で説明する一般的に使用される経験ベースのテスト技法は次の通り：

　・エラー推測
　・探索的テスト
　・チェックリストベースドテスト

1.エラー推測

エラー推測は、エラー、欠陥、故障の発生をテスト担当者の以下の知識に基づいて予測する技法であ
る。

　・アプリケーションの過去の動作状況
　・開発者が起こしやすいエラーの種類と、そのエラーに起因する欠陥の種類
　・他の類似アプリケーションで発生した故障の種類

一般に、エラー、欠陥および故障は、入力（例えば、正しい入力が受け付けられない、パラメーターの誤りまたは不足）、出力（例えば、誤った形式、誤った結果）、論理（例えば、条件の不足、誤った演算子）、計算（例えば、誤ったオペランド、誤った計算）、インターフェース（例えば、パラメーターの不一致、互換性のない型）またはデータ（例えば、誤った初期化、誤った型）に関連することがある。

フォールト攻撃は、エラー推測を実施するための系統的なアプローチである。この技法では、テスト担当者が、想定されるエラー、欠陥、故障のリストを作成または入手し、エラーに関連する欠陥を特定したり、欠陥を露わにしたり、故障を引き起こすようなテストケースを設計する必要がある。これらのリストは、経験、欠陥や故障のデータ、またはソフトウェアが失敗する理由についての一般的な知識に基づいて作成することができる。

エラー推測やフォールト攻撃については、（Whittaker 2002, Whittaker 2003, Andrews 2006）を参照のこと。

2.探索的テスト

探索的テストは、テスト担当者がテスト対象について学習しながら、テストケースを同時に設計、実
行、評価する。探索的テストは、テスト対象についてより深く知り、注力したテストでより深く探索
し、まだテストしていない領域のテストを作成するために使う。

探索的テストでは、活動を体系的にするためにセッションベースドテストを使用する場合がある。セッションベースドアプローチでは、探索的テストをあらかじめ決められた時間枠内で行う。テスト担当者はテスト目的を含むテストチャーターに従ってテスト実行をする。テストセッションの後には、通常、テスト担当者とテストセッションのテスト結果に関心を持つステークホルダーとの間で議論を行うデブリーフィングを行う。このアプローチでは、テスト目的はハイレベルのテスト条件として扱われることがある。カバレッジアイテムはテストセッション中に識別して確認する。テスト担当者はテストセッションシートを使用して、実行した手順や発見した事象を文書化する場合がある。

探索的テストは、仕様がほとんどなかったり、不十分であったり、テストのスケジュールに余裕がなかったりする場合に役立つ。他の形式的なテスト技法を補完する場合にも効果が大きい。テスト担当者が経験豊富で、ドメインの知識があり、分析力、好奇心、創造性などの重要なスキルを高いレベルで持っている場合、探索的テストはより効果的になる（1.5.1 項参照）。

探索的テストは、他のテスト技法と併用できる（例えば、同値分割法）。探索的テストに関する詳細な情報は、（Kaner 1999, Whittaker 2009, Hendrickson 2013）に記載されている。

3.チェックリストベースドテスト

チェックリストベースドテストでは、チェックリストのテスト条件をカバーするように、テストケースを設計、実装、および実行する。チェックリストは、経験、ユーザーにとって何が重要であるかという知識、またはソフトウェアが不合格となる理由と仕組みについての理解に基づいて作成することができる。チェックリストには、自動的にチェックできる項目、開始・終了基準に適した項目、一般的すぎる項目は含めない方がよい（Brykczynski 1999）。

チェックリストの項目は、多くの場合、質問の形で表現する。各項目を個別に直接チェックできるようにすべきである。これらの項目は、要件、GUI の設定、品質特性、または他の形式のテスト条件を参照することがある。チェックリストは、機能テストや非機能テストなど、さまざまなテストタイプをサポートするために作成することができる（例：使用性テストのための 10 のヒューリスティック（Nielsen1994））。

開発者は同じエラーを避けることを学ぶので、チェックリストへ追加した内容は、時間の経過とともに徐々に効果的でなくなるものがある。また、新たに発見した重要度の高い欠陥を反映するために、新しい項目の追加を必要とする場合もある。したがって、チェックリストは欠陥分析に基づき定期的に更新すべきである。ただし、チェックリストが長くなりすぎないように注意すべきである（Gawande2009）。

詳細なテストケースがない場合、チェックリストベースドテストは、テストのガイドラインとある程度の一貫性を与えることができる。チェックリストがハイレベルである場合、実際のテストである程度のばらつきが生じる可能性があり、その結果、カバレッジが大きくなる可能性があるが、再現性は低くなる。

上記の各技術（4.2, 4.3, 4.4 節参照）は、欠陥検出に関して特定の目的を持っている。一方、コラボレーションベースのアプローチは、コラボレーションとコミュニケーションによる欠陥を回避することにも焦点を当てる。

1.ユーザーストーリーの共同執筆

ユーザーストーリーは、システムやソフトウェアのユーザーや購入者にとって価値のある機能であることを表す。ユーザーストーリーには、3 つの重要な側面があり（Jeffries 2000）、これらを合わせて「3つの C」と呼ぶ：

　・カード（Card）-ユーザーストーリーを記述する媒体（例：インデックスカード、電子なボード
上のエントリー）
　・会話（Conversation）-ソフトウェアがどのように使用されるかを説明する（文書化または口
頭）
　・確認（Confirmation）-受け入れ基準（4.5.2 項参照）

ユーザーストーリーの最も一般的な形式は、「[役割]として[達成するゴール]を達成したい、それは[役割のための結果としてのビジネス価値]を実現するためだ」、その後に受け入れ基準が続くというのである。

ユーザーストーリーの共同執筆には、ブレーンストーミングやマインドマップなどの技法を用いることができる。コラボレーションによって、ビジネス、開発、テストの 3 つの視点を考慮し、チームが提供すべきものに対する共通のビジョンを得ることができる。

優れたユーザーストーリーは、独立性（Independent）があり、交渉可能（Negotiable）であり、価値があり（Valuable）、見積り可能（Estimable）であり、小さくて（Small）、テスト可能（Testable）であるべきである（INVEST）。ステークホルダーがユーザーストーリーをテストする方法がわからない場合、ユーザーストーリーが十分に明確ではないか、ステークホルダーにとって価値のあるものが反映されていない、またはステークホルダーがテストで助けを必要としているだけであることを示している可能性がある（Wake 2003）。

2.受け入れ基準

ユーザーストーリーの受け入れ基準とは、ユーザーストーリーの実装をステークホルダーが受け入れるために満たさなければならない条件のことである。この観点から、受け入れ基準は、テストケースによって確認すべきテスト条件とみなすことができる。受け入れ基準は，通常，会話（4.5.1 項参照）の結果である。
受け入れ基準は、以下のように使う：

　・ユーザーストーリーのスコープの定義
　・ステークホルダー間の合意形成
　・ポジティブシナリオとネガティブシナリオの両方に対する説明
　・ユーザーストーリーの受け入れテスト（4.5.3 項参照）のベースを提供
　・正確な計画と見積りへの貢献

ユーザーストーリーの受け入れ基準を書くには、いくつかの方法がある。2 つの形式が最も一般的である：

　・シナリオ指向（例えば、BDD で使用される Given/When/Then 形式、2.1.3 節参照）
　・ルール指向（例えば、箇条書きの検証リストや、入出力マッピングの表形式）
ほとんどの受け入れ基準は、これら 2 つの形式のいずれかで文書化することができる。しかし、受け入れ基準が十分に定義され、曖昧さがない限り、チームは別の独自の形式を使用してもよい。

3.受け入れテスト駆動開発（ATDD）

ATDD は、テストファーストのアプローチである（2.1.3 項を参照）。テストケースは、ユーザーストーリーを実装する前に作成する。テストケースは、顧客、開発者、テスト担当者など、さまざまな視点を持つチームメンバーが作成する（Adzic 2009）。テストケースは手動で実行することもあれば、自動で実行することもある。

最初のステップは仕様化のワークショップで、チームメンバーによって、ユーザーストーリーと（まだ定義されていない場合は）その受け入れ基準を分析、議論し、記述する。ユーザーストーリーの不完全さ、曖昧さ、または欠陥は、このプロセス中に解決する。次のステップは、テストケースを作成することである。これは、チーム全体で行うことも、テスト担当者が個別に行うこともできる。テストケースは受け入れ基準に基づいており、ソフトウェアがどのように動作するかの例示として見ることができる。これは、チームがユーザーストーリーを正しく実装するのに役立つ。

先の例示とテストケースは同じであるため、これらの用語はしばしば互換的に使用される。テスト設計では、4.2 節、4.3 節、4.4 節に記載しているテスト技法を適用することができる。

典型的には、最初のテストケースはポジティブなもので、例外やエラー条件のない正しい動作を確認
し、すべてが期待通りに進んだ場合に実行される一連の活動を構成する。ポジティブなテストケースが終了したら、チームはネガティブなテストを実施すべきである。最後に、チームは非機能的な品質特性もカバーすべきである（例えば、性能効率性、使用性など）。テストケースは、ステークホルダーが理解できるように表現すべきである。典型的に、テストケースは、必要な事前条件（もしあれば）、入力、事後条件を含む自然言語の文章が含まれる。

テストケースはユーザーストーリーの特性をすべてカバーすべきであるが、ストーリーを越えるべきではない。しかし、受け入れ基準では、ユーザーストーリーで示している重要な論点の一部を詳細に記述できる。また、2 つのテストケースにユーザーストーリーの同じ特性を記述すべきではない。
テスト自動化フレームワークでサポートしている形式でキャプチャした場合、ユーザーストーリーで記述しているフィーチャーを実装する際に、開発者がサポートコードを記述することで、テストケースを自動化することができる。このようにして受け入れテストは実行可能な要件となる。