リリースまでに、すべてのテストを終えられそうにない。確認項目は残っているのに、修正の確認も追加されていく。
そんなとき、項目書の上から順に進めるだけでは、重要な確認が最後まで残ることがあります。
Webサービスや業務アプリのテストでは、利用者への影響と、問題が起こりそうな条件を整理して、確認する順番と範囲を決めることが大切です。リスクに基づいてテストの選び方や優先順位を考える方法は、「リスクベースドテスト」と呼ばれます。
今回は、限られた時間で何から確認するか、確認できなかったことをどう共有するかを整理します。
※本記事の予約サービスの例は、説明用の架空例です。特定のお客様の事例や、実際の成果を示すものではありません。
最初に、止まると困る作業を挙げる
優先順位を考えるときは、画面やボタンの一覧から少し離れ、利用者が何を終えたいのかを書き出してみましょう。
予約サービスなら、「予約画面を表示する」だけでなく、「日時を選び、予約を確定し、あとから内容を確認する」までが一連の作業になります。
その流れに沿って、起きると困ることを並べます。
- 予約したつもりなのに、記録が残っていない
- 同じ予約が重複して登録される
- 変更した日時が、受付側に伝わっていない
- 自分の予約を確認できず、次に何をすればよいか分からない
ここで整理した困りごとが、確認項目を選ぶ理由になります。「この項目は何を確かめるためか」を説明できるようにすると、項目数だけで優先順位を判断しにくくなります。
影響の大きさと、起こりやすさを分けて考える
まずは、問題が起きた場合の影響を見ます。
金額や保存データが誤るのか、業務が止まるのか、利用者自身でやり直せるのか。問い合わせや手作業による復旧が必要なのかも確認します。
次に、問題が起こる可能性を考える材料を集めます。
- 今回、処理や設定を変更した箇所か
- 複数の機能や外部サービスにつながっているか
- 過去に似た不具合が出ているか
- 利用者が日常的に通る操作や条件か
- 仕様や実装について、分かっていない点が残っているか
利用頻度は、問題に遭遇する機会を考える材料です。ただし、よく使われる機能だから必ず壊れやすいわけではありません。反対に、めったに使わなくても、誤った相手に情報が表示されるなど、影響の大きい問題は優先して扱う必要があります。
判断材料がない場合は、「起こりにくい」と決めず、「未確認」として残します。最初から細かな点数表を作らなくても、影響・判断の根拠・不明点を言葉でそろえることから始められます。
変更した場所と、つながっている処理を確認する
修正箇所だけを確認しても、その前後の処理への影響が残ることがあります。
例えば、予約日時の変更機能を修正した場合です。変更画面が動くだけでなく、予約一覧、受付側の記録、通知などにも、変更後の日時が正しく反映されるかを考えます。
開発担当者には、次のように確認すると整理しやすくなります。
- 今回変えた処理は、ほかの機能でも使っているか
- 保存する情報や、外部とのやり取りは変わったか
- 変更前に作られた予約にも影響するか
- 元に戻す場合、データの扱いに注意点があるか
テスト担当だけで影響範囲を推測しきろうとせず、実装の変更内容と、利用者の操作の両方から確認候補を絞ります。
また、重要なテストほど、準備に時間がかかる場合があります。外部サービスとの接続や特別なデータが必要なら、実施直前まで待たず、先に準備を進めておきましょう。
予約サービスで、確認する順番を考えてみる
予約日時の変更機能を更新する架空のケースを考えます。確認の順番は、例えば次のように組み立てられます。
まず、主要な作業が最後まで成立するかを確認します。予約の作成・変更・確認を一通り行い、利用者側と受付側の記録が一致するかを見ます。ここで問題が見つかった場合は、関連する確認の進め方も見直します。
次に、影響の大きい状態変化を確認します。変更の処理中に再操作した場合や、結果が分からないまま画面を開き直した場合に、予約が重複したり、古い日時が残ったりしないかを調べます。
そのうえで、対応する端末・ブラウザや入力条件へ確認を広げます。利用状況と変更内容から優先する環境を決め、後回しにする条件も記録します。ひとつの環境で正常だった結果を、すべての対応環境へ当てはめないことが大切です。
これは、順番の一例です。文字の欠けによって料金や重要な注意点が読めないなら、表示の問題でも優先度は高くなります。「機能だから先、見た目だから後」と機械的に分けず、利用者への影響を確かめてください。
重要な操作には、中断や再開の条件も添える
正常な手順が通ることに加えて、その途中で何が変わると困るかも考えます。
例えば、予約変更なら「変更前」「変更の処理中」「変更完了後」で、再操作したときに期待する結果が異なります。限られた時間では、こうした状態の境目から、影響の大きい条件を選びます。
ゲームでも、場面の切り替わりや通信、直前の操作によって、確認すべき状態が変わります。このように前後の状態を追う視点は、予約や申請のテストにも応用できます。
確認内容は、次の形で短く残しておくと共有しやすくなります。
- 利用者の作業：予約日時を変更する
- 困ること：変更前と変更後の予約が両方残る
- 確認する条件：変更処理の途中で、同じ操作を繰り返す
- 期待する結果：合意した仕様どおりに処理され、確定した日時を確認できる
- 優先する理由：受付の重複や、利用者の来訪日時の誤認につながる
- 未決事項：処理結果が不明なときの再操作ルールを確認する
期待する結果が決まっていなければ、テスト担当の判断で合否を付けず、先に仕様の確認事項として共有します。
確認できなかったことも、リリース判断の材料にする
時間内にテストが終わらなかったときは、未実施の項目を一覧から消さずに残します。
少なくとも、次の状態を区別しましょう。
- 実施して、期待どおりだった
- 実施して、問題が見つかった
- 環境や仕様の問題で、実施できなかった
- 時間が足りず、まだ実施していない
結果を報告するときは、重要な作業ごとに、確認した環境・条件と、残っている問題を伝えます。修正後に再確認していないものも、解決済みとして扱わないようにします。
重大な問題や未確認事項が残る場合は、追加確認の時間を確保する、公開する機能を絞る、公開時期を見直すなどの選択肢を、リリースの判断責任者へ示します。
「優先順位を付けたから公開してよい」という結論にはなりません。何を確かめ、どのリスクが残っているかを共有して、判断できる状態を作ることが目的です。
社内で使える優先順位のチェックリスト
- 利用者が最後まで終えたい作業を挙げている
- 金額・データ・業務停止など、問題が起きた場合の影響を整理している
- 起こりやすさの判断に、変更内容や過去の不具合などの根拠がある
- 仕様が不明な箇所を、低リスクとして扱っていない
- 修正箇所だけでなく、つながる機能も確認候補に入れている
- 重要な操作について、中断・再操作・再開の条件を検討している
- 未実施・実施不能・未解決を分け、判断責任者に伝えている
まとめ
テストの時間が足りないときは、利用者への影響と、問題が起こりそうな条件を整理して、確認する順番と範囲を決めます。
まずは、重要な作業をひとつ選び、「何が起きると困るか」「なぜ先に確認するのか」「何がまだ分からないか」を書き出してみてください。優先順位の理由を共有できると、追加の修正や仕様変更が入ったときにも、確認計画を見直しやすくなります。
クロスゲームズでは、ゲーム開発・運営で培った視点を生かし、Webサービスや業務アプリのテスト設計、テスト実行、不具合報告、改善提案をご支援しています。
重要な操作や変更の影響を踏まえ、確認範囲から相談したい方は、テスト・QAサービスの詳細をご覧ください。
コメント