

工学とその様々な下位分野において、受入試験とは、仕様書や契約の要件が満たされているかどうかを判断するために実施される試験である。化学試験、物理試験、または性能試験が含まれる場合がある。[ 1 ]
システムエンジニアリングでは、システム(例えば、ソフトウェア、製造された機械部品のロット、または化学製品のバッチ)の納品前に実施されるブラックボックステストが含まれる場合があります。 [ 2 ]
ソフトウェアテスト において、ISTQBは受け入れテストを次のように定義しています。
ユーザーのニーズ、要件、およびビジネスプロセスに関する正式なテストを実施し、システムが受け入れ基準[ 3 ]を満たしているかどうかを判断し、ユーザー、顧客、またはその他の権限のある組織がシステムを受け入れるかどうかを判断できるようにします。
—ソフトウェアテストで使用される用語の標準用語集[ 4 ] : 2
QAライフサイクルの最終テストであるユーザー受け入れテストは、製品またはアプリケーションが現実世界のシナリオに対応できるかどうかを評価するために、最終リリースの直前に実施されます。ユーザーの行動を再現することで、システムがビジネス要件を満たしているかどうかを確認し、特定の基準を満たしていない場合は変更を拒否します。[ 5 ]
受け入れテストの形式には、ユーザー受け入れテスト(UAT)、エンドユーザーテスト、運用受け入れテスト(OAT)、受け入れテスト駆動開発(ATDD)、フィールド(受け入れ)テストなどがあります。受け入れ基準とは、システムまたはコンポーネントがユーザー、顧客、またはその他の権限のあるエンティティによって受け入れられるために満たさなければならない基準のことです。[ 6 ]
テストとは、テスト対象の 1 つ以上の項目の特性の発見や評価を容易にするために実施される一連の活動です。[ 7 ]テストケースと呼ばれる各テストは、テスト項目の実行を推進してテスト目標(正しい実装、エラーの特定、品質の検証、その他の重要な詳細を含む)を達成するために開発された、一連の事前定義されたテスト活動を実行します。[ 7 ]テスト環境は通常、想定される本番環境と同一、または可能な限り近いものとなるように設計されています。これには、ソフトウェアのテストを実行するために意図された、または使用されるすべての設備、ハードウェア、ソフトウェア、ファームウェア、手順、および/またはドキュメントが含まれます。[ 7 ]
UATおよびOATのテストケースは、理想的にはビジネス顧客、ビジネスアナリスト、テスター、開発者との協力のもとで作成されます。これらのテストには、ビジネスロジックテストと運用環境条件の両方を含める必要があります。ビジネス顧客(プロダクトオーナー)は、これらのテストの主要なステークホルダーです。テスト条件が受け入れ基準を正常に満たすと、ステークホルダーは開発が正しい方向に進んでいることを確信します。[ 8 ]
受け入れテストスイートは、すべてのテストケースが単一のテスト反復内で実行されない可能性があるため、複数回実行する必要がある場合があります。[ 9 ]
受け入れテストスイートは、事前に定義された受け入れテスト手順を使用して実行され、テスト担当者が使用するデータ、従うべきステップバイステップのプロセス、および実行後の期待される結果を指示します。実際の結果は、期待される結果と比較するために保持されます。[ 9 ]各テストケースの実際の結果が期待される結果と一致する場合、テストケースは合格したとみなされます。不合格のテストケースの数がプロジェクトの事前に定められたしきい値を超えない場合、テストスイートは合格したとみなされます。超える場合は、スポンサーと製造業者の間で事前に合意された条件に基づいて、システムが拒否されるか、受け入れられる可能性があります。
テスト実行が成功した場合に予想される結果:
目的は、開発された製品が機能要件と非機能要件の両方を満たしていることを確信してもらうことです。受け入れテストを実施する目的は、テストが完了し、受け入れ基準が満たされた場合、スポンサーが製品開発/機能強化が定義された要件(ビジネス部門と製品提供者/開発者の間で事前に合意されたもの)を満たしていると承認することです。
ユーザー受け入れテスト(UAT)は、ソリューションがユーザーにとって機能することを検証するプロセスです。[ 10 ]これはシステムテスト(ソフトウェアがクラッシュせず、文書化された要件を満たしていることを確認する)ではなく、ソリューションがユーザーにとって機能すること(つまり、ユーザーがソリューションを受け入れることをテストすること)を保証するものです。ソフトウェアベンダーはこれを「ベータテスト」と呼ぶことがよくあります。
このテストは、意図されたエンドユーザー、または主題専門家(SME)、できればテスト対象ソリューションの所有者またはクライアントによって実施され、試用またはレビュー後に続行するための確認のために結果の概要を提供する必要があります。ソフトウェア開発では、プロジェクトの最終段階の1つであるUATは、クライアントまたは顧客が新しいシステムを受け入れる前に行われることがよくあります。システムのユーザーは、実際のシナリオで発生するであろうことに沿ってテストを実行します。[ 11 ]
テスターに提供される資料は、エンドユーザーが使用する資料と類似している必要があります。テスターには、彼らが代表するユーザーが行う最も一般的または困難なタスクの 3 つなど、実際のシナリオが与えられるべきです。[ 12 ]
UATは、有料顧客または特定の大口顧客に代わって現実世界の状況をシミュレートし、必要なビジネス機能とシステムの適切な動作を最終的に検証する役割を果たします。ソフトウェアが通常の使用中に要求どおりに問題なく動作する場合、本番環境でも同じレベルの安定性が期待できると考えられます。[ 13 ]
通常、クライアントやエンドユーザーによって実施されるユーザーテストは、スペルミスなどの単純な外観上の問題や、ソフトウェアのクラッシュなどの致命的な欠陥を特定することには重点を置きません。これらの問題は、テスターや開発者が、より早い段階の単体テスト、統合テスト、システムテストの段階で特定し、修正します。
UAT はテスト シナリオに対して実行する必要があります。[ 14 ] [ 15 ]テスト シナリオは通常、システム テスト ケースや機能テスト ケースとは異なり、「プレイヤー」または「ユーザー」の旅を表します。テスト シナリオの広範な性質により、技術的またはシステム固有の詳細ではなく旅に焦点を当てることができ、ユーザーの行動のばらつきを許容するために「クリックごとの」テスト手順を避けることができます。テスト シナリオは論理的な「日」に分割することができ、これは通常、アクター (プレイヤー/顧客/オペレーター) またはシステム (バックオフィス、フロントエンド) が変化する日です。[ 16 ]
産業界では、一般的なUATは工場受入試験(FAT)です。この試験は機器の設置前に行われます。ほとんどの場合、試験担当者は機器が仕様を満たしているだけでなく、完全に機能することも確認します。FATには通常、完全性の確認、契約上の要件との照合、機能の証明(シミュレーションまたは従来の機能テストによる)、および最終検査が含まれます。[ 17 ] これらの試験の結果により、顧客はシステムが生産現場でどのように動作するかについて確信を持つことができます。システムの受入には、法的または契約上の要件がある場合もあります。
運用受入テスト(OAT) は、品質管理システムの一部として、製品、サービス、またはシステムの運用準備 (リリース前) を実施するために使用されます。OAT は、主にソフトウェア開発およびソフトウェア保守プロジェクトで使用される一般的な非機能ソフトウェアテストの一種です。このタイプのテストは、サポートされるシステム、および/または本番環境の一部となるシステムの運用準備に焦点を当てています。[ 18 ]
受け入れテストは、アジャイルソフトウェア開発手法、特にエクストリームプログラミングで使用される用語で、実装フェーズ中にソフトウェア開発チームが行うユーザーストーリーの機能テストを指します。 [ 19 ]
顧客は、ユーザー ストーリーが正しく実装されたかどうかをテストするシナリオを指定します。ストーリーには、機能が動作することを保証するために必要な、1 つまたは複数の受け入れテストを含めることができます。受け入れテストはブラックボックス システム テストです。各受け入れテストは、システムからの期待される結果を表します。顧客は、受け入れテストの正確性を検証し、テスト スコアを確認して、どの失敗したテストが最も優先度が高いかを決定する責任があります。受け入れテストは、本番リリース前の回帰テストとしても使用されます。ユーザー ストーリーは、受け入れテストに合格するまで完了とはみなされません。つまり、各イテレーションごとに新しい受け入れテストを作成する必要があり、そうしないと開発チームは進捗がゼロであると報告することになります。[ 20 ]
一般的な受け入れテストの種類には、以下のものがあります。
プロジェクトマネジメント協会によると、受入基準とは「成果物が受入される前に満たさなければならない条件の集合」である。[ 26 ]システムの特定のコンポーネントに対する受入基準に含まれる要件は、通常非常に詳細である。[ 27 ]
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク){{cite news}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)