はじめに
この記事は、テストだけでなく、他の分野の専門家にとっても役立ちます。
報告はプロジェクトで必要な部分であることが多いことを誰もが理解していると思いますが、それを書くことは常に問題です。 遅かれ早かれ誰もが、「それをどのように説明するのか」、「何を書くのか」、そして最も重要なことには「なぜ誰がそれを読むのか」という問題に直面しています。
実際、レポートは、エグゼキューターから顧客に情報を転送する重要かつ簡潔な形式です。 これは、その技術的要件に対する応答であると同時に、完了した作業に関する情報です。
今日は、テストレポートについて説明します。 この記事では、レポートを作成する際の重要なポイントに重点を置いています。
テストレポートをクリア
実際に明確なテストレポート（テストレポート）を作成します。
最初に、定義を思い出しましょう：
レポートは、実行されたアクション、実行された作業の結果に関する情報を含むドキュメントです。 通常、テーブル、グラフ、リストが含まれ、単にテキスト形式で情報を説明します。 それらの割合と内容によって、レポートの有用性と明確さが決まります。
誰のために、何のために、どのような条件でこれを行っているのか、それが提示する情報の認識をどの程度改善するのかを理解することが重要です。 各アクションには特定の目標があることを覚えておく必要があります。 報告書の場合、誰に対して、何のために、どのような条件でこれを行っているかを理解することが重要です。
図を見てみましょう：
分析セクション-これはレポートです。 その中で、作業の分析とテスト済み製品の評価を行います。
理想的な状況では、企業のタイプはレポートの品質と意味能力に影響を与えません。 残念ながら、残念ながら、アウトソーシング企業のレポートは、通常、フルタイムのテスト部門のレポートよりも優れており、より容量があります（快適な例外があります）。
私たちは、他のアウトソーシング会社と同様に、報告の質と透明性に大きな注意を払わざるを得ません。なぜなら、それは顧客に見える仕事を評価するための重要な指標だからです。
レポート自体は、最終版と定期版（毎日、毎週、毎月、バージョン化（製品の各バージョン）など）に分けることができます。 違いは、時間サンプルの深さにあります。
そのため、レポートを作成する前に、最初にレポートの作成者を決定する必要があります。
誰のためにレポートを作成していますか？
レポートを作成するときは、誰のために作成され、誰がそれを読むかを理解することが重要です。
ターゲットオーディエンスの優先順位に基づいて、レポートに含める情報を決定する必要があります。 したがって、プロジェクト中は、情報を反映する必要がある方向に統合する必要があります。
ターゲットオーディエンスの3つのグループを区別できます。
1. 技術ユーザー -テストマネージャー。 彼らの優先事項は、テストプロセス、発生する問題、それらの解決方法、テストプロセス自体の構築、および使用される方法と技術の説明を理解することです。
2. プロダクトマネージャー 、彼らはプロダクトマネージャーでもあります。 焦点は、期限、不必要な技術的詳細なしでテスト結果を絞り出すこと、および一般統計（デジタルおよび比較指標）にあります。
3. ビジネスユーザー 。 通常、これらはテストを完了する決定を行う人々です。 彼らは行われた仕事の質を決定します。 彼らにとって、まず第一に、最終結果は、最も簡潔で明確な形式（はい/いいえ）、情報の視覚的表現（グラフ、チャート）、詳細に入らずに産業環境で製品をリリースする可能性に関する専門家の意見などで重要です。
結論： すべてのグループに適したレポートを作成する ことは ほとんど不可能です。 レポートを作成する前に、対象読者を決定してください。 それに応じて、コンテンツは構造が大きく異なり、特定のグループに必要なさまざまな詳細が含まれます。
時間サンプルの深さは？
レポートは、時間に対して2つのタイプに分類できます。
1. （毎週、毎日、毎月）/暫定。
一般的に、これはほぼ同じ最終レポートですが、フォーカスの優先順位が変更され、タイムサンプリングの深さが削減されています。 次の2つの主要なメトリックが含まれている必要があります。
-製品の準備の評価。
-レポート間の時間のテストで実行された作業の評価（進行中）。
このレポートには、作業のダイナミクスが表示されます。
進捗は一定の値ではなく、動的な値であり、先週と現在のプロジェクトのステータスを比較することで決定されることを覚えておくことが重要です。 したがって、進捗状況は、プロジェクトの状態を理解できるようにするこの一連のメトリックです。
テストを成功させるために設定された目標に基づいて、プロジェクトごとに個別に作成されます。 メトリックは、TCの作成（テストケース）、TCの合格（失敗/合格）、欠陥の検出（重大度）時に設定されます。 これらを使用すると、プロジェクトの全体像を簡単かつ迅速に作成できます。 たとえば、TestLinkを使用している場合、メトリックを使用すると、問題をすばやく選択したり、失敗したTCの統計をコンパイルしたりできることを理解できます。
この情報はProduct Managerにとって有用であり、必要です。QEおよびSQEと同様にTest-managerによってコンパイルおよび制御されます。
別の重要で頻繁に使用される一時レポートには、 バージョン付き （反復レポート）があります。
それは最後のものに似ています。 製品の特定のバージョンに対してテストチームが実行したタスクについて説明します。
2. 最終/最終。
最終レポートでは、（確立されたメトリックのコンテキストで）行われた作業の一般的なビューと製品の進化を示すことが重要です。
また、現時点での製品の状態に関する包括的な情報（残りの未修正エラーの数、製品が完全にテストされているか、追加のテストサイクルが必要か、製品を「外の世界」にリリースする可能性の評価など）を提供する必要があります。
結論： プロジェクト全体でメトリックを使用して統計を保持します。 彼女は、適切なタイミングで顧客に情報を提供し、「第4週に正確に何をしましたか？」および「期限までに何をしますか？」という質問に対する恐怖からあなたを解放するのを手伝います。
レポートで使用する情報とデータの表示方法は何ですか？
技術スペシャリストが別の技術スペシャリストのために書くとき、情報を反映する特定の方法の適用の問題はめったに起こりません。 用語、公式、専門的なスラング-これはよく知られており、理解できるものです。 テストの仕様から比較的遠い人々のためにレポートを書くことははるかに困難です。
ビジネスユーザーの場合、多くの場合、グラフ形式の情報の表示を使用します。 彼らは、プロジェクトが何パーセント完了したかによって、製品がどれだけ産業環境にリリースされる準備ができているかを明確に示しています。
これは、たとえば、モジュールで渡されたTCのグラフにすることができます。 各モジュールですでに行われた作業の量が明確に示され、問題の切り分けに役立ちます。
また、作成されたチケット（検出されたバグ）とクローズされた（修正されたバグ）の関係のグラフは非常に便利です。 何のためではなく、それは多くのタスクトラッカーの主要なものです。
欠陥の修正と高品質のコードの作成に関するプログラマの生産的な作業の場合、重大なエラー曲線は、新しいリリースのリリースとともに底に向かう傾向がありますが、エラーの優先度と重要性も低下します。
しかし、開発者またはテスターが既存の欠陥にほとんど注意を払わない場合、閉じられたバグの曲線は閉じられていないバグよりもゆっくりと成長します。
理想的な場合、閉じられていないバグ（発見されたが修正されていない）の曲線は、修正されたバグの曲線に収束するはずです。 つまり、最終リリースでは、すべての欠陥を修正する必要があります。 そうでない場合、経営者は、すべての欠陥を排除するか、「製品」の製品をリリースするために開発とテストを拡張し、リスクを負うことを決定する場合があります。
スケジュールに加えて、ピボットテーブルを作成する必要があります。 グラフはこれらのデータに基づいて作成されます。
モジュールごとの完成したTCのグラフが作成された基礎となるテーブルの例を次に示します。
結論： ビジネスユーザーのグラフは、レポートの必須部分です。 これは、エンドユーザーにとって有益であり、アクセス可能であり、理解可能であり、プロジェクトでの活動のダイナミクス、または最悪の場合は停滞を示します。
また、迅速かつ明確に数値を比較してダイナミクスを表示する必要がある場合は、ユーザーおよび技術専門家向けのレポートでグラフを使用することをお勧めします。
レポートには常に何を表示する必要がありますか？
異なるタイプのレポートは非常に異なるように見えるかもしれません。
それにもかかわらず、それらは常に示されるべきである同様の機能とデータを持っています。
ここにあります：
1.チーム構成;
2.レポートがコンパイルされる期限。
3.テストプロセスの説明。
4.テストモデルの変更、TCの追加。
5.完了したTCの割合。
6.重大かつブロッキングの問題と、それらを除去するために取られた対策。
7.回帰の結果（および残りの問題の強調）。
8.次の反復\週\月を計画します。
ポイント3、4、6、および8は、レポートの対象読者に目を向けて作成する必要があります。
7番目のポイントは、「回帰テスト」が実行されたときに示される必要があります。 通常、この項目は「バージョン管理された」レポートに表示されます。
パラグラフ8は最終レポートから除外されています。
おわりに
そのため、レポートを作成する期間を指定し、コンテンツとブロックを定義し、ターゲットオーディエンスを理解しました。 実際、これは、実際に理解できる文書を作成するために必要なもののほとんどであり、確実に、それが宛てられた人々の頭の中で応答を見つけるでしょう。
優れたレポートは、作業の少なくとも3分の1であり、テスターやプログラマー以外の誰かが見ることができる唯一の部分であるため、レポートを詳細に、有能に、喜んで書きます。
著者：エフレモヴァ・ダリア