障害は欠陥によって引き起こされる場合もありますが、環境条件によっても引き起こされる場合もあります。障害とは、ソフトウェアシステムが必要な機能を実行しない、または期待された動作と異なる動作をすることを指します。欠陥とは、ソフトウェアシステムの欠陥、または要件や仕様からの逸脱であり、障害の原因となる可能性があります。ただし、すべての障害が欠陥によって引き起こされるわけではなく、ハードウェアの故障、ネットワークの中断、停電、構成の不適合など、環境条件によっても障害が発生する場合があります。環境条件は、ソフトウェアシステムの動作に影響を与える要因ですが、ソフトウェアシステム自体の一部ではありません。その他の記述は誤りです。理由は以下のとおりです。
* 欠陥は必ずしも障害を引き起こすわけではありませんが、バグは必ず障害を引き起こします。この記述は誤りです。欠陥は、ソフトウェア システムの入力、出力、状態、またはシナリオに応じて障害を引き起こす場合と引き換えに障害を引き起こす場合があり、バグは欠陥の別名であるため、欠陥と同様に障害を引き起こす可能性があります。たとえば、めったに使用されない機能やコードの隠れた分岐の欠陥は障害を引き起こさない可能性がありますが、頻繁に使用される機能やコードのクリティカル パスの欠陥は頻繁に障害を引き起こす可能性があります。バグは欠陥とは異なる概念ではなく、むしろ欠陥の同義語または口語的な用語であるため、定義と意味は欠陥と同じです。
* 欠陥は、発生すると必ずエラーを引き起こす故障を引き起こす可能性があります。この記述は誤りです。エラーは故障の結果ではなく、欠陥の原因です。エラーとは、タイプミス、論理的な欠陥、要件の誤解など、ソフトウェア システムに欠陥を生み出す人間の行為またはミスです。エラーはソフトウェア システムでは観察できませんが、コード、設計、ドキュメントなど、人間の思考または人間の作業成果物では観察できます。障害はエラーの原因ではなく、むしろ欠陥の結果であり、欠陥はエラーの結果です。たとえば、コード内のエラーはソフトウェア システムに欠陥を引き起こし、ソフトウェアの動作に障害を引き起こす可能性があります。
* バグはコンポーネントのテスト中に見つかった欠陥ですが、障害はより高いテスト レベルで見つかった欠陥です。
この記述は誤りです。バグと故障は欠陥の種類が異なるのではなく、欠陥とその現れ方を表す異なる用語だからです。前述のように、バグは欠陥の別名であり、故障とは欠陥によってソフトウェアシステムが期待どおりに動作しない事象を指します。
バグや障害は、コンポーネントテストやそれより上位のテストレベルだけでなく、あらゆるテストレベルで発見される可能性があります。テストレベルとは、コンポーネントテスト、統合テスト、システムテスト、受け入れテストなど、ソフトウェアシステムの統合レベルに対応するテスト段階です。テストの目的、テストベース、テスト手法、テスト環境に応じて、あらゆるテストレベルで欠陥や障害が発生し、検出される可能性があります。参考資料：ISTQB Certified Tester Foundation Level (CTFL) v4。
0 件のソースと文書:
* ISTQB®認定テスター基礎レベルシラバスv4.0、第1.1.2章「テストと品質1」
* ISTQB®認定テスター基礎レベルシラバスv4.0、第1.2.1章「テストの原則1」
* ISTQB®認定テスター基礎レベルシラバスv4.0、第1.3.1章「ソフトウェア開発ライフサイクルにおけるテスト」1
* ISTQB® テスト用語集 v4.0、故障、欠陥、バグ、環境条件、エラー、テストレベル2

静的解析は、プログラムを実行せずにソフトウェアのコード、設計、構造を解析するものです。セキュリティ上の脆弱性（II）や仕様・標準への不適合（III）など、さまざまな種類の欠陥を発見できます。しかし、静的解析は、ソフトウェアを実行して様々な条件下での動作を観察する動的テスト（I）の代わりにはなりません。動的テストは、実行時の問題やソフトウェアの異なる部分間の相互作用など、静的解析では検出できない障害を特定できます。記述IVは誤りです。静的解析は障害を検出するのではなく、欠陥を検出するからです。障害はソフトウェアの実行時に観察されますが、これは静的解析の範囲外です。

包括的かつ詳細な説明:製品リスクはソフトウェアの品質や機能に影響を与えるリスクであり、プロジェクト リスクはプロセス、リソース、またはタイムラインに影響を与えます。
* (A) は正解です。計算が間違っているとソフトウェアの正確性に影響が出るからです。
* (B)、(C)、(D) は、ソフトウェアの欠陥ではなく、チームの調整、人員配置、スケジュールに関連するプロジェクト リスクです。
製品リスクを早期に特定することで、欠陥の検出率が向上し、高リスク領域をより適切にカバーできるようになります。

意思決定表とは、入力や刺激（原因）と、それに対応する出力やアクション（結果）の組み合わせを示す手法です。意思決定表は、条件（入力）、アクション（出力）、条件エントリ（値）、アクションエントリ（結果）という4つの象限で構成されます。意思決定表に関する以下の記述は正しいです。
II. 決定表から導出されたテストケースは、コンポーネントテストに使用できます。決定表は、条件の論理的な組み合わせに依存する複数の入力と出力を持つコンポーネントのテストに使用できます。決定表は、あらゆる可能な組み合わせやシナリオを体系的にカバーするのに役立ちます。
III. 決定表の各列には、複数のテストケースを選択できます。決定表の各列は、条件エントリとアクションエントリの一意の組み合わせを表します。決定表に含まれていない他の入力値や期待される結果を変化させることで、各列に複数のテストケースを選択できます。決定表に関する以下の記述は誤りです。
I. 一般的に、デシジョンテーブルはリスクの低いテスト項目に対して生成されます。デシジョンテーブルはリスクレベルではなく、複雑さのレベルに関係します。デシジョンテーブルは、複雑なロジックや、複数の条件とアクションをテストする必要があるテスト項目に対して生成されます。
IV、決定表内の条件は、一般的には否定的なテストを表します。決定表内の条件は、テスト項目に対する有効な入力か無効な入力かに応じて、肯定的なテストと否定的なテストの両方を表します。検証済み参考文献：ISTQB Foundation Level 2018シラバス学習ガイド - Springer、第4章、42～43ページ。

インシデントとは、テスト中に発生し、調査が必要となるあらゆるイベントを指します。インシデント管理ツールは、インシデントのライフサイクル全体にわたる記録と追跡をサポートするソフトウェアツールです。あるスタートアップ企業のQAマネージャーは、1週間以内に低コストのインシデント管理ツールを導入する必要があります。このケースに最適な選択肢は、イントラネットに投稿されたスプレッドシートでインシデントを管理することです。この選択肢には、他の選択肢に比べていくつかの利点があります。
* 追加のソフトウェアやハードウェアを購入する必要がないため、コストが低く抑えられます。
* 複雑なソフトウェアやハードウェアのインストールや設定は不要なので、1 週間以内に簡単に実装できます。
* イントラネットにアクセスできるユーザーなら誰でも閲覧、更新できるため、アクセスしやすく透明性が保たれます。
* 識別子、概要、説明、重大度、優先度、ステータス、解決策など、インシデントに関するさまざまな情報を保存および表示できるため、構造化され整理されています。他のオプションは、選択したオプションに比べていくつかの欠点があるため、このケースには適していません。
* ラボ内の大きなボードにインシデントを記録するのは、ラボに物理的にいない人にはアクセスできず、透明性も確保できないため、適切な選択肢ではありません。また、インシデントに関する必要な情報をすべて保存または表示できない可能性があるため、構造化も整理もされていません。
* インシデント管理ツールを購入して導入するのは、低コストではなく、1週間以内に導入できるほど容易ではないため、良い選択肢ではありません。ソフトウェアやハードウェアの入手、インストール、設定に多大な費用と時間がかかる可能性があります。
* メールや電話でインシデントを管理するのは、体系的ではないため、良い選択肢ではありません。インシデントに関する情報の混乱、矛盾、または紛失につながる可能性があります。参考文献：ISTQB Foundation Level 2018シラバス学習ガイド - Springer、第3章、ページ
32-33.