「予定していたテストは、すべて終わった。それなのに、公開後に不具合の問い合わせが来る」
Webサービスや業務アプリを開発・運営していると、こうした場面に直面することがあります。予約できない、購入結果が分からない、入力した申請内容が消えてしまう。利用者にとっては、どれも安心して使い続けられるかに関わる問題です。
テスト項目を一つずつ確認することは大切です。ただ、「項目を全部消化した」という結果だけでは、その項目に含まれていなかった使い方や条件まで確認できたことにはなりません。
第1回では、ゲーム開発・運営で培ってきたQAの視点を、ゲーム以外のサービスにも役立つ形で紹介します。まず考えたいのは、項目の数を増やす前に「何を守るためにテストするのか」を整理することです。
「ボタンが押せる」と「安心して手続きを終えられる」は違う
例えば、予約サービスの確認項目に「予約ボタンを押すと、完了画面が表示される」と書かれていたとします。この手順が正常に動いても、次の状況には別の確認が必要です。
- 予約ボタンを押した直後に、通信が途切れた
- 反応が遅いため、利用者がもう一度ボタンを押した
- 完了画面を見る前にアプリを閉じ、後から開き直した
予約そのものは成立しているのに、画面には失敗と表示されるかもしれません。反対に、完了したように見えても予約が保存されていない、再操作で二重予約になる、といった問題も確認対象になります。
ここで守りたいのは、「ボタンが動くこと」に加え、「予約の成立状況を正しく確認でき、意図しない予約が増えないこと」です。どの画面で何を案内し、どう再操作できるべきかは、サービスの仕様に合わせて決めます。
※本記事の予約・購入・申請の例は、考え方を説明するための一般的な想定です。特定のお客様の事例ではありません。
ゲームQAの視点を、日常のサービスへ
ゲームでは、同じ操作でも、キャラクターの状態、直前の行動、通信状況、処理のタイミングによって結果が変わります。そのため、個々の機能だけでなく、条件の組み合わせや状態の変化を捉えることが重要になります。
この見方は、ゲーム以外にも応用できます。
購入手続きなら、「カートに入れた後に在庫が変わる」「クーポンを適用してから商品を減らす」。申請システムなら、「下書き保存後に入力項目が変わる」「承認待ちの間に申請を取り下げる」といった場面です。
画面を順番に確認するだけでは、前後の処理が関係する問題を見落とすことがあります。「今はどんな状態か」「次の操作で何が変わるか」「途中で止まると何が残るか」を追うことで、確認すべき範囲が見えてきます。
こうした考え方はゲームQAだけのものではありません。クロスゲームズでは、ゲームを開発・運営してきた経験を、仕様の背景を読み解き、潜在的なリスクを考えるQAに生かしています。
仕様の意図と、実装のつながりを確認する
もう一つ大切なのが、「なぜ、その仕様になっているのか」を開発側と確認することです。
例えば、保存中にボタンを押せなくする仕様には、処理の重複を防ぐ目的があるかもしれません。その場合、ボタンの見た目だけでなく、保存に失敗した後も操作できないままにならないか、画面を開き直したときに正しい状態へ戻れるかも気になります。
画面表示、通信、データ保存は、必ずしも同じタイミングで終わりません。実装について確認できる範囲で処理のつながりを理解すると、「どの境目で問題が起きそうか」という仮説を立てやすくなります。
もちろん、仕様が不明な部分をテスト担当だけで決めてよいわけではありません。「期待する動作が決まっていない」と「決まった動作と異なる」は分けて整理し、担当者と認識を合わせる必要があります。
項目を作る前に、押さえたい5つのこと
今ある試験項目書を見直すときは、次の5点から確認してみてください。
1. 利用者が達成したいことは何か
「入力画面を表示する」だけでなく、「必要な申請を完了し、後から内容を確認する」まで、利用者の目的で捉えます。途中の画面が正常でも、目的を達成できなければ困りごとは残ります。
2. 起きると特に困ることは何か
二重購入、データ消失、他人の情報の表示、操作不能など、影響が大きい問題を整理します。すべてを同じ重さで扱わず、起こりやすさと影響から確認の優先順位を決めます。
3. 状態・順番・タイミングで結果が変わらないか
初回と2回目、保存前と保存後、処理中と完了後を分けて考えます。正常な一本道に加えて、戻る、やり直す、同じ操作を繰り返す場面も確認候補にします。
4. 失敗した後、利用者が次に進めるか
通信エラーを表示できても、入力がすべて消えたり、再試行できなかったりすれば負担が残ります。何が成立済みかを確認できることと、適切な復帰手順があることを見ます。
5. 何を確認できて、何が残っているか
実施した端末・環境・条件、未実施項目、未解決の問題を記録します。実施率だけでなく、「重要なリスクをどこまで確かめたか」を説明できる状態にします。
「全部終わった」の先にある、品質の判断
テストで、不具合が一切ないと証明することはできません。また、重要な不具合が残っていれば、実施率が100％でも安心して公開できるとは限りません。
だからこそ、項目の消化状況と合わせて、重要な操作が成立するか、失敗時に重大な不都合が起きないか、残っているリスクは何かを整理します。その情報があって初めて、公開するか、修正を優先するかを判断しやすくなります。
クロスゲームズのQAでは、仕様の意図や実装背景を踏まえたテスト設計、潜在リスクの確認、開発チームとの連携を大切にしています。サービス内容は、テスト・QAサービスのページでご紹介しています。
「今の項目書で、利用者の困りごとまで確認できているだろうか」。そんな見直しのきっかけに、ぜひご覧ください。
次回は、「連打・戻る・やり直し。利用者は想定どおりに動かない」をお届けします。普段の操作の中にある見落としやすい条件を、もう少し具体的に考えていきます。
コメント