システム開発は設計・開発・テストの工程を経て、クライアント(発注)側へ納品されます。実際にシステムが納品されるかどうかは、クライアント側が受け入れテストを行い、最終的な判断を下します。

今回は、受け入れテストとはなにか、そして受け入れテストを実施するべきタイミングや種類についてご紹介します。

受け入れテスト(UAT)とは?

受け入れテスト(UAT)とは?

受け入れテスト(UAT=User Acceptance Test)とは、開発されたシステムが正しく仕様を満たしているか、仕様書の文言に誤りがないか等を、発注したクライアント側が確認して納品を受け付けるか否かを判断するテストです。

受け入れテストにおけるシステムのテストは、主に以下の要点をおさえて実施します。

本番環境と同等の環境、および実データで検証する

テスト環境でのテストは入念に行なっていても、実際にシステムが稼働する環境や、実際の業務で利用されるデータでの検証を行わなければ、リリース後に不具合が発生する可能性もあります。本番環境と同等の環境、および実データでシステムをテストすることは重要です。

実際の業務シナリオをベースにテストを行う

統合テストの段階でも、実際の業務に則ったシナリオでテストが行われることは多いですが、全てのユースケースを満たせているとは限りません。受け入れテストの段階でユースケースを網羅したテストケースを作成して、実際の業務シナリオに沿ってシステムが問題なく利用出来ることを検証します。

外部システム・サービスとの連携を確認する

こちらも前段階のテストで既に検証を行なっていたとしても、テスト環境と本番環境では、実際に連携する外部システム・サービス側で環境が異なる場合があります。

そのため、受け入れテストの段階で外部システム・サービスが本番環境と連携されても問題がないかを検証します。受け入れテストに問題がなければ、システム等の成果物一式はクライアント側へ納品されることになります。

テストによって不具合や仕様漏れが見つかった場合は、開発側に差し戻して修正を行ってもらったり、場合によっては追加発注という形で対応を行います。

受け入れテストはクライアント側で引き受けるのが一般的ですが、テストに必要な人員の不足等、テストの体制をクライアント側が整えられない場合もあります。その場合は、外部企業へ第三者検証として受け入れテストを委託するケースがあります。

第三者検証については、こちらの記事でも詳しく紹介しているのでぜひご確認ください。

受け入れテストを実施するべきタイミングは?

開発側でのシステムテストが終わったリリース直前のタイミングで行われることが基本的です。受け入れテストはシステムの不具合を見つけることが目的ではなく、実際の業務でシステムを問題なく利用できるのかという観点で検証を行います。

そのため、システムの不具合については開発側のテスト工程で徹底的に解消してもらった後、つまりリリース直前の最終チェックとして行われることが多いです。

受け入れテストの重要性とは?

受け入れテストの重要性とは?

受け入れテストの重要性を、システム開発手法の1つであるウォーターフォール開発を例に説明します。

要件定義、基本設計、詳細設計、コーディング、テストをシステム全体規模で上流工程から順に行っていく開発手法がウォーターフォール開発です。ウォーターフォール開発についてはこちらの記事でも詳しく紹介しているのでぜひご確認ください。

ウォーターフォール開発において、開発工程とテスト工程をレベルに応じて対に並べて、各工程の対応関係を明示したV字モデルというものがあります。

V字の左側から要件定義が始まり、開発工程を進める度に下へ降っていき、コーディング・単体テストの部分で折り返して、テスト工程を上へと並べていきます。

V字モデル

上記画像のようにV字で並んだ工程を左右で見比べることで、各開発工程に対応したテストがどれに当たるのか、何に着目したテストを行うべきであるかが一目見て分かります。そして、受け入れテストは要件定義と対になっています。

つまり要件定義で定義した、クライアント側がシステムに実装してほしい機能についてのテストを受け入れテストで行います。

受け入れテストが十分でなければ、以下のリスクが増大してしまいます。

  • システムリリース後のユーザー評価が低下
  • 仕様漏れがあった場合の修正コスト増加
  • 不具合によるシステム停止時の損失

システム開発を進めるにあたって一番大切な要件定義で決められた内容が、システムに正しく反映されているかを確認する最終的なテストなため、受け入れテストの重要性は非常に高いです。

また、V字モデルでは要求分析の対が受け入れテストとなる考え方もありますが、こちらもクライアントの求める機能が実装されているかどうかを確認することに違いはないため、受け入れテストが重要である点は変わりません。

要求分析については、こちらの記事でも詳しく紹介しているのでぜひご確認ください。

運用テストとの違い

運用テストとの違い

運用テストは、テストデータや計画書、仕様書などを作って進めていきますが、すべて開発者が作ったものが基準です。対して受け入れテストはユーザーが作成した要求仕様書が基準となり、要求定義書を作り想定できる動きや環境などを考え作成していきます。

運用テストは、テスト環境の定義が適切であるかを判断することが重要です。さらに、エラーや障害が起きた場合の手順、応答時間や処理時間についても運用テストで確認できます。

受入テストは、欲求仕様で設定した内容通りに動作していることをユーザーが判断します。運用テストがシンプルなシステムで導入されやすいのに対して、受入テストは複雑で大規模なシステムに導入されることが一般的です。

受け入れテストの種類

受け入れテストの種類

受け入れテストはいくつかの種類があり、様々な観点で行われます。

1.運用受け入れテスト

システムやデータのバックアップ、ユーザー情報の管理、セキュリティ、災害時のシステム復旧等の観点でテストを行います。運用時に問題なく運用出来るかを検証するテストです。

2.マニュアルテスト

システムの運用に関するマニュアルの文章に誤字や齟齬がなく、正しいかどうかを検証するテストです。

3.契約による受け入れテスト

契約書に記載された品質・納期等の項目が、実際に満たされているかを検証するテストです。

4.規定による受け入れテスト

安全基準や法律、ISO9001やISO14001に準拠した品質が保証されているか等の観点でテストを行います。

5.ベータテスト

システムやサービスを、公開直前のバージョン(ベータ版)としてユーザに提供して、機能や使い勝手、利用する実環境でのパフォーマンス等の評価を行なってもらうテストをベータテストと言います。

ユーザーは実際の作業工程に基づいてシステム・サービスを利用して、機能の不備、抜け漏れ等がないかを確認します。操作方法は全てユーザーに委ねられるためブラックボックステストとなりますが、様々な利用パターンを網羅的に検証出来るため、ベータテストはおすすめの手法です。

受け入れテストを実施する際の流れ

受け入れテストを実施する際の流れ

受け入れテストを実施する際は次のような流れとなるのが一般的です。

  • 計画
  • 構築・準備
  • 実施

1.計画

まず受け入れテストをおこなう目的を明確にして、テストの手法や予定などの計画を設定します。開発者が作成したテスト計画書を基準として、発注側が確認したあとテスト仕様書を作成することが必要です。

2.構築・準備

テスト計画書や仕様書が作成できたら、構築や準備を進めていきます。事前にテストに活用する端末やアカウント制限、担当者などを確認します。

システムを使って普段業務をおこなっているメンバーがテストに参加することが一般的です。受入テストは実際に利用してから不具合がでないかどうかを確認することが目的であるため、システムの使い方や業務内容を熟知している必要があります。

3.実施

構築段階が終わったらテストを実施していきます。テストの進捗状況は常に把握する必要があり、検証結果は誰もがわかるように共有することが重要です。

テストの段階で不具合が発生した場合は開発担当者が即座に対応することが求められます。テストの段階で不具合がなくなれば受け入れテスト完了です。

受け入れテストを実施の注意点

受け入れテストを実施の注意点

受け入れテストを実施する際次の点に注意が必要です。

  • プロジェクトの遅延
  • 網羅基準の設定
  • 合否基準の明確化

1.プロジェクトの遅延

受入テストは重要なテストであり、念入りにチェックをするため時間がかかりがちです。しかし、プロジェクトの最終段階でおこなわれるテストであることから、プロジェクト全体的に遅延してしまうと受入テストの時間を短くしなければいけないことがあります。

2.網羅基準の設定

受入テストは最終フェーズでおこなうことから、全体的に進行が遅れているとすべてのテストをできない可能性があります。しかし必要なテストが抜けてしまうと、不具合につながる可能性があるためテストの優先順位をあらかじめ決めておきましょう。

進行が遅れているからといってリスクが高いポイントのチェックが抜けてしまうと、あとから大きなトラブルになるリスクがあります。

3.合否基準の明確化

同じシステムであっても受け入れテスト担当者によって合格の基準が異なります。そのため、テストを始める前に合格基準を明確にすることが重要です。

合格基準はユーザーの要望を基準として要求を作り、要求を基準としてシステムを作成する目的や方法などを開発者と発注者の間で確認し要件を作ります。テストの合格基準は要件を基準として作成します。

受け入れテストでよくある3つの質問

受け入れテストでよくある3つの質問

受け入れテストでよくある質問として次の3つを解説します。

  • 受け入れテストの外注化は可能ですか?
  • システムテストとの違いは何ですか?
  • 受け入れテストを効率よく進める方法はありますか?

質問1.受け入れテストの外注化は可能ですか?

受け入れテストの外注化は可能です。受け入れテストは最終フェーズでおこなう重要なテストですが、全体的な工程が遅れていたりコストが十分でなかったりすると必要な部分まで省いてしまう、または受け入れテスト自体をしないケースがあります。

しかし、受け入れテストを十分にしていないと本番稼働後にトラブルになる可能性は少なくありません。そこで、受け入れテストを外注化することで業務負担が減り、なおかつシステムの品質向上につながります。

質問2.システムテストとの違いは何ですか?

システムテストは、ソフトウェア開発の最終フェーズに開発者がおこなう統合的なテストです。受け入れテストも最終フェーズにおこないますが、発注側が要求された内容と一致しているかどうかの確認をします。

テストの内容自体はほとんど変わらず確認をする事項や機能はほぼ同じです。

質問3.受け入れテストを効率よく進める方法はありますか?

受け入れテストは開発の最終フェーズにおこなうことから、開発の進み具合によっては十分な時間をとれない可能性があります。そこで、受け入れテストは特に効率の良さが求められます。

受け入れテストを効率よく進めるために、発注側の要求定義を基準としてテストを進めることが一般的です。発注側の要件を基準にすることで、発注者の要求に答えられます。

【まとめ】受け入れテストを理解しよう

【まとめ】受け入れテストを理解しよう

受け入れテストは、システムがリリース出来る状態であるかどうかをクライアント側に検証してもらう、システム開発の最終段階です。機能漏れや仕様書に誤りがないか、納品する成果物全てにチェックが入ります。

また、本番環境と同等の環境でのテストや、実データを利用したテスト等、実業務さながらの検証が行われるため、システム全体を網羅的に検証できる非常に重要なテスト工程でもあります。クライアント側で受け入れテストを十分に行う環境が整っていない場合は、第三者検証として受け入れテストを委託するなどの対応を検討しましょう。

受け入れテストについて理解して、安心・安全なシステムをリリースすることを心がけましょう。