システムの受入テストで考慮すべきポイントとは？

本ブログでは、ユーザー目線にて実施する「受入テスト」についてご紹介します。受入テストは開発の外注の際に発注元が行う重要なテスト工程です。

今回はまずテストの概要について解説し、考慮すべき点・種類・フローの順で説明します。

受入テスト【Acceptance test/検収テスト】とは、システムやソフトウェアの検証手法のひとつであり、開発工程を外注した際に発注元が行う最終確認を指します。

外注先から納品されたシステムを対象とし、発注元がユーザー目線で操作を行うことで、

• 仕様が要件を満たし正常に動作するか？
• リリース前の品質に問題がないか？

を検収します。

受入テストは、開発工程における最終段階です。

受入テストよる品質の承認後は、開発工程が完了となり、ユーザーに製品・サービスが開始、提供されることとなります。

受入テストを実施する際には、単に不具合検出に努めるだけでなく、品質保証の観点からシステムの動作に改善点が残存していないかを含め、ユーザー目線で慎重な検証作業を行うことが大切です。

つぎは、「運用テストと受入テストの違い」について説明します。

両テストの異なる点は、「実施担当者」と「テストを行う段階」です。

運用テスト【Operations Test/OT】は、開発側が行います。
開発システムが発注元・クライアント側が作成した要件定義書をもとに、
「ユーザー要求・ニーズを満たしているか」を確認します。

主な相違点は以下の通りです。

●運用テスト
実施担当：開発者
テストを行う段階：
システム完成後、発注者への納品前に行うユーザー要件・ニーズの確認

●受入テスト
実施担当：ユーザー（発注者）
テストを行う段階：
開発者から納品後、リリース前に行う要件・ニーズの最終確認

両テストに共通して実施においては、「エンドユーザーの利用環境を考慮したテスト環境を用意すること」が重要です。

受入テストを行う際にはまず、「リスク管理」の観点が重要となります。
あらかじめテスト環境を整備し、目的を明確化する必要があります。

具体的には、以下のポイントを考慮することが望ましいでしょう。

• 重要な機能
• 仕様変更した機能とその周辺機能
• 実環境・実データを使う

ここからは、それぞれについて解説します。

システムの稼働直前において、高品質で効率的な受入テストを実現するためには、システムの主要な機能や、不具合があってはならない「重要な機能」を適切に選定した上で、テスト条件を定義する必要があります。

前述の通り、リスク管理及び業務効率化、品質確保のためにも「重要な機能」を入念且つ優先的に検証するよう徹底しましょう。

開発工程において、ユーザー要求・ニーズや突発的な不具合検出により、途中で仕様変更が発生することも少なくはありません。

また、開発途中での仕様変更は、既存の設計部分への考慮・対処などの抜け漏れを発生させるリスクも高く、開発者を悩ませる問題のひとつであると言えます。そのため、上記トラブル発生のリスク回避を軸として、仕様変更がなされた機能及びその周辺機能もユーザー目線にて優先的にテストを行うことが重要です。

さらに、受入テストで考慮すべきポイントは「実環境・実データを使うこと」です。

外注先（開発者側）による開発工程のフェーズでは、
疑似的なテスト環境・データを用いるケースが多いためです。

疑似的なテスト環境から本番環境へ移行時における処理上のミス・抜け漏れリスクを低減させるためにも、エンドユーザーが実際に利用する環境・データを用いて受入テストを実施することが大切です。

つづいて、「受入テストの種類」についてご紹介します。

システム開発における受入テストは、以下の通りです。

• 運用受け入れテスト
• マニュアルテスト
• 機能確認テスト
• シナリオテスト
• システム間連携テスト
• 現新比較テスト

ここからは、各種類の主な検証内容について解説します。以下の内容を参考に「受入テストの種類」を正しく理解し、プロジェクト・対象システムに応じたテスト方式を選定・実行しましょう。

運用受け入れテストは、開発システム上の「バックアップ/ユーザー管理/セキュリティ面/システム障害時の復旧」などをテスト観点とします。さらに、これらの項目をふまえて開発システムを実際に稼働させ、全体として問題なく運用できているかを検証します。

マニュアルテストとは、開発システムの運用に関する手順書をチェックし、記載事項に誤りや曖昧な点、変更や改善すべき点がないかを検証する作業です。

機能確認テストでは要件定義書をもとに、システムの全機能が正確に実装されているかを確認します。主に各機能を単体のモジュール（部品）としてとらえ、問題がないかを細かく確認することが重要です。

シナリオテストでは、エンドユーザーによる実際の運用フローを再現し、開発システムが不具合なく正常に運用できているかを検証します。

システム間連携テストは、主にユーザー、クライアント側の主導にて実施されます。新しい開発システムとの連携システム間において、データのやり取り・連携が問題なく行われるかを検証します。

現新比較テストでは、現在行われているシステムと新規作成したシステムを同時に稼働させ、データのやり取り・連携が不具合なく実施されているかを検証します。
現新比較テストを無事完了することは、現行システム及び機能の品質担保に直結します。そのため、受入テストの中で最も重要なテストであることを留意しておきましょう。

ここからは、「受入テストの流れ」を以下の順でご紹介します。

• 計画
• 準備
• 実施

受入テストでは、まず正しい業務フローを把握することが大切です。
以下を参考に、「受入テストの計画～実施」のフェーズをイメージしてみましょう。

受入テストを行う際にはまず、「テスト計画」が要となります。
テスト計画は主にユーザー側で作成します。

受入テストの計画においては要件定義に関する「情報収集」が重要です。そのため、計画作成時には「準備・実施」にて重要となる要件定義を明確化し、曖昧な表現や項目の抜け漏れ・詳細不足がないかを必ず確認するようにしましょう。

定義・記載すべき項目

• テストの目的
• テスト対象・範囲（スコープ）
• テストスケジュール
• 実施担当者
• テスト管理の流れ
• テストシナリオの方針・方向性 など

テスト計画後は、受入テスト実施に向けて「準備」を行います。
主に、「テスト環境の構築/項目設定」を実施します。

また、トラブル防止の観点から予めチェックリストなどを作成し、以下を準備・確認しましょう。

準備・確認すべき項目

• テスト実施担当者・参加ユーザー
• 実施場所
• 利用機器・端末
• アカウント権限（データ編集など）
• テスト環境

尚、アカウント権限付与・テスト環境構築は比較的時間がかかるため、実施担当者全員への共有は速やかに行いましょう。

受入テストにおける最後のフェーズは、いよいよテストの本番となる「実施」です。
ここまでに定義・準備した要件やテストリソースをもとに、受入テストを実行します。
尚、受入テストでは、以下を最低限実施する必要があります。

最低限、実施すべきテスト

• 機能確認テスト
• システム間連携テスト
• シナリオテスト
• 現新比較テスト

受入テストの実行に携わる際は、テストの種類（各内容・目的）を予め理解・把握し、正しい内容とプロセスを用いて実施することを推奨します。

しかしながら、企業様の中には「社内で受入テストを行うためのリソース・ノウハウがない・・・」「策定した内容・方針が曖昧でテスト基準が明確化できていない」というケースも多いのではないでしょうか？

近年では、上記のような課題を解決すべく、「受入テストの外注」も可能です。
テクバンでは、今回ご紹介した「受入テストの流れ」における全工程をワンストップでサポートし、高品質な第三者検証サービスをご提供しております。

最後までお読みいただき、ありがとうございました。
今回は受入テストについて、「運用テストとの違い/考慮すべき点/種類/テストの流れ」を整理し、ご紹介しました。

受入テストは開発を外注した発注側がユーザー目線にて、開発システムが仕様を満たしているか、正式に納品・リリースができるかを検収する最終確認テストです。
システムの最終的な品質レベルに直結するため、より高い網羅性・妥当性が問われる重要な工程です。

本記事を参考に、基礎となる前提知識を正しく理解し、プロジェクトに応じた受入テストの進め方を再考しつつ、計画・実行していただければ幸いです。