システム開発のテスト工程｜発注者が知るべき受入テストの進め方

テスト工程はなぜ重要なのか

システム開発のテスト工程は、完成したシステムが要件通りに動作するかを確認する最後の砦です。

テストをおろそかにすると、以下のような問題が発生します。

• リリース後にバグが大量に見つかり、業務に支障が出る
• 「動くけど使いにくい」システムになり、現場に定着しない
• 本番データを入れたら想定外のエラーが発生する
• セキュリティの穴が見つかり、情報漏洩のリスクが生まれる

実際に、システム開発で失敗する原因の一つに「テスト・検収をおろそかにする」が挙げられています。テスト工程にしっかり時間をかけることが、プロジェクト成功のカギです。

テストの種類と全体像

システム開発の流れの中で、テストは複数の段階に分かれて実施されます。

発注者にとって最も重要なのは受入テスト（UAT: User Acceptance Test）です。これは開発会社ではなく、実際にシステムを使う発注者側が主体となって行うテストです。

単体テスト

プログラムの最小単位（関数やメソッド）が正しく動作するかを確認するテストです。開発者が実装と並行して行うため、発注者が直接関わることはほとんどありません。

結合テスト

単体テストで動作確認された機能同士を組み合わせて、データの受け渡しや連携が正しく行われるかを確認します。たとえば「商品を注文する → 在庫が減る → 請求書が生成される」といった一連の流れを検証します。

システムテスト（総合テスト）

システム全体を本番に近い環境で動かし、性能・セキュリティ・大量データ処理なども含めて総合的に検証します。開発会社側で行う最後のテストです。

受入テスト（UAT）

開発会社のテストがすべて完了した後、発注者が実際の業務シナリオに沿ってシステムを検証します。「要件通りに作られているか」だけでなく、「実際の業務で使えるか」を確認する重要な工程です。

発注者が主役：受入テスト（UAT）の進め方

Step 1：テスト計画を立てる

受入テストを始める前に、以下の項目を決めておきます。

Step 2：テストシナリオを作成する

実際の業務フローに沿ったテストシナリオを作成します。要件定義で決めた機能一覧をベースにすると漏れが少なくなります。

テストシナリオの例（受注管理システム）

Step 3：テストを実施する

テストシナリオに沿ってシステムを実際に操作し、期待通りに動作するか確認します。

テスト実施のポイント

• 正常系だけでなく異常系もテストする — 必須項目を空欄にしたらどうなる？数値に文字を入れたら？
• 実際の業務データに近いデータを使う — テスト用のダミーデータだけでは見つからない問題がある
• IT に詳しくないスタッフにも触ってもらう — 開発者や管理者では気づかない使いにくさが見つかる
• スマホやタブレットでも確認する — PCでは問題なくてもモバイルで崩れるケースがある

Step 4：不具合を報告する

不具合を見つけたら、以下のフォーマットで報告します。曖昧な報告は修正に時間がかかるため、できるだけ具体的に書くことが重要です。

開発会社との不具合報告のやり取りをスムーズにするコツは、開発会社とのコミュニケーション術でも解説しています。

テストでよくある失敗とその防ぎ方

失敗①：テスト期間が短すぎる

開発が遅れると、テスト期間が削られがちです。しかし、テスト期間の短縮はリリース後の不具合に直結します。

防ぎ方：契約時にテスト期間を最低2週間確保する。開発が遅延した場合は、リリース日を後ろ倒しにする。

失敗②：本番データでテストしない

テスト用のきれいなダミーデータだけでテストすると、本番データを入れたときに予想外のエラーが発生することがあります。

防ぎ方：本番データのコピー（個人情報をマスキングしたもの）を使ってテストする。特に文字数の長いデータ、特殊文字を含むデータ、大量のデータを試す。

失敗③：現場スタッフがテストに参加しない

IT部門や経営者だけでテストすると、実際の業務で使うスタッフの視点が欠けます。

防ぎ方：実際にシステムを使う現場スタッフをテストメンバーに含める。ITの知識がなくても「使いにくい」「わかりにくい」というフィードバックは非常に価値がある。

失敗④：「動けばOK」で終わらせる

機能が動くことだけ確認して、パフォーマンスやセキュリティのテストを省略するケースがあります。

防ぎ方：以下の観点もテストに含める。

• パフォーマンス — 大量データでも許容範囲の速度で動作するか
• セキュリティ — 権限のないユーザーがアクセスできないか
• ブラウザ互換性 — Chrome, Safari, Edge で正しく表示されるか
• モバイル対応 — スマホ・タブレットでも操作できるか

受入テストのチェックリスト

受入テストで最低限確認すべき項目をチェックリストにまとめました。

機能面

• 要件定義で決めたすべての機能が実装されているか
• 各機能が正しく動作するか（正常系）
• 不正な入力に対して適切なエラーメッセージが表示されるか（異常系）
• 検索・フィルター機能が正しく動作するか
• 帳票・PDF出力が正しいフォーマットで生成されるか

データ面

• データの登録・更新・削除が正しく行われるか
• 関連するデータが正しく連動しているか（在庫と受注の連動など）
• 本番に近いデータ量で動作に問題がないか
• データの移行が正確に行われているか

使いやすさ

• 画面の遷移が直感的か
• ボタンやリンクの配置がわかりやすいか
• エラーメッセージが具体的で対処法がわかるか
• 入力フォームの項目が適切か（不要な項目はないか）

セキュリティ・権限

• 権限のないユーザーが制限された機能にアクセスできないか
• パスワードの要件が適切か
• セッションタイムアウトが設定されているか
• 個人情報が適切に保護されているか

パフォーマンス

• 画面の表示が許容範囲の速度か（目安：3秒以内）
• 大量データの検索・集計が実用的な速度で行えるか
• 同時に複数人が操作しても問題なく動作するか

テスト完了後の検収ポイント

受入テストで問題がなければ、正式にシステムを「検収」します。検収は「この成果物を受け取ります」という正式な合意であり、契約上も重要な意味を持ちます。

検収前に以下を確認しましょう。

• 重大な不具合がすべて修正されているか
• 軽微な不具合について、修正スケジュールが合意されているか
• 操作マニュアルが納品されているか
• ソースコードが納品されているか（契約で定めている場合）
• サーバー・ドメインの管理情報が引き渡されているか
• 保守契約の内容が確認済みか（保守費用と契約のポイントを参照）
• 瑕疵担保期間が明確に定められているか（通常1〜3ヶ月）

まとめ

テスト工程は「開発の最終段階」ではなく、プロジェクト成功のための最後の関門です。

• テストは単体→結合→システム→受入の4段階で実施される
• 受入テスト（UAT）は発注者が主体で行う最重要テスト
• テスト計画・テストシナリオを事前に準備し、実際の業務データでテストする
• 不具合は「いつ・どこで・何をしたら・どうなったか」を具体的に報告する
• テスト期間は最低2週間確保し、開発が遅れても削らない
• 検収時には納品物の確認と保守契約の整備を忘れずに

テスト工程を含めたシステム開発の全体の流れはシステム開発の流れ完全ガイドで解説しています。

「テストの進め方がわからない」「受入テストをサポートしてほしい」という方は、お問い合わせからお気軽にご相談ください。FUNBREWでは、テスト計画の策定から受入テストのサポートまで対応しています。