ソフトウェアテスト用語において、故障とはソフトウェアが期待される動作から観測可能な逸脱を指します。欠陥（またはバグ）とは、ソフトウェアコードにおける故障の原因です。この場合、観測された速度低下が故障であり、アプリケーションコードにおける根本的なメモリリークが故障の原因となる欠陥です。この区別はISTQB CTFLシラバスv4.0で明確に示されており、故障（観測可能な問題）と欠陥（コードに内在する根本的な問題）が区別されています。

機能テストは、ブラックボックス動的テストの一例です。ブラックボックステスト（仕様ベーステストとも呼ばれる）は、テスト対象システムの内部構造や実装ではなく、外部の動作や機能性を考慮に入れたテストの一種です。動的テストは、テスト対象システムを様々な入力で実行し、その出力を観察するテストの一種です。機能テストは、ブラックボックス動的テストの一種で、テスト対象システムが要件や仕様に従って意図された機能を実行するかどうかを検証します。機能テストは、テストの目的や基準に応じて、さまざまなレベルと範囲で実行できます。その他のテストは、ブラックボックス動的テストの例ではありません。コード検査は、ホワイトボックス静的テストの一例です。ホワイトボックステスト（構造ベーステストとも呼ばれる）は、テスト対象システムの内部構造や実装を考慮したテストの一種です。静的テストは、テスト対象システムを実行せずに、欠陥、エラー、または標準違反がないか分析するテストの一種です。コード検査は、ホワイトボックス静的テストの一種で、テスト対象システムのソースコードの品質、可読性、保守性などを検査します。プログラムを実行してメモリリークをチェックすることは、ホワイトボックス動的テストの一例です。メモリリークとは、プログラムが割り当てたが不要になったメモリを解放できなかった場合に発生する欠陥です。プログラムを実行してメモリリークをチェックするには、メモリの割り当てと解放のメカニズム、ポインタ、参照など、プログラムの内部構造や実装に関する知識とアクセスが必要です。カバレッジ分析は、ホワイトボックス静的テストの一例です。カバレッジ分析は、テスト対象システムのコードまたは構造のうち、どの程度がテストスイートによって実行されたかを測定する手法です。カバレッジ分析には、ステートメント、分岐、パス、条件など、テスト対象システムの内部構造や実装に関する知識とアクセスが必要です。検証済みの参考文献：ISTQB® Foundation Level 2018 シラバスの学習ガイド - Springer、7 ページ。

テストケースとは、特定の目標またはテスト条件のために開発された、入力値、実行前提条件、期待される結果、および実行事後条件のセットです。テストケースは、テスト担当者またはテスト自動化ツールが実行できるテスト実行のための一連のアクションです。テストケースは、テスト実行に必要なテストウェアを準備するテスト実装アクティビティ中に指定されます。実際の結果はテスト実行中に取得され、期待される結果と比較されるため、テストケースには実際の結果は含まれません。テストケースにはテストする項目やイベントは記述されません。これらはテスト分析アクティビティ中にテストベースから導出されるためです。テストケースは、テストが必要なテスト条件または目標を指定するアクティビティであるテスト設計アクティビティ中に導出されません。検証済みの参考文献：[ISTQB Foundation Level 2018シラバス学習ガイド - Springer]、第3章、23～24ページ、第4章、34ページ。

コード内のすべての決定に対して、決定結果の少なくとも 1 つを実行すると、完全な分岐カバレッジが確実に達成されます。これは、コードの制御フロー内のすべての分岐がテスト ケースによって少なくとも 1 回実行されることを要求するテスト カバレッジ基準です。分岐は、単一のエントリ ポイントと単一の終了ポイントを持つコードの基本ブロックです。決定は、if-then-else ステートメント、switch-case ステートメント、ループ ステートメントなど、制御フローが複数の方向を取ることができるコード内のポイントです。決定結果とは、then 分岐または else 分岐、case 分岐または default 分岐、ループ本体またはループ終了など、決定から取ることができる可能なパスです。その他のステートメントは、次の理由により false です。
* 完全な分岐カバレッジを達成するために必要な最小テストケース数は、通常、完全なステートメントカバレッジを達成するために必要な数よりも多くなります。ステートメントカバレッジとは、コード内のすべての実行文がテストケースによって少なくとも1回実行されることを要求するテストカバレッジ基準です。これは、分岐カバレッジがステートメントカバレッジよりも強力な基準であるためです。分岐カバレッジはステートメントカバレッジを暗示しますが、その逆は当てはまりません。例えば、if-then-else文の場合、1つのテストケースで完全なステートメントカバレッジを達成できますが、then分岐とelse分岐の両方を実行する必要があるため、完全な分岐カバレッジを達成するには2つのテストケースが必要です。
* 完全な分岐カバレッジが達成された場合、コード内のすべての無条件分岐が必ずしも実行されているわけではありません。無条件分岐は、goto ステートメント、break ステートメント、return ステートメントなどのように、いかなる決定にも依存せず常に実行される分岐であるためです。
無条件分岐は、コードの制御フローにおける異なるパスを表していないため、分岐カバレッジ基準には含まれません。ただし、コード内の実行文であるため、文カバレッジ基準には含まれます。
* 完全な分岐カバレッジが達成されたとしても、必ずしもデシジョンテーブル内の条件のすべての組み合わせが実行されたわけではありません。これは、デシジョンテーブルとは、複数の条件とそれに対応するアクションの論理的な関係を表形式で表すテスト設計手法であるためです。各条件は、真偽、はい/いいえなど、2つ以上の値を取ることができるため、デシジョンテーブルには、コード内のデシジョン結果の数よりも多くの条件の組み合わせを含めることができます。例えば、4つの条件を持つデシジョンテーブルには16通りの条件の組み合わせを含めることができますが、対応するコードには合格/不合格など、2つのデシジョン結果しか含まれない可能性があります。デシジョンテーブル内のすべての条件の組み合わせを実行するには、条件組み合わせカバレッジなどのより強力なテストカバレッジ基準が必要です。条件組み合わせカバレッジでは、コード内の条件結果のすべての可能な組み合わせがテストケースによって少なくとも1回は実行されることが必要です。参考文献：ISTQB Certified Tester Foundation Level (CTFL) v4.0 のソースおよびドキュメント：
* ISTQB認定テスター基礎レベルシラバスv4.0、第2.3.1章「ソフトウェアの構造に基づくテストカバレッジ基準」
* ISTQB テスト用語集 v4.0、分岐カバレッジ、ステートメントカバレッジ、分岐、決定、決定結果、無条件分岐、決定表、条件組み合わせカバレッジ

レビューに関する次の記述は真実です。
I) ウォークスルーでは、レビュー会議は通常、作成者が主導します。ウォークスルーとは、事前に定義された目的と議題を持つものの、正式なプロセスや役割は設定されていないレビューの一種です。ウォークスルーは通常、レビュー対象の成果物の作成者が主導し、参加者にシナリオを案内し、フィードバックを求めます。
IV) 経営陣は技術レビュー会議にほとんど参加しません。技術レビューとは、事前に定義された目的と議題を持つものの、正式なプロセスや役割を持たないレビューの一種です。技術レビューは通常、技術的な専門知識を持つ同僚によって実施され、成果物の技術的側面を評価します。経営陣は、効果的に貢献するために必要な技術的知識やスキルを有していない可能性があるため、技術レビュー会議にほとんど参加しません。レビューに関する以下の記述は誤りです。
II) 検査は、オープンエンドのレビュー会議を特徴とします。検査とは、正式な開始・終了基準、参加者の役割と責任を定めた、定義されたプロセスに従うレビューの一種です。検査は、定められた期間と議題を伴う、構造化されたレビュー会議を特徴とします。
III) レビュー会議前の準備は非公式レビューの一部です。レビュー会議前の準備は、検査や技術レビューなどの公式レビューの一部です。準備には、以下の確認が含まれます。