ソフトウェアテストにおける欠陥管理プロセス

欠陥管理プロセスとは何ですか?

欠陥管理は、バグを特定して修正するための体系的なプロセスです。欠陥管理サイクルには、次の段階が含まれます。1) 欠陥の発見、2) 欠陥の分類、3) 開発者による欠陥の修正、4) テスターに​​よる検証、5) 欠陥のクローズ、6) プロジェクト終了時の欠陥レポート

このトピックでは、Guru99 Bank プロジェクトの Web サイトに欠陥管理プロセスを適用する方法を説明します。 以下の手順に従って欠陥を管理できます。

欠陥管理プロセス

ステップ 1) 発見

発見フェーズでは、プロジェクト チームは次のことを発見する必要があります。 多くの としての欠陥 可能、 最終顧客が発見する前に。 欠陥が発見されステータスに変化するといいます。 一般に認められた 開発者によって認識され、受け入れられたとき

上記のシナリオでは、テスターは Web サイト Guru84 で 99 個の欠陥を発見しました。

Discovery

次のシナリオを見てみましょう。テストチームが Guru99 Bank の Web サイトでいくつかの問題を発見しました。チームはそれを欠陥とみなし、開発チームに報告しましたが、矛盾が生じています。

このような場合、テストマネージャーとしてあなたはどうしますか?

A) それが欠陥であるというテストチームの意見に同意する

B) テストマネージャーは、問題が欠陥であるかどうかを判断する裁判官の役割を果たします。

C) 欠陥ではない開発チームの同意

正解
正しくない

このような場合、紛争を解決するために解決プロセスを適用する必要があります。あなたは、Web サイトの問題が欠陥であるかどうかを判断する裁判官の役割を果たします。

ステップ 2) 分類

欠陥の分類は、ソフトウェア開発者がタスクに優先順位を付けるのに役立ちます。 つまり、この種の優先順位は、開発者が非常に重要な欠陥を最初に修正するのに役立ちます。

カテゴリ

欠陥は通常、テストマネージャーによって分類されます。

次のような簡単な練習をしてみましょう

欠陥の優先度を下にドラッグ アンド ドロップします。
1) ウェブサイトのパフォーマンスが遅すぎる
2) ウェブサイトのログイン機能が正常に動作しない
3) Web サイトの GUI が正しく表示されない モバイル デバイス
4) Web サイトがユーザーのログイン セッションを記憶できませんでした
5) 一部のリンクが機能しない

推奨される回答は次のとおりです

いいえ。 説明 優先 説明

1

ウェブサイトのパフォーマンスが遅すぎる

ハイ

パフォーマンスのバグはユーザーに多大な不便をもたらす可能性があります。

2

Webサイトのログイン機能が正常に動作しない

クリティカル

ログインは銀行 Web サイトの主要機能の XNUMX つですが、この機能が動作しない場合は重大なバグです。

3

Web サイトの GUI がモバイル端末で正しく表示されない

M

この不具合はスマートフォンを使用してウェブサイトを閲覧しているユーザーに影響を与えます。

4

Web サイトがユーザーのログイン セッションを記憶できませんでした

ハイ

ユーザーはログインできてもそれ以上のトランザクションを実行できなくなるため、これは深刻な問題です。

5

一部のリンクが機能しない

ロー

これは開発担当者にとっては簡単な修正であり、ユーザーはこれらのリンクがなくてもサイトにアクセスできます。

ステップ 3) 欠陥の解決

欠陥の解決 ソフトウェアテストでは、欠陥を修正する段階的なプロセスが行われます。 欠陥解決プロセスは、開発者に欠陥を割り当てることから始まり、次に開発者は優先度に従って欠陥の修正をスケジュールし、次に欠陥が修正され、最後に開発者がテスト マネージャーに解決レポートを送信します。 このプロセスは、欠陥の修正と追跡を簡単に行うのに役立ちます。

欠陥を修正するには、次の手順に従ってください。

欠陥の解決

  • 譲渡: 開発者または他の技術者に修正を割り当て、ステータスを に変更しました。 応答する.
  • スケジュール確定: このフェーズは開発者側が担当します。 彼らは、欠陥の優先度に応じて、これらの欠陥を修正するスケジュールを作成します。
  • 欠陥を修正する: 開発チームが欠陥を修正している間、テスト マネージャーは上記のスケジュールと比較して欠陥修正のプロセスを追跡します。
  • 解決策を報告す​​る: 欠陥が修正された場合、開発者から解決策のレポートを取得します。

ステップ4) 検証

開発チームを終えて 固定の報告 欠陥、テストチーム 検証する 欠陥が実際に解決されていること。

たとえば、上記のシナリオでは、開発チームが 61 個の欠陥をすでに修正したと報告した場合、チームは再度テストを行って、これらの欠陥が実際に修正されたかどうかを確認します。

ステップ5) 閉鎖

欠陥が解決され検証されると、欠陥のステータスは次のように変更されます。 閉まっている。 そうでない場合は、欠陥を再度確認するよう開発部門に通知を送信する必要があります。

ステップ 6) 欠陥報告

欠陥報告 ソフトウェア テストにおけるテスト マネージャーは、欠陥管理プロセスと欠陥のステータスに関するフィードバックを得るために、テスト マネージャーが欠陥レポートを作成して管理チームに送信するプロセスです。 その後、管理チームが欠陥レポートを確認し、必要に応じてフィードバックを送信したり、さらなるサポートを提供したりします。 欠陥レポートは、欠陥をより適切に伝達し、追跡し、詳細に説明するのに役立ちます。

管理委員会は欠陥状況を知る権利があります。 このプロジェクトであなたをサポートするには、欠陥管理プロセスを理解している必要があります。 したがって、現在の欠陥状況を報告してフィードバックを得る必要があります。

なぜ欠陥管理プロセスが必要なのでしょうか?

あなたのチームは、Guru99 Banking プロジェクトのテスト中にバグを発見しました。

欠陥管理プロセス

XNUMX 週間後、開発者からの返答は次のとおりです。

欠陥管理プロセス

来週テスターが返答します

欠陥管理プロセス

上記の場合と同様に、欠陥の伝達が口頭で行われる場合、すぐに事態は非常に複雑になります。 バグを制御し、効果的に管理するには、欠陥ライフサイクルが必要です。

重要な欠陥指標

上記のシナリオに戻ります。 開発チームとテスト チームは、報告された欠陥をレビューします。 その議論の結果がこれです

重要な欠陥指標

テスト実行の品質を測定および評価するにはどうすればよいですか?

これは誰もが抱く質問です テストマネージャー 知りたいこと。考慮すべきパラメータは次の2つです。

重要な欠陥指標

上記のシナリオでは、次のように計算できます。 不良品除去率 (DRR) は 20/84 = 0.238 (23.8 %)。

別の例として、Guru99 Bank の Web サイトに合計があるとします。 64 欠陥はありますが、テストチームは検出するだけです 44 欠陥、つまり見逃した 20 欠陥。 したがって、欠陥漏れ率 (DLR) は 20/64 = と計算できます。 0.312 (31.2%)

結論として、テスト実行の品質は次の2つのパラメータによって評価されます。

重要な欠陥指標

DRR と DLR の値が小さいほど、テスト実行の品質は高くなります。 比率の範囲はどれくらいですか ことができます。? この範囲は、プロジェクトのターゲットに基づいて定義して受け入れることも、同様のプロジェクトの指標を参照することもできます。

このプロジェクトでは、許容可能な比率の推奨値は次のとおりです。 5〜10%。 これは、テスト実行の品質が低いことを意味します。 これらの比率を減らすための対策を見つける必要があります。

  • 向上させる メンバーのスキルをテストします。
  • もっと時間をかけて テスト実行、特にテスト実行結果を確認する場合に使用します。

よくあるご質問

バグはコーディング上の誤りの結果/結果です。

A ソフトウェアテストの欠陥 エンドユーザーの要件または元のビジネス要件からのソフトウェア アプリケーションのバリエーションまたは逸脱です。 ソフトウェア欠陥とは、実際の要件を満たさないソフトウェア プログラムから不正確または予期しない結果を引き起こすコーディング上のエラーです。 テスターはテスト ケースの実行中にこのような欠陥に遭遇する可能性があります。

これら XNUMX つの用語にはほとんど違いがありません。業界ではどちらも修正が必要な障害であるため、一部の企業では同じ意味で使用されています。 テスト チーム。

テスターがテスト ケースを実行すると、予想される結果と矛盾するテスト結果に遭遇する可能性があります。 テスト結果のこの変動は、ソフトウェアの欠陥と呼ばれます。 これらの欠陥やバリエーションは、問題、問題、バグ、インシデントなど、組織ごとに異なる名前で呼ばれています。

ソフトウェア テストのバグ レポートは、ソフトウェア アプリケーションで見つかったバグに関する詳細な文書です。バグ レポートには、説明、バグが見つかった日付、バグを発見したテスターの名前、修正した開発者の名前など、バグに関する各詳細が含まれます。バグ レポートは、将来同様のバグを特定し、回避できるようにするのに役立ちます。

  • 欠陥ID – 欠陥の一意の識別番号。
  • 欠陥 Descriptexpression CMS – 欠陥が見つかったモジュールに関する情報を含む、欠陥の詳細な説明。
  • バージョン - 欠陥が見つかったアプリケーションのバージョン。
  • 手順– 開発者が欠陥を再現できる詳細な手順とスクリーンショット。
  • 提起日 – 欠陥が報告された日付
  • 参照- 欠陥を理解するために、要件、設計、アーキテクチャ、またはエラーのスクリーンショットなどのドキュメントへの参照を提供します。
  • 検出者 – 欠陥を報告したテスターの名前/ID
  • 状態 - 欠陥の状況については後ほど詳しく説明します
  • 修正方法 – 修正した開発者の名前/ID
  • 休業日 – 欠陥が解決された日付
  • 重大度 アプリケーションに対する欠陥の影響を説明します。
  • 優先 これは欠陥修正の緊急性に関係します。 重大度の優先順位は、欠陥を修正する必要がある影響の緊急性に基づいて、それぞれ高/中/低になります。

クリック こちら ビデオにアクセスできない場合

<ご参考>

サンプルの欠陥報告テンプレートをダウンロードする