Hannah Son著
テストサマリーレポートとは、特定のテストサイクルのテスト戦略、成果物、結果を記述した文書です。どのような開発手法を採用する場合でも、テストサマリーレポートの主要な目的は、実施されたテストのアクションと結果を記録し、チームに可視性をもたらし、特定のスプリント、テストサイクル、リリースのテスト作業について履歴を作成することです。
以下に、効果的なテストサマリーレポートを作成するための５つのアクションについて説明します。
- テスト範囲を記述する
- テスト環境の詳細を文書化する
- 実施されたテストの種類と結果を要約する
- テストで得られた教訓があれば取り入れる
- 終了条件のステータスについてレポートする
アジャイル開発でテストサマリーレポートを作成する方法
1.テスト範囲を記述する
文書概要に含めることを検討するべき情報
- レポートの読者
- 読者が役割に応じてアクションを起こすために必要な情報
- 読者が期待するもの
製品概要に含めることを検討するべき情報
- 製品および製品機能の簡単な説明
- テスト作業の範囲
- テスト対象のモジュール
- テスト対象外のモジュール
- 制約があるためにテストされない領域
2.テスト環境の詳細を文書化する
テスト環境の詳細は、テスト条件や、テスト結果に影響を及ぼす可能性がある制約をステークホルダーが理解するのに役立ちます。テスト環境に関して通常含めるべき情報は以下のとおりです。
- 使用されたハードウェアおよびソフトウェア
- アプリケーションのURL
- データベースのバージョン
- バグ管理に使用されたツールの詳細
役に立つヒントとして、すべてのテスト環境情報を中央化する場所を用意すると、文書化と共有が簡単になるでしょう。
3.実施されたテストの種類と結果を要約する
アプリケーションがテスト戦略に従って適切にテストされたことを保証するには、実施されたソフトウェアテストの種類を文書化することが重要です。テストの種類には以下のようなものがあります。
4.テストで得られた教訓があれば取り入れる
テストプロセスで得られた教訓や推奨事項があれば文書化することが重要です。そうすると、次回のテストフェーズで振り返りを行い、製品機能、テストアクティビティ、その他の分野で行うべき改善などの推奨事項を作成し、次のリリースサイクルの計画に役立てることができます。
テストレポートで文書化するべき教訓の例として以下のようなものが挙げられます。
- テストプロセスで判明したベストプラクティス
- 遭遇した問題
- 今後のテストプロセスの改善点
- 欠陥を適切に検出することができた、あるいはテスト作業を改善できたテスト技法、ツール、プロセス
5.終了条件のステータスについてレポートする
終了条件は、ソフトウェアのすべての側面が徹底的にテストされ、製品をリリースする準備ができたことを保証するために、テストを完了する前に満たすべき条件の概要を記述したものです。
次のフェーズに進む前に対処する必要がある欠陥やリスクを特定するには、終了条件のステータスをレポートすることが重要です。終了条件のステータスをレポートする際は、次のような質問に答えを出す必要があります。「テストは終了条件を満たしたか？」「満たされていない終了条件はあるか？」「その理由は何か？」
アジャイルテストサマリーレポートに含めるべき情報
アジャイル開発では、テストサマリーレポートはテスト実施の記録として機能し、ウォーターフォール型のソフトウェア開発ライフサイクルの場合に比べると、それほど形式的ではないかわりに、より結果重視という特徴があります。どちらの場合でも、レポートに含めるべき、対象読者にとって必要な基本情報は共通していますが、アジャイル開発の場合は決まった書式はないため、テストレポートの目的に応じてどのようなデータを追加するべきかをテスターが判断する必要があります。
テストレポートは、テスト環境、テスト範囲、テストの細目などの不可欠な項目を含む簡潔なレポートであるべきです。
アジャイルテストサマリーレポートを作成する場合、次の 4 つを含めます。
- テストの目標: 実行したテストのタイプと理由を説明します。
- テストケース/実行の詳細/テストカバレッジ: テストスイートを説明します。いつテストが実行されたか、どのようなタイプのテストが実行されたか、どこにテストが保存されているかを記載します。
- 欠陥ステータス: このセクションには、テスト時に見つかったバグまたは欠陥に関する以下の情報を含めるべきです。
- テスト時に見つかったバグの総数
- このデータは、テスト対象製品の全体的な品質を判断するのに役立ちます。
- テスト時に見つかったバグのステータスおよび課題またはバグレポートへのリンク
- バグがオープン中か、クローズされたか、開発およびテストチームによって対処中かを記載します。
- 重要度および優先度ごとの内訳
- この情報は、各バグの重要性および必要な注意のレベルを理解するのに役立ちます。
- テスト時に見つかったバグの総数
- プラットフォームおよびテスト環境構成の詳細: テスト環境に関する情報を含めます。アプリケーションのコードに関連するテスト環境の詳細を共有する場合は、必ずセキュリティおよびコンプライアンスを考慮します。
アジャイルテストサマリーレポートのテンプレート
テストサマリーに何を含めるべきかについて、厳密なルールはありませんが、次のテンプレートをたたき台として使用できます。
| プロジェクト情報: テストプロジェクト名および説明 |
| テストの目標:テストの目的とテストのタイプ |
| テストサマリー: 計画、実行、成功、失敗したテストケースの数 |
| 欠陥: バグの全体的なステータス、現在オープン中、クローズ済み、対応中のバグの数、関連する欠陥レポートまたは課題へのリンク、深刻度および優先度別の内訳、深刻度高: 深刻度の高いバグの数、深刻度中: 深刻度が中程度のバグの数、深刻度低: 深刻度の低いバグの数 |
チームにとって最も意味があると考えられる要素でテストサマリーレポートを補完することができます。効果的なテストサマリーレポートの実例として、こちらのTestRailで生成されたレポートのサンプルを参照してください。
自動的にテストサマリーレポートを作成する方法
TestRailなどのテスト管理ツールは、テストサマリーレポートを自動的に生成し、必要な情報を収集して表に入力する手間を省くことでチームの作業時間を節約します。
TestRailを使用すると、ボタンをクリックするだけでレポートを生成できます。どのようなフレームワークや言語でもレポートを生成でき、強調したい情報に応じてステータスレポートをカスタマイズできます。下の図は、TestRailによって生成されたテストステータスレポートのサンプルです。
TestRailがどのようにリアルタイムでのテストデータの可視化に役立つか、またレポートテンプレートを使用してテストカバレッジおよびトレーサビリティをチェックする方法をより詳しく知るには、ぜひ一度TestRailをお試しください。
（この記事は、開発元Gurock社の Blog 「How to Write a Good Test Summary Report (Template + Example)」2023年9月1日の翻訳記事です。）
関連する製品
テスト管理ツール TestRail
テストケースの管理やテスト結果の記録、チームでの情報共有など、Excelを使ったテスト管理の業務に限界を感じていませんか？TestRailはシンプルで使いやすいUIを提供し、テストにかかるさまざまな管理コストの削減に貢献します。
■ TestRailの特長 ■
- テストにさまざまな情報を関連づけて一元管理
- Webブラウザー上でテストケースを簡単に入力や編集可能
- テスト実施の準備と結果の共有が容易
- 進捗や比較などのレポートを提供
- 要件 / 課題管理ツールやテスト自動化ツールと連携
日本国内では、テスト管理にExcelを使っていたお客さまからの乗り換えが多く、Web上で完結するテスト管理を実現されています。
TestRail でテスト管理のお悩みを解決しませんか？
