テスト技法

ソフトウェアテストの原則にありますように、全数テストは小さな開発でない限り不可能です。
そのため、リスクやテスト技法を考慮して、カバレッジの基準を満たして品質を最大限改善するように検討する必要があります。

テストアナリストは、テスト内容やリスクレベルに応じて様々なテスト技法を選択します。
JSTQBのシラバスでは、ホワイトボックステスト技法（構造ベース技法）とブラックボックステスト技法（仕様ベース技法）と経験ベースのテスト技法の3つが記載があります。

ホワイトボックステスト技法

ホワイトボックステスト技法とは、ソフトウェアの内部構造や動作を理解して、それに基づいてテストを行うテスト技法です。
コードの内部ロジックやフローの詳細を検証するため、ソースコードを直接確認しながらテストします。

制御フローテスト（パステスト）

制御フローテストとは、パステストとも呼ばれてプログラム内の実行経路（パス）を確認するテストです。
実行経路を網羅するには、ステートメントテスト・ブランチテスト・条件テスト・ループテストの技法を使用します。

ステートメントテスト

ステートメントテストは、制御フローテストでプログラム内のステートメント（命令文）を実行するテストです。
プログラム内の全てのステートメントを少なくとも一回は実行します。
ステートメントテストでは、分岐について考慮しません。

命令網羅 カバレッジ

すべてのステートメントが実行できればステートメントカバレッジ(網羅率)が100%になります。
上記フローのように、赤線を1回実行することでステートメントカバレッジの100%を達成できます。
ステートメントカバレッジは以下の計算式です。

\[ ステートメントカバレッジ = \left( \dfrac{実行されたステートメント数}{全ステートメント数} \right) \times 100 \]
補足

データ依存の欠陥はステートメントカバレッジでは検出されないことがあります。
ステートメントカバレッジを100%達成しても、判定ロジックのすべてをテストしていないことに注意が必要です。

ブランチテスト（デシジョンテスト）

ブランチテストは、制御フローテストでプログラム内の各分岐条件（ブランチ）の真または偽のケースを実行します。
分岐の真偽はどちらかを実行することで条件を達成できます。

ブランチ カバレッジ

分岐の真偽については考慮しないで、すべての分岐条件が実行できればブランチカバレッジが100%になります。
上記のようなフローでは、赤線と黄線の2回でブランチカバレッジ100%です。
ブランチカバレッジは以下の計算式です。

\[ ブランチカバレッジ = \left( \dfrac{実行されたブランチ数}{全ブランチ数} \right) \times 100 \]
補足

ブランチカバレッジを100%達成しても、すべての条件をテストしていないことに注意が必要です。
特定のパスの実行を必要とする欠陥は検出されない可能性があります。

条件テスト

条件テストは、制御フローテストで分岐条件中のandとorで結ばれた各判定条件を実行するテストです。 条件の真と偽のケースがあれば全ての条件のケースを実行します。

条件網羅 カバレッジ

分岐条件の真偽のすべてのケースを実行すると条件カバレッジが100%になります。
上記のようなフローでは、赤線と黄線と青線の3回で条件カバレッジ100%です。 条件カバレッジは以下の計算式です。

\[ 条件カバレッジ = \left( \dfrac{実行された条件数}{全条件数} \right) \times 100 \]
補足

複数条件がある場合、カバレッジを100%にするには複数の条件の組み合わせを少なくても1回は実行します。

ループテスト

ループテストは、制御フローテストでプログラム内のループ構造が正しく動作することをテストします。
ループテストでは、ループの最小回数、最大回数、境界条件をテストします。

ループテスト

ループカバレッジは以下の計算式です。

カバレッジ

ループが発生する全てのケースを実行するとループカバレッジが100%になります。

\[ ループカバレッジ = \left( \dfrac{実行されたループ数}{全ループ数} \right) \times 100 \]

データフローテスト

データフローテストは、プログラム内の変数の定義と使用の流れに注目して、変数が正しく使用されているかテストします。
データフローテストでは、データフロー図(DFD)を作成してそれに基づいてテストを実施します。
データフローでは、データが発生する実体からデータが流れて処理を行ってデータソースにデータが流れるような記述をします。

データフロー カバレッジ

データフローカバレッジは以下の計算式です。

\[ データフローカバレッジ = \left( \dfrac{実行されたデータフロー数}{全データフロー数} \right) \times 100 \]

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

ブラックボックステスト技法とは、ソフトウェアの内部構造を理解しないようにして、入力と出力に結果からテストを行うテスト技法です。
テストレベルに関係なく使用でき、機能と非機能のテストで実施できます。
形式的なテストで、仕様ドキュメントやユーザーストーリーに基づいてテスト条件を体系的に導出します。

ブラックボックステスト技法には、以下のような技法があります

同値分割法（EP）

同値分割法は、ブラックボックステスト技法で入力する領域の結果が同じになるパーティション（同値パーテーション）に分割して、同値になるパーティションの代表値だけをテストをします。
有効なデータからなる集合の有効同値パーティションと無効のデータからなる集合の無効同値パーティションで分けられます。
同値パーティションは、順序の有無、離散、連続、無限、有限、単一の代表地をセットします。
代表値のみですので、テスト数を削減できます。

月を春夏秋冬でテストする場合、同値テストであれば次のように考えます。

無効同値データ(0以下) 有効同値データ(春：3,4,5) 有効同値データ(夏：6,7,8) 有効同値データ(秋：9,10,11) 有効同値データ(冬：12,1,2) 無効同値データ(13以上)

各数値の領域から春の代表値、夏の代表値、秋の代表値、冬の代表値と無効同値データの代表値を利用してテストをします。
無効同値パーティションは、0以下と13以上が該当しますが、この2つの代表値を決定します。

マイナスを利用したり、条件付きで無効値をテストから除外する場合もあります。
また、無効値は複数の条件が発生する場合があります。例えば本テストであれば数値以外のデータを利用したりする場合もあります。
その場合、そのテストも実施する必要がありますので条件を足していきます。

カバレッジ

カバレッジは、各同値パーティションの代表値を全て取得して、その数を実行したパーティションの数で割ることによって算出できます。
複数のパラメーターがある場合、リスクに応じてシンプルなカバレッジの組み合わせを選択します。

無効な同値パーティションはリスクに応じて個別にテストする必要があります。
先ほどの例であれば、無効値は「0」「13」「a」など3つを無効パーテーションとしてテストします。
同値分割法カバレッジは以下の計算式です。

\[ 同値分割法カバレッジ = \left( \dfrac{実行されたパーティション数}{全パーティション数} \right) \times 100 \]

複数のパーティションセットがある場合、カバレッジの測定の基準に使用されるものとしてイーチチョイスカバレッジがあります。

補足

同値分割法は、すべてのテストレベルで適用できます。
単一のパーティション内の複数の値をテストしても、カバレッジの割合は増えません。
正、負、0の定義には気を付ける必要があります。

境界値分析（BVA）

境界値分析は、入力領域の境界となる値と隣接する値に対してテストします。
境界付近には、欠陥が頻出することを想定してテストを実施します。
境界値分析には、2つの値を使用する2値境界テストと3つの値を使用する3値境界テストがあります。

月をテストする場合、境界値分析であれば次のように考えます。

無効同値データ(0以下) 有効同値データ(1,2,3,4,5,6,7,8,9,10,11,12) 無効同値データ(13以上)

2値の境界値では、無効のすぐ近くにある有効な値が境界値で、境界値とすぐ近くの無効な値の2つを利用します。
そのため、境界値が「1」の場合はその値とすぐ下の値である「0」、境界値が「12」の場合はその値とすぐ上の値である「13」が対象です。
月の始まりの境界値として「0,1」、月の終わりの境界値として「12,13」の4つをテストします。

すぐ近くという表現は、単位によって異なりますので注意が必要です。
整数であればいいのですが、少数1桁の場合なら月の始まりの境界値は「1」と「0.9」となります。

3値の境界値では、2値と境界値は同じで、すぐ上とすぐ下の値を2つ利用します。
そのため、月の始まりの境界値の確認として、「0,1,2」と月の終わりの境界値として「11,12,13」の6つをテストします。

カバレッジ

カバレッジは、2値境界または3値境界の境界数を全て確認します。
境界値カバレッジは以下の計算式です。

\[ 境界値カバレッジ = \left( \dfrac{実施した境界値の数}{識別した境界値の数} \right) \times 100 \]
補足

境界値分析は、すべてのテストレベルで適用できます。
同値分割法と一緒に利用することが多くなり、同値分割法の制限や注意事項も対象になります。

デシジョンテーブル（決定表）

デシジョンテーブルは、複数の条件とその組み合わせの結果を決定表に落とし込み、それに基づいてテストをします。
条件の組み合わせのことをルールといいます。
デシジョンテーブル（決定表）は、組み合わせが網羅されるように記載します。

例えば、テーマパークに入場するというテストをすることになり、性別・年齢・祝日・割引券の4つの因子があったとします。
性別は2つ(男性と女性)、年齢は3つ（子供、大人、高齢者）、日は2つ（平日と祝日）と割引券も2つ（有りと無し）とします。
その場合のデシジョンテーブルは以下のようになります。
※記載しているのは男性の平日料金の一部のみです。

パラメータ 値 1 2 3 4 5 6
条件 性別 男性 T T T T T T
女性 F F F F F F
年齢 子供 T T F F F F
大人 F F T T F F
高齢者 F F F F T T
日 平日 T T T T T T
祝日 F F F F F F
割引券 有 T F T F T F
無 F T F T F T
結果 平日料金 2,000円 - - X - - -
1,900円 - - - X - -
1,400円 - - - - X -
1,300円 - - - - - X
1,200円 X - - - - -
1,100円 - X - - - -
祝日料金 3,000円 - - - - - -
2,900円 - - - - - -
2,400円 - - - - - -
2,300円 - - - - - -
2,200円 - - - - -
2,100円 - - - - - -

表の条件で、「T」は条件が真実なことを「F」は条件が真実でないことを意味します。
表の結果で、「X」がその結果になることで、「-」はその結果にならないことを意味します。
空白やその他の表記を使うこともあります。 カバレッジ

デシジョンテーブルのカバレッジ基準は、各ルールを1つのテストケースでカバーすることです。
拡張指定デシジョンテーブルでは、境界値分析と同値分割法を組み合わせて使用することができます。
順序付けられた同値パーティションが条件に含まれている場合、境界値はルールやテストケースの追加項目として使用されます。
デシジョンテーブルカバレッジは以下の計算式です。

\[ デシジョンテーブルカバレッジ = \left( \dfrac{実行されたルール数}{全ルール数} \right) \times 100 \]

デシジョンテーブのテストケースは、条件であるパラメータ数を明確にします。
テストケースは、性別(2) × 年齢(3) × 日(2) × 割引券(2) = 24通りとなります。
全ての条件とパラメータの組み合わせを完全なデシジョンテーブルといいます。

全数を実施せずに重複する条件やパラメータを削減する折りたたまれたデシジョンテーブル（簡単化）もあります。
ルールの条件で行えない場合にそのルールを削除します。

テストケースと工数が削減できますが、削減した分の欠陥が検出できない可能性がでます。
テストアナリストはテストマネージャーと連携して、リスクレベルに応じて折りたたまれたデシジョンテーブルを選択するか検討します。

補足

デシジョンテーブルテストは、コンポーネントテスト、統合テスト、システムテスト、受け入れテストで適用できます。
フローチャートやビジネスルールの場合に有効です。
デシジョンテーブルではルール数が多くなること（指数関数で増加）がありますので、条件の組み合わせでテスト可能か確認する必要があります。

原因結果グラフ

原因結果グラフは、対象となるものの原因と結果を結びつけたグラフを作成し、それを基にデシジョンテーブルやテストケースなどに落とし込んでテストを行います。
原因結果グラフを作成することで、機能や処理がが視覚的になります。

原因結果グラフは対象が大きいと作成が難しかったり、他の手法よりも時間と手間がかかります。 また、表記法も統一する必要があります。

例えば、「チケット券売機では、当日に購入して発券したり、事前に支払って発券できる予約発券がある。当日の購入では割引券を利用して割引価格にすることが可能である。」という対象があった場合は以下のように記述します。

原因結果グラフ

「∧」のandや「∨」のorの記号や「￢」のNotの記号を利用して表現します。

カバレッジ

カバレッジは、原因と結果の全てのパスです。 各カバレッジの詳細は以下になります。

\[ 原因結果グラフカバレッジ = \left( \dfrac{実施したパス数}{原因と結果の全パスの総数} \right) \times 100 \]

ドメイン分析

ドメイン分析は、入力データを特定の範囲（ドメイン）に分類して、その範囲でテストします。
ドメインでは複数の変数を利用して、ドメインを分類することで、異なる入力条件を網羅できます。

ドメイン分析マトリクスを作成して網羅します。

状態遷移テスト

状態遷移テストは、現在の状態からイベントやアクションが発生して次の状態に遷移することをテストします。
有効な状態に遷移するケースと無効な状態に遷移するケースを確認します。

状態遷移図は、状態を円で表示して線で遷移を記載します。
矢印の近くのラベルでイベント(イベントの後に「/」でアクションも記載することが可能)を記載します。
映画やカフェなどの席の状態遷移図の例を以下に記載します。

状態遷移

以下のような状態表を記載する場合もあります。

現在の状態 イベント 条件 アクション 次の状態
空席 予約 - - 予約済
予約済 使用 - - 使用中
予約済 キャンセル - - 空席
使用中 使用終了 - - 清掃中
清掃中 清掃終了 - - 空席
清掃中 修復必要 - - 修復中
修復中 修復完了 - - 空席

現在の状態から次の状態に1つ遷移することを0スイッチといいます。
現在の状態から次の状態とその次の状態に2つ遷移することを1スイッチといいます。
以降もN（遷移数-1）スイッチとして定義できます。

本表の0スイッチカバレッジを達成するテストケースは、8つです。 「-」は、無効なテストケースとして識別できます。

カバレッジ

カバレッジは、滞在する状態とその状態からの全ての遷移を確認します。
状態遷移のカバレッジには、全状態カバレッジと有効遷移カバレッジと全遷移カバレッジがあります。
各カバレッジの詳細は以下になります。

全状態カバレッジの以下の計算式です。

\[ 全状態カバレッジ = \left( \dfrac{通過した状態}{状態の総数} \right) \times 100 \]

有効遷移カバレッジの以下の計算式です。

\[ 有効遷移カバレッジ = \left( \dfrac{通過した有効な遷移の数}{総数} \right) \times 100 \]

全遷移カバレッジの以下の計算式です。

\[ 全遷移カバレッジ = \left( \dfrac{通過した有効および無効な遷移の数}{総数} \right) \times 100 \]
補足

状態遷移テストは、すべてのテストレベルで適用できます。
ユーザーインターフェースが含まれる場合、様々な画面を状態として表すことが多く、組込みソフトウェアではハードウェアの状態に依存します。

組合せテスト

組み合わせテストでは、すべての組み合わせをテストします。
因子と水準が多いとその分テストが多くなってしまいます。
例えば、テーマパークに入場するというテストをすることになり、性別・年齢・祝日・割引券の4つの因子があったとします。
性別は2つ(男性と女性)、年齢は3つ（子供、大人、高齢者）、日は2つ（平日と祝日）と割引券も2つ（有りと無し）とします。

\[ 24通り = 性別(2通り) \times 年齢(3通り) \times 日(2通り) \times 割引券(2通り) \]

全てをテストする時間が掛けれない場合もあります。
オールペアテストなどのテスト技法を仕様します。

ペアワイズテスト（オールペアテスト）

ペアワイズテストとは、欠陥は1つまたは2つの因子の組み合わせで起こるという経験から因子と水準を1回またはN回の組み合わせにしてテストします。
そのため、組み合わせてテストに比べるとテスト数が少なくてすみます。

1回の因子の組み合わせを1ペアワイズといい、回数をNとしてN回の因子の組み合わせをNペアワイズといいます。
ペアワイズテストで実施すると組合せテストでは24通りだったのが、以下のように2ペアワイズでは6通りになります。
1ペアワイズの場合は、3通りになります。

因子 水準 テストケース
No. 1 No. 2 No. 3 No. 4 No. 5 No. 6
性別 男性 1 1 1 0 0 0
女性 0 0 0 1 1 1
年齢 子供 1 0 0 1 0 0
大人 0 1 0 0 1 0
高齢者 0 0 1 0 0 1
日 平日 1 1 0 1 1 0
祝日 0 0 1 0 0 1
割引券 有 1 0 0 1 0 0
無 0 1 1 0 1 1

因子と水準の各組み合わせで最低限のテストケースを実施して効率的な欠陥を検出します。

補足

コンポーネント統合テスト、システムテストおよびシステム統合テストのテストレベルでテスト可能です。
ペアワイズ テストでは、3つ以上の変数が相互作用するシステム障害を検出できない場合があります。

カバレッジ

1ペアワイズでの計算は、1番目に長い因子数で求めることができます。
2ペアワイズでの計算は、1番目に長い因子数と2番目に長い因子数を掛けることで求められます。

\[ Nペアワイズカバレッジ = \left( \dfrac{テスト実施}{Nワイズの全てのペア} \right) \times 100 \]

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

クラシフィケーションツリーは、組み合わせテストを支援するため、因子と水準の組み合わせを視覚的に表現してテストの網羅性を高めます。
視覚的に表現するのにクラシフィケーションとクラスを利用してテスト項目になる組み合わせテーブルを作成して可視化します。

クラシフィケーションツリーでは、同値分割法、境界値分析、ペアワイズテストをサポートしており、その技法により欠陥の検出は異なってきます。
チケットを購入するテストで、年齢（子供、大人）、日（平日と祝日）と割引券（有りと無し）があった場合は以下になります。

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

チケット購入がトップノート（Root）で年齢・日・割引券がクラシフィケーションで、子供・大人・平日・祝日・有・無がクラスです。

カバレッジ
\[ クラシフィケーションツリーカバレッジ = \left( \dfrac{テスト実施}{組み合わせテーブル内のすべての項目} \right) \times 100 \]
補足

クラシフィケーションツリーはクラシフィケーションとクラスが多くなると図が大きくなり複雑になってしまいます。
多くならないようにするためにペアワイズや同値分割法などを利用して入力パラメータの数を減らすことができます。
組み合わせのテストケースは作成できるのですが、テストを実施した結果や期待結果などを記載するため別途テストドキュメントが必要になることがあります。

ユースケーステスト

ユースケーステストは、システム全体に対して一連のユースケースを実施してテストをします。
ユースケースとは、アクター（ユーザやハードウェアなど）とコンポーネントまたはシステムとの間の処理を可視化したものです。
以下のような図がユースケースです。

ユースケース図

ユースケーステストでは、基本的な振る舞いで誤った処理、代替およびエラー処理の振る舞いの問題、不適切なエラーメッセージなどを欠陥として検出できます。
ユースケーステストは、以下の流れでテストします。

ユースケーステストのテストシナリオを先ほどのユースケースで作成すると以下のようになります。

項番 シナリオ 対象 テストケース 期待結果 結果 実施者 実施日
1 予約 基本 該当の空席に予約を行う 該当の席が予約になること
2 予約 エラー AユーザとBユーザが該当の空席に同時に予約を行う どちらかのユーザが予約を行て、どちらかのユーザが予約が行えないこと
1 予約変更 基本 予約の変更を行う 予約の変更が行えること
カバレッジ

ユースケースはガイドラインとして捉えるべきで、テストすべき内容について完全に定義されているわけではありません。
ユースケースだけでは、テストすべき内容を完全に定義できない場合がありますのでフローチャートやデシジョンテーブルなど他のモデルも活用することが推奨されます。
ユースケースの許容可能な最小カバレッジは、基本的な振る舞い代替およびエラー処理の振る舞いをカバーします。

\[ ユースケーステストカバレッジ = \left( \dfrac{テスト実施}{基本的な振る舞いの数 + 代替およびエラー処理の振る舞いの数} \right) \times 100 \]
補足

統合テスト、システムテストレベルおよび受け入れテストレベルでテスト可能です。

経験ベースのテスト技法

経験ベースのテスト技法とは、テスト担当者の経験・知識・直観を利用して対蹠的またはヒューリスティックなアプローチでテストします。
テストレベルに関係なく使用でき、機能と非機能のテストで実施できます。

ドキュメントが整備されていない場合やテスト時間の制約がある場合に有効です。
テスト担当者の過去の経験や知識を活用できて、開発者へのフィードバックも早期に行えます。

カバレッジの評価が難しくテストドキュメントなどの作成も最低限となりますので、プロジェクトによっては利用できない場合もあります。

エラー推測

エラー推測は、開発者が起こしそうなエラーを推測したテストケースを作成してテストを実施する非公式なテスト技法です。
テストアナリストの経験や能力に左右されてしまい、テストケースもハイレベルなテストケースに近くなるので再現性が低くなります。
エラー推測を実施するための系統的なアプローチとして、フォールト攻撃があります。
フォールト攻撃は、想定されるエラーや欠陥を特定して、テストケースを設計します。

補足

すべてのテストレベルで使用できます。

カバレッジ

カバレッジを評価するのが難しいが、欠陥分類法を使用して求めることができます。
欠陥分類法を使用しない場合は、テスト担当者の経験と知識や利用可能な時間によりカバレッジが制限されます。
欠陥分類は、期待する詳細度を定義して、ベースとして使用する欠陥の分類を選択して共通の原因を定義します。

カバレッジ
\[ エラー推測カバレッジ = \left( \dfrac{分類アイテムの実施数}{基本的な振る舞いの数 + 分類アイテムの総数} \right) \times 100 \]

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

チェックリストベースドテストは、標準やテスト担当者の経験からチェックリストなどを作成してそれを基にテストを実施するテスト技法です。
アジャイルソフトウェア開発では、チェックリストはユーザーストーリーの受け入れ基準で実施されます。

チェックリストには、自動的にチェックできる項目、開始・終了基準に適した項目を記載し、一般的すぎる項目は含めないようにします。
チェックリストへ追加した内容は、開発者が欠陥について学習していくため時間が経過するとテストの効果が薄れていきます。
チェックリストは、ハイレベルになってしまいますので実施者によって結果が異なってしまう可能性があります。

カバレッジ

チェックリストベースのカバレッジは、チェックリストアイテムの総数を実施数で割って求めます。

\[ チェックリストベースドテストカバレッジ = \left( \dfrac{チェックリストアイテムの実施数}{チェックリストアイテムの総数} \right) \times 100 \]

分類アイテムの実施数は、結果の合否は関係ありません。

補足

すべてのテストレベルで使用できます。
形式的なテストの開始前と、テスト実施後に行うと効果的です。

探索的テスト

探索的テストは、テスト担当者がテストケースを作成せずに重要と判断した箇所と対象に重点を置きテストを実施する非公式なテスト技法です。
探索テストには3つの種類があります。

探索的テストでは、テスト担当者がテストの計画・設計・実行・学習・結果の報告を同時に行います。
結果の報告では、レポート（テストを実施した結果）を作成し、次のセッションを計画します。

補足

探索的テストでは、軽量なドキュメントやハイレベルのテストケースなどでテスト担当者の技量でテストを実施するためでテスト手順が不明確認になりやすいです。
そのため、故障の再現が難しいため、テストツールのキャプチャ/プレイバック機能などを使用して手順を記録していくのが一般です。

カバレッジ

テストチャーターは、タスク・目的・成果物のために設計して、テストセッションを計画します。 テストセッションでは、特定の欠陥タイプや問題点に焦点を当てて臨機応変にテストします。

タイミングテスト

タイミングテストは、テスト担当者が障害が発生しそうなタイミングを狙ってテストするテスト技法です。
具体的には、リアルタイムシステム、パフォーマンステスト、タイミング依存する機能などがあります。

補足

タイミングテストの例として、システムが一定の時間内にデータを処理しなければならない場合、その時間内に処理が完了するかどうかをテストします。

カバレッジ
\[ タイミングテストカバレッジ = \left( \dfrac{タイミング条件のテスト実施数}{識別された全タイミング条件の数} \right) \times 100 \]

欠陥ベースドテスト

欠陥ベースドテストは、既知の欠陥タイプを基に欠陥に焦点した一覧のテストケースを作成してテストします。
一覧には、欠陥のタイプ、根本原因、故障の兆候などが含まれます。

補足

すべてのテストレベルで使用できますが、一般的にはシステムテストで実施します。

カバレッジ

欠陥ベースのテスト技法は、カバレッジ基準を提供し、有用なテストケースを識別します。 カバレッジアイテムは、欠陥一覧に応じて構造要素、仕様要素、使用シナリオなどがあります。 欠陥ベースのテスト技法のカバレッジ基準は、一般的なルールのみが与えられ、具体的な決定は裁量に任されるため、ブラックボックステスト技法に比べて体系的ではありません。 カバレッジの基準は、すべてのテストセットが完全であることではなく、有用なテストケースがこれ以上ないことです。

\[ 欠陥ベーステストカバレッジ = \left( \dfrac{実施したテスト数}{識別された全欠陥のテスト数} \right) \times 100 \]

テスト技法の組み合わせ

ブラックボックスの技法と経験ベースのテスト技法は組み合わせて使用することで効果的にテストが実施できます。
テストアナリストは、テストベース・テストの実施内容・テスト期間・各テスト担当者のスキルを考慮してこれらを組み合わせてテストを設計します。

コラボレーションベースのテストアプローチ

コラボレーションベースのテストアプローチとは、チーム全体がで品質向上に取り組み信頼性の高いソフトウェアを提供する手法です。 各テスト技法は、欠陥を検出する目的があります。

ユーザーストーリー

ユーザーストーリーとは、ユーザーに基づいて価値のある機能や要件を記述したものです
そのため、ユーザーストーリーのテストではチームで確認する機能や非機能の特性を小さく分けて記述していきます。

ユーザーストーリーには、「3つのC」と呼ばれる重要なものがあります。 「3つのC」は以下です。

INVESTが定義されているユーザーストーリーが優れたものです。
INVESTは、独立性（Independent）の「I」、交渉可能（Negotiable）の「N」、価値（Valuable）の「V」、見積り可能（Estimable）の「E」、小ささ（Small）の「S」、テスト可能（Testable）の「T」の頭文字を取ったものです。

← リスクベースドテストの問題
テスト技法の問題 →