検収テストの項目シート

1. 検収の前に決めておくこと

テストを始める前に、合否の基準と手続きを開発会社と合意しておきます。基準がないまま触り始めると、気づいた点がすべて「不具合」として扱われ、仕様通りの動作なのか直すべき欠陥なのかで議論になります。契約書に検収期間が定められている場合は、その日数を過ぎると自動的に合格とみなされる条項が入っていることもあるため、期間内に確認を終えられる体制を先に組んでください。確認する人の時間を、業務の予定として先に押さえておくことをお勧めします。

• 検収の期間はいつからいつまでか（契約書の記載を確認する）
• 確認する人は誰か。業務を知る人と、初めて触る人の両方を入れられるか
• 不具合の報告先と形式（記録の残る手段で、画面と手順を添えて）
• 「仕様通りだが変えたい」ものは、不具合ではなく追加の相談として分けて扱う

2. 代表的な業務の流れを最初から最後まで通す

機能ごとにばらばらに確認するより、利用者が実際に行う一連の流れを通しで試すほうが問題を見つけやすくなります。個々の機能は動いても、つなぎ目で止まることがあるためです。登録から利用、そして運営側の対応まで、実際の業務と同じ順番でたどってください。途中で止まらずに最後まで到達できるかが最初の関門です。ここで止まる場合、他の確認に進む前に修正を依頼したほうが効率的です。

• 利用者が新規に登録し、最初の目的を達成するまでを通しで実行する
• 運営側がその利用者の登録内容を確認し、必要な対応を行うまでを実行する
• 同じ流れを、2人目、3人目の利用者でも実行する（1件目だけ動く不具合があります）
• 実行した手順と結果を記録する（後で再現できる形で）

3. 入力を意図的に間違える

正しく入力したときに動くのは当然として、確認すべきは間違えたときの振る舞いです。空欄のまま送信する、極端に長い文字を入れる、全角と半角を混ぜる、といった操作は、実際の利用者が日常的に行います。エラーの表示が出るか、何が悪いのか読んで分かる文言になっているか、そして入力した内容が消えてしまわないかを見てください。入力のやり直しを強いる画面は、それだけで利用者が離れる原因になります。

• 必須項目を空欄のまま送信する
• メールアドレス欄に記号だけ、電話番号欄に文字を入れるなど、形式の違う値を入れる
• 非常に長い文章、絵文字、改行を含む文章を入れる
• エラー後に入力済みの内容が消えていないか
• 送信ボタンを続けて2回押したときに、二重に登録されないか

4. 権限とアクセス範囲を確かめる

見えてはいけない情報が見えていないかは、公開後に発覚すると影響が最も大きい部分です。テスト用のアカウントを2つ以上用意し、別の利用者としてログインし直して、他人のデータが見えないかを実際に試します。画面上にリンクがなくても、URLを直接入力すれば開けてしまうことがあるため、そこも確認してください。個人情報を扱うサービスであれば、ここは特に時間をかける価値があります。

• 利用者Aでログインし、利用者Bのデータの画面を直接開こうとする
• ログアウトした状態で、管理画面のURLを直接開く
• 権限の違う担当者（一般・管理者など）で、操作できる範囲が分かれているか
• 退会や利用停止をした利用者が、その後ログインできないか

5. 想定する端末と環境で見る

開発者の画面では整っていても、実際の利用者の環境では崩れていることがあります。契約時に対応範囲として合意した端末とブラウザで、順に確認してください。逆に、合意していなかった環境で崩れていた場合、それは不具合ではなく範囲外の要望として扱われます。ここでも事前の取り決めが効いてきます。合意した範囲が実態と合っていないと感じたら、検収の場ではなく別途の相談として持ち出します。

• 対応範囲として合意した端末とブラウザの一覧を確認する
• スマートフォンの縦画面で、ボタンや文字が読めるか、押せるか
• 文字を大きくする設定にしたときに、レイアウトが崩れないか
• 通信が遅い状態で開いたときに、読み込み中であることが分かるか

6. メール・通知・外部サービスとの連携を試す

システム本体が動いても、メールが届かない、決済が完了しないといった問題は、外部サービスとの接続部分で起こります。テスト用の設定のまま納品されていないか、本番用の設定に切り替わっているかを必ず確認してください。特に決済は、テスト設定のまま公開すると売上が立ちません。届いたメールについては、差出人名・文面・返信先が自社の名義として適切かどうかも合わせて見ておきます。

• 登録完了、パスワード再設定などの自動メールが実際に届くか
• 迷惑メールフォルダに入っていないか
• メールの差出人名・文面・返信先が自社のものとして適切か
• 決済や外部サービスとの連携が、テスト環境ではなく本番の設定を向いているか
• 連携先が応答しないときに、画面がエラーのまま固まらないか

7. データの取り出しとバックアップを確認する

将来、別の仕組みに移行したり、集計のために分析したりするとき、データを取り出せるかどうかが問われます。納品時に確認しておかないと、必要になったときに追加の開発費と時間がかかります。あわせて、データの保存と復元の仕組みがどうなっているかを説明してもらい、記録として残してください。バックアップは「取っています」という言葉ではなく、頻度・保存期間・戻せる時点まで具体的に確認します。

• 登録されたデータを一覧で取り出せるか（管理画面からの書き出し、または依頼手順）
• バックアップは、どこに、どの頻度で、何日分保存されるか
• データが失われた場合に、どの時点まで戻せるか
• 個人情報を含むデータの保管場所と、アクセスできる人の範囲

8. 見つかった点を分類して伝える

気づいた点をすべて同列に並べると、対応の優先順位がつかず、開発側も何から手をつけるか判断に迷います。公開を止めてでも直すべきものと、公開後でも直せるものを分けて伝えると、検収が前に進みます。分類は発注側が仮に付け、最終的に双方で合意する形が現実的です。ここで「すべて重大」としてしまうと、本当に重大なものが埋もれ、結果として公開が遠のきます。

9. 検収を終えるときに残すもの

合格の判断を口頭で済ませず、記録として残します。何を確認して合格としたのか、どの項目を公開後の対応として残したのかが書かれていれば、後から問題が起きたときの話し合いが早く済みます。あわせて、保守の窓口と緊急時の連絡方法を、このタイミングで確定させてください。納品が終わると相手の体制が変わることがあるため、誰に連絡すればよいかを書面で押さえておく意味があります。

• 確認した項目と結果の記録（このシートに日付と担当者を入れて保管する）
• 公開後に対応すると合意した項目と、その期限
• 保守の範囲・窓口・連絡方法・対応できる時間帯
• 各種アカウント（サーバー、ドメイン、外部サービス）が自社名義になっているか