受入テスト

テスト

受入テストはシステム開発のプロセスの中で行われる最終のテストです。このテストに合格することが、システム開発の完了を意味し、システム開発会社が納品を行う基点となります。そして、この後、システム移行、データ移行、業務移行を行い、本番稼働を迎えます。

受入テストまでの各テスト（単体テスト、結合テスト、総合テスト）はすべてシステム開発会社が主体になって進めますが、受入テストは発注者側が主体になって行います。また、テストの担当部署として、業務実施部門と情報システム部門が協力して行います。

受入テストの目的は「要件定義書に記載した業務内容がシステムに洩れなく、問題なく反映されているか」を確認することにあります。受入テストの目的は「プログラムのバグを探す」ことではありません。受入テストを行っている間に、バグが見つかる可能性もありますが、本来の目的を見失わないようにしましょう。

受入テストは以下の流れで行われます。

「受入テスト計画」の作成
「受入テストシナリオ」の作成
「受入テスト」の実施
「受入テスト結果」の整理・評価・完了判定

テストシナリオについては「業務内容としての現実性があること」「業務の網羅性を高めること」が重要です。また、作成されたシナリオにしたがってテストが実施できるように、十分に考慮されたテストデータを準備することも重要なポイントです。

テストシナリオを作成する際に「例外的な業務をどこまでテストするか」という疑問が発生することがあります。例外的な業務であっても、要求定義と要件定義のフェーズで抽出されていることが前提となりますので、その業務の重要性や頻度をもとに分析した結果を要求定義・要件定義フェーズで文書化しておくことが理想的です。

大規模なシステムの受入テストはテストシナリオが膨大な数になることもあり、片手間で済ますことができないため、テストのための要員の確保も計画的に行わなければなりません。
受入テストは発注側企業で行いますが、実際にはシステム開発会社の協力なしで進めることは不可能ですので、あらかじめテストのサポートを依頼しておいたほうが良いでしょう。また、テスト担当者はシステムの操作方法を理解しておかなければいけないため、システム開発会社にマニュアルの作成や操作教育を依頼することも事前に検討しなければなりません。

受入テストでは業務に直結した機能要件だけではなく、運用段階で情報システム部門が担当することになる非機能要件についてもテストの範囲に含まれます。そのため、情報システム部門でも、テストのための体制を整える必要があります。とくに、セキュリティやバックアップ/リストア等の検証は、プラットフォームの複雑化の影響を受けることも考えられますので、充分なテストシナリオを準備しなければなりません。

受入テスト計画書をもとにテストを実施し、その結果をテスト結果報告書として作成したものをシステム開発会社と共有することも重要です。テストの合格を発注側企業内、およびシステム開発会社と合意して、システム開発自体は完了となりますが、この後、本番環境へのシステム移行、既存システムからのデータ移行、新業務プロセスへの業務移行を行うことになります。

あわせてこの用語と記事をチェック

・単体テストとは

・結合テストとは

・総合テストとは