Webサービス移行のテスト項目｜業務・データ・ログインを新旧で照合する

Webサービス移行のテストは、画面が開くかだけでなく、普段の業務が最後まで進むかを確認します。購入、申請、承認、請求などの流れを一つずつ書き出すと、画面と画面の間にある処理を確認できます。

テスト項目は、修正する開発担当者と、実際にサービスを使う業務担当者で決めます。以下の表を出発点に、サービス固有の業務や例外処理を加えてください。

機能ごとに、結果とデータの変化を確認する

会員サービスでは、一般ユーザーが他人の情報や管理機能にアクセスできないかも確認します。操作するアカウント、開始時の状態、実行する手順、期待する結果を一組にしてください。

たとえば申請テストなら、「申請ボタンが押せる」では足りません。申請者の履歴、承認者の一覧、通知メール、承認後の状態を同じ申請番号で照合します。この確認例は、操作とデータを結びつけるためのものです。

新旧の環境で同じ入力を試し、結果を照合します。金額、状態、日時、出力ファイル、通知が対象です。変更すると合意した仕様は別に記録し、意図していない差を調べます。

データ移行では、件数だけでなく、会員と取引の関連、添付ファイル、権限が維持されるかを確認します。ログイン方法を変えるなら、移行済みの利用者と新規登録者の両方を試します。移行設計の確認点とテスト範囲を合わせます。

決済の検証用環境、メールのテスト送信先、外部APIの接続先を用意します。検証用データを入れていても、本番の送信設定が残っていれば社外へ処理が出る可能性があります。

本番と似せる部分は、移行先の実行環境、設定、データの形式です。顧客の実情報まで同じにする必要があるかは別途判断します。テスト用のアカウントや、条件を満たすダミーデータを用意してください。

画像やファイルの保存先も分け、検証中の削除が本番へ影響しない構成を確認します。

既存サービスに自動テストがない場合も、重要な操作を手順書として残せます。ログイン、登録、承認、出力といった反復する業務を優先し、期待する結果を明記します。

人が一度見ただけの確認と、何度でも実行できるテストは役割が異なります。今回の移行で作る自動テストと、業務担当者が判断する表示・運用の確認を分けて合意します。

不具合が見つかったら、修正箇所だけでなく、影響する操作も再確認します。同じエラーが再発しない条件を残すと、次の更新でも使えます。

確認した機能、未確認の機能、残っている不具合、公開を判断する人を記録します。修正が終わっていても、業務担当者の確認が未了なら、その状態を明確にしてください。

公開後は、アクセス、エラー、通知、定期処理を確認します。旧版へ戻す際には、切り替え後に増えたデータの扱いも必要です。コードとデータを合わせて戻す手順を決めておきます。

依頼時の整理はサービス移行チェックリスト、全体の方針はPHPサービスの再構築ガイドにまとめています。テスト範囲を見積もりへ含めることで、開発側と業務側の作業分担を確認できます。