受け入れ試験

エンジニアリングおよびそのさまざまな分野では、 受け入れテストは、仕様または契約の要件が満たされているかどうかを判断するために実施されるテストです。化学試験、物理試験、または性能試験が含まれる場合があります。

（：ソフトウェアの一部、製造機械部品の多く、又は化学製品のバッチなど）の送達に先立ってシステム・エンジニアリングでは、システム上で実行ブラックボックステストを含むことができます。

ソフトウェアテストでは、ISTQBは受け入れテストを次のように定義しています 。

システムが受け入れ基準を満たしているかどうかを判断し、ユーザー、顧客、またはその他の承認されたエンティティがシステムを受け入れるかどうかを判断できるようにするために行われた、ユーザーのニーズ、要件、およびビジネスプロセスに関する正式なテスト。

受け入れテストは、ユーザー受け入れテスト（UAT）、エンドユーザーテスト、運用受け入れテスト（OAT）、受け入れテスト駆動開発（ATTD）、またはフィールド（受け入れ）テストとも呼ばれます。受け入れ基準は、システム、コンポーネントがユーザー、顧客、またはその他の認可されたエンティティによって受け入れられるために満たさなければならない基準です。

煙テストは、ソフトウェアのビルドをメインのテストプロセスに導入する前の受け入れテストとして使用できます。

概要

テストとは、テスト中の1つ以上のアイテムのプロパティの検出または評価を促進するために実行される一連のアクティビティです。テストケースと呼ばれる個々のテストは、テスト項目を実行してテストの目的を達成するために開発された一連の定義済みテストアクティビティを実行します。正しい実装、エラーの識別、品質検証、その他の重要な詳細を含みます。テスト環境は通常、予想される実稼働環境と同一、または可能な限り近くなるように設計されています。これには、ソフトウェアのテストを目的とする、またはソフトウェアのテストを実行するために使用されるすべての機能、ハードウェア、ソフトウェア、ファームウェア、手順、ドキュメントが含まれます。

UATおよびOATテストケースは、理想的には、ビジネス顧客、ビジネスアナリスト、テスター、および開発者とのコラボレーションで導き出されます。これらのテストには、ビジネスロジックテストと運用環境条件の両方を含めることが不可欠です。これらのテストの主な利害関係者は、ビジネス顧客（製品所有者）です。テスト条件が合格基準を正常に達成すると、利害関係者は開発が正しい方向に進んでいると安心します。

• （アジャイルソフトウェア開発における）ユーザー受け入れテスト（UAT）基準は、通常、ビジネス顧客によって作成され、ビジネスドメイン言語で表現されます。これらは、スプリント/イテレーション中に「プレイ」されたユーザーストーリーの完全性を検証するための高レベルのテストです。
• 運用受け入れテスト（OAT）基準（かかわらず、アジャイル反復または連続開発を使用している場合は）機能的および非機能要件の観点から定義されています。機能の安定性、移植性、信頼性の主要な品質属性をカバーしています。

処理する

すべてのテストケースが1回のテストの繰り返しで実行されるわけではないため、受け入れテストスイートを複数回実行する必要がある場合があります。

受入テストスイートは、データが従うように、ステップバイステップのプロセスを使用するテスターと実行次の期待される結果を導くために予め定義された受入試験手順を使用して実行されます。実際の結果は、予想される結果と比較するために保持されます。実際の結果が各テストケースの期待される結果と一致する場合、テストケースは合格と言われます。合格しないテストケースの数がプロジェクトの事前に決められたしきい値を超えない場合、テストスイートは合格と言われます。その場合、スポンサーとメーカーとの間で以前に合意した条件でシステムが拒否または受け入れられる可能性があります。

テスト実行の成功の予想される結果：

• 所定のデータを使用してテストケースが実行されます
• 実際の結果が記録されます
• 実際の結果と期待される結果が比較されます。
• テスト結果が決定されます。

目的は、開発された製品が機能要件と非機能要件の両方を満たしているという信頼を提供することです。受け入れテストを実施する目的は、完了し、受け入れ基準が満たされていれば、スポンサーが定義済みの要件（以前はビジネスと製品プロバイダー/開発者の間で合意した）として製品開発/機能強化を承認することです。 。

ユーザー受け入れテスト

ユーザー受け入れテスト（UAT）は、ソリューションがユーザーに対して機能することを確認するプロセスで構成されます。これは、システムテスト（保証するソフトウェアがクラッシュし、文書化の要件を満たしていない）ではなく、ソリューションは、ユーザ（利用者が解決策を受け入れること、すなわち、テスト）のために働くだろうことを保証します。ソフトウェアベンダーはしばしばこれを「ベータテスト」と呼んでいます。

このテストでは、主題の専門家（SME）、試験中の溶液を、好ましくは、所有者またはクライアントによって行われ、裁判やレビューの後に続行するために、確認のための調査結果の要約を提供する必要があります。ソフトウェア開発では、クライアントまたは顧客が新しいシステムを受け入れる前に、プロジェクトの最終段階の1つであるUATが発生することがよくあります。システムのユーザーは、実際のシナリオで発生することと一致するテストを実行します。

テスターに​​提供される資料は、エンドユーザーが所有する資料と類似していることが重要です。テスターに​​は、彼らが代表するユーザーが引き受ける3つの最も一般的または困難なタスクなどの現実のシナリオを与える必要があります。

UATは払ってクライアントに代わったり、特定の大規模な顧客に、現実世界の条件をエミュレートし、必要なビジネス機能とシステムの適切な機能の最終確認として機能します。ソフトウェアが必要に応じて機能し、通常の使用中に問題なく動作する場合、本番環境で同じレベルの安定性を合理的に推定できます。

通常、クライアントまたはエンドユーザーによって実行されるユーザー・テストは、通常、スペルミスなどの簡単な化粧品の問題を特定する上で、また、そのようなソフトウェアのクラッシュなどの致命欠陥、に焦点を当てていません。テスターと開発者は、初期のユニットテスト、統合テスト、システムテストの段階でこれらの問題を特定して修正します。

UATはテストシナリオに対して実行する必要があります。通常、テストシナリオは、システムまたは機能テストケースとは異なり、「プレイヤー」または「ユーザー」の旅を表します。テストシナリオの広範な性質により、技術やシステム固有の詳細ではなく、旅行に焦点が当てられ、「クリックごと」のテストステップから離れて、ユーザーの行動のばらつきを考慮します。テストシナリオは通常、ここで、アクター（プレイヤー/顧客/オペレータ）またはシステム（バックオフィス、フロントエンド）変更された論理「日」、に分けることができます。

業界では、一般的なUATは工場受け入れテスト（FAT）です。このテストは、機器の設置前に行われます。ほとんどのタイムテスターは、機器が仕様を満たしていることを確認するだけでなく、完全に機能することも確認します。 FATは、通常、完全のチェック、契約条件に対する検証、機能（いずれかのシミュレーションまたは従来の機能試験による）と最終検査の証拠を含みます。

これらのテストの結果は、システムが本番環境でどのように機能するかについてクライアントに自信を与えます。また、システムを受け入れるための法的または契約上の要件がある場合があります。

運用受け入れテスト

運用承認テスト（OAT）は、品質管理システムの一部として製品、サービス、またはシステムの運用準備（プレリリース）を行うために使用されます。 OATは一般的なタイプの非機能ソフトウェアテストであり、主にソフトウェア開発およびソフトウェアメンテナンスプロジェクトで使用されます。このタイプのテストは、サポートされるシステムの運用準備、および/または本番環境の一部になることに焦点を当てています。

極端なプログラミングでの受け入れテスト

受け入れテストは、実装フェーズでのソフトウェア開発チームによるユーザーストーリーの機能テストを参照して、アジャイルソフトウェア開発方法論、特に極端なプログラミングで使用される用語です。

顧客は、ユーザーストーリーが正しく実装されたときにテストするシナリオを指定します。機能が機能することを確認するために必要なものは何でも、ストーリーには1つ以上の受け入れテストを含めることができます。受け入れテストは、ブラックボックスシステムテストです。各受け入れテストは、システムから予想される結果を表します。お客様は、受け入れテストの正確性を検証し、テストスコアを確認して、どのテストが最も優先順位が高いかを判断する責任があります。受け入れテストは、製品リリース前の回帰テストとしても使用されます。ユーザーストーリーは、受け入れテストに合格するまで完全とは見なされません。つまり、反復ごとに新しい受け入れテストを作成する必要があります。そうしないと、開発チームは進捗状況を報告しません。

受け入れテストの種類

受け入れテストの典型的なタイプには次のものが含まれます

ユーザー受け入れテストには、工場受け入れテスト（FAT）、つまり、製品またはシステムを目的のサイトに移動する前にベンダーが行うテストが含まれます。その後、サイトのユーザーがサイト受け入れテスト（SAT）を実行します。運用受け入れテスト運用準備テストとも呼ばれます。これは、システムを使用して保守できるようにプロセスと手順が整っていることを確認するためにシステムに対して行われるチェックを指します。これには、バックアップ施設、災害復旧の手順、エンドユーザーのトレーニング、保守手順、およびセキュリティ手順に対して行われるチェックが含まれる場合があります。契約および規制の受け入れテスト契約受け入れテストでは、システムが受け入れられる前に、契約に文書化されている受け入れ基準に対してシステムがテストされます。規制の受け入れテストでは、システムが政府、法律、および安全基準を満たしていることを確認するためにテストされます。

受諾は、コンポーネントまたはシステムは、通常、ハードウェアならびにソフトウェアを含む、要件を満たしているか否かを判断するために、製品は供給者組織の従業員によって開発され、実行されたサイトで行われるテスト。

アルファおよびベータテストアルファテストは開発者のサイトで行われ、外部の顧客にリリースされる前に、内部スタッフによる運用システムのテストが含まれます。ベータテストは、顧客のサイトで行われ、自分の場所でシステムを使用して、システムが他の顧客にリリースされる前に、フィードバックを提供し、顧客のグループによってテストが含まれます。後者はしばしば「フィールドテスト」と呼ばれます。

受け入れテストフレームワークのリスト

• 一致、仕様別仕様（SbE）フレームワーク
  • Concordion.NET、.NETでの受け入れテスト
• Cucumber、行動駆動開発（BDD）受け入れテストフレームワーク
  • Capybara、Ruby Webアプリケーションの受け入れテストフレームワーク
  • Behat、PHPのBDD受け入れフレームワーク
  • レタス、Python用BDD受け入れフレームワーク
• 自動受け入れテスト用のFabasoft app.test
• 統合テストのフレームワーク（フィット）
  • FitNesse、Fitのフォーク
• iMacros
• ItsNat Java Ajax Webフレームワークには、サーバーベースの機能的なWebテスト機能が組み込まれています。
• Mocha、JavascriptとNode.jsに基づく人気のあるWeb受け入れテストフレームワーク
• ラノレックス
• ロボットフレームワーク
• セレン
• 例による仕様（Specs2）
• ワティル
• ゲージ（ソフトウェア）