2時間のテストセッション中にテスターの経験に基づいて作成される、台本のないテストは、テスト象限Q3に属します。テスト象限とは、テストの目的（テストがチームのサポートに重点を置くか、製品の評価に重点を置くか）とテストの基盤（テストが技術に基づくか、ビジネスに基づくか）という2つの側面に基づいてテストの種類を分類したものです。テスト象限はQ1、Q2、Q3、Q4とラベル付けされており、各象限はユニットテスト、受け入れテスト、ユーザビリティテスト、パフォーマンステストなど、異なるテストの観点を表しています。テスト象限 Q3 は、探索的テスト、ユーザビリティ テスト、ユーザー受け入れテスト、アルファ テスト、ベータ テストなど、ビジネスの観点から製品を批評することを目的とするテストの種類に対応します。 指定されたシナリオでテスターが実行するスクリプトのないテストは、テスターの経験、直感、Web アプリケーションの学習に基づいており、ユーザー インターフェイス、ユーザー満足度、ユーザー フィードバックなどの特定のユーザビリティの問題に焦点を当てているため、探索的テストとユーザビリティ テストの例です。 その他のオプションは、次の理由により不正解です。
* テスト象限 Q1 は、ユニットテスト、コンポーネントテスト、統合テスト、システムテストなど、技術の観点からチームをサポートすることを目的とするテストの種類に対応します。これらのテストの種類は通常、ソフトウェア システムのソースコード、設計、アーキテクチャ、または構成にアクセスできる開発者またはテスト担当者によって実行され、さまざまな統合レベルでソフトウェア システムの機能、品質、信頼性を検証することを目的としています。
* テスト象限 Q2 は、機能テスト、受け入れテスト、ストーリー テスト、シナリオ テストなど、ビジネスの観点からチームをサポートすることを目的とするテストの種類に対応します。これらのテストの種類は通常、ソフトウェア システムの要件、仕様、ユーザー ストーリー、またはビジネス プロセスにアクセスできるテスターまたは顧客によって実行され、ソフトウェア システムがユーザーと利害関係者の期待とニーズを満たしていることを検証することを目的としています。
* テスト象限Q4は、パフォーマンステスト、セキュリティテスト、信頼性テスト、互換性テストなど、技術的な観点から製品を批評することを目的としたテストの種類に対応しています。これらのテストの種類は通常、ソフトウェアシステムのツール、メトリクス、標準、ベンチマークにアクセスできるテスターまたは専門家によって実行され、さまざまな条件や環境におけるソフトウェアシステムの効率性、セキュリティ、信頼性、互換性など、ソフトウェアシステムの非機能的側面を評価することを目的としています。参考資料：ISTQB Certified Tester Foundation Level (CTFL) v4.0のソースおよびドキュメント：
* ISTQB® 認定テスター基礎レベルシラバス v4.0、第 1.3.1 章「ソフトウェア開発ライフサイクルにおけるテスト」
* ISTQB® テスト用語集 v4.0、テスト象限、探索的テスト、ユーザビリティテスト、単体テスト、コンポーネントテスト、統合テスト、システムテスト、機能テスト、受け入れテスト、ストーリーテスト、シナリオテスト、パフォーマンステスト、セキュリティテスト、信頼性テスト、互換性テスト

包括的かつ詳細な説明：
決定ルールは、条件と結果の可能な組み合わせを定義します。
このシナリオの場合:
まとめ買い割引には3つのカテゴリー（0%、5%、10%）があります
常連客割引には2つのカテゴリーがあります（はい = +5%、いいえ = 0%）
決定ルールの合計数は次のとおりです。
まとめ買い割引オプション 3 つ × 常連顧客オプション 2 つ = 6 つのルール。
したがって、正解は6つの決定ルール（B）です。

確認テスト（再テストとも呼ばれる）は、特定の欠陥が修正されたことを確認するために実施されます。一方、回帰テストは、最近の変更がソフトウェアの既存の機能に悪影響を与えていないことを確認するために実施されます。どちらのテストも、変更後のソフトウェアの整合性と品質を維持するために不可欠です。

コードのピアレビューとツールを用いたコードの静的解析の主な違いは、そのアプローチと範囲にあります。ピアレビューとは、同僚や仲間によるコードの手動検査であり、コードの技術的な側面だけでなく、設計、標準への準拠、保守性といった他の要素にも焦点を当てます。ピアレビューによって、欠陥を特定し、改善を提案し、コードがベストプラクティスやチーム標準に準拠していることを確認できます。
一方、静的解析は、コードを実行せずに解析するように設計されたツールによって実行される自動化されたプロセスです。これらのツールは、事前に定義されたルールとパターンに基づいて、構文エラー、脆弱性、コードの臭いなどの潜在的な問題を検出できます。静的解析は技術的な側面に焦点を当てていますが、コードの保守性やプロジェクト固有の標準への準拠を評価するなど、人間のレビュー担当者が提供できるより広範な視点は備えていません。したがって、静的解析はコードを技術的な側面から評価するのに対し、ピアレビューはより広範な側面を網羅するため、選択肢Bが正解となります。

レビューの目的は、欠陥を発見し、成果物の品質を向上させることであり、作成者を批判したり非難したりすることではありません。欠陥を客観的に報告するということは、作成者を不快にさせたり、モチベーションを損なったりするような否定的または感情的な言葉を用いずに、事実に基づき建設的に記述することを意味します。こうすることで、作成者はフィードバックを個人的な攻撃ではなく、成果物を改善するための努力として前向きに受け止めることができます。参考文献：ISTQB Foundation Level 2018シラバス学習ガイド - Springer、138ページ。