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

An incident is any event that occurs during testing that requires investigation. An incident management tool is a software tool that supports recording and tracking incidents throughout their life cycle. A QA manager of a start-up company needs to implement within a week a low cost incident management tool. The best option for this case is to manage the incidents in a spreadsheet posted on the intranet. This option has several advantages over other options:
* It is low cost, as it does not require purchasing any additional software or hardware.
* It is easy to implement within a week, as it does not require installing or configuring any complex software or hardware.
* It is accessible and transparent, as it can be viewed and updated by anyone who has access to the intranet.
* It is structured and organized, as it can store and display various information about incidents, such as identifier, summary, description, severity, priority, status, resolution, etc. The other options are not suitable for this case, as they have several disadvantages over the chosen option:
実験室の大きなボードにインシデントを記録する方法は、実験室に物理的にいない人にとってはアクセスしにくく、透明性も低いため、良い選択肢とは言えません。また、インシデントに関する必要な情報をすべて保存または表示できるとは限らないため、構造化されておらず、整理もされていません。
インシデント管理ツールを購入して導入することは、費用がかさむ上、1週間以内に簡単に導入できるものではないため、良い選択肢とは言えません。ソフトウェアやハードウェアの入手、インストール、設定に多額の費用と時間が必要になる可能性があります。
* インシデントをメールや電話で管理することは、構造化されておらず組織化されていないため、良い選択肢ではありません。混乱、矛盾、またはインシデントに関する情報の喪失につながる可能性があります。検証済み参考文献：ISTQB Foundation Level 2018 シラバス学習ガイド - Springer、第 3 章、ページ
32-33。

ソフトウェアアプリケーションを構成する様々なモジュール間で欠陥が均等に分布しているわけではなく、むしろパレートの法則に従って分布する傾向があるという事実は、「欠陥は集中する」というテスト原則によって表されます。この原則は、検出された欠陥の大部分が少数のモジュールに集中している、あるいは欠陥の大部分は少数の原因によって引き起こされていることを示しています。この原則は、最も重要またはリスクの高いモジュールのテストを優先したり、より厳密なテスト手法を適用したりすることで、テスト分析および設計活動を導くために活用できます。したがって、選択肢Cが正解です。
ISTQB認定テスター基礎レベルシラバスv4.01、セクション1.2.1、11ページ。ISTQB用語集v4。
02、16ページ。

経験に基づくテスト手法とは、ソフトウェアシステムの欠陥を発見する可能性の高いテストケースを特定し実行するために、テスターの経験、知識、直感、創造性を活用するテスト設計手法です。経験に基づくテスト手法は、ソフトウェアシステムの内部構造や実装を考慮せず、外部の動作や仕様をテストの基準とするブラックボックステスト手法では検出できなかった隠れた欠陥を検出するのにしばしば役立ちます。
経験に基づくテスト手法は、ユーザビリティ、セキュリティ、信頼性、パフォーマンスなど、明示的に指定されていない側面をカバーすることで、ブラックボックステスト手法を補完することができます。その他の記述は誤りです。理由は以下のとおりです。
経験に基づくテスト手法は、ブラックボックステスト手法で発見された欠陥の根本原因を特定するためにテスターの経験に頼るのではなく、テスター自身の洞察、ヒューリスティック、または探索的テストに基づいて欠陥の潜在的な原因を特定します。欠陥の根本原因は通常、デバッグまたは根本原因分析によって特定されます。これらは、コードまたは開発プロセスを調査して、欠陥につながったエラーを見つけて修正する活動です。
ホワイトボックステスト手法でよく用いられるテストの基準としては、ソフトウェアシステムのソースコード、設計ドキュメント、アーキテクチャ図、制御フロー図などが挙げられる。
ホワイトボックステスト手法は、ソフトウェアシステムの内部構造と実装をテストの基盤として用いるテスト設計手法であり、ステートメント、分岐、パスなどのコード要素に基づいて一定レベルのテストカバレッジを達成することを目的としています。一方、ブラックボックステスト手法では、ユーザーストーリー、ユースケース、ビジネスプロセスなどがテストの基盤として用いられます。これらは、ユーザーや利害関係者の視点からソフトウェアシステムの機能要件と非機能要件を記述するものです。
* 経験に基づくテスト手法の主な目的は、GUI ベースのテスト自動化ツールを使用して簡単に自動化できるテストケースを設計することではなく、境界値分析、同値分割、状態遷移テストなどの他のテスト手法では容易に検出できない欠陥を明らかにするテストケースを設計することです。テスト自動化とは、ソフトウェアツールを使用してテストケースを実行し、人間の介入なしに実際の結果と期待される結果を比較することです。テスト自動化は、テストの目的、テストレベル、テストツール、テストリソースに応じて、さまざまな種類のテスト手法に適用できます。ただし、テスト自動化は、特に経験に基づくテスト手法で設計されたもののように、人間の判断、創造性、または探索を必要とするテストケースでは、常に実現可能または有益であるとは限りません。参照: ISTQB 認定テスター基礎レベル (CTFL) v4.0 ソースとドキュメント:
* ISTQB認定テスター基礎レベルシラバスv4.0、第2.2.1章、ブラックボックステスト設計手法
* ISTQB認定テスター基礎レベルシラバスv4.0、第2.2.2章、ホワイトボックステスト設計手法
* ISTQB認定テスター基礎レベルシラバスv4.0、第2.2.3章、経験に基づくテスト設計手法
* ISTQBテスト用語集v4.0、経験ベーステスト技法、ブラックボックステスト技法、ホワイトボックステスト技法、テストベース、テストカバレッジ、テスト自動化