受け入れテストとは？ 定義、種類、プロセス
受け入れテストは、ソフトウェアを開発する際に非常に重要なステップです。このステップにおいては、製品、プロトタイプ、ソフトウェアアプリケーションを評価し、仕様と品質を満たしていることを確認した後本番稼働となります。
1. 受け入れテストとは？
受け入れテストは、アプリケーションがユーザーの期待に応えているかどうかを確認します。受け入れテストは、一般的にソフトウェアが計画通りに機能しているかどうかを判断するために、エンドユーザにより、本番環境に近い環境で実施されます。
簡単に言うと、受け入れテストは、システムテストの後、システムを実際に使用できるようにする前に行う、ソフトウェアテストの最終レベルです。
2. 受け入れテストの種類
2.1. ユーザ受け入れテスト (User Acceptance Testing_UAT)
UATは、ソフトウェアがユーザーにとって正しく動作しているかどうかを判断します。エンドユーザーがよく使う特定の要件が主にテスト目的で選ばれます。これは、エンドユーザーテストとも呼ばれます。
ここで言う「ユーザー」とは、そのソフトウェアが対象とするエンドユーザーであり、従って、テストは彼らの視点や観点から行われます。
2.2. ビジネス受け入れテスト (Business Acceptance Testing_BAT)
BATは、そのソフトウェアがビジネス上の目標や目的に合致しているかどうかを判断するためのものです。
主にビジネスベネフィット（財務）に集中しますが、市場環境の変化や技術の進歩により、現在の実装を変更しなければならず、追加予算が発生する可能性があります。
また、技術的な基準を満たした製品であっても、このような理由でBATに不合格となる場合があります。
2.3. コントラクト受け入れテスト (Contract Acceptance Testing_CAT)
CATは、本製品が稼動したら、あらかじめ決められた期間内に受け入れテストを行い、すべての受け入れユースケースに合格しなければならないという契約です。
ここで締結される契約は、サービスレベル契約（Service Level Agreement_SLA）と呼ばれ、本製品のサービスがすべての要件を満たした場合のみ支払いが行われる、つまり契約が履行されるという条件が含まれています。
時に、この契約は、ソフトウェアのゴーライブ前に起こるかもしれません。いずれにせよ、契約は、テストの分野、テストの期間、後の段階で発生した問題に対する条件、支払いなどの面で十分に定義されている必要があります。
2.4. 規制/コンプライアンス受け入れテスト (Regulations/Compliance Acceptance Testing_RAT)
RATは、その製品が発売される国の政府によって定められた規則や規制に違反していないかどうかを判断するためのものです。意図的でなくても、ビジネスに悪影響を及ぼす可能性があります。
通常、全世界で発売される予定の開発されたアプリケーションは、RATを受けなければなりません。なぜなら、国や地域により、政府が定めた特定のルールやレギュレーションがあるためです。
また、国や地域により、その国の法令に違反した場合、その国はそのアプリケーションを使用することができず、失敗とみなされます。
2.5. 運用受け入れテスト (Operational Acceptance Testing_OAT)
これは本製品の運用準備状況を評価するものであり、非機能テストです。主に、リカバリ、互換性、保守性、テクニカルサポートの可用性、信頼性、フェイルオーバー、ローカライゼーションなどのテストが含まれます。OATは主に、製品を本番にリリースする前に安定性を保証します。
2.6. アルファテスト
これは、アルファテスターと呼ばれる専門のテスターチームが、開発・テスト環境において製品を評価することです。テスターからのフィードバックや提案は、製品の使用方法の改善や、特定のバグの修正に役立ちます。
ここでは、テストは管理された方法で行われます。
2.7. ベータテスト/フィールドテスト
これは、通常ベータテスター/ベータユーザーと呼ばれる実際のエンドユーザーの環境で製品を公開することにより評価するものです。ユーザーからの継続的なフィードバックを収集し、問題点を解決していきます。また、豊かなユーザーエクスペリエンスを提供するための製品の強化・改善にも役立ちます。
テストは管理された方法で行われません。つまり、ユーザーは製品の使用方法について何の制約も受けません。
3. 受け入れテストのプロセス
実際のAT (Acceptance Testing/ 受け入れテスト) は以下のような流れになります。
ステップ1：ビジネス要件分析
プロジェクトの関連ドキュメントをすべて参照し、ビジネス要件を分析します。
そのいくつかは：
- システム要求仕様書
- 業務要件定義書
- 使用例
- ワークフロー図
- 設計データマトリックス
ステップ2：受け入れテスト計画書の設計
受け入れテスト計画書においては、文書化すべき項目があります。
そのいくつかを見てみましょう。
- 受け入れテストの戦略およびアプローチ。
- 入口と出口の基準を明確にする必要があります。
- 受け入れテストの仕様とスコープを明確にし、ビジネス要件のみをカバーする必要があります。
- 受け入れテスト設計のアプローチは、テストを書く人がその書き方を理解できるように、明確かつ詳細に書くべきです。
- テストベッドセットと実際のテストスケジュールを記載すること。
- テストは様々な利害関係者により行われ、利害関係者がその手順を知らない可能性があるため、バグの記録に関する詳細が示されるべきです。
ステップ3: 受け入れテストの設計とレビュー
受け入れテストは、何をしなければならないかをシナリオレベルで記述する必要があります（どのように行うかの詳細なものではありません）。これらは、ビジネス要件の特定された範囲のみに対して記述されるべきであり、それぞれのテストは、参照する要件にマッピングされなければなりません。
ビジネス要求の高いカバレッジを達成するために、書かれたすべての受け入れテストシナリオ/テストケースを見直す必要があります。
これは、記載された範囲以外のテストが含まれていないことを確認し、テストが予定されたスケジュール内で行われるようにするためです。
ステップ4：受け入れテストベッドの設置
テストベッドは本番環境と同じようにセットアップする必要があります。環境の安定性と使用状況を確認するために、非常にハイレベルなチェックが必要です。環境を使用するための認証情報は、このテストを実行する関係者のみと共有します。
ステップ5：受け入れテストデータの設定
本番データをテストデータとしてシステム内に用意しなければなりません。また、そのデータをテストに使わなければならないような形で、詳細なドキュメントを用意する必要があります。
TestName1、TestCity1などのテストデータを用意するのではなく、Albert、Mexicoなどのデータを用意します。これにより、リアルタイムのデータをふんだんに体験でき、テストもある程度の所まで行えるようになります。
ステップ6：受け入れテストの実施
このステップにおいては、設計された受け入れテストを実環境上で実行する必要があります。理想的には、すべてのテストが最初のトライでパスすることです。 受け入れテスト中に機能的なバグが発見された場合、それらは修正されるべき高い優先度として報告されるべきです。
また、修正されたバグは、優先度の高いタスクとして検証され、クローズされなければなりません。テスト実行レポートは、日次で共有されなければなりません。
このフェーズで記録されたバグは、バグトリアージミーティングでレビューされ、根本原因解析の手順を踏む必要があります。受け入れテストは、製品がビジネス要件をすべて満たしているかどうかを判断する唯一のポイントです。
ステップ7：ビジネス判断
Go/No-Goの決定が本番のソフトウェア投入のためになされます。Goの決定がなされると、そのソフトウェアは市場に投入されることになります。No-Goの決定は、そのソフトウエアは失敗作として記録されます。
No-Goの決定にはいくつかの要因がある：
- 製品の品質が悪い。
- 余りに多くの自明な機能上のバグ。
- ビジネス要件からの逸脱。
- 市場要件に合致しておらず、現在の市場標準を満たすために改善が必要である。
まとめ
受け入れテストは、ソフトウェア開発プロセスにおける重要なステップであり、チームが時間をかけて適切に実施することが重要です。ソフトウェアの品質を向上させるためのテスターチームを探している場合、お気軽にCMC Japanにご相談ください。弊社は、ISTQBのプラチナパートナーであることを誇りに思い、より良い製品を提供するためにお客様のビジネスを支援できるエンドツーエンドのアプローチを提供いたします。
