回帰テストは、以前にテストされたソフトウェアが変更後も正しく動作することを検証するテストの一種です。回帰テストは、新たな障害や副作用を引き起こさないことを確認することで、以前に修正された欠陥の再オープンを防ぐのに役立ちます。企業に対する最初の推奨事項は、既存の回帰テスト スイートが適切であることを確認し、必要に応じてそれを拡張して、以前に修正された欠陥が後続の各ビルドで確実に再テストされるようにすることです。これは、回帰テストの範囲と有効性を向上させ、回帰の欠陥をできるだけ早く検出するのに役立ちます。既存のテスト スイートを自動化すると、回帰テストに必要な時間と労力を削減することもできますが、すべてのテスト ケースで自動化が実現可能または費用対効果が高いわけではないため、これが最初の推奨事項ではありません。最大の欠陥を含む製品モジュールを分析し、徹底的にテストして欠陥を 1 回限りの作業として修正することも、欠陥密度を減らし、それらのモジュールの品質を向上させるのに役立つ可能性がありますが、これは最初の推奨事項ではありません。再オープン時の欠陥の根本原因は以前に修正されました。最大数の欠陥を含むモジュールの開発とテストを担当するチームをトレーニングまたは交代させることも、チームのスキルやパフォーマンスの向上に役立つ可能性がありますが、すべてのチームにとって必要または適切ではない可能性があるため、これが最初の推奨事項ではありません。検証済み参考文献: [ISTQB Foundation Level 2018 Syllabus - Springer]、第 2 章、19 ページ。第 4 章、45 ページ。

テスト管理ツールは、テスト プロセスの計画、実行、監視をサポートするように設計されています。これらは、テスト ケースの管理、テストの実行、欠陥の追跡、およびテスト活動のレポート作成のための機能を提供します。ただし、オプション C の記述では、テスト管理ツールがテスト活動中のシステムの動作を監視および報告するものと説明されていますが、これは正確ではありません。テスト管理ツールは、テスト対象のシステムの動作ではなく、テスト プロセス自体に重点を置いています。
テスト データ準備ツール (A) は、実際に、テスト実行中に使用するテスト データを作成および管理します。
テスト実行ツール (B) は、テスト ケースの実行と、実際の結果と期待される結果の比較を自動化します。
テスト コンパレータ (D) は、実際の結果と期待される結果を比較し、矛盾を強調するツールです。
したがって、テスト管理ツールの機能について不正確に説明している選択肢 C が正解です。

すべての遷移を少なくとも 1 回カバーすることは、状態遷移ベースのテスト ケースの最も高いカバレッジ基準です。これにより、考えられるすべての状態変更が少なくとも 1 回テストされることが保証されます。これは、遷移をトリガーするすべてのイベントと、遷移から生じるアクションと出力が検証されることを意味します。すべての遷移を少なくとも 1 回カバーすることは、すべての状態を少なくとも 1 回カバーすることを意味しますが、その逆は当てはまりません。したがって、オプション D は最高の適用範囲基準ではありません。オプション C は、中間状態や遷移をチェックせずに、システムまたはコンポーネントの初期状態と最終状態のみをテストするため、カバレッジ基準が最も低くなります。選択肢 A は不正解です。状態遷移ベースのテスト ケースのカバレッジ基準は、対象となる遷移と状態の数に基づいて決定および比較できるためです。参照 = CTFL 4.0 シラバス、セクション 4.2.3、49 ～ 50 ページ。

探索的テストは、学習、テスト設計、テスト実行を同時に重視するテストのアプローチです。探索的テストは、テスト対象のソフトウェアを探索して欠陥を発見するために、テスターのスキル、創造性、直感に依存します。探索的テストは、未知の要件、前提条件、リスクを明らかにするのに役立つため、ドキュメントが少なく、バグの可能性が高い新しいプロジェクトに適しています。探索的テストは、文書化された要件または仕様からテスト ケースを導き出すテストのアプローチである要件ベースのテストではありません。要件ベースのテストは、明確で完全な要件が利用可能である必要があるため、ドキュメントがほとんどない新しいプロジェクトには実行できません。探索的テストは、テスト プロセスを監視および制御し、ソフトウェア製品の品質を評価するために定量的な尺度を使用するテストのアプローチである、指標ベースのアプローチではありません。指標ベースのアプローチは、品質のすべての側面を把握できるわけではなく、誤った自信や非現実的な期待につながる可能性があるため、バグが発生する可能性が高い新しいプロジェクトには効果的ではありません。探索的テストは、以前にテストされたソフトウェアが変更後も正しく動作することを検証するテストのアプローチである回帰テストではありません。回帰テストは、以前のバージョンやベースラインがない新しいプロジェクトには関係ありません。検証済みの参考文献: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer]、第 5 章、47-48 ページ。

等価分割は、ソフトウェアまたはシステムへの入力を同様の動作を示すと予想されるグループに分割するブラック ボックス テスト設計手法です。1 ～ 15 の値を受け入れる必要がある整数フィールドの場合、有効な同値クラスは 1 ～ 15 です。無効な同値クラスは 1 未満の数値と 15 を超える数値です。したがって、オプション D、「1 未満、1 ～ 15」 15 を超えると、有効な同値クラスと 2 つの無効なクラスが正しく識別され、フィールドで考えられるすべての入力シナリオがカバーされます。オプション A、B、および C は、有効な範囲を正確に取得しないか、範囲の境界を誤って指定します。