読み取り時間:14分
製品の技術的な品質を保証し、ソフトウェアのバグや論理的な間違いを見つけるためには、品質保証活動に従事することが不可欠です。 ただし、QAテストでは、最終製品がビジネス目標に適合しており、実世界のシナリオで必要なタスクを実行できるかどうかはわかりません。 そのため、開発チームが実際のエンドユーザーに適した製品を構築するためには、ユーザー受け入れテストを実施することが不可欠です。
ユーザー受け入れテストとは何ですか？
ユーザー受け入れテスト(UAT)は、製品がエンドユーザーにとって適切なものであるかどうかをチェックします。 それは他の名前、例えば、エンドユーザテスト、運用、アプリケーション、ベータテスト、または検証を持っていますが、彼らは同じことを記述します。 品質保証では、検証と検証を区別することが重要です。
検証とは、製品の技術的側面をテストして実際に動作することを確認することを目的とした一般的なQAプロセスを指します。 検証（またはユーザー受け入れテスト）は、製品がビジネス要件に対応し、エンドユーザーが使用できることを確認するために行われます。
製品テスト全体の検証と検証活動
検証活動は、二つのタイプのテストに分けることができます。
アルファテストは、製品が正しく機能し、ビジネス要件を満たしていることを確認するために、通常は内部テスターによって実行される受け入れテス
ベータテストは、第二のタイプの受け入れテストであり、ユーザーの受け入れ基準を満たすことを目的としています。 UATは、
- 既存の製品の実際のユーザー、
- 以前のバージョンの製品のユーザー、
- 製品の開発に関わる利害関係者、および/または
- ビジネスアナリ
これにより、開発チームは、機能、システム設計、ビジネス要件などに関するユーザビリティの問題、バグ、予期しない問題のほとんどを修正することがで
なぜ実際にUATが必要なのですか？
受け入れテストの主な目的は、製品がユーザーのニーズ（製品検出段階で定義）に対応し、発売準備が整っていることを検証することです。 OrigsoftのUATの使用に関する調査によると、回答者の75％以上がエンドユーザテストを複数回実施していると回答し、57％が製品の品質が悪いと主張しています。
だから、UATが重要であり、あなたの開発の一部でなければならない主な理由は次のとおりです。
ビジネス要件への対応を確保します。 すでに述べたように、UATは、製品が必要に応じて現実世界の状況で動作し、エンドユーザーが目標とする問題を解決できることを確認するために行われます。 あなたはUATをスキップした場合、あなたは必然的にユーザーの不満を引き起こすいくつかの重要な欠陥やシステムの誤動作を逃す可能性があります。
時には、エンドユーザーが製品をテストするとき、テストされたソフトウェアを改善する方法についていくつかの貴重な考えを思い付くこ そのようなフィードバックを得ることはあなたの顧客のためにより有用である結果を得るためにあなたの条件を調節することを可能にする。
まず、開発の初期段階で製品を修正する方が安いので、UATによる欠陥を見つけることで、開発チームは製品をはるかに簡単に改善することができます（主 詳細については、をお読みください）。 第二に、私たちは皆、機能性と使いやすさの悪さのために製品の失敗についての話を知っています。 UATは、実際のユーザーからのフィードバックを提供し、製品の発売に失敗したことによって損失が発生する可能性がはるかに低くなります。
いずれにしても、UATはそれを有効にするための組織と準備作業を必要とします。 製品の有効性を確認する場合は、ユーザー受け入れテストを実施する際に次の手順を検討してください。
UATキーステージ
製品要件の分析と主要成果物の定義
製品要件の分析は、UAT計画の最初のステップです。 入力情報の主なソースは、ビジネス要件と機能要件の完全な範囲が含まれているため、ソフトウェア要件仕様です。
ビジネス要件は、ビジネスニーズを伝える組織の高レベルの目標です。 これらは、”顧客は複数の支払い方法を使用することができるはずです。”
機能要件は、技術的なソリューションとビジネス要件を橋渡しします。 そのため、機能要件は「paypal、Visa、Mastercard、Payoneer支払いゲートウェイを実装する」ように聞こえます。”
これらの要件の概要は、実装されたソリューションがユーザーのために機能し、ビジネスの問題を解決するかどうか、テストすべきものを正確に教えてくれ 機能要件は、ビジネス要件の達成基準を考慮して、テストケースに変換することができます。 そして、それはあなたが全体的なテスト戦略を形成するのに役立ちます。 ビジネスアナリスト、QAエンジニア、または製品所有者に要件分析を依頼することを検討してくださ
最終的な計画段階は、UATプロセスの技術文書の作成です。 ここでは、テスト戦略、ルール、テストシナリオ/ケース、標準などを文書化します。 次のセクションでは、ユーザー受け入れテストで使用されるドキュメン
ユーザー受け入れテスト成果物
UATテスト計画。 UATテスト計画を作成すると、誰もが同じ目的とビジョンに合わせて維持するのに役立ちます。 主な文書には、何がテストされるのか、誰によって、どのようにテストされるのかに関するすべての情報が含まれています。 UATのすべての組織的およびプロセス的側面をカバーするには、テスト戦略と入退室基準を詳細に説明する必要があります。
エンドユーザテスト戦略。 この戦略では、テストする製品、ユーザー受け入れテストの目的、テストの種類、および目的の概要が説明されています。 テスト戦略は、
- 製品の説明、
- テスト目標、
- テスト範囲、
- 標準、
- テストタイプ、
- テスター/ロール
- プロセスキュレーター（マネージャー）、
- プロセスキュレーター（マネージャー）、
- 査読者、
- 報告基準、および
- 成果。
これらは、ソフトウェアがテストされる準備ができていることを確立する条件です。 これらは、開発チーム、QA、ビジネスアナリスト、および利害関係者によって計画の初期段階に設定されます。
これらは、ソフトウェアがユーザーにとって有効であることを指示する条件です。 合格基準に一致することは、あなたのUATの最終段階になります。
テストシナリオは、ユーザーが製品を操作するときに発生する可能性のある仮説的な状況です。 彼らの目的は、システム使用の可能性のある問題をテスターに案内することです。
基本的に、テストシナリオは、何がテストされるかの簡単なアイデアを伝える必要があります。 シナリオの例は、”ショッピングカートの機能を確認する”です。”各ユーザーシナリオは、1つまたは2つの要件またはユーザーストーリーに関連しています。 これらは、システムが使用可能であることを検証し、エンドツーエンドの操作を実際のデータでチェックするために書かれています。
ユーザー受け入れテストのための適切なテストシナリオを作成するには、一般的で珍しいすべての可能なユースケースを含めるようにエンドユーザーを承認 また、複雑な言い回しや過度に技術的な説明を避けて、平易な言葉で書くことを検討してください。
テストケース。 テストケースは、特定のシステムの動作、機能、または機能をテストおよび検証するために実行される特定のアクションのセットです。 テストケースは、すべてのテストシナリオに対応する必要があるより詳細な単位です。 ほとんどの場合、ユーザーストーリーとビジネスユースケースを変換して、効率的なテストケースを作成します。 テストケースの例は次のとおりです:
- 未登録のユーザーがショッピングカートに商品を追加するにチェックを入れます。
- ショッピングカートのフィルタリングを確認します。
- “買い物を続ける”ボタンにチェックを入れてください。
テストケースは、明確な目的が記載されており、ユーザーがそれを完了するために何をすべきかを理解できる場合に効率的です。 テストケースのユーザーガイドは次のようになります:
- アプリケーションを開きます。
- ショッピングカートに商品を追加します。
- 認証は必要ありません。
- ショッピングカートに進みます。
ユーザーが何が起こるかを認識できるように、テストケースに期待される結果を含めることもできます:
- 商品はショッピングカートに表示されます。
- システムは登録ユーザーとして承認するように求めます。
レポートの表示方法と、エンドユーザーが提供する情報を定義します。
テストレポート。 これらは、テストが完了したときに文書化された出力データを蓄積します。 テスト基準とテストシナリオに応じて、さまざまな情報をレポートに含めることができます。 しかし、通常、UATでは、QAチームはテスターからのサインオフのみを必要とします。 サインオフは、テストが成功し、ユーザーの基準に対応していることを確認するだけです。
UATの終わりに、提供された成果物をQAエンジニアまたはUATマネージャーが使用して、貴重なデータを抽出し、結果を開発チームに伝えることができます。
従来、品質保証エンジニアはエンドユーザーからのフィードバックの処理を担当していました。 テストの結果、バグレポート、および失敗/合格記録は、チームの異なる部分間の一定の通信を確保するために、開発者に提供されています。 エンドユーザーからのフィードバックに基づいて、QAチームは、UATの観点から進歩を測定するためのソフトウェア品質指標を提供することもできます。
ユーザー受け入れテストテンプレート
適切なUATの計画と実行のために作成する必要があるいくつかの重要な文書について言及しました。 そこにそれらを書くためのさまざまな方法がありますが、ここで便利になるかもしれないいくつかのテンプレートがあります。
- テスト計画テンプレート: Coley Consultingによるテスト計画テンプレート、sfsuテンプレート(ダウンロード可能なリンク)、またはiibaテンプレート(ダウンロード可能なリンク)
- テストシナリオテンプレート
- テストレポートテンプレート
エンドユーザテストの時間と形式を選択
受け入れテストは、使用している方法論に応じて、プロジェクトのさまざまな段階で行われることがありますが、通常はリリース前の開発サイクルの終わりに行われます。 ソフトウェア開発で最も人気のあるプロジェクト管理方法論の二つはウォーターフォールとアジャイルであるため、これら二つのモデル内のユーザー受け入れ
ウォーターフォールモデルでの受け入れテスト
詳細を深く掘り下げるには、ウォーターフォールモデルが何であるかをすばやく要約する必要があります。 これは、製品の段階的な開発に基づく伝統的なプロジェクト管理方法論です。
ステージは交差しておらず、同時に設計と設計テスト、または開発とテストがないことを意味します。 プロセス全体は厳密に文書化されており、開発の終わりに完全に機能するアプリケーションを反復せずに提供することを意図しています。
ウォーターフォールモデル内のユーザー受け入れステージ
ウォーターフォールでのユーザー受け入れテストは、発売直前の開発の最終段階
以下のベンチマークを達成した後、システムがコードと機能の準備ができているとみなされた後にのみ実行できます。
- 製品のビジネス要件が満たされています。
- コードベースは終了しました。
- QA活動(システム、統合、単体テスト)が完了しました。
- QA段階で明らかになったバグを修正しました。
- 小さな視覚的な問題が許容範囲内にあります。
- ユーザー受け入れ環境(UATマネージャ、テスト用ツール、テストシナリオなど)）が作成されます。
ウォーターフォールモデルでは、ユーザー受け入れテストがソフトウェアの準備状況を示す決定的なポイントです。 製品がユーザーの受け入れ基準を満たしている場合は、製品が生産の準備ができていることを意味します。 その場合のUATアクティビティは、システムチェック、その機能、使いやすさ、およびバグを完了するためのものです。 しかし、依然として主な目標は、製品が最初の要件とエンドユーザーのニーズに対応することを保証することです。
アジャイル方法論におけるユーザーの受け入れ
ソフトウェア開発のアジャイルモデルは、ウォーターフォールほど簡単ではありません。 これは、製品が必要な品質と機能に達するまで、各開発段階を反復することに基づいています。 アジャイルは多くのドキュメントの作成に焦点を当てていないので、各フェーズの反復は、非常に柔軟な開発と要件の動的な変更を可能にします。 これにより、開発チームは顧客からの変化する要件に迅速に対応することができます。
アジャイルモデルのユーザー受け入れテスト
画像は、反復を伴うアジャイル製品開発サイクルを示しています。 プロジェクトの各段階でユーザー受け入れテストを実施して、製品の有効性を確認することができます。 ウォーターフォールとアジャイルのUATの主な違いは、UATが複数回（多くの場合、各反復内で）実行され、その結果が最初の要件に影響を与える可能性があることで
アジャイルプロジェクトでエンドユーザテストを開始するためのチェックポイントは、
- 形成されたビジネス要件、
- UX/システムドキュメント、
- テスト材料（対話型モックアップ、忠実度の高いプロトタイプ、デモ）、
- ユーザー受け入れ環境です。
アジャイルでは、UATは全体的なテスト活動の不可欠な部分であるため、異なる形式をとり、異なるツールを使用することがあります。 たとえば、機能要件および非機能要件に関するテストや、計画段階で行われた仮定を検証するための初期段階のテストなどがあります。 各反復の終わりに、受け入れテストは、要件、システムアーキテクチャ、UXスタイルガイドなどを変更するために使用される成果物を生成します。
ユーザーを募集し、UATチームを形成
先に述べたように、テスターは既存のユーザーベースから募集することができます。 プロジェクトの詳細に応じて、それらは主題の専門家、製品の実際のユーザー、利害関係者、ビジネスアナリスト、製品所有者、または顧客になります。 また、クラウドソーシングのプラットフォームを使用して、テスターを検索したり、フリーランスのユーザーテストスペシャリストを雇うこともできます。
ソーシャルメディアのメッセージや、視聴者を引き付けるためのランディングページを作成することを検討してくださ 潜在的なテスターは、必ずしも技術に精通しているか、ソフトウェアテストプロセスに精通しているべきではありません。 しかし、すでに製品を持っている、または使用する人（または同様のもの）は、その場合、深いオンボーディングやQAチームの関与を避けることができるので、UAT
エンドユーザテストツールとオンボードテスターの実装
もちろん、エンドユーザテスト用に設計された特定の機器が市場にあります。 最も一般的なツールは、レポート、タスクの概要、テスト文書テンプレートなどのテスト管理機能を提供します。 ここでは、UAT活動をサポートするために使用できるソフトウェアの例をいくつか紹介します。
Usersnapは、テストされたソフトウェアとwebベースのアプリケーションに関する視覚的なフィードバックを提供するための一般的なプラッ 基本的には、ユーザーが画面上でバグをマークしたり、コメントや提案を残したり、フィードバックを共有したりすることができるツールです。 UserbackやUserTestingなどの同様のツールがたくさんあります。
FitNesseは、受け入れテストの自動化のためのオープンソースのwikiベースのフレームワークです。 これにより、すべての関係者がテストを簡単に作成、編集、実行し、早期のフィードバックを作成できます。 ユーザーは、システムによってすぐに実行されるテストを自動的に生成するために、特別な書式設定された入力を入力します。 次に、出力が返され、期待される結果と一致するかどうかに応じて強調表示されます。 このコラボレーションプラットフォームは緩やかな学習曲線を持ち、アジャイルチームの間で人気があります。
BugwolfはUATを指揮するための別の楽器です。 テスト環境とバグ報告に加えて、ゲーミフィケーションと競争機能を提供し、ユーザーをやる気にさせ、従事させます。 オンラインでエンドユーザテストを実施する場合は、便利な組み込みの支払いオプションもあります。
JiraやTrelloのようなよく知られたプロジェクト管理ツールには、UATを実行するための機能もあります。
SpiraTestでのテストダッシュボード
ユーザー受け入れ環境を作成し、トレーニングを実行
エンドユーザーテストを最大限に活用するには、トレーニン あなたのテスターとUATマネージャーがその責任を負います。 次の側面を含むようにあなたの訓練プロセスを構造化することを考慮しなさい。
- は、テストプロセスとその目的をユーザーに紹介します。
- 使用する場合は、エンドユーザテストのためのツールを使用するようにユーザーに訓練します。
- 報告基準とガイドラインを提供する。
- ユーザーがテストケースを適切に理解していることを確認し、必要に応じてサポートを提供します。
- テスト環境へのアクセスを彼らに提供する。
ほとんどの場合、エンドユーザテストはユーザー側で行うことができます。 全プロセスはまたオンラインですることができる。 より複雑なプロジェクトや機密データは、あなたのオフィスでユーザーテスターの専用チームを収集する必要があります。 また、ドキュメント、ツール、およびサポートを提供するマネージャーを任命することも重要です。
テストを実行する
テストシナリオとテストケースを取得したら、テストを行ってもいいです。 プロセス中にエンドユーザーをサポートし、必要な結果を得るには、各テストケースが必要とするアクションを明確に理解します。 ユーザーはプロのテスターではないことに注意してください。 テスト中は、サンプルコンテンツやダミーボタンを避けて、実際のデータまたは実際のデータに近いデータをユーザーに提供してください。 誤解があれば、テストケースで立ち往生する可能性があります。
もう一つの重要な側面は、開発者がうまくいかないことを修正する準備ができていることです。 テスト環境がシャットダウンしたり、ユーザーのテストを妨げるエラーが発生したりする可能性があります。 ユーザーは、テスト計画に含まれる各テストケースを実行できるように、テストの各段階で必要な機能にアクセスできるようにする必要があります。
出力情報を収集し、それを分析
あなたのUATの活動の間に、あなたはテスターからデータのトンを取得します。 QAチームはそれを分析する必要があります。 データは、手動または特定のツールを介して提出されたユーザーレポートを介して収集されます。 さらに、別のユーザーとのインタビューを実施して、実行したテストケースとその考えについてより多くの洞察を得ることができます。
システムの準備状況を評価するには、合格/失敗/固定のテストの割合を測定することを検討してください。
Panayaのテストトラッキングダッシュボード
さらに考慮すべき点がいくつかあります。
システムの安定性。 安定性は、UAT中に満たされた予期しないエラーの数によって決定することができます。
カバレッジは、記述されたテストシナリオ/ケースの数と、完成したテスト全体に対する比率によって測定されます。 また、UATテスト結果をユーザージャーニーマップと照合して、テストされていない機能の部分を理解することもできます。
これは、ユーザーがそれを行う方法を見つけられなかったため、合格しなかったテストの数で計算できます。 しかし、全体的なUXは、別の活動として行われるユーザビリティテスト中にテストされます。
契約/要件遵守。 すべてのエンドユーザテストが終了した後、要件準拠がチェックされます。 これにより、ユーザーの受け入れによって変更が加えられた後でも、ソフトウェアビルドが初期要件/契約範囲に対応することが保証されます。
バグの修正、再テスト、サインオフ
UATを実行した後、すべての欠陥を関連するコメントで文書化し、開発チームに渡す必要があります。 彼らはUATによって明らかにされた問題に対処するためにコードを調整する必要があります。
バグを修正したら、すべてが正常に動作していることを確認するためにそれらを再テストします。 合格基準に達し、査読者によって承認されると、製品の生産準備について最終的な合格決定が行われます。
UATチームの役割
先に述べたように、UATテストは技術専門家だけでなく、実際のエンドユーザーをこのプロセスに参加させることも重要です。 また、プロジェクトマネージャーや開発チームとの緊密な協力も必要です。
UATチームの責任は、会社やプロジェクトのニーズによって異なる場合がありますが、ここでは考慮できる役割の配分の例を示します。
ビジネスプログラムマネージャー。 これは、プロジェクト全体を調整し、監督し、ビジネス目標に合わせて調整する人です。 UATステージの前に、プログラムマネージャは、テスト活動をサポートするために、プログラム配信計画とビジネス要件文書を生成する必要があります。 彼/彼女はまた、テスト計画とテスト戦略の見直しと承認を担当しています。
UAT中、プログラムマネージャはテストアクティビティの実行を監視し、スケジュールと予算に基づいて完了を保証します。 その後、彼/彼女はテストレポートをレビューし、本番環境への展開を決定します。
UATテストリード/マネージャー。 テストリードの責任は、UATを正確に計画して整理することです。 そのためには、通常、プロジェクトマネージャーとの緊密な協力が必要です。
テストリードは、テスト戦略、テスト計画、テストシナリオなど、必要な文書を開発するために使用されるすべてのビジネス要件および機能要件を収集 さらに、準備段階では、テストチームと協力して、テストシナリオをチームメンバーに割り当て、テスト担当者がUAT手順を理解できるようにトレーニングを組織 また、テストリードは、必要なリソースを準備して管理し、テストツールに必要なテストデータをロードします。
uat全体を通して、リードはテストケースの実行を調整し、すべてのテスト結果が文書化されていることを確認します。 彼/彼女はまた、テストの進捗状況を追跡し、メトリックを収集し、テストレポートを作成/維持します。
UATテストチームメンバー。 テストチームの主な仕事は、提供されたスケジュールと指示に従ってテストを実行することです。 テスト担当者は、テストログを作成し、欠陥やインシデントを報告する必要があります。 彼らはまた、通常、再テスト活動に参加します（必要に応じて）。
プロジェクトマネージャーは、プロジェクトの成功の責任者として、テスト活動を監視し、組織的なサポートを提供し、進捗状況を報告する必要があります。 彼/彼女はまた、テストチーム、開発者、顧客、およびその他の可能な利害関係者との間の仲介者としても機能します。
UATチェックリスト
上記のUATガイドラインを要約すると、テスト活動を整理し、重要なことを見逃さないようにチェックリストを開発しました。
UATプロジェクトを開始する。
- すべての製品コンポーネントがテストの準備ができていることを開発チームに確認します。 UATの前に対処することができなかったすべての問題を文書化します。
- 主要な利害関係者を特定します。
- 事務処理を含め、プロジェクトを担当するチームリーダーを選択します。
- プロジェクト構造、UATチーム、UAT文書について議論し、同意する。
- テスト手順を徹底的に議論し、最初のUAT計画を作成します。
- あなたのUATチームを作成し、各市場セグメントおよび/または利害関係者の各グループからテスターを持っていることを確認してください。 すべての参加関連文書が完成し、署名されていることを確認してください（非公開、参加契約など）。).
- テストの戦略とスケジュールをチームに伝える。 すべてのメンバーが役割、手順、責任を理解していることを確認してください。
- すべてのビジネス要件が把握され、UATチームに伝達されていることを確認します。
- 出入国基準について議論し、同意する。
- テスト計画、テストシナリオ、テストケースなど、すべてのビジネス文書を準備します。
- システムのビジネス目標と受け入れ/終了基準を伝えます。
- システムと補助ツールに関する必要なトレーニングを実施する。 テスト担当者がインシデントの報告方法を理解していることを確認します。
- UAT活動に必要なすべてのリソースを収集し、準備する。 必要に応じてブックスペース。
- 環境の準備とテスト、管理ツール、デバイス、サーバー、フィードバックチャネル、問題追跡、コンテンツ配信などをテストします。
- すべてのログインがあり、セキュリティアクセスが設定されており、テストデータがロードされていることを確認してください。
- 手順の実行方法を監視し、報告書が適時かつ正確に提出されていることを確認します。
- テスト概要レポートを作成および管理します。
UAT後の活動。
- 合格/失敗したテストの割合を測定し、重大度別に欠陥を分類することにより、出力情報を分析します。
- 受け入れ基準に対してステータスを特定します。
- 最終的なUAT報告書を作成し、承認基準とリリースの推奨事項を満たすために必要な推定時間と労力とともに利害関係者に提示する。
テスト手順は会社によって異なる場合があります。 ここにあなたの必要性にまた合うかもしれない幾つかの他のダウンロード可能なUATのチェックリストはある:チェックリスト1、チェックリスト2。