Software Testing Status Reporting
“特定の情報が、特定の形式で、特定のチーム/個人によって、特定の時間間隔で、特定のメンバーに送信されるという合意は、握手のようなものです。”
これはITプロフェッショナルの誓いの最初のセクションです。 まあ、私は冗談です！ 誓いはありませんが、もしあれば、これは確かにその中のアイテムのリストのトップになります。 そうでしょ?
説明責任と透明性(A&T)は、プロジェクトレベル、チームレベル、タスクレベル、さらには個人レベルのさまざまなレベルのすべてのITプロジェクトに不可欠 これらの属性が満たされていることを確認するにはどうすればよいですか？ 答えは-コミュニケーション、より正式に-ステータスレポートです！
個人レベルでは、皆さんの日常業務の成果（または非成果）を伝えるために、毎日eodを報告するのではありませんか。 これは、あなたが実際にあなたの義務が何から始まるのかを認識していることを証明するために行きます。
デイリーステータスレポート
個人の”デイリーステータスレポート”の一部である必要がある情報は次のとおりです:
- 今日は何をしたの?
- 明日は何をするつもりですか？
- あなたの日中に何か問題に直面しましたか？ はいの場合、どのようにそれらを解決しましたか、それともまだ開いていますか？
- 明日のために何か入力が必要ですか？ はいの場合、誰から、そして彼らは何ですか？
この電子メール/レポートの受信者は一般的にマネージャーであり、チームメンバーは場合によってはCC’edすることもできます–これはチームが従う通信プロトコルに
テストレポート
さて、テスト/QAチームが送信するレポートについて具体的に学び、すべてを学ぶ時です。
テストチームはSTLCの異なる段階で様々なレポートを送信します。
- テスト計画ステータス
- テスト文書ステータス
- テスト実行ステータス(欠陥ステータス)
テスト計画：テスト計画が作成されたとき、または大きな変更が加えられたときに、プロジェクトチームの残りの部分と通信するだけで十分です。
テスト文書:テストの設計、データ収集、その他の活動がいつ開始されたか、また終了したかをすべてのチームに知らせてください。 このレポートは、タスクの進行状況を知らせるだけでなく、成果物を確認してサインオフを提供する必要があるチームに、次の作業が行われていることを通知します。
テスト実行:テストチームが主な焦点であるとき、実行はプロジェクトの段階です–積極的にも否定的に–私たちは英雄であり、悪役です。
テストサイクル中の典型的な日は、毎日のステータスレポートが送信されない限り行われません。 いくつかのチームでは、彼らは毎週のレポートに同意することができますが、それは毎日送信されることが標準です。
QAチームのステータスを関係者に提示するために、毎日（または週）ステータス会議を開催することも珍しくありません。
したがって、ステータスレポートのモードは次のようになります:
- 電子メール/ドキュメント
- 会議/プレゼンテーション
- 両方–毎日の電子メールと毎週の会議など。
テスト実行ステータスレポート
日次/週次テスト実行レポート:
それは何ですか？ 一般的に、これはテストサイクル中のQAチームのその日の活動に対する透明性を確立するために送信される通信であり、欠陥情報とテストケースの実行
誰に行くべきですか？ -通常、開発チーム、環境サポートチーム、ビジネスアナリスト、プロジェクトチームは受信者/会議参加者です。 テスト計画は、この情報を見つけるのに最適な場所です。
テスト実行ステータスレポートには何が含まれていますか？ –10ポイント
- その日に計画されたテストケース数
- 実行されたテストケース数–その日
- 実行されたテストケース数全体
- その日に発生した欠陥数/そまだ開いている
- 環境のダウンタイム-存在する場合
- showstoppers–存在する場合
- テスト実行シートの添付/テストケースが配置されているテスト管理ツールへのリンク
- 添付 バグレポートへ/インシデント管理に使用される欠陥/テスト/管理ツールへのリンク
上記の10点は、あなたが密接に気づいた場合は、生のデータです。 事実を報告することは一つのことであり、いくつかの”スマート”な事実を報告することは別のものです。 この情報をどのように絞り込むのですか？
- 全体のステータスをカラーインジケータで表示します。 例えば、緑-時間に、オレンジ-わずかに遅れているが、遅延を吸収することができ、赤-遅延。
- には、これまでのテストケースの合格率、欠陥密度、深刻な欠陥の％などの簡単な指標が含まれています; これを行うことによって、あなただけの数字を与えていない、あなたは実際にあなたがテストしている製品の品質を垣間見ることを提供しています。
- 重要なフェーズが完了した場合-それを強調表示します。
- 将来の実行のすべて/一部をブロックする重大な欠陥がある場合は、それを強調表示します。
- プレゼンテーションを使用する場合は、より良い影響を与えるためにいくつかのグラフを含めるようにしてください。
たとえば、下のグラフは、モジュール単位で開いている欠陥の数を表しています:
これらとは別に、必要に応じて次のものを含めることもできます:
- 次に計画されている活動は何ですか？
- あなたは他のチームのいずれかからの入力が必要ですか、もしそうなら、何ですか？
最後に、プロセスを助けるためのいくつかのポインタ:
- 簡潔にする
- 報告する結果が正確であることを確認する
- 箇条書きのポイントを使用してレポートを非常に読みやすくする
- 正しい日付、件名、リスト、添付ファイルを含めるようにダブルチェックします。
- レポートが大きすぎて、レポートする要因が多すぎる場合:ファイルとして共通の場所に配置し、ファイル自体ではなく電子メールでリンクを送信します。 (受信者がこの場所とファイルへのアクセス許可を持っていることを確認してください)
- それがステータスミーティングである場合–プレゼンテーションのため
サンプルステータスレポート
QAテストステータスレポート:
これらのガイドラインに従って、以下の状況報告に到着しました。
読者の便宜のために、彼らが伝えることができるさまざまなレベルの情報を伝える3枚のシートが含まれています。
シート1–プロジェクトの全体的な状況の概要です。
シート2-テストケースの状態の個々の詳細についての詳細です。
シート3-バグレポートのサンプルです。
このサンプルステータスレポートXlsテンプレートを三つのシートすべてでダウンロードします。 （リンクを右クリックし、”名前を付けてリンクを保存”を選択します。.’ダウンロードするには)
著者について–これはSTHチームメンバー Swati Seelaによる記事です。 あなたは私たちのソフトウェアテストコースページで彼女についての詳細を知ることができます。
