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

レビューに関する次の記述は真実です。
* I) ウォークスルーでは、レビュー会議は通常、作成者が主導します。ウォークスルーとは、事前に定義された目的と議題を持つものの、正式なプロセスや役割は設定されていないレビューの一種です。ウォークスルーは通常、レビュー対象の成果物の作成者が主導し、参加者にシナリオを案内し、フィードバックを求めます。
* IV) 経営陣が技術レビュー会議に参加することは稀です。技術レビューとは、事前に定義された目的と議題を持つものの、正式なプロセスや役割が定められていないレビューの一種です。技術レビューは通常、技術的な専門知識を持つ同僚によって実施され、成果物の技術的な側面を評価します。
経営陣は、効果的な貢献をするための十分な技術的知識やスキルを有していない可能性があるため、技術レビュー会議にほとんど参加しません。レビューに関する以下の記述は誤りです。
* II) 検査は、オープンエンドのレビュー会議を特徴とします。検査とは、正式な開始・終了基準、参加者の役割と責任が定められた、定義されたプロセスに従うレビューの一種です。検査は、定められた期間と議題を伴う、構造化されたレビュー会議を特徴とします。
* III) レビュー会議前の準備は非公式レビューの一部です。レビュー会議前の準備は、検査や技術レビューなどの公式レビューの一部です。準備には、以下の確認が含まれます。

包括的かつ詳細な説明:ビジネス、開発、テスト (C) は、アジャイル ユーザー ストーリーの改善における 3 つの重要な視点です。
* ビジネス (製品オーナー、利害関係者) - ストーリーがユーザーのニーズとビジネス目標と一致していることを確認します。
* 開発 (開発者) - 実現可能性と技術的制約に関する洞察を提供します。
* テスト (テスター、QA) - テスト可能性、受け入れ基準、およびリスクの識別を保証します。
* (A) は不正解です。プロダクトオーナーはビジネスステークホルダーの一部だからです。
* (B) は不正解です。アーキテクチャは開発の一部ではあるものの、ユーザー ストーリーの主な推進力ではないためです。
* (D) は不正解です。受け入れテストはプロセスであり、利害関係者グループではないためです。
機能横断的なチームのコラボレーションにより、明確に定義され、テスト可能で、実現可能なユーザー ストーリーが保証されます。

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

年齢入力の正しい境界値リストには、各年齢グループの最小値と最大値 (0、12、13、18) に加えて、各境界のすぐ下と上の値 (-1、19) を含める必要があります。境界値分析は、入力ドメインまたは出力範囲の境界またはその付近の値をテストするテスト設計手法です。これらの値は、中央の値よりもエラーが発生する可能性が高くなります。オプション A は、6 つの境界値 (-1、0、12、13、18、19) すべてを持っているため、この条件を満たしています。オプション B には、同じ同値クラスからの値が 2 つ (12 と 13)、オプション C には境界値が 4 つ (0、12、18、19) のみ、オプション D には境界値がまったくありません。検証済みの参考文献: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer、34 ページ。