問題19:要件に応じたテスト技法の選択
問題 #19
Section titled “問題 #19”複数のチームを運営するサッカークラブのメンバーシップを管理するための新しいモバイルアプリが開発されることになった。
クラブオーナーの主要な目的の1つは、新規メンバーの登録に必要な時代遅れの手作業を置き換えることである。すべてのユーザーが最新のユーザーインターフェースに慣れているわけではないため、アプリの機能は比較的シンプルに保たれる。 そのためクラブオーナーは、ユーザーがさまざまな画面間をナビゲート(移動)する際の容易さと、アプリケーションの使用性(ユーザビリティ)に重点を置いている。
もう1つの目的は、チームに登録できる選手の人数を管理することである。したがって制限が適用され、その結果として応募者がキャンセル待ちリスト(waiting list)に載る可能性がある。
このモバイルアプリのテストに最も適しているテスト技法は以下のうちどれか?(※2つ選択してください)
- a) 状態遷移テスト(State transition testing)
- b) デシジョンテーブルテスト(Decision table testing)
- c) 境界値分析(Boundary value analysis)
- d) ユースケーステスト(Use case testing)
- e) ペアワイズテスト(Pairwise testing)
a) 状態遷移テスト(State transition testing)
c) 境界値分析(Boundary value analysis)
(※注釈:プロジェクトの文脈によっては、手作業の置き換えに着目して「d) ユースケーステスト」が選ばれるケースもありますが、JSTQBシラバスの典型的なキーワードマッピングに基づいて解説します)
a) 正解。 状態遷移テストは、さまざまな画面間の正しいナビゲーションをテストできるため適切です。また、これによりキャンセル待ちリストの管理を評価することも可能になります(例:申し込み承認とキャンセル待ちリスト間の状態遷移など)
b) 不正解。 現在の仕様では、デシジョンテーブルテストを使用しても限定的な価値しか得られません。
c) 正解。 仕様書では、特定のチームに登録できる選手数を管理することが目的の1つとして言及されています。制限(すなわち、チームが登録できる選手数の上限)が適用され、その結果として応募者がキャンセル待ちリストに載る可能性があります。これらの制限をテストするには、境界値分析の使用が関連してきます。
d) 不正解。 アプリに求められる機能は比較的シンプルに保たれる予定です。ユースケーステストを適用することは可能ですが、状態遷移テスト(選択肢a)や境界値分析(選択肢c)と比べると適切ではありません。なお、シナリオ内でユーザビリティについて言及されているからといって、テスト技法としてユースケーステストを適用すべきだということにはならない点に注意してください。
e) 不正解。 シナリオのどこにも、ペアワイズテストが適切であることを示す記述はありません。適用すべき組み合わせロジックについての明確な言及はありません。
JSTQB AL TAの試験において、要件の記述(キーワード)から適切なテスト技法を導き出す典型的な問題です。問題文に含まれる「目的」と「制約」を分解して技法を割り当てます。
-
「画面間をナビゲート(移動)する際の容易さ」へのアプローチ 画面遷移(Screen navigation)やメニュー構造のテストにおいて、最も効果的なブラックボックス技法は 状態遷移テスト(a) です。各画面を「状態(State)」、ユーザーの操作(ボタンタップなど)を「遷移(Transition)」としてモデル化することで、アプリ内のナビゲーションが正しく機能するかを網羅的にテストできます。
-
「登録できる選手の人数制限」と「キャンセル待ち」へのアプローチ 「人数の制限(例:定員20名)」という数値の境界をテストするためには、 境界値分析(c) が最適です。定員に達する直前(19名)、定員ちょうど(20名)、定員オーバー(21名:キャンセル待ちリストに入るか)という境界の振る舞いを効率的に検証できます。
JSTQB試験では、問題文の中に「どの技法を使うべきか」を示す明確なトリガー(キーワード)が隠されています。
- 状態遷移テストのトリガー: 「画面のナビゲーション」「メニュー構造」「システムのステータス変更(例:未登録→登録済→退会)」
- 境界値分析のトリガー: 「制限(Limits)」「最大/最小」「範囲」
- ユースケーステストのトリガー: 今回の問題にも「手作業の置き換え」というユースケースと相性の良いキーワードが含まれています。もし選択肢に状態遷移テストがない場合や、より「ビジネスプロセスのシナリオ(一連のユーザー操作フロー)」が強調されている場合は、ユースケーステストが正解の有力候補となります。
- デシジョンテーブルテストのトリガー: 「複雑なビジネスルール」「複数の条件の組み合わせによる異なるアクション」
- ペアワイズテストのトリガー: 「膨大な設定値や環境(OS、ブラウザなど)の組み合わせの削減」
実務においては、これらの技法は排他的なものではなく組み合わせて使用されます。例えば、「画面遷移(状態遷移テスト)」を行いながら、特定の入力フォームで「人数制限(境界値分析)」を行うといったアプローチが一般的です。