what is user acceptance testing
ユーザー受け入れテスト（UAT）とは何か、その定義、タイプ、手順、および例を学びます。
新しい概念を理解しようとするときの私の一番のルールは次のとおりです。 名前は常に関連性があり、ほとんどが文字通りの意味です （技術的な文脈で）。
それが何であるかを知ることは、それを最初に理解し、私が始めるのに役立ちます。
ハッシュテーブルの例c ++
=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください
この概念をテストしてみましょう。
=> すべてのチュートリアルを読む 検収試験シリーズで。
学習内容：
ユーザー受け入れテストとは何ですか？
私たちはテストとは何かを知っています。受け入れとは承認または同意を意味します。ソフトウェア製品のコンテキストでのユーザーは、ソフトウェアの消費者か、ソフトウェアの構築を要求した人（クライアント）のいずれかです。
したがって、私のルールに従うと、定義は次のようになります。
ベータテストまたはエンドユーザーテストとも呼ばれるユーザー受け入れテスト（UAT）は、ユーザーまたはクライアントがソフトウェアをテストして、受け入れられるかどうかを判断することとして定義されます。 これは、機能テスト、システムテスト、および回帰テストが完了した後に実行される最終テストです。
このテストの主な目的は、ビジネス要件に対してソフトウェアを検証することです。この検証は、ビジネス要件に精通しているエンドユーザーによって実行されます。
UAT、 アルファおよびベータテスト さまざまな種類の検収試験です。
ユーザー受け入れテストは、ソフトウェアが稼働する前に実行される最後のテストであるため、明らかに、これは、顧客がソフトウェアをテストして、目的に適しているかどうかを測定する最後のチャンスです。
いつ実行されますか？
これは通常、製品が稼働する前、または製品の配送が受け入れられる前の最後のステップです。これは、製品自体が徹底的にテストされた後に実行されます（つまり、 システムテスト後 ）。
誰がUATを実行しますか？
ユーザーまたはクライアント–これは、製品を購入している人（商用ソフトウェアの場合）、またはソフトウェアが利用可能になっている場合はソフトウェアサービスプロバイダーまたはエンドユーザーを通じてカスタムビルドされたソフトウェアを持っている人のいずれかです。事前に、そして彼らのフィードバックが求められるとき。
チームはベータテスターで構成することも、顧客は組織のすべてのグループから内部的にUATメンバーを選択して、すべてのユーザーの役割をそれに応じてテストできるようにする必要があります。
ユーザー受け入れテストの必要性
開発者と機能テスターは、ソフトウェアを検証する技術者です。 機能仕様 。彼らは知識に従って要件を解釈し、ソフトウェアを開発/テストします（ここにドメイン知識の重要性があります）。
このソフトウェアは機能仕様に従って完全ですが、エンドユーザーだけが知っているいくつかのビジネス要件とプロセスが通信に失敗するか、誤って解釈されます。
このテストは、市場で使用するソフトウェアをリリースする前に、すべてのビジネス要件が満たされているかどうかを検証する上で重要な役割を果たします。ライブデータと実際のユースケースを使用することで、このテストはリリースサイクルの重要な部分になります。
リリース後の問題により大きな損失を被った多くの企業は、ユーザー受け入れテストを成功させることの重要性を知っています。リリース後に欠陥を修正するコストは、以前に修正するよりも何倍も高くなります。
UATは本当に必要ですか？
システムのロード、統合、および回帰テストを実行した後、このテストの必要性について疑問に思うでしょう。実際には、これはプロジェクトの最も重要なフェーズです。これは、実際にシステムを使用するユーザーが、目的に合っているかどうかシステムを検証する時間だからです。
UATは、エンドユーザーの視点とエンドユーザーを代表する部門のドメイン知識に大きく依存するテストフェーズです。
実際のところ、ビジネスチームがプロジェクトにかなり早い段階で関わっていれば、実際のシステムの効果的な使用に役立つ意見や貢献を提供できるので、ビジネスチームにとって非常に役立ちます。
ユーザー受け入れテストプロセス
このプロセスを理解する最も簡単な方法は、これを自律的なテストプロジェクトと考えることです。つまり、計画、設計、および実行の各フェーズがあります。
計画フェーズを開始する前の前提条件は次のとおりです。
＃1）主要な合格基準を収集する
簡単に言えば、受け入れ基準は、製品を受け入れる前に評価されるもののリストです。
これらには2つのタイプがあります。
（i）アプリケーションの機能またはビジネス関連
理想的には、すべての主要なビジネス機能を検証する必要がありますが、時間などのさまざまな理由により、すべてを実行することは現実的ではありません。したがって、このテストに関与するクライアントまたはユーザーとの1〜2回の会議で、どの程度のテストが関与し、どの側面がテストされるかについてのアイデアを得ることができます。
（ii）契約 –これについては説明しませんが、QAチームがこれに関与することはほとんどありません。 SDLCが始まる前に作成された最初の契約がレビューされ、契約のすべての側面が提供されたかどうかについて合意に達します。
ここでは、アプリケーションの機能のみに焦点を当てます。
＃2）QA関与の範囲を定義します。
QAチームの役割は次のいずれかです。
（i）関与なし –これは非常にまれです。
（ii）このテストを支援する– ごくありふれた。この場合、私たちの関与は、アプリケーションの使用方法についてUATユーザーをトレーニングし、このテスト中にスタンバイ状態にして、問題が発生した場合にユーザーを支援できることを確認することです。または、場合によっては、スタンバイ状態での支援に加えて、ユーザーが実際のテストを実行している間に、応答を共有して結果を記録したり、バグをログに記録したりすることがあります。
（iii）UATを実行し、結果を提示する– この場合、ユーザーは評価したいAUTの領域を指定し、評価自体はQAチームによって実行されます。完了すると、結果がクライアント/ユーザーに提示され、AUTを受け入れるために、手元にある結果が十分であるかどうか、および期待に応じて決定を下します。決定はQAチームの決定ではありません。
手元のケースに応じて、どちらのアプローチが最適かを決定します。
主な目的と期待：
通常、UATは、対象分野の専門家（SME）および/またはビジネスユーザーによって実施されます。これらのユーザーは、テスト対象のシステムの所有者または顧客である可能性があります。システムテストフェーズと同様に、UATフェーズには、閉鎖される前の宗教フェーズも含まれます。
各UATフェーズの主な活動は以下のとおりです。
UATガバナンス
システムテストと同様に、UATには効果的なガバナンスが適用され、定義された開始および終了基準（**の下に提供）とともに強力な品質のゲートが保証されます。
**これは単なるガイダンスであることに注意してください。これは、プロジェクトのニーズと要件に基づいて変更できます。
UATテスト計画
プロセスは、とほぼ同じです 定期的なテスト計画 システムフェーズで。
ほとんどのプロジェクトで採用されている最も一般的なアプローチは、システムとUATの両方のテストフェーズを一緒に計画することです。サンプルとともにUATテスト計画の詳細については、添付のテスト計画ドキュメントのUATセクションを確認してください。
ユーザー受け入れテストプラン
（これは、QAトレーニングシリーズのサイトにもあるものと同じです）。
下の画像をクリックして下にスクロールすると、さまざまな形式のテスト計画ドキュメントのサンプルが見つかります。そのテンプレートで、UATセクションを確認してください。
日付、環境、アクター（who）、通信プロトコル、役割と責任、テンプレート、結果とその分析プロセス、出入り基準–これらすべてと関連するその他すべてがUATテスト計画に記載されています。
QAチームがこのテストに参加しているか、部分的に参加しているか、まったく参加していないかにかかわらず、このフェーズを計画し、すべてが考慮されていることを確認するのが私たちの仕事です。
=> これは、ユーザー受け入れテスト計画のサンプルドキュメントです。
ユーザー受け入れテストの設計
このステップでは、ユーザーから収集された受け入れ基準が使用されます。サンプルは次のようになります。
（これらはからの抜粋です CSTE CBOK 。これは、このテストに関して利用できる最高のリファレンスの1つです。）
ユーザー受け入れテストテンプレート：
c ++面接の質問pdf
基準に基づいて、私たち（QAチーム）はユーザーにUATテストケースのリストを提供します。これらのテストケースは、通常のシステムテストケースと同じです。これらは、主要な機能領域だけでなく、すべてのアプリケーションをテストするためのサブセットにすぎません。
これらに加えて、次のフェーズに進む前に、データ、テスト結果を記録するためのテンプレート、管理手順、欠陥ログメカニズムなどを用意する必要があります。
テストの実行
通常、このテストは、可能であれば、ユーザー、PM、QAチームの代表者全員が1日か2日一緒に座って、すべての受け入れテストケースを処理する会議または戦争室のような設定で行われます。
または、QAチームがテストを実行する場合は、AUTでテストケースを実行します。
すべてのテストが実行され、結果が手元にあると、 受理決定 作られています。これは、 Go / No-Goの決定 。ユーザーが満足している場合、それは成功です。そうでない場合は、失敗です。
受け入れの決定に達することは、通常、このフェーズの終わりです。
ツールと方法論
通常、このテストフェーズで使用されるソフトウェアツールの種類は、機能テストの実行中に使用されるツールと似ています。
ツール：
このフェーズでは、アプリケーションの完全なエンドツーエンドフローを検証する必要があるため、この検証を完全に自動化する1つのツールを用意するのは難しい場合があります。ただし、ある程度、システムテスト中に開発された自動スクリプトを活用することはできます。
システムテストと同様に、ユーザーはQC、JIRAなどのテスト管理および欠陥管理ツールも使用します。これらのツールは、ユーザー受け入れフェーズのデータを累積するように構成できます。
方法論：
製品のUATを実行する特定のビジネスユーザーなどの従来の方法論は依然として適切ですが、今日のような真にグローバルな世界では、ユーザー受け入れテストでは、製品に基づいて国全体のさまざまな顧客を関与させる必要があります。
例えば、 eコマースWebサイトは、世界中の顧客によって使用されます。このようなシナリオでは、クラウドテストが最良の実行可能なオプションになります。
群集テスト は、世界中の人々が参加して製品の使用法を検証し、提案や推奨事項を提供できる方法論です。
群集テストプラットフォームが構築され、現在多くの組織で使用されています。クラウドテストが必要なWebサイトまたは製品はプラットフォームでホストされ、顧客は検証を行うために自分自身を指名できます。提供されたフィードバックは分析され、優先順位が付けられます。
クラウドテストの方法論は、世界中の顧客の脈動を簡単に理解できるため、より効果的であることが証明されています。
アジャイル環境でのUAT
アジャイル環境は本質的によりダイナミックです。アジャイルの世界では、ビジネスユーザーはプロジェクトのスプリント全体に関与し、プロジェクトはそれらからのフィードバックループに基づいて強化されます。
プロジェクトの開始時には、ビジネスユーザーが要件を提供する主要な利害関係者となり、それによって製品のバックログが更新されます。各スプリントの終了時に、ビジネスユーザーはスプリントデモに参加し、フィードバックを提供できるようになります。
さらに、UATフェーズは、ビジネスユーザーが検証を行うスプリントが完了する前に計画されます。
スプリントデモおよびスプリントUAT中に受信したフィードバックは照合され、製品バックログに追加されます。製品バックログは常に確認され、優先順位が付けられます。したがって、アジャイルの世界では、ビジネスユーザーはプロジェクトにより近く、従来のウォーターフォールプロジェクトとは異なり、より頻繁に使用するために同じものを評価します。
UATチーム–役割と責任
典型的なUAT組織には、次の役割と責任があります。 UATチームは、プロジェクトマネージャー、開発チーム、およびテストチームのニーズに基づいてサポートされます。
| 役割 | 責任 | 成果物 |
|---|---|---|
| ビジネスプログラムマネージャー | •プログラム提供計画を作成および維持する •UATテストの戦略と計画を確認および承認する •スケジュールと予算内でプログラムが正常に完了するようにします •ITプログラムマネージャーと連絡を取り、プログラムの進捗状況を監視します •ビジネスオペレーションチームと緊密に連携し、1日目のオペレーションに備えます。 •サインオフビジネス要件ドキュメント •eラーニングコースの内容を確認する | •プログラム進捗レポート •毎週のステータスレポート |
| UATテストマネージャー | •クレタUAT戦略 •ITとビジネスBAおよびPMO間の効果的なコラボレーションを確保します •要件ウォークスルーミーティングに参加する •作業量の見積もり、テスト計画を確認します •要件のトレーサビリティを確保する •メトリック収集を推進して、更新されたテスト方法、ツール、および環境の使用から得られるメリットを定量化します。 | •マスターテスト戦略 •テストシナリオのレビューと承認 •テストケースのレビューと承認 •要件トレーサビリティマトリックスを確認および承認する •毎週のステータスレポート |
| UATテストリードおよびチーム | •ビジネスプロセスに対するビジネス要件の検証と妥当性確認 •UATの見積もり •UATテスト計画の作成と実行 •要件JADセッションに参加する •ビジネスプロセスに基づいて、テストシナリオ、テストケース、およびテストデータを準備します •トレーサビリティを維持する •テストケースを実行し、テストログを準備します •テスト管理ツールの欠陥を報告し、ライフサイクル全体でそれらを管理します •UATテスト終了レポートを作成する •ビジネス準備サポートとライブ証明を提供します | •テストログ •毎週のステータスレポート •欠陥レポート •テスト実行メトリクス •テスト要約レポート •アーカイブされた再利用可能なテスト成果物 |
UATと緩和計画の7つの課題
あなたが10億ドルのリリースに参加しているのか、スタートアップチームに所属しているのかは関係ありません。エンドユーザーに成功するソフトウェアを提供するには、これらすべての課題を克服する必要があります。
＃1）環境のセットアップと展開のプロセス：
機能テストチームが使用するのと同じ環境でこのテストを実行すると、実際のユースケースを見落とすことになります。また、パフォーマンステストなどの重要なテストアクティビティは、不完全なテスト環境では実行できません。 テストデータ 。
このテストでは、本番環境のような別の環境を設定する必要があります。
UAT環境がテスト環境から分離されたら、リリースサイクルを効果的に制御する必要があります。制御されていないリリースサイクルは、テスト環境とUAT環境で異なるソフトウェアバージョンにつながる可能性があります。ソフトウェアが最新バージョンでテストされていない場合、貴重な受け入れテスト時間が無駄になります。
一方、誤ったソフトウェアバージョンでの問題追跡に必要な時間は長くなります。
＃2）テスト計画：
このテストは、要件分析および設計段階で明確な受け入れテスト計画を使用して計画する必要があります。
クロックインクロックアウトソフトウェア無料
戦略計画では、実行のために一連の実際のユースケースを特定する必要があります。このテストフェーズの大規模なアプリケーションでは完全なテスト実行は不可能であるため、このテストのテスト目標を定義することは非常に重要です。テストは、最初に重要なビジネス目標に優先順位を付けて実行する必要があります。
このテストは、テストサイクルの最後に実行されます。明らかに、それはソフトウェアリリースにとって最も重要な時期です。開発とテストの前の段階のいずれかが遅れると、UAT時間が消費されます。
不適切なテスト計画は、最悪の場合、システムテストとUATの重複につながります。期限を守るための時間とプレッシャーが少ないため、機能テストが完了していなくても、ソフトウェアはこの環境に展開されます。このような状況では、このテストの主要な目標を達成することはできません。
UATテスト計画を作成し、このテストを開始する前にチームに伝達する必要があります。これは、テスト計画、テストケースとテストスクリプトの作成、およびUAT環境の作成に役立ちます。
＃3）インシデント/欠陥としての新しいビジネス要件の処理：
要件のあいまいさは、UATフェーズで捕捉されます。 UATテスターは、（要件収集フェーズでは利用できなかった完全なUIを確認することで）あいまいな要件が原因で発生する問題を見つけ、それを欠陥としてログに記録します。
お客様は、変更要求の時間を考慮せずに、これらが現在のリリースで修正されることを期待しています。これらの直前の変更についてプロジェクト管理者がタイムリーな決定を下さない場合、リリースの失敗につながる可能性があります。
＃4）熟練していないテスターまたはビジネス知識のないテスター：
常勤チームがいない場合、会社はさまざまな内部部門からUATスタッフを選択します。
スタッフがビジネスニーズに精通している場合、または開発中の新しい要件についてトレーニングを受けていない場合でも、効果的なUATを実行することはできません。また、技術以外のビジネスチームは、テストケースの実行において多くの技術的な問題に直面する可能性があります。
一方、UATサイクルの最後にテスターを割り当てても、プロジェクトに価値はありません。 UATスタッフをトレーニングする時間がほとんどない場合、UATが成功する可能性が大幅に高まります。
＃5）不適切な通信チャネル：
リモート開発、テスト、およびUATチーム間の通信はより困難です。オフショアの技術チームがいる場合、電子メールによるコミュニケーションは非常に難しいことがよくあります。インシデントレポートのわずかなあいまいさにより、修正が1日遅れる可能性があります。
適切な計画と効果的なコミュニケーションは、効果的なチームコラボレーションにとって重要です。プロジェクトチームは、Webベースのツールを使用して欠陥や質問をログに記録する必要があります。これにより、ワークロードを均等に分散し、重複する問題の報告を回避できます。
＃6）機能テストチームにこのテストを実行するように依頼する：
機能テストチームにUATの実行を依頼することほど悪い状況はありません。
リソースが不足しているため、顧客はテストチームに責任を負わせます。このような場合、このテストの目的全体が損なわれます。ソフトウェアが稼働すると、エンドユーザーは機能テスターによって実際のシナリオとは見なされない問題をすばやく見つけることができます。
これに対する解決策は、このテストをビジネス知識を持つ熱心で熟練したテスターに割り当てることです。
＃7）非難ゲーム
ビジネスユーザーは、ソフトウェアを拒否する理由を見つけようとすることがあります。彼らがどれほど優れているかを示したり、開発およびテストチームを非難してビジネスチームに敬意を払ったりするのは、彼らの自我かもしれません。これは非常にまれですが、内部政治のあるチームで発生します。
そのような状況に対処することは非常に困難です。ただし、ビジネスチームとの前向きな関係を構築することは、非難のゲームを回避するのに間違いなく役立ちます。
これらのガイドラインが、さまざまな課題を克服することにより、ユーザー受け入れ計画を成功させるのに確実に役立つことを願っています。適切な計画、コミュニケーション、実行、および意欲的なチームは、ユーザー受け入れテストを成功させるための鍵です。
システムテストとユーザー受け入れテスト
テストチームの関与は、要件分析フェーズからプロジェクトのかなり早い段階で始まります。
プロジェクトのライフサイクル全体を通じて、プロジェクトに対して何らかの検証が実行されます。 静的テスト 、単体テスト、システムテスト、統合テスト、エンドツーエンドテストまたは回帰テスト。これにより、UATフェーズで実行されたテストと、以前に実行された他のテストとの違いについて理解を深めることができます。
SITとUATには違いがありますが、相乗効果を活用しながら、両方のフェーズ間の独立性を維持して、市場投入までの時間を短縮することが重要です。
結論
＃1） UATは、ページ、フィールド、またはボタンに関するものではありません。根底にある 仮定 このテストが始まる前でさえ、すべての基本的なものがテストされ、正常に機能しているということです。神は禁じています、ユーザーはそれと同じくらい基本的なバグを見つけます–それはQAチームにとって非常に悪いニュースの一部です。 :(
＃二） このテストは、ビジネスの主要な要素であるエンティティに関するものです。
例を挙げましょう： AUTがチケットシステムの場合、UATは、ページを開くメニューの検索などを行うことはありません。チケットとその予約、取得できる状態、システム内の移動、等
別の 例、 サイトが自動車販売店のサイトである場合、焦点は「自動車とその販売」にあり、実際にはサイトではありません。したがって、コアビジネスは、検証および妥当性確認されたものであり、ビジネスオーナーよりも誰がそれを行うのが優れているかです。そのため、このテストは、顧客が大部分関与している場合に最も理にかなっています。
＃3） UATは、その中核となるテストの一形態でもあります。 この段階でもいくつかのバグを特定する可能性が高いこと 。それは時々起こります。 QAチームの大きなエスカレーションであるという事実を除けば、UATのバグは通常、このテストに続いて修正して再テストする時間がないため、座ってそれらの処理方法について話し合う会議を意味します。
決定は次のいずれかになります。
- 運用開始日をプッシュし、最初に問題を修正してから次に進みます。
- バグはそのままにしておきます。
- 将来のリリースの変更要求の一部と見なしてください。
＃4） UATはアルファテストとベータテストに分類されますが、サービスベースの業界における一般的なソフトウェア開発プロジェクトのコンテキストでは、その分類はそれほど重要ではありません。
- アルファテスト UATがソフトウェアビルダーの環境で実行される場合であり、市販のソフトウェアのコンテキストでより重要です。
- ベータテスト UATが実稼働環境またはクライアントの環境で実行される場合です。これは、顧客向けのアプリケーションでより一般的です。ここでのユーザーは、このコンテキストでのあなたや私のような実際の顧客です。
＃5） 通常のソフトウェア開発プロジェクトでは、ほとんどの場合、UATは QA環境 ステージングまたはUAT環境がない場合。
要するに、 あなたの製品が受け入れられ、目的に合っているかどうかを知る最良の方法は、実際にそれをユーザーの前に置くことです。
組織はアジャイルな提供方法に参入し、ビジネスユーザーはより関与し、プロジェクトはフィードバックループを介して強化および提供されています。すべてが完了すると、ユーザー受け入れフェーズは、実装と本番環境に移行するためのゲートと見なされます。
UATの経験は何でしたか？スタンバイ状態でしたか、それともユーザーのテストを行いましたか？ユーザーは何か問題を見つけましたか？はいの場合、どのように対処しましたか？
=> このシリーズのすべてのチュートリアルもここで読んでください
=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください