| ID | 優先度 | 項目 | 前提条件 | 手順 | 期待結果 | 判定 | 備考/ログ | 環境 |
|---|---|---|---|---|---|---|---|---|
| 1 | H | クエスト受注 YES選択時の挙動 |
・受注ダイアログ表示中 ・スタミナ≥10 |
1) 受注ダイアログで「YES」を選択 2) ローディング完了まで待機 |
・バトル画面へ遷移 ・スタミナを10消費 ・BGMをバトル用に切替 |
OK | スクショ quest_yes_ok.png |
iPhone 13 (iOS 17) |
| 2 | M | アイテム使用 「ポーション」でHP回復 |
・バトル中 ・所持品に「ポーション」×1 ・現在HPが最大未満 |
1) アイテムメニューを開く 2) 「ポーション」を使用 |
・HPが+50回復 ・所持数が1減少 ・使用ログを出力 |
OK | ログ battle/item_green_003.txt |
Pixel 6 (Android 13) |
| 3 | H | ショップ 確認ダイアログでのキャンセル挙動 |
・ショップ画面 ・「ジェム100」購入ボタン有効 |
1) 「ジェム100」をタップして購入確認を表示 2) ダイアログで「キャンセル」を選択 |
・課金処理は開始しない ・ショップに留まる |
NG | Bug report №101 外部ストアへ遷移 vid/cancel_bug.mp4 |
iPhone 14 (iOS 17) |
| ID | スキル名 | 説明 | 対象 | 効果 | 効果時間 | 備考/ログ |
|---|---|---|---|---|---|---|
| 1 | 烈火斬 | OK | NG | OK | OK | Bug report №204 対象が敵単体（仕様：敵グループ） |
| 2 | 蒼穹の守護 | OK | OK | OK | OK | |
| 3 | 影縫い | OK | OK | OK | NG | Bug report №207 効果時間60秒（仕様：30秒） |
| 4 | 星霊の祈り | OK | OK | OK | OK | |
| 5 | 虚空衝 | OK | OK | NG | OK | Bug report №208 ダメージ200～250（仕様：100前後） |
購入確認 |
→ OK |
ショップ |
← 保留 |
売却確認 |
↑ OK |
↓ OK |
↑ NG |
||
商品選択 |
↓ OK |
所持品選択 |
||
↑ OK |
↓ OK |
↑ OK |
||
商品一覧 |
← NG |
購入/売却 |
→ OK |
所持アイテム一覧 |
 |
NG |
アイテム選択時の挙動が正しいことを確認 |
「正しい」は基準が曖昧でテスターごとに判断が分かれるため、検証結果が均一にならない 具体的な期待結果を明記するべき |
| OK |
アイテム選択時に確認ダイアログが開くことを確認 |
 |
NG |
キャラの挙動が不自然でないことを確認 |
「不自然か否か」はテスターの感覚に依存するため、検証結果が均一にならない 基準資料を明示すれば判断を統一することができるが 参照箇所が分かりにくいと、確認に時間がかかったり誤認することがある |
| OK |
キャラの挙動が仕様通りなことを確認 |
 |
NG |
セーブデータに問題がないことを確認 |
テストで「問題があること」は示せても、「問題がないこと」は証明できない 「問題がないこと」ではなく、どの状態ならOＫなのか(判定条件)を明記するべき |
| OK |
ロード時にセーブ地点から再開できることを確認 |
 |
NG |
「金の鍵」を使わずにドアを開ける方法がないことを確認 |
「〜方法がないか」は網羅探索になり非現実的 否定の網羅ではなく、仕様に基づく具体的な期待結果を明記するべき |
| OK |
・「銀の鍵」では開かないことを確認 ・「銅の鍵」では開かないことを確認 |
 |
NG |
・赤い鍵では扉が開かないことを確認 ・青い鍵で扉が開くことを確認 ・黄色い鍵では扉が開かないことを確認 ・レバー操作で扉が閉じることを確認 |
肯定・否定の動詞が混在していると、可否の判定軸が揺れて読みづらくなる。 基本的には「〜になる」「〜が表示される」など、肯定形に統一すると誤読を防げる。 |
| OK |
・赤い鍵では扉が「開かない」と表示される ・青い鍵で扉が開くことを確認 ・黄色い鍵では扉が「開かない」と表示される ・レバー操作で扉が閉じることを確認 |
 |
NG |
クリア時に回復薬（大）を入手できることを確認 |
開発中に使われている「仮名」「俗称」は使わない ゲーム内で実際に表示される正式名称で統一し、齟齬や混乱を防ぐべき |
| OK |
クリア時に緑のポーションを入手できることを確認 |
 |
NG |
ミッションクリアで「キャラA」が仲間になる |
前提条件が記載されていない状態ではテスト結果が不正確になる NGのテストケースでは「キャラB」加入中に、キャラAが仲間になっても不具合に気づかない |
| OK |
前提：「キャラB」が仲間にいない ミッションクリアで「キャラA」が仲間になる |
 |
NG |
画像が表示されることを確認 |
テストケースに「表示されるか否か」と記載されていると 何か表示されていればOKと誤判定してしまう可能性がある 表示されるべき画像の資料は明示しておくべき |
| OK |
仕様通りの画像が表示されることを確認 |
 |
NG |
1.「YES」→ クエスト開始 2.「NO」 → 開始しない |
YES先行だと同フローでNOを試せない NO検証のためにはセーブデータの巻き戻し/再起動など余計な工数が必要 工数基準で考えた場合、このテストケースの順序は不適切 |
| OK |
1.「NO」 → 開始しない 2.「YES」→ クエスト開始 |
 |
NG |
新規「武器」と既存「兜」「鎧」の全組合せを確認 |
各10種でも10×10×10=1000ケースで工数が膨張 全組合せの網羅は非現実的 実行する場合もマトリクス表や代表的な組合せで検証するべき |
| OK |
新規「武器」と「炎の兜」「水の鎧」の組合せを確認 |
 |
NG |
バトル開始時の挙動が仕様通りかを確認 |
1ケースに複数観点を入れると、失敗時の切り分けが困難になり報告も曖昧になる 1テストケース＝1観点で記載する |
| OK |
・バトル画面へ遷移を確認 ・アニメーション再生を確認 ・BGM再生を確認 |
 |
NG |
クエストが開始された後、仕様通りのセリフが表示され、BGMが切替わることを確認 |
長文かつテスト観点が複数含まれたテストケースになっている 要素を分解して、それぞれの観点に対してテストケースを作成するべき |
| OK |
・クエスト開始を確認 ・仕様通りのセリフ表示を確認 ・BGMの切替を確認 |