受け入れ試験

航空機カタパルトの受け入れ試験
ジェームズ・ウェッブ宇宙望遠鏡の主鏡のうち6枚が受け入れテストの準備中

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

システム エンジニアリングでは、システム(例: ソフトウェア製造された多数の機械部品、または化学製品のバッチ) の納品前に実行されるブラック ボックス テストが含まれる場合があります。[2]

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

ユーザーのニーズ、要件、およびビジネス プロセスに関する正式なテスト。システムが受け入れ基準[3]を満たしているかどうかを判断し、ユーザー、顧客、またはその他の認可された団体がシステムを受け入れるかどうかを決定できるようにするために実施されます。

— ソフトウェアテストで使用される用語の標準用語集[4] : 2 

QA ライフサイクルの最終テストであるユーザー受け入れテストは、製品またはアプリケーションが現実世界のシナリオを処理できるかどうかを評価するために、最終リリースの直前に実施されます。ユーザーの行動を複製することで、システムがビジネス要件を満たしているかどうかをチェックし、特定の基準が満たされていない場合は変更を拒否します。[要出典]

受け入れテストの形式には、ユーザー受け入れテスト(UAT)、エンドユーザー テスト、運用受け入れテスト(OAT)、受け入れテスト駆動開発(ATDD)、フィールド (受け入れ) テストなどがあります。受け入れ基準は、システムまたはコンポーネントがユーザー、顧客、またはその他の認可されたエンティティによって受け入れられるために満たさなければならない基準です。[5]

概要

テストは、テスト対象の 1 つ以上の項目の特性の発見および/または評価を容易にするために実行される一連のアクティビティです。[6]テスト ケースとして知られる個々のテストは、テスト目的を達成するためにテスト項目の実行を推進するために開発された、事前定義されたテスト アクティビティのセットを実行します。正しい実装、エラーの特定、品質検証、その他の重要な詳細が含まれます。[6]テスト環境は通常、予想される運用環境と同一か、可能な限り近づけるように設計されます。これには、ソフトウェアのテストを目的とした、またはソフトウェアのテストを実行するために使用されるすべての設備、ハードウェア、ソフトウェア、ファームウェア、手順および/または文書が含まれます。[6]

UAT および OAT テスト ケースは、企業顧客、ビジネス アナリスト、テスター、開発者と協力して作成するのが理想的です。これらのテストには、ビジネス ロジック テストと運用環境条件の両方が含まれることが重要です。これらのテストの主な関係者は企業顧客 (製品所有者) ですテスト条件が合格基準を正常に達成すると、関係者は開発が正しい方向に進んでいることを安心できます。[7]

プロセス

すべてのテスト ケースが 1 回のテスト反復内で実行されるわけではないため、受け入れテスト スイートは複数回実行する必要がある場合があります。[8]

受け入れテスト スイートは、事前に定義された受け入れテスト手順を使用して実行され、どのデータを使用するか、従うべき段階的なプロセス、および実行後に期待される結果をテスターに​​指示します。実際の結果は、期待される結果と比較するために保持されます。[8]実際の結果が各テスト ケースの期待結果と一致する場合、そのテスト ケースは合格したと言われます。不合格のテスト ケースの量がプロジェクトの所定のしきい値を超えていない場合、テスト スイートは合格したとみなされます。そうなった場合、システムは、スポンサーと製造業者の間で事前に合意された条件に基づいて拒否されるか、または受け入れられる可能性があります。

テスト実行が成功した場合に予想される結果は次のとおりです。

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

目的は、開発された製品が機能要件と非機能要件の両方を満たしているという確信を与えることです。受け入れテストを実施する目的は、完了し、受け入れ基準が満たされていれば、スポンサーが製品開発/機能強化が定義された要件(企業と製品プロバイダー/開発者の間で事前に合意されている)を満たしていると承認することが期待されることです。 。

ユーザー受け入れテスト

ユーザー受け入れテスト (UAT) は、ソリューションがユーザーにとって機能することを検証するプロセスで構成されます。[9]これはシステム テスト(ソフトウェアがクラッシュしないこと、文書化された要件を満たしていることを確認すること) ではなく、ソリューションがユーザーにとって機能することを確認すること (つまり、ユーザーがソリューションを受け入れることをテストすること) です。ソフトウェア ベンダーは、これを「ベータ テスト」と呼ぶことがよくあります。

このテストは、対象となるエンド ユーザー、または対象分野の専門家(SME)、できればテスト対象のソリューションの所有者またはクライアントによって実施され、試用またはレビュー後に続行するための確認のために結果の概要を提供する必要があります。ソフトウェア開発では、クライアントまたは顧客が新しいシステムを受け入れる前に、プロジェクトの最終段階の 1 つとして UAT が行われることがよくあります。システムのユーザーは、現実のシナリオで発生することに沿ったテストを実行します。[10]

テスターに​​提供されるマテリアルが、エンド ユーザーが入手するマテリアルと類似していることが重要です。テスターに​​は、テスターが担当するユーザーが引き受ける 3 つの最も一般的なタスクまたは困難なタスクなどの現実のシナリオを与える必要があります。[11]

UAT は、必要なビジネス機能とシステムの適切な機能の最終検証として機能し、支払いを行っているクライアントまたは特定の大規模顧客に代わって現実世界の状況をエミュレートします。ソフトウェアが要求どおりに動作し、通常の使用中に問題がなければ、運用環境でも同じレベルの安定性があると合理的に推測できます。[12]

ユーザー テストは通常​​、クライアントまたはエンド ユーザーによって実行されますが、通常、スペル ミスなどの単純な表面上の問題や、ソフトウェア クラッシュなどの重大な欠陥の特定には焦点を当てません。テスターと開発者は、初期の単体テスト統合テスト、およびシステム テストの段階でこれらの問題を特定し、修正します。

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

業界では、一般的な UAT は工場受け入れテスト (FAT) です。このテストは機器の設置前に行われます。ほとんどの場合、テスターは機器が仕様を満たしているかどうかをチェックするだけでなく、完全に機能するかどうかもチェックします。FAT には通常、完全性のチェック、契約上の要件に対する検証、機能の証明 (シミュレーションまたは従来の機能テストによる)、および最終検査が含まれます。[16] これらのテストの結果により、クライアントはシステムが運用環境でどのように動作するかについて確信を得ることができます。システムの受け入れには法的または契約上の要件がある場合もあります。

運用受入テスト

運用受け入れテスト(OAT) は、品質管理システムの一部として、製品、サービス、またはシステムの運用準備 (リリース前) を実施するために使用されますOAT は一般的なタイプの非機能ソフトウェア テストであり、主にソフトウェア開発およびソフトウェア メンテナンスプロジェクトで使用されます。このタイプのテストは、サポートされるシステム、および/または運用環境の一部となるシステムの運用準備に焦点を当てます。[17]

エクストリーム プログラミングでの受け入れテスト

受け入れテストは、アジャイル ソフトウェア開発手法、特にエクストリーム プログラミングで使用される用語で、実装段階でのソフトウェア開発チームによるユーザー ストーリー機能テストを指します。[18]

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

受け入れテストの種類

典型的な種類の受け入れテストには次のようなものがあります。

ユーザー受け入れテスト
これには、工場受け入れテスト (FAT)、つまり、製品またはシステムが目的のサイトに移動される前にベンダーによって行われるテストが含まれる場合があります。その後、サイトのユーザーによってサイト受け入れテスト (SAT) が実行されます。[20]
運用受入テスト
これは運用準備テストとも呼ばれ、システムの使用と保守を可能にするプロセスと手順が整備されていることを確認するためにシステムに対して行われるチェックを指します。これには、設備をバックアップするために行われるチェック、災害復旧の手順、エンドユーザー向けのトレーニング、メンテナンス手順、セキュリティ手順が含まれる場合があります。[21]
契約および規制の受け入れテスト
契約受け入れテストでは、システムが受け入れられる前に、契約に文書化されている受け入れ基準に照らしてシステムがテストされます。規制受け入れテストでは、システムが政府、法律、安全基準を満たしていることを確認するためにテストされます。[22]
工場での受け入れテスト
製品が開発されているサイトでサプライヤー組織の従業員によって実施される受け入れテスト。コンポーネントまたはシステムが要件 (通常はハードウェアとソフトウェアを含む) を満たしているかどうかを判断します。[23]
アルファ版とベータ版のテスト
アルファ テストは開発者のサイトで行われ、外部の顧客にリリースされる前に内部スタッフによる運用システムのテストが行​​われます。ベータ テストは顧客のサイトで行われ、システムが他の顧客にリリースされる前に、自分の場所でシステムを使用してフィードバックを提供する顧客のグループによるテストが含まれます。後者は「フィールドテスト」と呼ばれることが多いです。[24]

合否基準

Project Management Instituteによると承認基準とは「成果物が承認される前に満たす必要がある一連の条件」です。[25] システムの特定のコンポーネントの受け入れ基準にある要件は、通常、非常に詳細です。[26]

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

こちらも参照

参考文献

  1. ^ "BPTS - ビジネス プロセス テストは最適な名前/説明ですか". SFIA 2023 年2 月 18 日に取得
  2. ^ ブラック、レックス (2009年8月)。テスト プロセスの管理: ハードウェアおよびソフトウェアのテストを管理するための実践的なツールとテクニックニュージャージー州ホーボーケン: ワイリー。ISBN 978-0-470-40415-7
  3. ^ "受け入れ基準". イノリューション合同会社 2019年6月10日。
  4. ^ 「ソフトウェア テストで使用される用語の標準用語集、バージョン 3.2: すべての用語」(PDF)ISTQB 2020 年11 月 23 日に取得
  5. ^ ISO/IEC/IEEE 国際標準 - システムおよびソフトウェア エンジニアリングISO/IEC/IEEE。2010. pp. vol., no., pp.1–418。
  6. ^ abc ISO/IEC/IEEE 29119-1:2013 ソフトウェアおよびシステム エンジニアリング - ソフトウェア テスト - パート 1: 概念と定義。ISO2013年2014 年10 月 14 日に取得
  7. ^ ISO/IEC/IEEE 29119-4:2013 ソフトウェアおよびシステム エンジニアリング - ソフトウェア テスト - パート 4: テスト技術。ISO2013年2014 年10 月 14 日に取得
  8. ^ ab ISO/IEC/IEEE 29119-2:2013 ソフトウェアおよびシステム エンジニアリング - ソフトウェア テスト - パート 2: テスト プロセス。ISO2013年2014 年5 月 21 日に取得
  9. ^ ロブ・シンパーマン (2006)。UAT の定義: 実践的なユーザー受け入れテストのガイドピアソン教育。ページ、第 2 章、ISBN 9780132702621
  10. ^ ゲーセム、ブライアン; ヴァン・ハンブリング、ポーリン(2013)。ユーザー受け入れテスト: 段階的なガイドBCS ラーニング & ディベロップメント リミテッド。ISBN 9781780171678
  11. ^ 「2.6: システムのテスト」. LibreText のエンジニアリング2021年8月2日2023 年2 月 18 日に取得
  12. ^ プスルリ、ナゲシュワル ラオ (2006)。ソフトウェア テストの概念とツールドリームテックプレス。p. 62.ISBN _ 9788177227123
  13. ^ "これらのテスト シナリオで信頼性の高いユーザビリティを実現し、リスクを回避する". パナヤ2022 年 4 月 25 日2022 年5 月 11 日に取得
  14. ^ エラザール、エヤル (2018 年 4 月 23 日)。「ユーザー受け入れテスト (UAT) とは何ですか - 完全なプロセスの説明」。パナヤ2023 年2 月 18 日に取得
  15. ^ ワイソッカ、エミリア M. マシュー・ペイジ。スノーデン、ジェームズ。シンプソン、T.イアン(2022年12月15日)。「DARPP-32 信号ネットワークの規則微分方程式と常微分方程式に基づく動的モデルの比較」。ピアJ10「表 1: ODE モデルと RB モデルの仕様は要素に分類でき、要素の数を比較できます。」土井10.7717/peerj.14516ISSN  2167-8359。PMC 9760030PMID  36540795。 
  16. ^ 「工場受け入れテスト (FAT)」。テュフ ラインランド。2013 年 2 月 4 日のオリジナルからアーカイブ2012 年9 月 18 日に取得
  17. ^ ビジェイ (2018 年 2 月 2 日)。「受け入れテストとは (完全ガイド)」。ソフトウェア テストのヘルプ2023 年2 月 18 日に取得
  18. ^ "要件成果物としての受け入れ/顧客テストの概要". アジャイルモデリング.comアジャイルモデリング2013 年12 月 9 日に取得
  19. ^ ウェルズ、ドン。「受け入れテスト」。Extremeprogramming.org 2011 年9 月 20 日に取得
  20. ^ プラサド、ドゥルガー (2012 年 3 月 29 日)。「FATとSATの違い」。ニート.com2017年6月16日のオリジナルからアーカイブ2016 年7 月 27 日に取得
  21. ^ ポール・ターナー (2020年10月5日). 「運用準備」。コミッショニングとスタートアップ2023 年2 月 18 日に取得
  22. ^ ブロスナン、アデリン(2021年1月12日)。「情報技術契約における受け入れテスト | LegalVision」。リーガルビジョン2023 年2 月 18 日に取得
  23. ^ "ソフトウェア テストで使用される用語の ISTQB 標準用語集". 2018年11月5日のオリジナルからアーカイブ2019 年3 月 15 日に取得
  24. ^ ハミルトン、トーマス (2020 年 4 月 3 日). 「アルファ テストとベータ テスト – それらの違い」。www.guru99.com 2023 年2 月 18 日に取得
  25. ^ Project Management Institute 2021、§用語集セクション 3. 定義。
  26. ^ Project Management Institute 2021、§2.6.2.1 要件。

情報源

  • プロジェクト管理知識体系ガイド (PMBOK ガイド) (第 7 版)。ペンシルバニア州ニュータウンスクエア: プロジェクト管理研究所。2021.ISBN _ 978-1-62825-664-2

参考文献

  • ハンブリング、ブライアン。ヴァン・ゲーセム、ポーリン(2013)。ユーザー受け入れテスト: ステップバイステップガイドスウィンドン: BCS Learning and Development Ltd. ISBN 978-1-78017-167-8

外部リンク

Retrieved from "https://en.wikipedia.org/w/index.php?title=Acceptance_testing&oldid=1210394483#User_acceptance_testing"