検収試験とは（完全ガイド）

what is acceptance testing

検収試験入門（パートI）：

このチュートリアルシリーズでは、次のことを学びます。

1. 検収試験とは
2. 検収試験と試験計画
3. 検収試験のステータスと要約レポート
4. ユーザー受け入れテスト（UAT）とは

システムテストは終了しましたか？ほとんどのバグは修正されていますか？バグは検証され、クローズされていますか？では、次は何ですか？

リストの次は、ソフトウェアテストプロセスの最後のフェーズである受け入れテストです。 。 これは、お客様が決定するフェーズです GO / No-GO 製品については、製品を市場にリリースする前に強制的に従わなければなりません。開発チームとテストチームの共同の努力は、開発された製品を受け入れるか拒否することによって、顧客によって授与されます。

受け入れテストに関するこのユニークなチュートリアルでは、理解を深めるために、受け入れテストに関連する意味、タイプ、使用法、およびその他のさまざまな要素の完全な概要を簡単かつ簡単に説明します。

学習内容：

• 検収試験とは何ですか？
• なぜ検収試験？
• タイプ
  • ＃1）ユーザー受け入れテスト（UAT）
  • ＃2）ビジネス受け入れテスト（BAT）
  • ＃3）契約受け入れテスト（CAT）
  • ＃4）規制/コンプライアンス受け入れテスト（RAT）
  • ＃5）運用受け入れテスト（OAT）
  • ＃6）アルファテスト
  • ＃7）ベータテスト/フィールドテスト
• 検収試験は誰が行いますか？
• アクセプタンステスターの品質
• 使用する
• システムテスト、受け入れテスト、およびユーザー受け入れテストの違い
• 検収試験
• 検収試験ベッド
• ATの開始および終了基準
  • エントリー基準
  • 終了基準
• 検収試験プロセス
• このテストの成功要因
• 結論
• 推奨読書

検収試験とは何ですか？

一度 システムテストプロセス テストチームによって完了され、サインオフされると、製品/アプリケーション全体が顧客/顧客の少数のユーザー/両方に渡され、その受容性をテストします。つまり、製品/アプリケーションは、重要な要件と主要なビジネス要件。また、エンドツーエンドのビジネスフローは、リアルタイムシナリオと同様に検証されます。

本番環境のような環境は、テストを受け入れるためのテスト環境になります（通常、ステージング、製品前、フェイルオーバー、UAT環境と呼ばれます）。

これは ブラックボックステスト手法 製品が指定された受け入れ基準を満たしていることを確認するために機能のみが検証される場合（設計/実装の知識は必要ありません）。

なぜ検収試験？

システムテストは正常に完了しましたが、受け入れテストはお客様から要求されています。ここで実行されるテストは、システムテストでカバーされているため、繰り返し行われます。

では、なぜこのテストは顧客によって行われるのですか？

それの訳は：

• 市場にリリースされている製品への信頼を得るため。
• 製品が必要な方法で機能していることを確認するため。
• 製品が現在の市場基準に適合し、市場の他の同様の製品と十分に競争力があることを保証するため。

タイプ

このテストにはいくつかの種類があります。

それらのいくつかを以下に示します。

＃1）ユーザー受け入れテスト（UAT）

UATは、製品がユーザーのために機能しているかどうか、使用法について正しく評価することです。エンドユーザーが頻繁に使用する特定の要件は、主にテスト目的で選択されます。これは、エンドユーザーテストとも呼ばれます。

ここでの「ユーザー」という用語は、製品/アプリケーションの対象となるエンドユーザーを意味します。したがって、テストはエンドユーザーの観点とその観点から実行されます。

=>また 読んだ： ユーザー受け入れテスト（UAT）とは何ですか？

＃2）ビジネス受け入れテスト（BAT）

これは、製品がビジネスの目標と目的を満たしているかどうかを評価するためのものです。

BATは主に、市場の状況の変化やテクノロジーの進歩により非常に困難なビジネス上のメリット（財務）に焦点を当てているため、現在の実装では変更が必要になり、追加の予算が発生する可能性があります。

初心者のためのコンピュータプログラミングの方法

技術要件に合格した製品でさえ、これらの理由によりBATに失敗する可能性があります。

＃3）契約受け入れテスト（CAT）

これは、製品が稼働すると、所定の期間内に受け入れテストを実行し、すべての受け入れユースケースに合格する必要があることを指定する契約です。

ここで署名された契約は、サービスレベル契約（SLA）と呼ばれます。これには、製品サービスがすべての要件に準拠している場合にのみ支払いが行われる条件が含まれます。つまり、契約が履行されます。

この契約は、製品が稼働する前に発生する場合があります。いずれにせよ、契約は、テストの期間、テストの領域、後の段階で発生する問題の条件、支払いなどの観点から明確に定義する必要があります。

＃4）規制/コンプライアンス検収試験（RAT）

これは、製品がリリースされる国の政府によって定義された規則および規制に違反しているかどうかを評価するためのものです。これは意図的ではないかもしれませんが、ビジネスに悪影響を及ぼします。

通常、世界中でリリースされることを目的とした開発された製品/アプリケーションは、RATを受ける必要があります。これは、国/地域によって、統治機関によって定義された規則や規制が異なるためです。

いずれかの国で規則や規制に違反した場合、その国またはその国の特定の地域は製品の使用を許可されず、失敗と見なされます。製品がリリースされた場合、違反があったとしても、製品のベンダーは直接責任を負います。

＃5）運用受け入れテスト（OAT）

これは、製品の運用準備を評価するためのものであり、機能しないテストです。これには主に、リカバリ、互換性、保守性、テクニカルサポートの可用性、信頼性、フェイルオーバー、ローカリゼーションなどのテストが含まれます。

OATは主に、製品を製品にリリースする前に製品の安定性を保証します。

＃6）アルファテスト

これは、通常アルファテスターと呼ばれる専門のテスターチームによって、開発/テスト環境で製品を評価するためのものです。ここでは、テスターのフィードバック、提案が製品の使用法を改善し、特定のバグを修正するのに役立ちます。

ここでは、テストは制御された方法で行われます。

=>また読む： アルファテストとは何ですか？

＃7）ベータテスト/フィールドテスト

これは、製品を実際のエンドユーザー（通常はベータテスター/ベータユーザーと呼ばれます）に環境内で公開することによって評価することです。ユーザーからの継続的なフィードバックが収集され、問題が修正されます。また、これは、製品を強化/改善して、豊かなユーザーエクスペリエンスを提供するのに役立ちます。

テストは制御されていない方法で行われます。つまり、ユーザーは製品の使用方法に制限がありません。

=>また読む： ベータテストとは何ですか？

これらすべてのタイプには共通の目標があります。

• 製品への信頼を獲得/強化するようにしてください。
• 製品が実際のユーザーによって使用される準備ができていることを確認してください。

検収試験は誰が行いますか？

アルファタイプの場合、（製品を開発した）組織のメンバーのみがテストを実行します。これらのメンバーは、プロジェクトの直接の一部ではありません（プロジェクトマネージャー/リード、開発者、テスター）。管理、販売、サポートチームは通常、テストを実行し、それに応じてフィードバックを提供します。

アルファタイプを除いて、他のすべての受け入れタイプは通常、さまざまな利害関係者によって実行されます。顧客、顧客の顧客、組織の専門テスターのように（常にではありません）。

タイプに基づいてこのテストを実行する際に、ビジネスアナリストと対象分野の専門知識を関与させることもお勧めします。

アクセプタンステスターの品質

以下の品質のテスターは、アクセプタンステスターとしての資格があります。

• 論理的かつ分析的に考える能力。
• 優れたドメイン知識。
• 市場で競争力のある製品を研究し、開発された製品で同じものを分析することができます。
• テスト中にエンドユーザーの認識を持つ。
• 各要件のビジネスニーズを理解し、それに応じてテストします。

このテスト中に見つかった問題の影響

受け入れテストフェーズで発生した問題は、優先度の高いものと見なし、すぐに修正する必要があります。これには、見つかったすべての問題に対して根本原因分析を実行する必要もあります。

テストチームは、アクセプタンスの問題にRCAを提供する上で主要な役割を果たします。これらは、テストがどの程度効率的に実行されるかを判断するのにも役立ちます。

また、受け入れテストの有効な問題は、印象、評価、顧客調査などの点でテストチームと開発チームの両方の取り組みに影響を与えます。検証に関するテストチームからの無知が見つかった場合は、エスカレーションにもつながることがあります。

使用する

このテストは、いくつかの側面から役立ちます。

そのうちのいくつかが含まれます：

• 機能テスト段階で見逃された問題を把握するため。
• 製品がどれだけうまく開発されているか。
• 製品は、実際に顧客が必要としているものです。
• 実施されたフィードバック/調査は、製品のパフォーマンスとユーザーエクスペリエンスの向上に役立ちます。
• プロセスを改善し、続いてRCAを入力として使用します。
• 生産製品から生じる問題を最小化または排除します。

システムテスト、受け入れテスト、およびユーザー受け入れテストの違い

以下に、これら3種類の検収試験の主な違いを示します。

検収試験

製品のテストケースと同様に、受け入れテストもあります。受け入れテストは、ユーザーストーリーの受け入れ基準から導き出されます。これらは通常、製品がさまざまな条件下で何をしなければならないかについての高レベルの詳細で書かれたシナリオです。

テストケースのように、テストの実行方法を明確に把握することはできません。合格テストは、製品を完全に把握しているテスター、通常は対象分野の専門知識によって作成されます。作成されたすべてのテストは、顧客および/またはビジネスアナリストによってレビューされます。

これらのテストは、受け入れテスト中に実行されました。受け入れテストに加えて、実行するセットアップに関する詳細なドキュメントを準備する必要があります。適切なスクリーンショット、設定値、条件などを含む詳細を毎分含める必要があります。

検収試験ベッド

このテスト用のテストベッドは通常のテストベッドと似ていますが、別のものです。必要なすべてのハードウェア、ソフトウェア、オペレーティング製品、ネットワークのセットアップと構成、サーバーのセットアップと構成、データベースのセットアップと構成、ライセンス、プラグインなどを備えたプラットフォームは、非常によく似たセットアップが必要です。実稼働環境。

受け入れテストベッドは、設計された受け入れテストが実行されるプラットフォーム/環境です。検収試験環境をお客様に引き渡す前に、環境問題や製品の安定性を確認することをお勧めします。

受け入れテスト用に個別の環境が設定されていない場合は、その目的で通常のテスト環境を使用できます。ただし、ここでは、通常のシステムテストのテストデータと、受け入れテストのリアルタイムデータが単一の環境で維持されるため、煩雑になります。

検収テストベッドは通常、顧客側（つまり、ラボ内）に設置され、開発チームとテストチームへのアクセスが制限されます。

チームは、VMまたは特別なアクセス資格情報を使用して特別に設計されたURLを介してこの環境にアクセスする必要があり、これへのすべてのアクセスが追跡されます。この環境では、お客様の許可なしに追加/変更/削除する必要はなく、加えられた変更についてお客様に通知する必要があります。

ATの開始および終了基準

STLCの他のフェーズと同様に、受け入れテストには、受け入れテスト計画（このチュートリアルの後半で説明します）で明確に定義される一連の開始基準と終了基準があります。

これは、システムテストの直後に開始し、本番環境の起動前に終了するフェーズです。したがって、システムテストの終了基準は、ATの開始基準の一部になります。同様に、ATの終了基準は、プロダクションローンチの開始基準の一部になります。

エントリー基準

開始する前に満たす必要のある条件を以下に示します。

• ビジネス要件は明確で利用可能でなければなりません。
• システムと回帰のテストフェーズを完了する必要があります。
• 重大、メジャー、および通常のバグはすべて修正して閉じる必要があります（受け入れられるマイナーバグは主に、製品の使用を妨げない外観上のバグです）。
• 既知の問題リストを作成し、利害関係者と共有する必要があります。
• 受け入れテストベッドを設置し、環境問題がないか高レベルのチェックを実行する必要があります。
• 製品をATフェーズに移行させるには、システムテストフェーズをサインオフする必要があります（通常は電子メール通信を介して行われます）。

終了基準

製品を本番環境に投入するためにATが満たす必要のある特定の条件があります。

それらは次のとおりです。

• 合格テストを実行し、すべてのテストに合格する必要があります。
• 重大/重大な欠陥は未解決のままではありません。すべての欠陥を修正し、すぐに検証する必要があります。
• ATはサインオフする必要があります-含まれているすべての利害関係者によって Go / No-Go 製品の決定。

検収試験プロセス

に Vモデル 、ATフェーズは要件フェーズと並行しています。

実際のATプロセスは次のようになります。

ビジネス要件分析

プロジェクト内で利用可能なすべてのドキュメントを参照して、ビジネス要件を分析します。

そのうちのいくつかは：

• システム要件仕様
• ビジネス要件ドキュメント
• ユースケース
• ワークフロー図
• 設計されたデータマトリックス

設計検収試験計画

受け入れテスト計画に文書化される特定の項目があります。

それらのいくつかを見てみましょう：

• 検収試験の戦略とアプローチ。
• 開始基準と終了基準は明確に定義する必要があります。
• ATの範囲は十分に言及されている必要があり、ビジネス要件のみをカバーする必要があります。
• テストを書く人は誰でも簡単にテストの書き方を理解できるように、受け入れテストの設計アプローチを詳細に説明する必要があります。
• テストベッドのセットアップ、実際のテストスケジュール/タイムラインを記載する必要があります。
• テストはさまざまな利害関係者によって実施されるため、利害関係者が従う手順を認識していない可能性があるため、ログのバグの詳細について言及する必要があります。

検収試験の設計とレビュー

受け入れテストは、何をしなければならないかを述べたシナリオレベルで作成する必要があります（実行方法を含む詳細ではありません）。これらは、ビジネス要件の範囲の特定された領域に対してのみ作成する必要があり、すべてのテストをその参照要件にマッピングする必要があります。

ビジネス要件を高い範囲でカバーするには、すべての筆記試験をレビューする必要があります。

これは、上記の範囲以外の他のテストが含まれていないことを確認し、テストがスケジュールされたタイムライン内に収まるようにするためです。

検収試験ベッドのセットアップ

C ++で書かれたプログラム

テストベッドは、実稼働環境と同様に設定する必要があります。環境の安定性と使用状況を確認するには、非常に高度なチェックが必要です。このテストを実行している利害関係者とのみ環境を使用するための資格情報を共有します。

検収試験データの設定

生産データは、システムのテストデータとして準備/入力する必要があります。また、データをテストに使用する必要があるような詳細なドキュメントが必要です。

TestName1、TestCity1などのテストデータはなく、代わりにアルバート、メキシコなどを使用してください。これにより、リアルタイムデータの豊富なエクスペリエンスが提供され、テストは最新のものになります。

検収試験の実施

このステップでは、設計された受け入れテストを環境で実行する必要があります。理想的には、すべてのテストは最初の試行で合格する必要があります。受け入れテストから生じる機能的なバグがない場合は、修正するために高い優先度で報告する必要があります。

繰り返しになりますが、修正されたバグは、優先度の高いタスクとして検証して閉じる必要があります。テスト実行レポートは、毎日共有する必要があります。

このフェーズで記録されたバグは、バグトリアージ会議で議論する必要があり、根本原因分析手順を実行する必要があります。これは、すべてのビジネス要件が製品によって実際に満たされているかどうかを受け入れテストが評価する唯一のポイントです。

ビジネス上の決定

出てきます Go / No-Go 製品を本番環境で発売するかどうかの決定。 行く 決定により、製品は市場にリリースされる前に進みます。 立ち入り禁止 決定により、製品は失敗としてマークされます。

ノーゴー決定のいくつかの要因：

• 製品の品質が悪い。
• 開いている機能バグが多すぎます。
• ビジネス要件からの逸脱。
• 市場標準に達しておらず、現在の市場標準に一致するように拡張する必要があります。

このテストの成功要因

このテストが計画されたら、テストの成功率を高めるチェックリストを準備します。合格試験を開始する前に従うべきいくつかの行動項目があります。

彼らです：

• 明確に定義されたスコープを用意し、このテストで特定されたスコープのビジネスニーズがあることを確認します。
• システムテストフェーズ自体で少なくとも1回は受け入れテストを実行します。
• 広範囲に実行 アドホックテスト 受け入れテストシナリオごとに。

結論

一言で言えば、受け入れテストは、開発チームとテストチームの効率を把握するのに役立ちます。

このアクティビティを実行するためのツールはいくつかありますが、技術的なバックグラウンドを持たない実際のユーザーやさまざまな利害関係者が関与し、実行できない可能性があるため、通常は手動で実行することをお勧めします。

次は何ですか？

次のチュートリアルでは、以下のトピックにカーソルを合わせます。

• 検収試験基準の例。
• 検収試験計画の書き方。
• 検収試験の作成に適したテンプレート。
• 例を使って検収試験を書く方法。
• 検収試験シナリオの特定。
• 検収試験レポート。
• アジャイルおよびテスト駆動開発における受け入れテスト。

次のチュートリアル＃2：検収試験計画

検収試験を実施しましたか？あなたの経験を聞いてうれしいです！

推奨読書

• アルファテストとベータテスト（完全ガイド）
• ユーザー受け入れテスト（UAT）とは：完全ガイド
• ビルド検証テスト（BVTテスト）完全ガイド
• 機能テストと非機能テスト
• 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
• ソフトウェアテストの種類：詳細を含むさまざまなテストの種類
• ETLテストデータウェアハウステストチュートリアル（完全ガイド）
• Webアプリケーションセキュリティテストガイド