sample template acceptance test report with examples
検収試験報告書の概要（パートIII）：
以前のチュートリアルでは、 リアルタイムシナリオを使用した検収試験のドキュメント 」私たちは、検収試験計画について話し合いました。
このチュートリアルでは、受け入れテストのステータス、受け入れテストの概要、およびサインオフのレポートについて詳しく説明します。
このチュートリアルには、理解を深めるための一般的なテンプレートがいくつか含まれています。また、アジャイル開発における受け入れテストと受け入れテスト駆動開発の概念にカーソルを合わせます。
要するに、このチュートリアルでは、明確に理解するためのいくつかの一般的なテンプレートとともに、受け入れテストのステータスレポートと要約レポートについて説明し、アジャイルでの受け入れテストとテスト駆動開発の概念を簡単に理解できる方法でブラッシュアップします。
学習内容：
検収試験状況報告
受け入れテストレポートは、実行された受け入れテストとその結果を常に要約する必要があります。これは、受け入れテストフェーズの一部である特定されたすべての利害関係者に対処する必要があります。受け入れテストの実行が開始されたら、進捗状況を日常的に報告する必要があります。
合格テストステータスレポートの汎用テンプレート：
日付 ：検収試験状況報告日
本日の検収試験の実施の詳細：
- 合格したテストの数
- 失敗したテストの数
- 進行中のテストの数
日付までの受け入れテストの実行の詳細：
- テストの総数
- 合格したテストの数
- 失敗したテストの数
- 進行中のテストの数
- 保留中のテストの数
欠陥の詳細：
最高のファイル回復ソフトウェアウィンドウズ10
- ログに記録された欠陥の数
- 各欠陥には、以下の詳細が必要です。
- ID、要約、コンポーネント、重大度
- これまでに記録された欠陥の総数（受け入れテストフェーズ）。
このレポートは、実行が順調に進んでおり、計画されたスケジュールから逸脱していないことを確認するために、毎日確認する必要があります。
検収試験概要レポート
これは、受け入れテストフェーズ全体のステータスを要約したレポートです。これには、実施されたテストアクティビティ、満たされている基準への参照、要件仕様、ビジネスルール、実行結果、計画されたスケジュール、逸脱などの詳細が含まれます。
検収試験要約レポートの汎用テンプレート：
概要
差異
結果
評価
勧告
尽力
サインオフレポート
製品が合格テストに合格したら、稼働させることをお勧めします。本番環境にリリースする前に、正式にサインオフする必要があります。
サインオフレポートの汎用テンプレート：
製品名、リリースバージョン、ビルド番号
最新レポート
レビューオン
によってレビュー
コメントを確認する
サインオフ日
サインオフ
サインオフコメント
一般に、上記のレポートはいずれも、そのテンプレートについて主要な利害関係者がレビューする必要があり、内部の情報として何を行う必要があるかについて合意する必要があります。
レポートに記入されるすべての詳細は、利害関係者と共有する前にクロスチェックする必要があります。レポートに不一致があると、ビジネス上の決定に大きな影響を与え、市場で製品の故障につながる可能性があります。
したがって、報告は常に専門家またはチームの上級メンバーが処理する必要があります。
アジャイルでの検収試験
に アジャイル 、各ユーザーストーリーの受け入れ基準は、受け入れテストの対象となります。つまり、受け入れテストは、ユーザーストーリーの受け入れ基準から導出されます。各受け入れ基準には、シナリオをカバーする1つ以上の受け入れテストを含めることができます。
検収試験は通常、その分野の専門知識であるQAによって設計されます。アジャイルでの受け入れテストは、他のアプローチと比較すると、通常はスプリント自体の中で、はるかに早く開始されます。
各スプリントには新しいユーザーストーリーが登場し、前のストーリーの機能強化/継続も行われるため、これは非常に頻繁に実行されます。
受け入れテストは、アジャイルの2つの異なる段階で実行されます。
- 機能が作成され、その初期段階にあるとき–基本。
- 機能が製品の他の機能と統合され、安定化されている場合。
ここでの各ユーザーストーリーは、受け入れテストを受ける必要があり、検討のために合格する必要があります。受け入れテストの失敗はすべて優先度が高いと見なされ、すぐに修正される必要があります。これにより、受け入れテストが実行されます。
ストーリーポイントは、各受け入れ基準の受け入れテスト結果の成功に基づいて、各ユーザーストーリーに与えられます。受け入れテストでは、ユーザーストーリーレベルでの完了も定義され、ストーリーの受け入れ基準が満たされていることが示されます。
アジャイルでの検収試験は誰が行いますか？
通常、プロダクトマネージャー、対象分野の専門知識（顧客および/またはベータテスターの可能性があります）は、アジャイル環境で受け入れテストを実行します。場合によっては、QAは、通常の回帰タスクとともにこのアクティビティにも関与します。
アジャイルでの検収試験の利点
アジャイルでの受け入れテストにはいくつかの利点があります。
利点は次のとおりです。
- プロダクトマネージャーとチーム間のより緊密なコラボレーション。
- ユーザーストーリーレベルで信頼を築きます。
- 各受け入れ基準をカバーするために、より多くのシナリオを導き出すのに役立ちます。
- ユーザーストーリーの承認基準を通じて、製品のソリューションを即興で作成する可能性が高まります。
欠点
いくつかのメリットがありますが、特定のデメリットもあります。
欠点は次のとおりです。
- すべてのストーリーが検収試験の対象となるわけではありません。カバーされる機能的なストーリーのみ–ストーリーごとのカバーが低下する可能性があります。
- すべての受け入れ基準を受け入れテストの対象と見なすことができるわけではありません。機能的な基準のみがカバーされます–ユーザーストーリー内の受け入れ基準に関するカバレッジが低下する可能性があります。
- さまざまなバックグラウンドの利害関係者が関与し、ストーリーごとの受け入れテストが直接実行されるため、全員が同じページにいることは非常に困難です（基本的に個々のユーザーストーリーのレベルを理解する上で）。
- 他のアプローチと比較するとリリース期間が短いため、スプリント内での受け入れテストに対応することは非常に困難です。
受け入れテスト駆動開発（ATDD）
これはアジャイル開発プラクティスの1つであり、チーム全体がユーザーストーリーの各受け入れ基準について共同で話し合い、それらを中心に強力な受け入れテストを構築します。
これは、チームメンバーごとに異なる視点が受け入れ基準ごとに新しい考え方を与え、より多くのシナリオをカバーする多数の受け入れテストが到着するためです。時々、 ATDD とも呼ばれます ストーリーテスト駆動開発（STDD）。
実際、ATDDは開発が始まる前に発生します。したがって、開発者は、このアプローチでは、実際に何が期待され、それをどのように達成するかを知っています。チーム全体が、機能と構築されているものについての共通の理解を共有します。
これは、製品がどのように構築されているかを説明し、テストのために引き渡される前に、製品が実際にどのように機能するかについての公正なアイデアを提供します。したがって、それは「 受け入れテスト駆動開発 」。
結論
そのアプローチのいずれかでの検収試験には、製品が稼働する前に開発された製品に対する顧客の信頼と満足を構築するという共通の目標があります。これは、機能を妨げることのない重大度の低い欠陥が製品にないか少ない場合にのみ得られます。
手短に：
- 検収試験に合格しました。
- 欠陥は許容レベルにあります。
- フローワイズ/シナリオワイズのカバレッジが達成されました。
- 製品とそのソリューションが受け入れられます。
- 顧客は製品に十分な自信を持っています。
- すべての製品ドキュメントは、最新の機能に一致するように更新されています。
- チームの努力の結果。
- プロダクションローンチを進めてください。
これらの検収試験チュートリアルから膨大な知識を得られたことを願っています。以下のコメントセクションで、お気軽にご意見をお聞かせください。