プロジェクト リスクとは、範囲、スケジュール、コスト、品質など、プロジェクトの目標に影響を及ぼす可能性のある不確実性または脅威のことです。ISTQB Certified Tester Foundation Level (CTFL) v4.0 のシラバスによると、プロジェクト リスクに寄与する要因には次のようなものがあります。
* スキルとスタッフの不足: この要因は、プロジェクト タスクを実行するのに適切または資格のある人材が不足していることを指します。これにより、遅延、エラー、やり直し、または生産性の低下が発生する可能性があります。
* 適切な要件の定義に関する問題: この要因は、プロジェクトの要件の抽出、分析、指定、検証、または管理における困難または曖昧さを指します。これにより、要件の不一致、矛盾、ギャップ、または変更が発生し、プロジェクトの範囲と品質に影響する可能性があります。
* 契約上の問題: この要素は、クライアント、サプライヤー、ベンダー、下請け業者などのプロジェクト関係者間の契約上の合意から生じる可能性のある課題や紛争を指します。これにより、法的、財務的、倫理的なリスクが生じ、プロジェクトの実施と満足度に影響する可能性があります。
他のオプションは、プロジェクト リスクではなく製品リスクに寄与する要因をリストしているため、正しくありません。
製品リスクとは、ソフトウェア製品またはシステムの品質や機能に影響を及ぼす可能性のある不確実性または脅威のことです。製品リスクに寄与する要因には次のようなものがあります。
* ソフトウェア品質特性の低さ: この要因は、信頼性、使いやすさ、セキュリティ、パフォーマンス、保守性など、ソフトウェア製品またはシステムの品質特性または基準の遵守または準拠の欠如を指します。これにより、欠陥、障害、またはユーザーまたは利害関係者の不満が発生する可能性があります。
* ソフトウェアが意図した機能を実行しない: この要因は、ソフトウェア製品またはシステムの期待される動作または出力と実際の動作または出力との間の偏差または不一致を指します。これにより、ソフトウェア製品またはシステムのエラー、障害、または誤動作が発生する可能性があります。
参考資料 = ISTQB Certified Tester Foundation Level (CTFL) v4.0 シラバス、第 1 章: テストの基礎、セクション 1.5: リスクとテスト、14 ～ 16 ページ。

構造テストは、テストによって実行されたコード行を追跡することで有効性を測定するテストの一種です。構造テストは、ホワイト ボックス テストまたはグラス ボックス テストとも呼ばれ、ソフトウェアの内部構造、設計、または実装に基づいています。構造テストの目的は、コード パス、分岐、ステートメント、条件、またはデータ フローを実行して、ソフトウェアがパフォーマンス、セキュリティ、信頼性、保守性などの指定された品質属性を満たしていることを確認することです。構造テストでは、関数カバレッジ、行カバレッジ、分岐カバレッジ、ステートメント カバレッジなどのさまざまなカバレッジ メトリックを使用して、コードのテスト済み範囲を判断し、コード内のテストされていない部分や到達できない部分を識別します。構造テストは、単体テスト、統合テスト、システム テスト、受け入れテストなど、あらゆるレベルのテストに適用できますが、テスターがソース コードにアクセスできる低レベルで使用されることが一般的です。
その他のオプションは、テストによって実行されたコード行を追跡することで有効性を測定するタイプのテストではないため、正しくありません。受け入れテストは、ソフトウェアが受け入れ基準とユーザー要件を満たしていることを確認するタイプのテストです。受け入れテストは通常​​、エンドユーザーまたは顧客によって実行されますが、彼らはソフトウェアのソースコードや技術的な詳細にアクセスできない場合があります。受け入れテストは、ソフトウェアの内部構造や実装ではなく、ソフトウェアの機能性、使いやすさ、適合性に重点を置いています。統合テストは、ソフトウェアコンポーネントまたはサブシステムが期待どおりに連携して動作することを確認するタイプのテストです。統合テストは通常​​、開発者またはテスト担当者によって実行され、構造テストと機能テストの両方の手法を使用して、コンポーネントまたはサブシステム間のインターフェイス、相互作用、または依存関係をチェックする場合があります。統合テストは、ソフトウェアの個々のコード行ではなく、ソフトウェアの統合ロジック、データフロー、または通信に重点を置いています。探索的テストは、同時学習、テスト設計、およびテスト実行を伴うタイプのテストです。探索的テストは通常​​、テスト担当者によって実行されます。テスト担当者は創造性、直感、または経験を活用してソフトウェアを探索し、欠陥、リスク、または改善の機会を見つけます。探索的テストは、ソフトウェアの内部構造や実装ではなく、ソフトウェアの動作、品質、または価値に重点を置いています。参照 = ISTQB Certified Tester Foundation Level (CTFL) v4.0 シラバス、第 4 章: テスト手法、セクション 4.3: 構造テスト手法、51 ～ 54 ページ、第 1 章: テストの基礎、セクション 1.4: ソフトウェア開発ライフサイクル全体のテスト、11 ～ 13 ページ、第 3 章: 静的テスト、セクション 3.4: 探索的テスト、40 ～ 41 ページ。

テストウェアの構成管理は、テスト ライフサイクル全体にわたってテスト資産の整合性と追跡可能性を維持する上で重要な要素です。構成管理の主な利点は、テスト ケース、テスト スクリプト、テスト データ、テスト結果などのすべてのテストウェア項目が体系的に識別され、バージョン管理され、相互の変更が追跡されることです。
オプション C は、この利点を正確に表しています。テストウェアに構成管理の原則を適用することで、チームはテスト資産への変更を効率的に管理し、テストウェアの一貫性と最新性を維持し、テスト対象のソフトウェアのバージョンと整合させることができます。この制御メカニズムにより、テストの再現性が向上し、テスト活動の信頼性が向上し、要件から欠陥までの追跡可能性がサポートされます。
オプション A、B、および D は、テスト管理とテスト プロセスの他の側面を説明していますが、テストウェア項目の体系的な制御と追跡を中心としたテストウェアの構成管理の中心的な利点を捉えていません。

この答えは正解です。構成管理とは、製品のパフォーマンス、機能、物理的属性と、その要件、設計、運用情報との一貫性を、製品のライフサイクル全体にわたって確立し、維持するプロセスです。構成管理は、関連するすべてのプロジェクト ドキュメントとソフトウェア項目がすべてのバージョンで一意に識別され、テスト ドキュメントで明確に参照できるようにするのに役立ちます。これにより、テスト成果物とテスト対象ソフトウェアの追跡可能性、一貫性、および制御が提供され、テストがサポートされます。参考資料: : ISTQB テスト用語集 v4.0、: ISTQB Foundation Level シラバス v4.0、セクション 2.2.2.2

特定のインシデント レポートに対する最も重要なレポート改善は、欠陥が検出されたときにどの Web ブラウザーが使用されたかに関する情報を追加することです。Web ブラウザーが異なると動作が異なったり、Web アプリケーションとの互換性の問題が発生したりする可能性があるため、この情報は欠陥の再現とデバッグに関係します。その他のオプションは、インシデント レポートにとってそれほど重要ではないか、無関係です。バグを修正する開発者は、欠陥を報告したテスターではなく、プロジェクト マネージャーまたは欠陥追跡システムによって割り当てられます。インシデントが発生したときのタイムスタンプは、欠陥の原因や頻度を示していないため、あまり役に立ちません。影響分析は、インシデント レポートの一部ではなく、リスク評価または優先順位付けプロセスの一部です。検証済みの参考文献: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer、140 ページ。