パイロット プロジェクトとは、テスト自動化ツールを大規模に実装する前に、その実現可能性、有効性、適合性を評価するために実施される小規模な実験または試験です1。
パイロット プロジェクトの目的は、テスト自動化イニシアチブのコンテキストと範囲によって異なる場合がありますが、一般的な目的は次のとおりです2。
ツールの機能とオプションに慣れるには
ツールが既存のテスト プロセスと環境にどのように適合するかを確認する ツールを使用する利点と課題を評価する ツールの実装と使用に関する標準とガイドラインを決定する ツールの展開と保守に必要なコストとリソースを見積もる したがって、この段階ではツールの使用についてすべてのテスターをトレーニングする必要はないため、オプション C はパイロット プロジェクトの有効な目標ではありません。ツールの使用についてすべてのテスターをトレーニングするのは、ツールが選択され、本格的な実装が承認され、標準とガイドラインが確立された後の方が適切です。パイロット プロジェクト中にツールの使用についてすべてのテスターをトレーニングすることは、ツールが意図した目的に適していないか効果的でないか、後で別のツールに置き換えられる可能性があるため、非効率的でコストがかかり、時期尚早です。
参照：
1: ISTQB 認定テスター基礎レベルシラバス 2018、バージョン 4.0、p. 82
2: ISTQB 認定テスター基礎レベルシラバス 2018、バージョン 4.0、p. 83
3: ISTQB 認定テスター基礎レベルシラバス 2018、バージョン 4.0、p. 84
4: ISTQB 認定テスター基礎レベルシラバス 2018、バージョン 4.0、p. 85

製品リスクには、欠陥、パフォーマンスの問題、使いやすさの問題など、ソフトウェア製品の品質と機能に影響を与える可能性のある潜在的な問題が含まれます。一方、プロジェクト リスクは、遅延、コスト超過、リソースの制約など、プロジェクトのスケジュール、予算、リソースに影響を与える可能性のあるリスクに関連します。両方の種類のリスクを理解することは、ソフトウェア プロジェクトにおける潜在的な問題を管理および軽減するために不可欠です。
参考資料: ISTQB CTFL シラバス、セクション 5.2.1「テストにおけるリスク管理」。

再テストと回帰テストに関する次の記述は正しいです。
* I) 欠陥が修正された後に再テストを実行する必要があります。再テストは、以前にその欠陥が原因で失敗したテストケースを実行して、欠陥が正常に解決されたことを確認するタイプのテストです。
欠陥が修正され納品された後、新たな障害や副作用が発生しないことを確認するために再テストを実行する必要があります。
* III) 再テストと回帰テストは、どのテストレベルでも実行できます。再テストと回帰テストは、特定のテストレベルに限定されず、状況や目的に応じて任意のレベルに適用できます。たとえば、再テストと回帰テストは、ユニットレベル、統合レベル、システムレベル、または受け入れレベルで実行できます。
* IV) 回帰テストには、機能テスト、非機能テスト、構造テストが含まれます。回帰テストは、以前にテストしたソフトウェアが変更後も正しく動作することを確認するテストの一種です。
回帰テストには、変更の範囲と目的に応じて、さまざまな種類のテストが含まれます。たとえば、回帰テストには、ソフトウェアが要件を満たしているかどうかを確認する機能テスト、ソフトウェアが品質属性を満たしているかどうかを確認する非機能テスト、ソフトウェアが設計またはコード標準を満たしているかどうかを確認する構造テストが含まれます。再テストと回帰テストに関する次の記述は誤りです。
* II) 回帰テストは、欠陥が修正された後に必ず実行する必要があります。欠陥によっては、ソフトウェアの他の部分に影響を与える可能性が低いか、影響が小さい場合もあるため、欠陥が修正された後に回帰テストが必ずしも必要というわけではありません。回帰テストは、欠陥が修正された後にのみ実行する必要があります。
* 欠陥を修正するために行われた変更によって、新しい欠陥が導入されるリスクや、既存の欠陥が発生するリスクがある場合。検証済みの参考文献: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer、第 2 章、19 ページ、第 4 章、45 ページ。

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

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