テスト管理者はおそらく、ソフトウェア開発の V モデルに従っていると思われます。V モデルは、4 つの開発フェーズに対応する 4 つのテスト レベルを定義するソフトウェア開発モデルです。コンポーネント テストはコンポーネント設計に対応し、統合テストはアーキテクチャ設計に対応し、システム テストはシステム要件仕様に対応し、受け入れテストはユーザー要件に対応します。仕様。V モデルは、各テスト レベルのテスト計画とテスト実行アクティビティも定義します。アジャイルは、反復的で増分的なアプローチに従うソフトウェア開発モデルであり、テストが各反復に統合され、変化する要件とフィードバックに適応します。ウォーターフォールは、開発フェーズが完了した後にテストが実行される、逐次的かつ線形なアプローチに従うソフトウェア開発モデルです。プロトタイピングは、最終製品を開発する前に、ユーザーからのフィードバックを引き出し、要件を検証するためにソフトウェアの簡易バージョンを作成するソフトウェア開発モデルです。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、18 ページ。

テスト終了基準は、特定のテスト フェーズを終了する前に満たさなければならない条件です。これらの基準は、テストの目的を達成し、テストが完了したかどうかを評価するチェックポイントとして機能します1。テスト終了基準は通常、テスト計画フェーズの出力の 1 つであるテスト計画文書で定義されます。テスト計画文書には、テスト活動の範囲、アプローチ、リソース、スケジュールが記載されています。また、テスト項目、テスト対象の機能、テストタスク、リスク、およびテスト成果物2も特定します。ISTQB Certified Tester Foundation Level Syllabus v4.0 によると、テスト計画文書には、テスト終了基準に関連する次の情報が含まれている必要があります3:
* テストの完了を評価する基準。実行されたテスト ケースの割合、達成されたテスト カバレッジの割合、発見および修正された欠陥の数と重大度、ソフトウェア製品の品質と信頼性、関係者の満足度など。
* テスト戦略の順守、テスト活動の効率と有効性、学んだ教訓と特定されたベスト プラクティス、将来の改善のための推奨事項など、テスト プロセスの改善を評価するための基準。
したがって、テスト計画文書は、記載されているテスト終了基準を見つけるのに最も適切なテスト文書です。
テスト設計仕様、プロジェクト計画、要件仕様などの他のオプションは、テスト終了基準に直接関係しません。テスト設計仕様には、特定のテスト レベルまたはテスト タイプ 3 のテスト ケースとテスト手順が記述されています。プロジェクト計画には、ソフトウェア プロジェクトの全体的な目的、範囲、前提条件、リスク、および成果物が記述されています4。要件仕様には、ソフトウェア製品の機能要件と非機能要件が記述されています5。これらの文書には、テスト プロセスの終了条件やテスト結果の評価条件が指定されていません。参考文献 = ISTQB Certified Tester Foundation Level Syllabus v4.0、ソフトウェア テストの開始基準と終了基準 | コンピューター サイエンスに関する Baeldung、ソフトウェア テストの開始基準と終了基準 - Rishabh Software、ソフトウェア テスト ライフ サイクルの開始基準と終了基準 - STLC [2022 年更新] - Testsigma ブログ、ISTQB が Certified Tester Foundation Level v4.0 (CTFL) をリリース。

欠陥レポートでは、欠陥がシステムに及ぼす影響の程度を示す属性が重大度です。重大度は、システムの機能に大きな影響を与えない軽微な問題から、システム障害を引き起こす可能性のある重大な欠陥まで、システムの動作への影響という観点から欠陥の深刻さを反映します。したがって、選択肢 B が正解です。

インシデントとは、テスト中に発生し、調査が必要なイベントです。インシデント管理ツールは、ライフサイクル全体にわたるインシデントの記録と追跡をサポートするソフトウェア ツールです。新興企業の QA マネージャーは、低コストのインシデント管理ツールを 1 週間以内に導入する必要があります。この場合の最善の選択肢は、イントラネットに投稿されたスプレッドシートでインシデントを管理することです。このオプションには、他のオプションに比べていくつかの利点があります。
* 追加のソフトウェアやハードウェアを購入する必要がないため、低コストです。
* 複雑なソフトウェアやハードウェアのインストールや設定が必要ないため、1 週間以内に簡単に導入できます。
* イントラネットにアクセスできる誰でも表示および更新できるため、アクセス可能かつ透過的です。
* 識別子、概要、説明、重大度、優先度、ステータス、解決策など、インシデントに関するさまざまな情報を保存および表示できるため、構造化され、整理されています。他のオプションは、いくつかのオプションがあるため、このケースには適していません。選択したオプションの欠点:
* 研究室の大きなボードにインシデントを文書化することは、研究室に物理的に存在しない人にはアクセスできない、または透過的にできないため、良い選択肢ではありません。また、インシデントに関する必要なすべての情報が保存または表示されていない可能性があるため、構造化または整理されていません。
* インシデント管理ツールを購入して導入することは、低コストではなく、1 週間以内に導入するのが簡単ではないため、良い選択肢ではありません。ソフトウェアまたはハードウェアの入手、インストール、構成に多大な費用と時間を費やす必要がある場合があります。
* 電子メールや電話によるインシデントの管理は、構造化または組織化されていないため、良い選択肢ではありません。インシデントに関する混乱、不一致、または情報の損失につながる可能性があります。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、第 3 章、ページ
32-33。

テスト自動化を適用する正しい理由は、反復的なテスト タスクが多数ある場合です。テストの自動化とは、ソフトウェア ツールまたはスクリプトを使用して、テスト ケースの実行、テスト結果の比較、テスト データの生成などのテスト活動を実行またはサポートすることです。テストの自動化は、必要な反復的なテスト タスクが多数ある場合に有益です。回帰テスト、パフォーマンス テスト、負荷テストなど、頻繁または一貫して実行する必要があります。テストの自動化は、時間と労力を節約し、信頼性と精度を高め、テストの範囲と効率を向上させるのに役立ちます。他のオプションは、テスト自動化を適用する正しい理由ではありません。新しいテスト自動化ツールがいつリリースされるかは、テスト自動化を適用する理由ではなく、テスト自動化ツールを選択する際の要素となります。自動化が容易であるかどうかは、テスト自動化を適用する理由ではなく、むしろテスト自動化の実現可能性を評価するための要素です。テスト自動化ツールをいつ購入できるかは、テスト自動化を適用する理由ではなく、テスト自動化のコストと利点を見積もるための要素です。検証済みの参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、10 ページ。