納品前の動作確認環境のそろえ方｜本番との差をなくす

テスト環境で問題がなかったのに、公開後にフォームが送れない。そんな食い違いの多くは、画面の見た目では分からない環境差から生じる。納品時の品質を説明するためには「どの端末で」「何を操作して」「どんな結果になったか」を具体化する必要がある。検収の前に、実環境との差分を整理する進め方を扱う。

確認環境の一覧を先につくる

OS、ブラウザ、画面幅、ネットワーク条件、ログイン権限、言語設定を検証表に並べる。すべての端末を網羅すると約束するのではなく、発注者の実利用環境から優先順位を決める。指定されたブラウザのバージョンは記録に残す。

納品直前に検証担当が初めて環境を確認するのは危険だ。端末、ブラウザ、アカウント種別、接続先、権限を事前に一覧化し、検収で使う条件と照合する。追加条件があれば検証対象として明示する。

本番と検証の差分を見える化する

テスト用と公開用でドメイン、環境変数、認証設定、キャッシュ、外部APIの接続先が異なることがある。差分をチェックリストとして固定し、テスト環境で通った操作が本番でも通るとは限らないと考える。

ステージング環境だけ設定が緩い場合、本番で初めて失敗することがある。認証方式、リダイレクト先、API制限、通知メールの送信元など機能ごとに差を洗い出す。意図した差は理由を添えて残す。

本番とステージングの差分点検を外部へ頼む場合は、検証項目と証跡の納品範囲を見積書に入れる。 公開や納品の環境を整えるなら、レンタルサーバー エックスサーバーのようなレンタルサーバーも候補になります。

架空データだけでなく境界条件を試す

名前が短い利用者だけではフォームの崩れが見えない。長い会社名、未入力、複数行の自由記述、画像未設定、権限のないアカウントなどを用意する。ただし個人の実データを無断でコピーして試験に使わない。

通常のデータで成功することは例外処理の合格を意味しない。入力欄が空のとき、権限がないとき、通信が途切れたときの挙動を観察する。実データを持ち込まずに同等の条件を作れるかが準備のポイントだ。

テストの進め方や確認観点は、MDN Web Docsのテスト解説にもまとまっています。

スマートフォンの操作を独立して点検する

表示幅を狭めるだけでは、指で押せる領域、ソフトウェアキーボード、端末固有のスクロール挙動を確認しきれない。重要な申込導線は実機でも送信まで試し、画面収録や再現手順を添える。

画面が縮小表示されることと操作できることは別問題である。片手で押せないボタン、キーボードに隠れる送信欄、横スクロールを引き起こす要素を実機で確認する。画像の見た目だけの検収にしない。

実機テストを補うサービスを選ぶ際も、対象端末の網羅性と手作業の確認を分けて評価する。 記録とあわせて会計まわりも整えるなら、クラウド会計ソフト freee会計のようなクラウド会計もあります。

モバイルでの表示と操作の確認観点は、web.devの学習資料でも扱われています。

メールや決済など外部連携を通す

画面に完了と表示されたからといって、通知メールや顧客管理への登録が成功したとは限らない。入力から受信側の結果確認まで追い、エラー時に利用者へ何が伝わるかを確認する。金銭の伴うテストは事前に安全な方法を合意する。

フォームが送信完了になっても通知が届かなければ業務は回らない。テスト送信先と実際の受信確認先を決め、決済はテストモードの結果で判定する。実課金を伴う確認には発注者の明示的な承認を得る。

メール送信まわりの要件は、Googleのメール送信者のガイドラインに明記されています。

検証結果を再現可能な形に残す

「大丈夫でした」では検収資料として弱い。操作、期待結果、実測結果、確認日時、実施端末、証拠ファイルをひもづける。再現しない問題は条件と発生頻度を分け、未確認を合格に含めない。

「確認した」という口頭報告では不具合が再現できない。操作手順、期待結果、実際の結果、画面記録を残し、未修正項目を別表にする。検証日と対象バージョンを紐付ければ修正後の再試験も容易になる。

検証担当者の育成では、テストケース作成と不具合報告を実践できる研修内容が重要になる。 体系立てて学びたい場合は、Webスキルを学ぶオンラインスクール デイトラのようなオンラインスクールも選択肢になります。

リリース直前に設定変更を凍結する

検証後の修正が別の画面に影響することがあるため、変更範囲に応じた再テストを行う。最終成果物のバージョンとチェック表の対象版を一致させ、口頭で届いた修正依頼を記録から落とさない。

公開前に設定やコードを変更したなら、その時点から影響する検証をやり直す必要がある。差分を確認せずに古い合格記録を使い回さない。公開承認の直前には変更管理者と連絡経路を確定させる。

検収と保守の線引きを残す

納品時点で確認できた範囲と、運用開始後に追跡する課題を区別して引き渡す。発注側も受入条件を示しやすくなり、制作者は契約外の検証追加を無制限に抱えにくくなる。

納品は「サイトが一度開いた」だけでは終わらない。顧客が受け入れるテストの範囲と、公開後に見つかった不具合への対応窓口を区別する。保証内容や追加工数の判断は契約時点で確認したい。

判断に使う比較表

確認する場面	実際に見ておく材料
確認環境の一覧を先につくる	OS、ブラウザ、画面幅、ネットワーク条件、ログイン権限、言語設定を検証表に並べる
架空データだけでなく境界条件を試す	名前が短い利用者だけではフォームの崩れが見えない
メールや決済など外部連携を通す	画面に完了と表示されたからといって、通知メールや顧客管理への登録が成功したとは限らない
リリース直前に設定変更を凍結する	検証後の修正が別の画面に影響することがあるため、変更範囲に応じた再テストを行う

案件での使い方

納品検証では、制作会社の開発用アカウントでは操作できるのに、顧客の一般利用者権限では失敗する事態に注意したい。権限によって見えるメニューや書き込み先が異なるなら、少なくとも主要な利用者役割で同じ操作を確認する。検証用データの扱いと、本番環境へ持ち込まない情報も決めておく。

外部連携を試す際には、テスト通知を受け取るメールアドレスや検証用の決済番号を誰が用意するか決める。本番宛てのメールを誤送信したり、実際の購入処理を発生させたりしない設定を確認してから作業する。テスト用の代替動作が本番より簡略化されているなら、その限界を検収資料へ残す。

最後に確認した版と納品した版が違えば、それまでの合格記録は完全な証拠にはならない。修正したファイル、設定、連携先を明記し、変更に影響を受ける項目を選んで再試験する。時間を優先して一部を省略する場合も、未検証範囲を依頼者へ明示し、承認を得る必要がある。

検証表の項目は画面名ではなく操作の完了条件で書くと使いやすい。「予約ページを確認」ではなく、入力から確認メール受信までの成否を記載する。閲覧できることと取引が成立することは異なるためだ。

検収の手間を削れば一時的な制作費は下がるかもしれないが、納品後の無償対応が増えれば採算を悪化させる。実施した試験と残る不確実性を合意資料に残すことが重要だ。

運用時に確認したいこと

検収の基準を明確にするため、チェックの結果は合格、不合格、未実施を区別する。実行できなかった項目を「問題なし」と記すと、後で不具合が起きた際に判断材料を失う。テスト環境の制約で確認できない部分があるなら、追加確認が必要な条件を発注者と合意する。

最後の確認

制作した本人がテストすると、操作の前提を無意識に補ってしまうことがある。利用者が初めてアクセスした場面を想定し、説明を受けていない担当者が画面の指示だけで目的を達成できるか確かめる。手順の途中で迷った場所は、操作説明の不足なのか画面設計の問題なのかを分けて記録すると、修正の優先順位が決めやすい。

出典

• MDN Web Docs

CTA

仕事の取り方や単価の決め方で迷ったら、HYPEへご相談ください。→ お問い合わせはこちら

※本記事にはプロモーションを含みます。

合わせて読みたい

• レスポンシブの考え方
• 納品物のファイル管理の型
• レンタルサーバー比較｜制作の受け渡しで選ぶ3社