「申請する」を押した直後に、通信エラーが表示された。送れていないと思ってもう一度押したら、同じ申請が二つ登録されていた。
通信が不安定なとき、利用者が困るのは、画面が開かないことだけではありません。操作が成功したのか分からない、入力した内容が消える、復旧しても何をすればよいか分からない。こうした状態も、サービスの使い続けやすさに関わります。
前回は、端末や接続機器の状態変化を取り上げました。今回はWebサービスや業務アプリの通信断テストを題材に、処理の途中で通信が切れたあと、利用者が適切に作業を再開できるかを考えます。
※本記事の申請・予約の例は、説明用の架空例です。特定のお客様の事例ではありません。
通信エラーでも、処理が失敗したとは限らない
申請内容を送信してから結果が表示されるまでには、いくつかの段階があります。
- アプリから送信を始める
- サーバーが申請を受け付ける
- サーバーが処理結果を返す
- アプリが結果を受け取り、画面に表示する
この途中で通信が切れると、サーバーでは申請を受け付けていても、アプリには結果が届かない場合があります。
そのため、「通信エラーが出たので、申請されていないはず」とは判断できません。利用者に再送を案内する前に、成立済みの処理を確認できるのか、同じ操作を繰り返した場合にどう扱うのかを整理する必要があります。
テストでは、エラーメッセージの表示と、実際に保存された申請の状態を分けて確認しましょう。
通信を切るタイミングを分ける
通信断テストは、どこかで一度ネットワークを切り、エラーが出ることを確かめるだけでは十分ではありません。まずは、通信が切れると困る処理を選び、その前後の状態を並べます。
架空の申請フォームなら、次のように分けられます。
- 送信前に通信できなくなった
- 送信を始めたが、受付結果が分からない
- 受付は完了したが、完了画面が表示されない
- 完了画面の表示後に、申請一覧を取得できなくなった
それぞれで、期待する結果は違います。送信前なら入力を保持して再操作できるか、受付後なら登録済みの申請を確認できるかが主な確認点になります。
端末の機内モード切り替えだけで、すべてのタイミングを正確に作れるとは限りません。細かな条件を確認するときは、開発担当者と相談し、検証環境で応答を遅らせるなど、再現方法も合わせて決めます。再現できなかった条件は、確認済みにせず残しておきましょう。
復旧後の「もう一度」が重複を生まないか
通信が戻れば、利用者は止まっていた作業を進めようとします。このとき、何度も送信を求める画面になっていないかを確認します。
例えば、申請の受付は済んでいるのに、画面には送信ボタンが残っている場合です。再度押すことで別の申請が作られるなら、利用者の意図と結果がずれてしまいます。
確認したいのは、次のような点です。
- 結果が不明なとき、成立済みか確認する方法があるか
- 同じ申請を再送した場合の扱いが決まっているか
- 自動再試行と利用者の再操作が重なっても問題ないか
- 復旧後に表示される受付番号や申請内容が一致しているか
ボタンを押せなくする対応だけで判断せず、検証環境で確認できる記録や管理画面と照合します。画面が一度しか進まなくても、裏側で処理が重複していないかを見ることが大切です。
入力内容を残すときは、古い条件にも注意する
通信エラーのあと、入力内容が残っていれば、利用者は最初から入力し直さずに済みます。ただし、入力内容を残すことと、そのまま確定してよいことは別に考えます。
例えば予約フォームでは、通信が戻るまでの間に空き枠が埋まっているかもしれません。入力した希望日時は保持しつつ、再開時に最新の空き状況を確認する必要があります。
申請フォームでも、添付ファイルが一部だけ送信済みになったり、ログインの有効期限が切れたりする場面を考えます。
何を保持し、何を再取得し、何を利用者に確認してもらうのか。そのルールが曖昧なら、テスト担当だけで正解を決めず、仕様の確認事項として整理しましょう。
「通信エラー」の先の案内まで確かめる
エラーが表示されても、次の操作が分からなければ、利用者の作業は止まったままです。
「しばらくしてからお試しください」という案内が適切な場面もあります。一方、申請が成立したか分からない状態で再送だけを促すと、重複や問い合わせにつながる可能性があります。
テストでは、状態に応じて次のことが伝わるかを見ます。
- 入力内容が保存されているか
- 受付結果を確認中なのか、未送信なのか
- 利用者が再操作してよいのか
- 履歴の確認や再ログインが必要なのか
- 自分で解決できない場合、どこに問い合わせればよいか
実際には結果を確定できていないのに、「送信できませんでした」と言い切っていないかも確認点です。表示内容と、システムが把握している状態をそろえることで、利用者が次の行動を選びやすくなります。
状態の変化を追い、再現できる記録にする
ゲームでは、通信中に画面が切り替わる、接続し直す、別の操作が入るなど、複数の変化をまたいで状態を確認します。このように、操作前から復帰後までをつなげて見る視点は、申請や予約のテストにも役立ちます。
不具合を見つけたら、「通信を切ったら止まった」だけではなく、条件と結果を分けて残します。
- 端末、OS、ブラウザやアプリのバージョン
- 送信前の入力内容と画面の状態
- 通信を遮断した方法、タイミング、時間
- 復旧後に自動で起きた処理と、手動で行った操作
- 期待した結果と、実際の表示・保存内容
通信断の試験は、検証用の環境・アカウント・データを用意して実施します。実際のお客様の申請や予約、ほかの業務に影響する回線を、確認のために止めないようにしましょう。
社内で使える通信断テストのチェックリスト
- 送信前・処理中・受付後を分けている
- エラー表示だけでなく、実際の処理結果を照合している
- 結果が分からない状態での再送ルールが決まっている
- 自動再試行と手動操作が重なる場面を確認している
- 入力を保持する範囲と、最新情報を確認する範囲が明確になっている
- 復旧後に、利用者が状況と次の操作を判断できる
- 再現できた条件と、未確認の条件を区別して記録している
まとめ
通信断テストでは、エラーを表示できることに加えて、復旧後に正しい結果を確認し、作業を再開できることまで確かめます。
重要な処理を一つ選び、「通信が切れる直前に、どこまで進んでいたか」「戻ったときに、何を確かめる必要があるか」を並べるところから始めてみてください。確認項目を増やす前に、守りたい入力や処理を整理すると、優先するテストが見えてきます。
クロスゲームズでは、ゲーム開発・運営で培った視点を、Webサービスや業務アプリのテスト設計にも生かしています。通信断や再試行を含め、利用者が最後まで作業を進められるかを見直したい方は、テスト・QAサービスの詳細をご覧ください。
次回は「時間が足りないとき、何からテストする？ 利用者への影響で決める優先順位」を取り上げます。
コメント