障害の原因を分析して除去することはテストの目的ではなく、開発または保守の作業です。障害とは、テスト対象のシステムの予期または指定された結果から逸脱するイベントまたは動作です。障害は、ソフトウェア コード、設計、または仕様のエラー (間違いまたは障害とも呼ばれます) によって引き起こされます。障害の原因を分析して除去することは、ソフトウェア コード、設計、または仕様内のエラーを特定して修正するプロセスであり、デバッグまたは欠陥解決とも呼ばれます。障害の原因を分析して除去することは、欠陥を発見または報告することを目的とするのではなく、欠陥を修正または予防することを目的としています。他のオプションはテストの目的です。欠陥の発見は、ソフトウェア製品の品質と信頼性の向上に役立つため、テストの主な目的の 1 つです。意思決定のための情報を提供することは、意思決定とリスク管理のサポートに役立つため、テストのもう 1 つの目的です。ソフトウェア製品がその要件、顧客またはユーザーのニーズと期待を満たしていることを確認するのに役立つため、ソフトウェアの品質レベルについて自信を得ることがテストのもう 1 つの目的です。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、3 ページ。

IEEE 829 標準はテスト文書に広く使用されている仕様ですが、必須でも普遍的でもありません。ほとんどのテスト文書化体制は、特定の状況や組織に合わせて変更を加えながら、ある程度この仕様に従っています。この標準は、逸脱に対して経営陣、マーケティング、開発部門の承認を必要とせず、プロジェクトの種類 (軍事市場または消費者市場) にも依存しません。また、この規格は、実際の内容や品質基準ではなく、一般的な概要と形式のみを提供するため、高品質のテスト文書化体制を保証するものではありません。検証済みの参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、16 ページ。

インシデントとは、テスト中に発生し、調査が必要なイベントです。インシデントレポートとは、インシデントの詳細を記録する文書です。逸脱を記録する前にテスターが実行すべき次のステップは、報告する前にインシデントを再現してみることです。これは、インシデントに再現性があり、ランダムまたは外部要因によって引き起こされたものではないことを確認するのに役立ちます。これは、インシデントを再現する手順、予想される結果と実際の結果、インシデントの重大度と優先度、インシデントを説明できるスクリーンショットやログなど、インシデントに関する詳細情報を収集するのにも役立ちます。問題の原因となっているコード断片を特定することは、通常、インシデントレポートを受け取った後に開発者によって実行されるデバッグ作業であるため、逸脱を記録する前にテスターが実行すべき次のステップではありません。開発者に電子メールを送信してバグを報告しないことは、逸脱を記録する前にテスターがとるべき次のステップではありません。これは、混乱、不一致、または情報の損失につながる可能性のあるインシデントを伝達する非公式で構造化されていない方法だからです。何もせずにそのままインシデントを報告することは、逸脱を記録する前にテスターが実行すべき次のステップではありません。これは、インシデントの調査と解決を妨げる不完全または不正確なインシデントレポートにつながる可能性があるためです。検証済み参考文献: ISTQB Foundation Level 2018 Syllabus の学習ガイド - Springer、第 3 章、32 ～ 33 ページ。

受け入れテストは、ソフトウェア製品が合意された受け入れ基準を満たしており、納品に耐えられることを確認するために実行されるテストのレベルです。受け入れテストは、ソフトウェア製品の主な関係者である顧客またはシステム ユーザーによって実行されることがよくあります。受け入れテストの主な目的は、欠陥を見つけることではなく、システムの信頼性を高めることです。欠陥は初期のレベルのテストで検出され修正されているはずだからです。受け入れテストは、再テストが必要な変更や修正がない限り、システムのリリース前に実行される最後のレベルのテストです。災害復旧とバックアップ/復元のテストは、顧客の満足度と信頼に影響を与えるシステムの信頼性とセキュリティの重要な側面であるため、通常は受け入れテストの一部です。したがって、ステートメント A は正しくありませんが、ステートメント B、C、D は正しいです。検証済み参考文献: ISTQB Foundation Level 2018 Syllabus の学習ガイド - Springer、第 2 章、20-21 ページ。

インシデントとは、テスト中に発生し、調査が必要なイベントです。インシデントレポートとは、インシデントの詳細を記録する文書です。逸脱を記録する前にテスターが実行すべき次のステップは、報告する前にインシデントを再現してみることです。これは、インシデントに再現性があり、ランダムまたは外部要因によって引き起こされたものではないことを確認するのに役立ちます。これは、インシデントを再現する手順、予想される結果と実際の結果、インシデントの重大度と優先度、インシデントを説明できるスクリーンショットやログなど、インシデントに関する詳細情報を収集するのにも役立ちます。問題の原因となっているコード断片を特定することは、通常、インシデントレポートを受け取った後に開発者によって実行されるデバッグ作業であるため、逸脱を記録する前にテスターが実行すべき次のステップではありません。開発者に電子メールを送信してバグを報告しないことは、逸脱を記録する前にテスターがとるべき次のステップではありません。これは、混乱、不一致、または情報の損失につながる可能性のあるインシデントを伝達する非公式で構造化されていない方法だからです。何もせずにそのままインシデントを報告することは、逸脱を記録する前にテスターが実行すべき次のステップではありません。これは、インシデントの調査と解決を妨げる不完全または不正確なインシデントレポートにつながる可能性があるためです。検証済み参考文献: ISTQB Foundation Level 2018 Syllabus のスタディ ガイド - Springer、第 3 章、32 ～ 33 ページ。