包括的かつ詳細な説明：
静的テスト（A）は、要件定義やコードレビューといった実行不可能な成果物（I）に適用されます。また、欠陥検出（III）にもつながり、ソフトウェアを実行せずに欠陥を直接発見（IV）します。選択肢B、C、Dは、静的テストをパフォーマンス測定（II​​）や動的テストの側面（V）と誤って関連付けています。

典型的なテスト リーダーの最も重要なタスクは、プロジェクト マネージャーとテスト戦略を調整することです。テスト戦略とは、プロジェクトまたは組織のテストに対する一般的なアプローチと目的を定義する高レベルのドキュメントです。テスト リーダーは、プロジェクトの目標と制約に沿ってテスト戦略を定義、文書化、伝達、実装する責任があります。また、テスト リーダーは、テスト戦略が実行可能で、効果的かつ効率的であることを確認するために、プロジェクト マネージャーやその他の関係者と調整する必要もあります。その他のオプションは、典型的なテスト リーダーの最も重要なタスクではありません。テストを自動化するのは、テスト自動化エンジニアまたはテスト自動化スペシャリストの仕事です。テスト データの準備と取得は、テスト アナリストまたはテスト エンジニアの仕事です。テスト環境をセットアップするのは、テスト環境マネージャーまたはテスト環境スペシャリストの仕事です。検証済みの参考文献: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer、13 ページ。

振り返りはアジャイルプラクティスの重要な部分であり、プロセスの改善点を特定し、それらを効果的に実装する方法を決定することを目的としています。参加者は、どのような改善が可能かだけでなく、ソフトウェア開発ライフサイクルを含むプロジェクトの文脈の中で、それらの改善点をどのように統合し、維持していくかについても議論する必要があります。これにより、ISTQB CTFLシラバスの記述Dが正確になります。

この図は、状態遷移テストを用いた欠陥のライフサイクルを示しています。状態遷移テストは、イベントや条件に応じてシステムがある状態から別の状態へどのように遷移するかをモデル化する手法です。図には6つの状態（S0からS5）と7つの遷移（T0からT6）が示されています。図に示されている状態遷移の正しい順序は、S0->S1->S2->S3->S5->S1->S2->S3です。この順序は、以下のシナリオを表しています。
* S0: 欠陥はまだ検出されていません（初期状態）。
* T0: テストにより欠陥が検出されます（イベント）。
* S1: 欠陥が報告され、登録されます (状態)。
* T1: 不具合は修正のために開発者に割り当てられます (イベント)。
* S2: 欠陥は開発者によって修正中です (状態)。
* T2: 開発者が欠陥を修正し、新しいバージョンを配信します (イベント)。
* S3: テストによって欠陥が検証されます (状態)。
* T5: テストで欠陥が修正されたことを確認できませんでした (イベント)。
* S5: 欠陥はテストによって拒否されます (状態)。
* T6: 不具合は修正のために開発者に再割り当てされます (イベント)。
* S1: 欠陥が報告され、登録されます (状態)。
* T1: 不具合は修正のために開発者に割り当てられます (イベント)。
* S2: 欠陥は開発者によって修正中です (状態)。
* T2: 開発者が欠陥を修正し、新しいバージョンを配信します (イベント)。
* S3: 欠陥はテストによって検証される（状態）。その他のシーケンスは、図に示されている遷移に従っていないため、誤りです。検証済みの参考文献: [ISTQB Foundation Level の学習ガイド]
2018年度シラバス - Springer]、第4章、40-41ページ。

探索的テストとは、学習、テスト設計、テスト実行を同時に重視するテスト手法です。探索的テストでは、テスト担当者のスキル、創造性、そして直感に頼ってテスト対象のソフトウェアを探索し、欠陥を発見します。探索的テストは、未知の要件、前提、リスクを発見するのに役立つため、ドキュメントが少なくバグ発生の可能性が高い新規プロジェクトに適しています。探索的テストは、文書化された要件や仕様からテストケースを導出するテスト手法である要件ベーステストとは異なります。要件ベーステストは、明確かつ完全な要件が必要となるため、ドキュメントが少ない新規プロジェクトには適していません。探索的テストは、定量的な指標を用いてテストプロセスを監視・制御し、ソフトウェア製品の品質を評価するテスト手法であるメトリックベースアプローチとは異なります。メトリックベースアプローチは、品質のあらゆる側面を捉えることができず、誤った自信や非現実的な期待につながる可能性があるため、バグ発生の可能性が高い新規プロジェクトには効果的ではありません。探索的テストは回帰テストとは異なります。回帰テストは、以前にテストされたソフトウェアが変更後も正常に動作することを検証するテスト手法です。回帰テストは、以前のバージョンやベースラインがない新しいプロジェクトには適していません。検証済み参考文献：[ISTQB Foundation Level 2018シラバス学習ガイド - Springer]、第5章、47～48ページ。