ソフトウェアテストにおけるテストドキュメント（例）
トーマス・ハミルトン
⚡ スマートサマリー
テストドキュメントは、ソフトウェアテストの前またはテスト中に作成される構造化された成果物を定義します。これは、計画、実行、 trac目的、戦略、テストケース、結果を文書化することで、信頼性と品質保証を向上させます。効果的な文書化は、プロジェクト全体における網羅性、透明性、再現性を高めます。
テストドキュメントとは何ですか?
テストドキュメントは、ソフトウェアのテスト前またはテスト中に作成された成果物のドキュメントです。これは、テストチームが必要な作業量を見積もるのに役立ちます。 trac必要なリソースと進捗状況を把握し、十分なテストカバレッジを確保します。テストの記録とレポートは、テスト活動から得られるテスト計画、テスト設計、テスト実行、およびテスト結果を記述および文書化するための完全なドキュメント群です。
👉 無料のライブソフトウェアテストプロジェクトに登録する
テストの形式化がなぜ必要なのか?
初心者にとって、テストとはコードの様々なセクションをアドホックに実行し、その結果を検証することだと思い込みがちです。しかし、現実の世界では、テストは非常に正式な活動であり、詳細な文書化が行われます。テストの文書化によって、テストの計画、レビュー、実行が容易になり、検証も容易になります。
テストの形式性の程度は、次の要素によって決まります。
- テスト対象アプリケーション (AUT) のタイプ。
- 組織が従う標準。
- 開発プロセスの成熟度。
テスト活動は通常、 30％と50％ ソフトウェア開発の総労力。ドキュメント化は、将来のプロジェクトに適用できるテストプロセスの改善を特定するのに役立ちます。
テストドキュメントの種類は何ですか?
重要なテストドキュメントの種類は次のとおりです。
「実際には、これらのドキュメントは、初期計画（テストポリシー、戦略）から実行および終了（欠陥および概要レポート）まで、さまざまな段階で作成されます。」
| 試験書類の種類 | 詳細説明 |
|---|---|
| テストポリシー | これは、組織の原則、方法、およびすべての重要なテスト目標を説明する高レベルのドキュメントです。 |
| テスト戦略 | プロジェクトで実行されるテスト レベル (タイプ) を識別する高レベルのドキュメント。 |
| テスト計画 | テスト計画は、テスト活動の範囲、アプローチ、リソース、スケジュールなどが記載された完全な計画文書です。 |
| 要件 Trac能力マトリックス | これは要件とテストケースを結び付けるドキュメントです。 |
| テストシナリオ | テストシナリオ 1 つ以上のテスト ケースによって検証できるソフトウェア システムの項目またはイベントです。 |
| テストケース | 入力値、実行前提条件、期待される実行事後条件、および結果の集合であり、テストシナリオ用に開発されます。 |
| テストデータ | テストデータは、テストを実行する前に存在するデータです。テストケースを実行するために使用されます。 |
| 欠陥レポート | 欠陥レポートとは、期待された機能を実行できないソフトウェア システムの欠陥を文書化したレポートです。 |
| テスト概要レポート | テスト概要レポートは、実行されたテスト アクティビティとテスト結果を要約した高レベルのドキュメントです。 |
テストドキュメントを実現するためのベストプラクティスは何ですか?
このセクションでは、テストドキュメントの作成に役立つベストプラクティスについて、理解を深めるための例とともに学習します。
- プロジェクトの早い段階でQAを関与させる: プロジェクトの最初から QA チームを参加させて、製品の設計と要件に合わせてテスト ドキュメントを開発します。
例： QA はスプリントの計画中に協力し、ユーザー ストーリーに基づいて初期テスト ケースを作成します。 - ドキュメントを最新の状態に保つ: テスト ドキュメントを作成して忘れるのではなく、要件や機能が変更されるたびに更新してください。
例： ログイン API が変更された場合は、関連するテスト ケースと結果をすぐに更新します。 - バージョン管理を使用する: 管理と trac混乱やデータ損失を避けるため、テスト文書へのすべての変更はバージョン管理システムを通じて行うようにしてください。
例： 明確なバージョン履歴とロールバック オプションを維持するために、テスト プランを GitHub に保存します。 - 明確さと目的のための文書: テストの進行状況と成果物を自分と関係者が理解するのに役立つものだけを記録します。
例： 管理者のレビュー用に、合格、不合格、ブロックされたテスト ケースを強調表示したテスト概要レポートを含めます。 - 標準テンプレートを使用する: ドキュメントの作成とレビューを容易にするために、Excel や Word テンプレートなどの一貫した形式に従います。
例： ID、説明、前提条件、および予想される結果のフィールドを含む標準の「テスト ケース テンプレート」を使用します。 - ドキュメントストレージの集中化: プロジェクト関連のすべてのドキュメントを 1 つのアクセス可能な場所に保管し、チーム メンバーが簡単に参照したり更新できるようにします。
例： テスト成果物を共有ディレクトリに保存する Google Drive QA チームと開発チーム全体がアクセスできるフォルダー。 - 十分な詳細を含める: 曖昧または不完全な情報は避けてください。詳細なドキュメントは理解を深め、テスト実行中のエラーを減らします。
例： 「ログインを確認する」の代わりに、「有効な資格情報を使用してユーザーがログインし、ダッシュボードに正常にリダイレクトされることを確認します。」と記述します。
ソフトウェア テストのテスト ドキュメントはいつ作成すればよいですか?
ソフトウェア テスト用のテスト ドキュメントを作成する必要があるタイミングに関する重要なポイントを次に示します。
- 計画段階： テスト実行を開始する前に、範囲、目的、テスト戦略を明確に定義します。
- テストの準備: テスト計画中に、タイムライン、リソース、環境要件を効率的に確立します。
- 要件分析： 要件分析後、機能仕様と非機能仕様が完全にカバーされていることを確認します。
- 設計標準化: テストケースを設計する前に、フォーマットを標準化し、維持するために tracすべての文書におけるアクセシビリティ。
- シナリオドキュメント: テスト設計中に、シナリオ、入力、予想される出力、テスト データの詳細を文書化します。
- 実行準備: テストを実行する前に、テスト環境、ツール、ドキュメントの正確性の準備を確認します。
- 事後評価: テスト後、プロセス改善のために結果、欠陥、学んだ教訓を記録します。
テストドキュメントにはどのような種類のテンプレートが必要ですか?
ソフトウェア テストのテスト ドキュメントに必要なテンプレートの一部を次に示します。
| テンプレート名 | ツール |
|---|---|
| テスト計画テンプレート | Microsoft Word, Google Doc共同編集とバージョン管理にはConfluenceをご利用ください |
| テストケーステンプレート | TestRailZephyr (JIRA内)、 Xrayまたは Excel/Google 構造化テスト管理用シート |
| テストシナリオのテンプレート | JIRA、TestLink、または Google 高レベルのテスト条件を文書化するためのシート |
| 要件 Trac能力マトリックス（RTM）テンプレート | Excel、 Google シート、または TestRail 地図用ping テストケースの要件 |
| 欠陥レポートテンプレート | JIRA、 Bugzillaまたは Azure 欠陥ログ記録のためのDevOpsと trac王 |
| テスト概要レポート テンプレート | 合流、 Google Docs、または TestRail 試験結果の集計と分析 |
テストドキュメントの長所と短所
メリット
- テストドキュメントを作成する主な目的は、テスト活動に関する不確実性を軽減または排除することです。これは、タスクの割り当てにおいてしばしば生じる曖昧さを排除するのに役立ちます。
- ドキュメンテーションは、体系的なアプローチを提供するだけではありません。 ソフトウェアテストだけでなく、ソフトウェア テスト プロセスの初心者向けのトレーニング マテリアルとしても機能します。
- 成熟したテストプロセスを示すためにテストドキュメントを公開することは、優れたマーケティングおよび販売戦略として機能します。
- テストドキュメントは、特定の時間制限内にクライアントに高品質の製品を提供するのに役立ちます。
- In ソフトウエアエンジニアリングテスト ドキュメントは、構成ドキュメントやオペレーター マニュアルを通じてプログラムを構成またはセットアップするのにも役立ちます。
- テストドキュメントは、クライアントに対する透明性を向上させるのに役立ちます。
デメリット
- ドキュメント作成には非常に時間がかかるため、コストがその価値を上回る可能性があります。
- 多くの場合、文章を書くのが下手な人や、内容を知らない人によって書かれています。
- キーping tracクライアントからの変更依頼と、それに対応する文書の更新は疲れる。
- ドキュメントが不十分だと、顧客と組織の間で誤解が生じる可能性があるため、製品の品質に直接影響を及ぼします。
テストドキュメントで避けるべきよくある間違い
テストドキュメントで避けるべき最も一般的な間違いは次のとおりです。
- 不明瞭または曖昧なテストケースの説明を書かないようにしてください。
- テストの前提条件と依存関係のドキュメント化を省略しないでください。
- 各テストの予想される結果を必ず含めてください。
- 異なるテスト ドキュメント間で書式設定に一貫性がないように注意してください。
- 曖昧または測定不可能なテスト目標を使用しないでください。
- テスト ドキュメントの更新のバージョン管理を省略しないでください。
- 複数のテスト成果物間で情報が重複しないようにします。
- ドキュメントの正確性と完全性を確認することを怠らないでください。
