実際に機能するQAドキュメントの書き方

ソフトウェア製品は飛行機のようなものです。発売前に技術チェックを受ける必要があります。

品質保証は、ソフトウェア製品を成功させるために必要なステップです。それはすべてのプロジェクト作業のほんの一部ですが、誰もそれが簡単だとは言いませんでした。

ソフトウェアテストには、自動と手動、探索的と機能、互換性、UI / UX、回帰、ユニット、API、パフォーマンステストなど、非常に多くの種類があります。それらすべてに頭を包んで頑張ってください!

ただし、これらすべてのタイプに共通しているのは、それぞれが完全なQAテストドキュメントを作成する必要があるということです。テストドキュメントの品質は、あなたの仕事が有用であると証明されるか、無駄になるかを定義します。

私はあなたの人生を少し楽にするためにこの記事を書きました。これが、機能するソフトウェアQAドキュメントの作成方法に関する究極のガイドです。

テスト計画とテスト進捗レポートを作成する

テスト計画は、QAプロセスの全体像を概説するガイド文書であり、やることリスト、戦略、リソース、およびスケジュールが含まれています。

QA計画書を作成する前に、「ソフトウェアソリューションの目的は何ですか?」と自問してください。および「どの機能をテストする必要がありますか?」ソフトウェアのすべての部分を急いでテストしないでください。使用する方法論、テクノロジー、およびツールを決定する必要があります。

テスト計画は、次のことを理解するのに役立ちます。

  • 受け入れ基準は何ですか?
  • どのようなリソースが必要ですか?どのオペレーティングシステム、いくつのコピー、そしてどのライセンスで?技術コンサルタントが必要ですか?
  • あなたの役割と責任は適切に指定されていますか?
  • テストの時間枠は何ですか?

テスト進捗レポートはQAドキュメントの別の部分であり、テスト計画に似ていますが、現在の進捗に関するデータが追加されています。このドキュメントを使用すると、開発チームはプロジェクトの進行状況を監視し、組織の問題がある場合はそれを特定できます。

テスト計画とレポート

テストケースを作成する

テスト計画でテストする必要のある一連の機能を明確にしたら、ソフトウェアの各部分のテストケースを作成する必要があります。

テストケースは非常に単純です。このQAドキュメントは、ID、テストケース、テスト手順、期待される結果、ステータス、実際の結果、コメントの7つのセクションで構成されています。

  1. IDは、テストケースに割り当てられた一意の番号です。
  2. テストケース」セクションでは、テストする要件を指摘し、仕様書にその要件へのリンクを提供します。
  3. [テスト手順]セクションでは、テストケースを完了するために必要なすべてのアクションを一覧表示します。
  4. [期待される結果]セクションでは、特定のテストが成功した場合の結果を要約します。
  5. [ステータス]セクションで、特定のステップがテストに合格したか失敗したかを示します。
  6. 実際の結果」セクションでは、失敗したテストの結果について説明します。
  7. コメントセクションは必須ではないが、あなたはいくつかの追加のメモを残して、それを追加することができます。
テストケース

欠陥レポートを書く

欠陥レポートは、QAドキュメントの重要な要素です。それはあなたのプログラムに不要な問題を登録します。これはプロジェクトドキュメントの重要な要素であり、バグのないソフトウェアソリューションを入手するために役立ちます。

簡単そうですね。はい。ただし、文書化を開始するまでです。ここでは、典型的な欠陥レポートの例を見ることができます。

欠陥レポート

欠陥レポートは、識別子、要約、説明、再現手順、再現性、重大度、優先度、環境、および添付ファイルのセクションで構成されています。

  1. 特定のソフトウェアの問題ごとに、一意の番号(識別子)が割り当てられます。QAドキュメントのナビゲーションを最適化し、開発者、テスター、PM間のコミュニケーションを促進します。
  2. 要約どこで、どのような状況の下で、何が起こったのか:セクション、次の3つの簡単な質問に簡潔な答えを提供しています。
  3. 説明セクションあなたは詳細のバグについて説明します。実際の結果と期待される結果について教えてください。ソフトウェア要件へのリンクを提供すると便利です。
  4. 次に、再現する手順(STR)について記述します。これは、開発者に問題を再現する方法を正確に示しています。ステップをお見逃しなく。さもないと、レポートが返ってくる可能性があります。
  5. 再現性のバグは、あなたがSTRに続くたびに表示された場合のセクション、あなたは明確。おおよその可能性を示すには、数字を使用する必要があります。たとえば、10回のうち7回です。
  6. では重大度セクション、あなたはバグがプロジェクトにもたらすことがどのくらいの害を説明します。つまり、システム全体に対する欠陥の技術的な影響度を示しています。小さな問題でも、アプリケーション全体に悪影響を与える可能性があります。
  7. 優先度は、特定の欠陥レポートの重要性を示します。優先度は、文字(最も緊急度が高い場合は「A」、最も緊急度が低い場合は「Z」、数字-最も緊急度が高い場合は「1」、最も緊急度が低い場合は「9」、または単に「高」などの単語を使用して示すことができます。 」、「中」、または「低」。
  8. では環境セクションには、オペレーティングシステムやブラウザのバージョンが影響を受けたかを定義する必要があります。
  9. 最後に、添付ファイルには、欠陥レポートに追加されたビデオ、スクリーンショット、またはコンソールログファイルのリストが含まれています。

欠陥レポートを作成するためのこれらの便利なヒントを念頭に置いてください

  1. 十分かつ適切な要約を書いてください。長いか短いかは関係ありません。重要なのは、それが明確でなければならないということです。
  2. 概要と説明をご覧ください。それらはほとんど同じに見えますか?説明に期待される結果と実際の結果の概要を示し、要件へのリンクを追加することを忘れている必要があります。
  3. スクリーンショットを使用して問題をキャプチャします。それはあなたと開発チームに多くの時間を節約するかもしれません。時々、写真を一目見れば状況を理解するのに十分です。
  4. 問題を報告する前に、少なくとも3回再現して、問題が存在することを確認してください。
  5. 問題をできるだけ早く報告し、問題が重大である場合はプロジェクトマネージャーまたは製品所有者に通知してください。
  6. QAドキュメントで文法の間違いをチェックして、文法警察に取り下げられないようにします。
  7. コミカルに聞こえますが、問題が機能ではないことを確認してください。ドキュメントをもう一度確認してください。
  8. 再現手順の重要な情報をお見逃しなく。

欠陥レポートを提出する

欠陥レポートは、問題を報告した瞬間から問題がクローズされる瞬間までのライフサイクルを通過します。

欠陥レポートのライフサイクル

最初のステップは、欠陥レポートを編集して提出することです。この時点で、プロジェクトマネージャーまたは技術リーダーはそれを開発者に割り当てるか、不十分または不十分であるという理由で拒否するかを決定します。

割り当てられた開発者がバグを修正した後、QAとして、バグが修正されたことを再確認して確認する必要があります。はいの場合、欠陥レポートを閉じることができます。ベストプラクティスは、1〜2週間で閉じることです。

バグが修正されていない場合は、再度開く不具合報告をし、割り当てられた開発者にそれを送り返します。バグ修正プロセスは長くなる可能性がありますが、すべての欠陥レポートが最終的に閉じられるまで、強力な状態を維持する必要があります。

まとめる

品質保証は、避けられないプロセスです。出発前の各飛行機は技術チェックを受けます。問題がある場合は、問題が解決するまで航空機は接地されます。

同様に、各ソフトウェア製品は発売前にチェックする必要があります。ユーザーがアプリに2回目のチャンスを与えないため、バグのあるソフトウェアをデプロイする余裕はありません。

ソフトウェアの品質を向上させる必要がありますか?

私の会社KeenEthicsは、堅実な開発と品質保証サービスを提供しています。同様のプロジェクトの見積もりが必要な場合は、お気軽にご連絡ください

この記事を楽しんだら、プロトタイピングとは何か、なぜそれが必要なのか、そして最小限の実行可能な製品:アイデアと製品の間を続ける必要があります。

PS

KeenEthicsブログに投稿された元の記事はここにあります:機能するQAドキュメントの書き方?