【初心者向け】受入テスト完全マニュアル

この記事では、システム開発における受入テストを体系的に整理し、完全マニュアルとしてまとめることを目的とする。

受入テストで困ったときにはこの記事を読めば、ほとんどのことは解決するという状態を目指したい。

なお、受入テストは様々な呼び方が存在するが、本記事では引用文を除き、全て”受入テスト”で統一する。

1.受入テストとは何か？

まずは、受入テストとは何かについて、解説したい。

IT用語辞典のe-Wordsの定義は下記の通りである。

UATとは、情報システムの開発を外部に委託した場合に、その最終段階で発注元（ユーザ企業）側が完成したシステムの納品を受け付けるか否かを判定するための試験。このテストにパスすると開発は終了となり、納品および業務への導入、利用開始となる。

IT用語辞典 e-Wordsより一部引用

つまり、受入テストの重要なポイントとして、下記2点を必ず押さえなくてはならない。

　① ユーザー目線で業務遂行可能かどうかを判断するテスト

　② システム品質に問題ないことを承認するテスト

① ユーザー目線で行うテストである

システム開発において、テストはいくつか存在するが、受入テストはユーザー目線で行うという点に特徴がある。

つまり、システムの不具合を発見するという観点だけではなく、ユーザーの業務が遂行できるかという観点でテストを行う必要が出てくる。

そのため、受入テストは原則として、外注は不可である。受入テストの全てを外注する企業は、自社の業務品質を他社に丸投げしているのと同義である。

② システム品質を承認するテストである

もう1つの特徴として、システム品質を承認するためのテストであることが挙げられる。

受入テストは、システム自体の検収作業の一つである。つまり、受入テストで手を抜くと、実際の業務が開始したときに不具合が発生しても、システム開発者に改修してもらえないという事態も起こり得るということだ。

受入テストは品質に問題ないことを承認する最後の砦であり、ここでシステムの不具合を洗い出す必要がある。

2.受入テストのプロセスについて

次に、受入テストのプロセスだが、大きく4プロセスに分けることが出来る。

では、それぞれ具体的に説明したい。

①.受入テスト計画

受入テスト計画は、テスト全体の計画を設計するプロセスである。計画の際は以下のような内容を検討すべきである。

これらの内容を検討するため、テスト計画書やテスト仕様書を作成することを推奨したい。

(1)受入テスト計画書

受入テスト計画書の作成手法については、下記の記事で解説しているため、参考にして欲しい。

(2)受入テスト仕様書

受入テストのシナリオ策定のためには、仕様書を作成するべきである。受入テスト仕様書の作成手法については、下記の記事を参考にして欲しい。

②.受入テスト準備

受入テスト実施前には必ず準備が必要である。少なくとも以下の項目は事前に確認しておかないと、受入テスト当日にトラブルになる可能性は高い。

これらの準備が出来ているかどうかを管理するために、チェックリストを作成するのが望ましい。

また、受入テスト実行メンバーは、実業務を行っているメンバーで実施するべきである。前述した通り、受入テストはユーザー目線でシステム品質を承認するテストのため、業務外のメンバーや外注で実施するべきではない。

アカウント権限の発行やテスト環境の準備など、時間を要する場合があるため、参加者に対する周知は早めに行うべきである。

③.受入テスト実行

受入テスト当日の状況は受入管理表で管理すべきである。

また、当日のトラブル時の対応や連絡フローなどはあらかじめ参加者に共有し、スムーズな運用が出来るように心がけよう。

3.受入テスト種類

「情シス・IT担当者[必携]システム発注から導入までを成功させる90の鉄則」によると、受入テストで最低限行うべきテストとして、下記4つが挙げられている。

受入テスト種類

①機能確認テスト

②システム間連携テスト

③シナリオテスト

④現新比較テスト

「情シス・IT担当者[必携]システム発注から導入までを成功させる90の鉄則」より抜粋

それぞれのテストについて内容を確認したい。

① 機能確認テスト

目的

要件定義で定めた機能一覧がすべて網羅されているかを確認する。

説明

ベンダーからシステムを提供されて、最初に行うテスト。まずは大枠で機能単位に漏れがないかを総点検する。ベンダーは細部に気を取られ、大枠の考慮に欠けることがあるからだ。機能確認テストでは業務の流れは特に意識しないためとりかかりやすいテストと言える。機能を部品として捉え、1つずつチェックしていく。

② システム間連携テスト

目的

新システムと連携するシステムとの間で、データ連携に問題がないことを確認する。

説明

システム間連携テストは、ベンダーのテストと思われがちだが、自社主導のテストである。なぜなら、システム間連携は自社の他部門とのデータのやり取りだからだ。実際にデータを連携してみて、問題ないかを確認する。

③ シナリオテスト

目的

実際の業務の流れを再現し、問題なく運用ができるかを確認する。

説明

ベンダーにとって、最も不足しているテストである。実際の現場目線でテストができるのは、自社のエンドユーザーだけだからだ。業務の流れを具体的に設定した「シナリオ」をもとに、テストを実施する。点ではなく線で捉えるテストである。

④ 現新比較テスト

目的

現行システムと新システムの出力結果を比較し、一致することを確認する。

説明

受入テストで最重要となるテストである。新システムを漠然とテストしていてはまず見つからない不具合も、現行システムと「答え合わせ」を行うことで、細かい不具合まで検出可能となる。全件テストを行うことで、自社が登録したマスターデータの不備も全て検出できる。この検証でOKとなれば、現行機能は担保されたと言える。

4.受入テストの注意点

4-1.受入テストの手法は会社によってバラつきがある

実は受入テストの手法は一般化されておらず、会社や人によって認識や手法が異なるのが現状です。

したがって、まずやるべきことは、「受入テストとは何か」という定義をプロジェクト内で共有することです。

冒頭でも記載している通り、本サイトの受入テストの定義は下記2点です。

　➀ユーザー目線で業務遂行可能かどうかを判断する

　② 品質に問題ないことを承認する

4-2.テスト期間中の最適な連絡/管理方法を設計する

受入テスト期間中は開発側と業務側とのやり取りが頻繁に発生します。

プロジェクトの規模や関係者の所在地などによって、最適な連絡方法を設計しましょう。

重要なことは、スピード感があり、きちんと管理出来るような方法にすることです。

具体的な連絡方法としては、会議、電話、メール、チャットなどがありますので、最適な方法を選択しましょう。

4-3.対応策を検討する

受入テストで出てきた要望やバグ改修については、期間や人員の点から全て対応できるとは限りません。

そのため、必ずやるべきは出てきた要望やバグ改修について優先順位を付けることです。

優先順位の高いものから対応し、低いものについては対応しないもしくは代替案でしばらくは運用することも検討しなければいけません。

ただ、なるべく開発側と業務側の認識相違は無いように要件定義の段階で、成果物や出来上がりイメージの認識合わせをしておくことが重要です。

4-4.システム連携がある場合のポイント

受入テストでシステム間連携がある場合は、下記の観点で検証が必要です。

5.まとめ

いかがだろうか。

受入テストは実業務の運用ができるかどうかを実業務メンバーの目線で確認するためのテストである。また、品質を担保するためにも重要なテストのため、しっかりと計画と準備をした上で、当日に臨みたい。

なお、下記の書籍はユーザー目線でのシステム開発について解説されている。非常に分かりやすいため、おすすめである。

↓↓このブログが少しでもお役に立ったならば、応援クリック頂けると嬉しいです！↓↓