こんにちは！
株式会社アイスリーデザイン エンジニアリング部の芹田です。
以前投稿した「受け入れテスト（UAT）とは？」という記事では、たくさんの方に読んでいただきました。改めて自分の記事を読み返すと、受け入れテストの進め方や、発注側と開発側でやること等について、もっと噛み砕いて、具体的な例を用いてお伝えした方が良いなと感じたので、続編を書くことにしました。
大きなプロジェクトとは異なり、小規模開発や追加開発のような規模の場合、どこまでをどんなことに留意して進めれば良いかの塩梅がわからないという方もいらっしゃるのではないでしょうか。
私自身、初めて担当した受け入れテストの時は「何を考えて、何を準備して、何を確認すれば良いのか」をイメージすることが難しいと感じていた記憶があります。
そこで今回は、ユーザー受け入れテストにおいて開発側がどんな準備をすれば良いかという視点で、私の経験を交えてお伝えしていきます。
1. 「テストで何を検証したいのか」発注者側の期待を整理する
私たち開発側は、発注者（顧客）が「テストでどんな目的が達成されるのか？」を理解することが最も重要だと考えています。
特に発注者側が開発経験の少ない企業である場合は、開発側が思い描く観点から少しずれる場合があります。
例えば、あなたが一般消費者という立場で保険や不動産などを契約するシーンを思い描いてみてください。細かいことは、根拠として必要かも知れませんが、本当に必要なのは、「私にとってどう有用であるのか、損しない（信頼できる）情報源はどんなものか」が知りたいですよね？
受け入れテストも似ている点があると感じています。
私の場合、発注者側がテストに何を期待しているのかを理解するために、日頃のコミュニケーションを見直すことにしています。例えば、発注者が「どのような観点で話をしているか？」とか「システムにどの程度理解があるか？」などを意識して会話をするように心がけています。
場合によっては、直接テストで検証したいことについて聞いてしまうのも良いかもしれません。
また、言葉だけでなく表情にも注目することで、相手の気持ちや考えを推測することはできます。理解はできているが面倒なことはやりたくないと感じているのか、そもそも理解が浅く不安な表情になっているのかなど、今までのコミュニケーションを振り返ってみることもいいかもしれません。
2. 事前準備の重要性
発注者側の期待を理解したうえで、テストをスムーズに進めるための準備を行います。
発注者にとって受け入れテストは「システムが本当に使えるか」を確認する重要な場面なので、開発者は 技術的な対応だけでなく、スムーズに進行するための準備やサポートを意識すること が大切です。
3. 具体的な準備例
発注者側との契約内容や関係性などによっても、準備するものは変わってきます。今回は発注者が開発経験の少ない企業を想定して、準備のポイントを紹介します。
3.1 受け入れ基準の決定と確認
受け入れテストでは、システムが仕様書や契約書の要件を満たしているかを確認し、「合格」または「不合格」の判定を行います。その判断基準となるのが合否基準です。
主なチェック項目は以下のとおりです。
- 機能や画面操作が設計通りに動作するか
- 性能やセキュリティ要件を満たしているか
- 例外処理やエラーメッセージが適切か
基準を満たさない箇所があれば、発注者へ事前に説明し、合意を取ります。軽微な修正は後対応とし、重大な不具合は修正計画を決めた上で対応します。開発側は、発注者がスムーズにテストを進められるよう、合否基準を明確にし、判断に迷うポイントがないようにすることが求められます。
受け入れ基準のサンプル
| チェック項目 | 合格基準 | 備考 |
|---|---|---|
| 1. 仕様通りの動作 | 仕様書に記載された要件を満たすこと | 画面遷移、ボタン動作など |
| 2. 主要業務フロー | 業務手順どおりに実行できること | 業務担当者が実際に操作 |
| 3. 既存システムとの連携 | 正常にデータを送受信できること | API連携、DB接続 |
| 4. エラーハンドリング | 想定外の操作時に適切なエラーメッセージが表示される | 例外処理、バリデーション |
| 5. パフォーマンス | 指定の条件下で快適に動作する | レスポンスタイム2秒以内など |
| 6. セキュリティ | 不正アクセスが防止されていること | 認証・認可、SQLインジェクション対策 |
| 7. UI/UX | 操作が直感的で分かりやすいこと | ナビゲーションの統一性 |
3.2 受け入れテスト概要説明資料の準備
受け入れテスト概要説明資料
「そもそも受け入れテストは何をすべきなのか？」という問いに対して、すぐに明確な回答ができるような発注者の場合は不要になるケースもありますが、そうでない発注者の場合は概要説明資料を用意してあげるとよいでしょう。
ここで使う単語についても、発注者側のリテラシーを考慮してあげるとより良い資料となります。
特に共通認識を持ちづらい専門用語や、プロジェクトや会社ごとに異なる概念を持つ単語は極力避け、簡単な言葉でシンプルに説明するようにしましょう。
資料に掲載しておくといい項目
- テスト概要（目的、実施期間）
- 仕様の簡単な説明
- テスト範囲と操作方法（マニュアルがあれば参照でも良い）
- UAT環境の準備方法（本番環境との違いを記載）
- テスト実施の流れ（テスト期間、テスト実施後の報告フロー）
- テストの優先度一覧（必須・推奨の区分）
- 障害報告フォーマット（発生条件、スクリーンショットの添付方法）
- 承認プロセスのフロー（合格基準を満たした後の進行手順）
資料が多すぎても混乱させてしまったり、面倒に思わせてしまったりしますので、テストの規模に合わせて適切に調整することをお勧めします。
3.3 テストケースの準備
一般的に、受け入れテストのテストケース準備では、発注側と開発側がそれぞれ役割を担います。発注側は、業務フローに基づいたテストケースを整理し、実際の業務データに近いものを用意します。また、合否基準を明確にし、バグ報告のルールを決めます。
一方、開発側は、発注側がスムーズにテストできる環境を整えます。正常系・異常系のテストを網羅し、テスト手順やバグ報告の方法を案内することも必要です。
稀ではありますが、発注者側がテストするにあたって、何をテストすれば良いかが分からないケースもあります。
必要に応じてにはなりますが、開発側がテストしたテストケースを共有したり、テストケースを簡単に言語化したりして、何をやるべきかを明確にしておく必要があります。場合によっては、開発側がテストケースを作成することになるかもしれません。
発注者側は、基本的には他の業務に追われている中で時間を調整して対応することになります。そのことを十分に理解し、開発側の工数を考慮しながら組み立てていくとよいでしょう。
どのような場合も、両者が事前に準備を整えることで、受け入れテストを円滑に進めることができます。
最後に
いかがでしたでしょうか？
今回は受け入れテストを円滑に進めるための事前準備について以下の観点についてお伝えしました。
- 発注者の期待を理解する
- 明確な受け入れ基準を設定する
- 発注者がスムーズにテストできる環境を整える
開発側と発注者側で立場や知識の違いがあり、相手が何を求めているか、何を期待しているかといったことを事前に考えておくことで、やるべきことが見えてくる局面も多いと思います。
今後も様々なフェーズにおけるテストに関する記事を執筆していきます！
＞ アイスリーデザイン会社概要
＞ アイスリーデザインのアプリケーション開発支援
過去に、クライアント側にテスト経験が少なかったプロジェクトがありました。 私はクライアント側の視点を十分に考慮せず、テストの説明を形式的に進めてしまったことがありました。その結果、クライアントから、「何をどうすればいいのか？」「どんなテストを実施すれば良いのか？」「どの資料を参考にすれば良いのか？」など、多くの質問を受けることになりました。
最終的には丁寧に一つひとつ説明を重ねて理解してもらえましたが、事前に適切な準備をしていれば、双方の時間を無駄にせずに済んだと反省しています。