欠陥クラスタリングとは、リリース前テストで検出された欠陥の大部分、あるいは運用上の障害の大部分は、少数のモジュールに存在しているというテスト原則です。欠陥クラスタリングは、問題の約80%がモジュールの20%に存在しているというパレートの法則（80-20ルールとも呼ばれる）によって説明できます。欠陥クラスタリングは、欠陥密度や重大度が高いモジュールのテストに、より多くの労力を割くべきであることを示唆するため、次のテストサイクルに向けて現在のテスト戦略を変更することを示唆しています。ペストサイドパラドックスとは、同じテストを何度も繰り返すと、最終的には新しい欠陥が見つからなくなるという、別のテスト原則です。ペストサイドパラドックスは、次のテストサイクルに向けて現在のテスト戦略を変更することを示唆していますが、これは欠陥クラスタリングではなく、テストの多様性とカバレッジに基づいています。早期テストとは、テスト活動はソフトウェア開発ライフサイクルのできるだけ早い段階で開始し、定義された目標に重点を置くべきであるというテスト原則です。
早期テストは、次のテストサイクルに向けて現在のテスト戦略を変更することを示唆するものではなく、むしろ欠陥の発生や拡大を防ぐための積極的なアプローチです。エラーの不在の誤謬とは、構築されたシステムが使い物にならず、ユーザーのニーズと期待を満たさない場合、欠陥を発見して修正しても役に立たないというテスト原則です。エラーの不在の誤謬は、次のテストサイクルに向けて現在のテスト戦略を変更することを示唆するものではなく、むしろ品質特性とユーザー要件に重点を置くことを示唆しています。検証済みの参考文献：ISTQB Foundation Level 2018シラバス学習ガイド - Springer、第1章、9～10ページ。

コンポーネントテスト（ユニットテストまたはモジュールテストとも呼ばれる）は、個々のソフトウェアコンポーネント（モジュール、クラス、関数、メソッドなど）の機能と品質の検証に重点を置いたテストレベルです。コンポーネントテストでは、主にコンポーネント間のインターフェースと相互作用、およびコンポーネントの内部ロジックとデータ構造がテストされます。コンポーネントテストは、コードを実装する前にテストを記述するテストファーストアプローチ（テスト駆動開発や振る舞い駆動開発など）を使用して適用できます。コンポーネントテストでは、モジュールやクラスの欠陥は特定されません。これはコンポーネントテストの結果であり、目的ではないためです。シミュレータとスタブは、テストに必要な不足または不完全なコンポーネントや外部システムをシミュレートまたは置き換えることができるため、コンポーネントテストに必要な場合があります。検証済みの参考文献：ISTQB® Foundation Level 2018シラバス学習ガイド - Springer、ページ
19.

画像内のデシジョンテーブルによると、シルバールームのプリファードゲストカード会員はゴールドラグジュアリーへのアップグレード資格（YES）を有しますが、プリファードゲストカード会員以外の方は、客室タイプに関わらず、アップグレード資格がありません（NO）。したがって、お客様A（シルバールームのプリファードゲストカード会員）にはゴールドラグジュアリーへのアップグレードが提案され、お客様B（プラチナルームのプリファードゲストカード会員以外の方）にはアップグレードは提案されません。参考資料：回答は画像内のデシジョンテーブルから直接導き出されており、ISTQB Certified Tester Foundation Level (CTFL) v4.0の特定のドキュメントは参照されていません。

欠陥レポートとは、テスト中に発見された欠陥の詳細を記録した文書です。欠陥レポートには通常、以下の項目が含まれます。
* 識別子: 欠陥レポートの一意の識別子
* 概要: 欠陥の簡潔な概要
* 説明: 不具合の詳細な説明（不具合を再現する手順、期待される結果と実際の結果、関連するスクリーンショットやログなど）
* 重大度: 欠陥がシステムに与える影響の度合い
* 優先度: 欠陥を解決するための緊急度
* ステータス: 新規、オープン、解決済み、クローズ済みなど、欠陥の現在の状態。
* 解決：修正、回避策、却下など、欠陥を解決するために講じられた措置。これらの項目のうち、欠陥レポートで明記する必要のない項目は、欠陥の修正方法です。欠陥の修正方法は、通常、欠陥解決を担当する開発者が決定する技術的な解決策です。欠陥の修正方法は、欠陥レポートの一部ではなく、欠陥を修正するために提供されるコード変更またはパッチの一部です。その他の項目は、欠陥の特定、追跡、解決に不可欠な情報を提供するため、欠陥レポートで明記する必要があります。検証済みの参考文献：[A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer]、第3章、32～33ページ。

包括的かつ詳細な説明:比率ベースの見積もり方法は、開発とテストの労力間の過去の関係に依存します。
与えられた5:3の比率を使用します:

したがって正解は270人日（D）です。
* (A) と (C) は労力を過大評価しているため誤りです。
* (B) は比率に基づいてテストの労力を過小評価します。
比率ベースの見積りは、過去のプロジェクト データに基づいてリソースを効果的に割り当てることができます。