コンポーネントテストはテストレベルです。テスト レベルは、いくつかの共通の特性または目的に基づいて編成および管理されるテスト アクティビティのグループです。テスト レベルは、テストの範囲とターゲット、開発のフェーズとモデル、テストに関与する関係者と役割など、さまざまな要素に基づいて定義できます。コンポーネント テスト (単体テストまたはモジュール テストとも呼ばれます) は、個々のソフトウェア コンポーネント (モジュール、クラス、関数、メソッドなど) の機能と品質を検証することに重点を置いたテスト レベル。コンポーネントのテストは、開発者またはテスターが、コンポーネントのタイプと複雑さに応じてさまざまな技術とツールを使用して実行できます。他のオプションはテスト レベルではありません。統合テストは、相互に、または外部システムと対話するソフトウェア コンポーネントのグループの機能と品質の検証に焦点を当てた別のテスト レベルです。機能テストは、テスト対象のシステムが要件または仕様に従って意図した機能を実行することを検証する、ブラックボックス動的テストの一種です。経験ベースのテストは、同様のシステム、テクノロジー、ドメイン、リスクなどの経験に基づいてテスト ケースを導き出し、選択するためのテスターの知識と直感に依存するテスト設計手法のカテゴリです。基礎レベルの 2018 シラバス - Springer、19 ページ。

インシデントレポートとは、インシデントの詳細を記録する文書です。インシデントレポートには通常、次の項目が含まれます。
識別子: インシデントレポートの一意の識別子
概要: 事件の簡潔な概要
説明: インシデントの詳細な説明 (再現手順、予想される結果と実際の結果、関連するスクリーンショットまたはログなど) 重大度: インシデントがシステムに与える影響の程度 優先度: 問題を解決するための緊急度のレベルインシデントのステータス: インシデントの現在の状態 (新規、オープン、解決済み、クローズなど)。
解決策: インシデントを解決するために取られたアクション (修正、回避策、拒否など)。質問で与えられた情報に基づいて、テスターはテスト ケース ID を除くこれらの項目をすべて書き留めることができます。テスト ケース識別子は、テスト ケースを他のテスト成果物 (テスト計画、テスト スクリプト、テスト結果、インシデント レポートなど) にリンクするために使用されるテスト ケースの一意の識別子です。ただし、テスターは探索的テストを実行しているため、インシデントに関連付けることができる事前定義されたテスト ケースはありません。探索的テストは、学習、テスト設計、テスト実行を同時に重視するテストのアプローチです。探索的テストは、テスト対象のソフトウェアを探索して欠陥を発見するために、テスターのスキル、創造性、直感に依存します。探索的テストでは、正式なテスト ケースやスクリプトは使用されませんが、テスターの行動や目的を導くテスト憲章やミッションが使用されます。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、第 3 章、32 ～ 33 ページ。第 5 章、47 ～ 48 ページ。

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

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