問題34：要件に基づくテスト条件と品質特性のマッピング

問題 #34

HeatWellモバイルアプリは、住宅所有者が自宅の暖房を制御および監視できるようにするものです。HeatWellアプリに関して、以下の要件が最も重要であると特定されました。

あなたはHeatWellチームのテストアナリストです。記載された要件の機能的および/または非機能的品質特性を検証するために、最も適切だと思われるテスト条件は次のうちどれですか？（※2つ選択してください）

b) ユーザーは最小限の手順で、目標温度を効果的に設定できる。

c) 効率化機能が熱消費量を正確に算出する。

この問題は、提示された要件から「どの品質特性が求められているか」を読み取り、それを直接的に検証できるテスト条件（Test Condition）を選択する力を問うています。

a) 不正解。 これは「設置性 / インストール性（Installability）」に対処するテスト条件ですが、今回の要件1および要件2にはインストールに関する記述は一切含まれていません。
b) 正解。 要件1の「簡単に設定でき（easily set）」という記述は、 「使用性（Usability）」 の要件です。この使用性の側面（特に効率性）を検証するためには、「最小限の手順で目標温度を設定できるか」をテストすることが極めて適切です。
c) 正解。 要件2の「消費されたエネルギーを算出し（calculate the energy consumed）」という記述は、計算機能の 「機能正確性（Functional correctness）」 を求めています。したがって、「効率化機能が熱消費量を正確に算出するか」を検証するテスト条件が直接的に合致しています。
d) 不正解。 異なるOSとデータベースサーバー間のデータ保存は「相互運用性（Interoperability）」に対処するテスト条件ですが、これも今回の要件には関連していません。
e) 不正解。 要件1に「監視できる」とはありますが、「過去30日間の履歴を表示する」という具体的な機能は要求されていません。要求されていない機能をテスト条件の最優先とするのは不適切です。

JSTQB AL TA試験において、「要件からテスト条件を導出する問題」の鉄則は 「書かれていない要件を勝手に推測（追加）しないこと」 です。

要件に潜む品質特性のキーワードを見抜く:
- 「簡単に（easily）」「分かりやすく」＝ 使用性（選択肢b）
- 「算出する（calculate）」「処理する」＝ 機能正確性（選択肢c）
もっともらしいダミー選択肢の排除: 問題32でも触れましたが、アプリのテストにおいて「インストールできるか（選択肢a）」や「サーバーに保存できるか（選択肢d）」は実務上間違いなく重要です。しかし、 「提示された要件（Req1, 2）の検証において」 という設問のスコープから外れているため、試験では不正解となります。
過剰な具体化に注意: 選択肢(e)の「過去30日間」のような、要件定義書に存在しない具体的な数値（マジックナンバー）が含まれている選択肢は、要件の拡大解釈（スコープクリープ）の典型例であり、不正解のサインとなります。

テスト条件（Test Condition）とは
JSTQBにおけるテスト条件とは、 「テストベース（要件など）の分析によって特定された、テスト可能なアイテムやイベント」 のことです。要件を品質特性のレンズを通して翻訳したものがテスト条件になるとイメージしてください。