Webアプリの納品、何を確認すればいい？受入テストの進め方

最初に試すのは、毎日行う仕事を一つ

説明用の例として、研修への参加を社員が申請し、上司が承認するアプリを考えます。最初に試したいのは、各画面の表示より「社員が申し込み、上司が確認し、本人が結果を知る」までの流れです。本人には完了と出るのに上司の一覧に届かないなら、申請という仕事は終わっていません。

発注側が用意するのは、実際の操作順と、終わったと判断する条件です。会社名が長い、兼務の上司がいる、申請を差し戻すといった現場の事情を添えます。開発者が想定しにくい条件を持ち込むことに、発注側が確認する意味があります。コードを読めることより、仕事の流れを説明できることが役立ちます。

実際に確認する人も、業務ごとに選びます。企画担当だけでは、現場で行う修正や問い合わせ対応を見落とすことがあります。社員、上司、運営の担当者がそれぞれ自分の役割で操作すると、別の人の処理を待つ場面も再現できます。申請例なら、上司が不在で代理承認が必要な日にどう進めるかも相談します。最初から大量の試験項目を作るより、普段の仕事と例外の仕事を現場の言葉で並べると参加しやすくなります。

「正しく動く」を、目で確かめられる結果にする

「承認できる」だけでは、何を見れば合格かが曖昧です。「承認後、社員の画面が承認済みに変わり、同じ申請番号の通知が届く」と書くと、担当者が変わっても同じ判断ができます。期待する結果は、画面、保存された情報、通知先まで必要な範囲でつなげます。

Playwrightの公式ガイドは、利用者に見える動作を試し、試験同士を独立させる考え方を勧めています。手動確認でも、前の人が変更したデータをそのまま使うと再現が難しくなります。確認用の社員や申請を用意し、何を戻せば同じ条件で試せるかを開発会社と共有しておきましょう。

結果を確かめるデータには、受付番号のように対応が分かる目印を使います。画面に表示された件数が合っていても、別の申請への通知が送られている可能性は、件数だけでは見つけられません。一つの申請がどの一覧、どの通知へ進んだかを追うことで、仕事のつながりを確認できます。確認後に状態を戻す方法と、再度試すときに使うデータも決めておくと、修正前後を同じ条件で比べやすくなります。

表が収まらない場合は横にスクロールできます。

参考：Microsoft / Playwright：Best Practices

二回押したとき、途中で通信が切れたときも試す

利用者はいつも理想どおりには操作しません。反応が遅いと送信を押し直し、通信が切れるとページを開き直します。申請が保存された後に応答だけ届かなかった場合、再送で二件になる設計では困ります。画面が止まった場面でも、受付が成立したかを確認でき、必要なら安全にやり直せるかを試します。

試す失敗は、開発会社に検証環境で再現してもらいます。金銭や個人情報を扱う操作、取り消せない変更を優先し、本番で無計画に通信を切ったり実データを消したりしないことが大切です。承認画面を二人で開き、片方が承認した後にもう片方が差し戻すなど、同時操作も仕事に沿って選べます。

現場の端末で、説明なしでも最後まで使えるか

開発者の大きな画面では分かりやすくても、スマートフォンで入力するとキーボードがボタンを隠す場合があります。利用予定の端末とブラウザを決め、長い文や添付ファイルを使って試します。キーボードだけで移動できるか、文字を拡大しても内容が欠けないかも、業務を終えるための確認です。

W3C WAIのEasy Checksには、キーボード操作やフォーカスの確認など、初期点検の観点があります。ただし、それだけでアクセシビリティの全面的な適合を示せるわけではありません。専門的な評価が必要な範囲は別途合意し、今回の試験で確認した環境と操作を記録します。実際の担当者に説明せず試してもらうと、表示上の問題に加え、言葉の分かりにくさも見つけられます。

参考：W3C Web Accessibility Initiative：Easy Checks – A First Review of Web Accessibility

「動かない」より、直しやすい伝え方がある

不具合を報告するときは、「誰が、何を開いて、何を押し、どうなったか」を残します。発生時刻や申請番号があると、開発者が処理の記録と照合できます。画像は役立ちますが、パスワードや不要な個人情報を含めず、期待していた結果も文章で添えましょう。別の人が再現できる報告ほど、原因を絞りやすくなります。

指摘が出たら、合意した動作と違う不具合なのか、使って初めて欲しくなった機能なのかを相談します。どちらも大事ですが、費用や日程の扱いは同じとは限りません。修正後は報告した操作を再度試し、関連する通知や他の役割の操作も確かめます。未実施や外部サービスの準備待ちは、問題が出ていないことと分けて残します。

困りごとの大きさは、不具合の件数とは別に伝えます。ボタンのずれが複数あっても、別会社の資料が一件見える問題のほうが先に対処すべきです。「月末の処理が止まる」「別の手順で続けられる」「表示は違うが作業に影響しない」など、現場への影響を添えると修正順を相談できます。対応を後日にする場合は、代わりの手順を実際に使えるかも確認し、誰も把握していない未解決事項を残さないようにします。

機能の確認が終わったら、公開の準備も確かめる

受入テストが終わっても、本番の通知先や利用者の招待、問い合わせ窓口が未準備なら、運営は始められません。公開前には、実際の接続先、バックアップ、操作する人の権限、問題が起きたときの連絡先をそろえます。データ破損や他社情報の表示が残っているなら、軽微な見た目の修正と同じ扱いにはできません。

開発を依頼する段階で、担当者が確認する時間と、指摘の修正・再確認の時間を工程に入れておくと進めやすくなります。候補会社には、納品日に初めて見せるのか、途中で主要な流れを試せるのかを聞いてみてください。操作条件と結果の記録を受け取れば、後の機能追加でも、大切な仕事が壊れていないかを確かめる土台になります。

外部メールや決済を使うアプリでは、検証環境と本番の境界も受け取ります。検証用の疑似応答で画面を確認したことと、本番用アカウントの設定が正しいことは別です。本番でどこまで試すかは影響を考えて開発会社と決め、利用者へ不要な通知や請求が出ない方法を選びます。試していない範囲を明確にしておけば、公開後に問題が出た際も、環境設定と業務処理のどちらから調べるかを判断しやすくなります。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □最も重要な業務を、開始から完了まで選んだ。確認状況・メモ：
• □確認用の利用者とデータを用意した。確認状況・メモ：
• □成功後の保存先・通知先まで確認できる。確認状況・メモ：
• □重複、取消、通信失敗、権限外の操作を試す。確認状況・メモ：
• □利用予定の端末と操作方法で確認する。確認状況・メモ：
• □不具合・追加要望・未実施を分けて記録する。確認状況・メモ：
• □再確認と公開準備の時間を確保した。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Best PracticesMicrosoft / Playwright
• Easy Checks – A First Review of Web AccessibilityW3C Web Accessibility Initiative