コンポーネントテストはテストレベルです。テスト レベルは、いくつかの共通の特性または目的に基づいて編成および管理されるテスト アクティビティのグループです。テスト レベルは、テストの範囲とターゲット、開発のフェーズとモデル、テストに関与する関係者と役割など、さまざまな要素に基づいて定義できます。コンポーネント テスト (単体テストまたはモジュール テストとも呼ばれます) は、個々のソフトウェア コンポーネント (モジュール、クラス、関数、メソッドなど) の機能と品質を検証することに重点を置くテスト レベル。コンポーネントのテストは、開発者またはテスターが、コンポーネントのタイプと複雑さに応じてさまざまな技術とツールを使用して実行できます。他のオプションはテスト レベルではありません。統合テストは、相互に、または外部システムと対話するソフトウェア コンポーネントのグループの機能と品質の検証に焦点を当てた別のテスト レベルです。機能テストは、テスト対象のシステムが要件または仕様に従って意図した機能を実行することを検証する、ブラックボックス動的テストの一種です。経験ベースのテストは、同様のシステム、テクノロジ、ドメイン、リスクなどの経験に基づいてテスト ケースを導き出し、選択するテスト担当者の知識と直観に依存するテスト設計手法のカテゴリです。基礎レベルの 2018 シラバス - Springer、19 ページ。

工数の見積もりはプロジェクトの予算ではなく、ソフトウェア製品とテスト活動の範囲、複雑さ、品質によって決まります1。予算は、工数見積もりの​​実現可能性と精度に影響を与える可能性のある制約ですが、工数見積もりを決定する要素ではありません。推定工数とは、テスト作業を完了するために必要な作業量であり、人時、人日、または人月で測定されます2。
他のオプションは次の理由から正しいです。
A) テストの労力を見積もると、リソースはテスト計画プロセスの相互に関連する側面であるため、リソースを特定してスケジュールを作成できます3。リソースとは、テスト活動を実行するために必要な人材、ツール、機器、施設です4。スケジュールとは、プロジェクトのマイルストーンと期限に合わせたテスト活動の時間枠と順序です5。
B) テスト対象の製品の品質が不明であるため、工数の見積もりが不正確になる可能性があります。これは、検出される可能性のある欠陥の数と重大度、およびそれらを修正するために必要な再作業に影響するためです6。品質とは、ソフトウェア製品が指定された要件を満たし、ユーザーとクライアントのニーズと期待にどの程度応えるかを表します7。
D) 経験ベースの見積もりは、テスト担当者や他のプロジェクト関係者の判断と専門知識に依存して、過去に実行された同様のプロジェクトやタスクに基づいてテストの労力を見積もります。経験に基づく推定は、ソフトウェア製品とテスト活動に関する履歴データ、正式な手法、または詳細情報が不足している場合に役立ちます。
参照
1 ISTQB Certified Tester Foundation Level シラバス v4.0、2023、p. 154
2 ISTQB Certified Tester Foundation Level シラバス v4.0、2023、p. 155
3 ISTQB Certified Tester Foundation Level シラバス v4.0、2023、p. 156
4 ISTQB Certified Tester Foundation Level シラバス v4.0、2023、p. 157
5 ISTQB Certified Tester Foundation Level シラバス v4.0、2023、p. 158
6 ISTQB Certified Tester Foundation Level シラバス v4.0、2023 年、p. 159
7 ISTQB Certified Tester Foundation Level シラバス v4.0、2023、p. 16
[8] ISTQB Certified Tester Foundation Level シラバス v4.0、2023 年、p. 160
[9] ISTQB Certified Tester Foundation Level シラバス v4.0、2023 年、p. 161

IEEE 829 標準はテスト文書に広く使用されている仕様ですが、必須でも普遍的でもありません。ほとんどのテスト文書化体制は、特定の状況や組織に合わせて変更を加えながら、ある程度この仕様に従っています。この標準は、逸脱に対して経営陣、マーケティング、開発部門の承認を必要とせず、プロジェクトの種類 (軍事市場または消費者市場) にも依存しません。また、この規格は、実際の内容や品質基準ではなく、一般的な概要と形式のみを提供するため、高品質のテスト文書化体制を保証するものではありません。検証済み参考文献: ISTQB ファウンデーション レベル 2018 シラバスの学習ガイド - Springer、16 ページ。

障害とは、コンポーネントまたはシステムが指定された制限内で必要な機能を実行しないイベントです1。要件とは、問題を解決したり目的を達成したりするためにユーザーが必要とする条件または能力です2。この場合の要件は、診断テストが 2 秒以内に実行されることです。したがって、この要件に違反するイベントは失敗となります。この要件に明らかに違反する唯一のオプションは B です。診断テストの実行に時間がかかりすぎます。診断テストが完了するまでに 2 秒以上かかる場合、診断テストは指定された制限を満たしていないため、失敗します。他のオプションは、必ずしも指定された要件に関連する失敗であるとは限りません。オプション A: システム リセットが失敗した後、診断テストの開始に失敗しますが、時間制限とは関係ありません。これは自己診断モジュールの機能に関連しています。オプション C. メモリの速度を測定する診断テスト。失敗も失敗ですが、時間制限とは関係ありません。それは記憶力テストの精度に関係します。オプション D. テスト コードの実装が正しくないために診断テストが失敗する場合も失敗ですが、時間制限とは関係ありません。それはテストコードの品質に関係します。参照 = ISTQB Certified Tester Foundation Level シラバス v4.0、要件エンジニアリングの基礎。

障害とは、コンポーネントまたはシステムが指定された制限内で必要な機能を実行しないイベントです。障害は、ソフトウェア ユーザーまたはその他の関係者によって観察可能です。障害は、ソフトウェアの 1 つ以上の欠陥によって引き起こされます。この場合、ソフトウェアが望ましい応答時間を満たせないことは、規定された要件から逸脱し、ユーザー エクスペリエンスに影響を与えるため、失敗の一例となります。これは欠陥ではなく、障害の原因となるソフトウェアの欠陥です。これは、誤った結果を生み出す人間の行為であるエラーではありません。明らかに規定要件に違反しているため、良品ではありません。検証済みの参考文献: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer]、第 1 章、4 ページ。