「予約する」を押しても、画面が変わらない。もう一度押してみる。入力内容が気になって前の画面へ戻り、修正してからやり直す。
利用者にとっては、どれも自然な操作です。しかし、順番どおりに一度ずつ操作するテストだけでは、こうした場面の問題を見落とすことがあります。
前回は、確認項目を作る前に「利用者の何を守るか」を考える大切さを紹介しました。今回は、日常的な操作の中にあるリスクを、どのようにテストへ組み込むかを整理します。
※本記事の予約・購入・申請の例は、説明用の架空例です。特定のお客様の事例ではありません。
1. 「なぜ、その操作をしたくなるのか」から考える
想定外の操作を調べるというと、ボタンをむやみに押したり、無理な手順で画面を動かしたりすることを思い浮かべるかもしれません。
まず考えたいのは、利用者がそうする理由です。
- 反応がないので、もう一度押す
- 間違いに気づいて、前の画面へ戻る
- 失敗したように見えたので、最初からやり直す
- 確認したい情報があり、別の画面を開く
例えば、申請ボタンを押した後に何も表示されなければ、「押せていなかったのかな」と感じるでしょう。処理が始まったことや、待つ必要があることが伝わるかも確認対象です。
利用者の行動を入口にすると、単なる連打テストではなく、「不安になって再操作しても、申請が重複せず、結果が分かるか」という目的のある確認になります。
2. 同じ操作を「処理前・処理中・処理後」で分ける
同じボタンを2回押しても、押したタイミングによって確認すべきことは変わります。
予約サービスなら、少なくとも次の状態を分けて考えます。
- まだ予約を送信していない
- 送信して、結果を待っている
- 予約は成立したが、完了画面はまだ出ていない
- 完了画面が表示されている
この各状態で「もう一度押す」「前に戻る」「開き直す」を試すと、確認したい組み合わせが見えてきます。
ゲームでも、操作を受け付ける前後や、場面が切り替わる途中では状態が変化します。クロスゲームズでは、ゲーム開発・運営で培った、操作と状態の組み合わせを追う視点をQAに生かしています。
ただし、すべての組み合わせを無制限に増やす必要はありません。予約の確定、決済、申請の送信など、重複や取り消しの影響が大きい処理から優先して整理します。
3. 「画面が戻った」と「処理が取り消された」を分ける
確認画面で「戻る」を押したら、入力画面へ戻れた。これだけで確認を終えていないでしょうか。
例えば、予約の送信後に前の画面へ戻った場合、画面が変わっても予約自体は成立しているかもしれません。その状態で日時を変えて再送すると、新しい予約として扱われるのか、変更として扱われるのか。先に仕様を合わせる必要があります。
確認したいのは、次のような点です。
- 入力内容は、仕様どおり保持または破棄されるか
- 戻る前に成立した処理の状況を確認できるか
- 修正後の金額や選択内容が、古いまま残っていないか
- 再送したとき、意図しない予約や申請が増えないか
アプリ内の「戻る」と、ブラウザや端末の戻る操作も、利用できる範囲で分けて確認します。
どの操作を許すかはサービスによって異なります。テスト担当だけで「こう動くはず」と決めず、期待する動作が曖昧なところは、仕様の確認事項として整理します。
4. 連打を止めた後も、次の操作へ進めるか
重複を防ぐため、送信中はボタンを押せなくすることがあります。その場合も、ボタンが無効になれば確認終了というわけではありません。
- 処理中だと分かる表示があるか
- 完了後は、結果や受付番号を確認できるか
- 失敗した場合は、必要に応じて再操作できるか
- ボタンが押せないまま、先へ進めなくなっていないか
また、画面上で押せなくなっていても、それだけで処理の重複が防げているとは判断できません。テスト環境で確認できる範囲に応じて、予約件数や申請状態など、実際の結果も照合します。
結果が分からない状態では、利用者に再操作を求めることが適切かどうかも重要です。成立済みかを確認する手順や、問い合わせ先の案内が必要な場合もあります。
実際のお客様の予約や決済に影響しないよう、検証用の環境・アカウント・データを用意して実施しましょう。
5. やり直した後に「古い情報」が残らないか
入力エラーを修正し、もう一度送信したところ、完了画面が表示された。このときも、表示された結果の中身まで見ます。
例えば購入手続きなら、数量を変更した後の合計金額、クーポンの適用状況、注文内容がそろっているか。申請なら、修正した内容が保存され、古いエラー表示が消えているかを確認します。
やり直せることと、正しい内容でやり直せることは、分けて確認したいポイントです。
問題が起きた場合は、「何度か押したらおかしくなった」だけでなく、直前の状態、操作の順序、押した回数、画面が切り替わる前後のどちらだったかを残します。期待した結果と実際の結果も分けると、開発側が原因を調べやすくなります。
社内で使える確認チェックリスト
今あるテスト項目に、次の観点が入っているかを見直してみてください。
- 利用者が連打ややり直しをしたくなる場面を挙げている
- 送信前、処理中、成立後を分けて確認している
- 戻ったときの入力内容と、成立済みの処理を確認している
- 画面表示だけでなく、保存された内容や件数も照合している
- 失敗後に、結果を確認して適切に次の操作へ進める
- 操作の順序とタイミングを、再現できる形で記録している
まとめ
連打・戻る・やり直しは、特別な利用者だけが行う操作ではありません。反応を待つ間の不安や、入力を修正したい気持ちから、誰でも行う可能性があります。
その理由を考え、処理の前後で何が変わるかを追うことで、確認する項目を具体的にできます。大切なのは、操作後の表示だけでなく、処理の結果と、利用者が次へ進めることまで確かめることです。
クロスゲームズは、仕様の意図や状態の変化を踏まえたテスト設計を大切にしています。「通常の手順は確認しているけれど、途中で戻ったり、やり直したりする場面まで見られているだろうか」。テストの見直しをご検討の方は、サービスページもぜひご覧ください。
次回は「端末とアプリの境目に潜む不具合。電池・接続・復帰の確認ポイント」を取り上げます。
コメント