オラクルは、特定のテスト入力または状況に対して期待される結果を提供できるメカニズムまたはソースです。
新しいバージョンで実行されるテスト ケースに対して古いバージョンが正しく動作すると想定される場合、製品の古いバージョンをオラクルとして使用できる場合があります。これはバックツーバック テストとも呼ばれます。
オラクルは、実際の結果ではなく期待される結果のみを提供するため、再現不可能なバグの再現には役立ちません。オラクルは設計からではなく、要件や仕様から派生します。データ ジェネレーターはテスト入力のみを提供し、テスト出力は提供しないため、データ ジェネレーターを使用して Oracle を自動的に生成することはできません。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、ページ
9.

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

適切なテスト手法を選択することは、さまざまな種類のテストに適した手法が異なるため、非常に重要であり、欠陥を検出する可能性がより高いテストを作成することでテスト プロセスの効率を大幅に向上させることができます。テスト数の削減 (A) と回帰サイクル数の定義 (D) はテスト プロセスにおける考慮事項ですが、それらはテスト手法を選択する主な理由ではありません。ソフトウェア アプリケーションをテストする唯一の方法は、十分に証明されたテスト手法 (B) を使用することであるという主張は限定的すぎ、さまざまな状況や目的に合わせてテストに必要な適応性を認めていません。したがって、オプション C が最も包括的な理由です。これはテストの有効性と効率に焦点を当てており、バグを発見する可能性が高い高品質のテストの作成につながります。

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

正式なレビューは、正式な開始および終了基準、参加者の役割と責任を伴う、定義されたプロセスに従うタイプのレビューです。正式なレビューには、マネージャー、モデレーター、著者、査読者、筆記者など、さまざまな役割が関与する場合があります。正式なレビューにおけるマネージャーの責任には、次のいずれかを除くすべての責任が含まれます。
* レビューの計画 (正しい責任)
* レビューの目的が達成されたかどうかを判断します (誤った責任)
※レビューの実施を決定する（正しい責任）
* レビューに時間を割り当てる（正しい責任） レビューの目的が達成されたかどうかを判断する責任は、マネージャーの役​​割ではなく、モデレーターの役割に属します。検証済みの参考文献: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer]、第 3 章、28-29 ページ。