パイロット プロジェクトとは、テスト自動化ツールを大規模に実装する前に、その実現可能性、有効性、適合性を評価するために実施される小規模な実験または試験です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

記述Bはテストの一般原則に反しています。なぜなら、システムや環境にテスト結果に影響を与えるような変更がない限り、同じテストセットをより頻繁に実行しても、新たな欠陥を発見する可能性は高まらないからです。入力、出力、または条件が異なる異なるテストセットを実行する方が、新たな欠陥を発見する上でより効果的です。記述A、C、Dはテストの一般原則と一致しています。
ステートメントAは、ほとんどの欠陥はシステムモジュールの小さなサブセットに見つかると述べています。これは欠陥クラスタリング原則に当てはまります。ステートメントCは、テストはプロジェクトの開始時に開始する方がよいと述べています。これは早期テスト原則に当てはまります。ステートメントDは、テストの実施方法は特定のプロジェクトの状況に基づいていると述べています。これは状況依存テスト原則に当てはまります。検証済みの参考文献：ISTQB Foundation Level 2018シラバス学習ガイド - Springer、4～6ページ。

2時間のテストセッション中にテスターの経験に基づいて作成される、台本のないテストは、テスト象限Q3に属します。テスト象限とは、テストの目的（テストがチームのサポートに重点を置くか、製品の評価に重点を置くか）とテストの基盤（テストが技術に基づくか、ビジネスに基づくか）という2つの側面に基づいてテストの種類を分類したものです。テスト象限はQ1、Q2、Q3、Q4とラベル付けされており、各象限はユニットテスト、受け入れテスト、ユーザビリティテスト、パフォーマンステストなど、異なるテストの観点を表しています。テスト象限 Q3 は、探索的テスト、ユーザビリティ テスト、ユーザー受け入れテスト、アルファ テスト、ベータ テストなど、ビジネスの観点から製品を批評することを目的とするテストの種類に対応します。 指定されたシナリオでテスターが実行するスクリプトのないテストは、テスターの経験、直感、Web アプリケーションの学習に基づいており、ユーザー インターフェイス、ユーザー満足度、ユーザー フィードバックなどの特定のユーザビリティの問題に焦点を当てているため、探索的テストとユーザビリティ テストの例です。 その他のオプションは、次の理由により不正解です。
* テスト象限 Q1 は、ユニットテスト、コンポーネントテスト、統合テスト、システムテストなど、技術の観点からチームをサポートすることを目的とするテストの種類に対応します。これらのテストの種類は通常、ソフトウェア システムのソースコード、設計、アーキテクチャ、または構成にアクセスできる開発者またはテスト担当者によって実行され、さまざまな統合レベルでソフトウェア システムの機能、品質、信頼性を検証することを目的としています。
* テスト象限 Q2 は、機能テスト、受け入れテスト、ストーリー テスト、シナリオ テストなど、ビジネスの観点からチームをサポートすることを目的とするテストの種類に対応します。これらのテストの種類は通常、ソフトウェア システムの要件、仕様、ユーザー ストーリー、またはビジネス プロセスにアクセスできるテスターまたは顧客によって実行され、ソフトウェア システムがユーザーと利害関係者の期待とニーズを満たしていることを検証することを目的としています。
* テスト象限Q4は、製品を批評することを目的としたテストの種類に対応しています。
* パフォーマンステスト、セキュリティテスト、信頼性テスト、互換性テストなど、技術的な観点からのテスト。これらのテストの種類は通常、ソフトウェア システムのツール、メトリック、標準、ベンチマークにアクセスできるテスターまたは専門家によって実行され、さまざまな条件や環境下でのソフトウェア システムの効率、セキュリティ、信頼性、互換性など、ソフトウェア システムの非機能的な側面を評価することを目的としています。
参考資料: ISTQB Certified Tester Foundation Level (CTFL) v4.0 のソースおよびドキュメント:
* ISTQB認定テスター基礎レベルシラバスv4.0、第1.3.1章「ソフトウェア開発ライフサイクルにおけるテスト」
* ISTQB テスト用語集 v4.0、テスト象限、探索的テスト、ユーザビリティテスト、単体テスト、コンポーネントテスト、統合テスト、システムテスト、機能テスト、受け入れテスト、ストーリーテスト、シナリオテスト、パフォーマンステスト、セキュリティテスト、信頼性テスト、互換性テスト

「トレーサビリティによって変更の影響を把握しにくくなる可能性がある」という記述は誤りです。テストにおけるトレーサビリティは、テストケースと要件を結び付けることで、変更の影響を把握しやすくします。この結び付けにより、要件の変更がテストケースに適切に反映され、検証されることが保証され、変更の効果的な管理と開発中のシステムまたは製品の整合性の維持につながります。（ISTQB非営利団体）（ISTQBメインウェブサイト）。参考文献：
* ISTQB認定テスター基礎レベルシラバスv4.0:
https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB_CTFL_シラバス-v4.0.pdf
* ISTQB公式サイト - CTFL認定:
https://www.istqb.org/certifications/certified-tester-foundation-level/