問題29：機能適切性テストの実施タイミング
問題 #29
Section titled “問題 #29”機能適切性のテストは通常いつ実施されるか？
- a) コンポーネントテストおよび統合テストの期間
- b) 統合テストおよびシステムテストの期間
- c) システムテストおよびユーザー受け入れテストの期間
- d) 受け入れテスト、特にアルファテストおよびベータテストの期間
b) 統合テストおよびシステムテストの期間
前回の問題（28）にも関連する、テストレベルと品質特性のマッピングに関する問題です。
- a) 不正解。 システムのごく一部しか評価できないコンポーネント（単体）レベルで、ユーザーの目的に合致しているか（機能適切性）を評価することは一般的に困難です。
- b) 正解。 機能適切性（Functional appropriateness）のテストは通常、システムテスト中に実施されますが、統合テストの後期段階で実施されることもあります。
- c) 不正解。 機能適切性のテストは、受け入れテストの「前」に実施されるべきです。もし受け入れテストの段階で「ユーザーの目的に合っていない」と発覚した場合、コーディングの大幅なやり直し（巨大な手戻り）につながる可能性があるためです。
- d) 不正解。 機能適切性はアルファテストやベータテストの主目的とすべきではありません。アルファテストおよびベータテストにおいて、ユーザーは例えば「使用性（ユーザビリティ）」や「完全性（必要な機能が欠けていないか）」の問題により焦点を当てる傾向があります。
JSTQB AL TA試験において、「機能適切性（Appropriateness）」をテストするタイミングは非常に重要なコンセプトです。以下の理由とセットで覚えておきましょう。
- なぜコンポーネントテストではダメなのか？ 適切性とは「ユーザーのタスク（業務）の達成に役立つか」という指標です。関数やモジュール単体が動くかどうかを見るコンポーネントテストでは、「業務フロー全体」が見えないため、適切性の判断ができません。
- なぜ受け入れテスト（UAT）では遅すぎるのか？ 「正しく作られたが、顧客が欲しかったものではなかった」という悲劇を防ぐのが適切性テストの目的です。完成間近のUATでこれに気づくと、設計からやり直すことになり、コストが爆発します（選択肢cの解説にある “huge coding rework”）。
- 結論：システムテスト（または統合テスト後期）が最適 ある程度のシステムが繋がり、業務シナリオが通せるようになった段階（システムテストや統合テスト後期）で、プロトタイプなどを使いながらビジネス側の専門家を交えて検証するのがベストプラクティスです。
前回の問題（問題28）とのリンク 問題28では「適切性のテストを受け入れテストで実行するのは遅すぎる」という選択肢が不正解になっていました。今回の問題29は、まさにその理由（なぜ遅すぎるのか）を裏付ける内容になっています。セットで復習すると理解が深まります！