ソフトウェアテストにおける欠陥管理プロセス
欠陥管理プロセスとは何ですか?
欠陥管理は、バグを特定して修正するための体系的なプロセスです。欠陥管理サイクルには、次の段階が含まれます。1) 欠陥の発見、2) 欠陥の分類、3) 開発者による欠陥の修正、4) テスターによる検証、5) 欠陥のクローズ、6) プロジェクト終了時の欠陥レポート
このトピックでは、Guru99 Bank プロジェクトの Web サイトに欠陥管理プロセスを適用する方法を説明します。 以下の手順に従って欠陥を管理できます。
ステップ 1) 発見
発見フェーズでは、プロジェクト チームは次のことを発見する必要があります。 多くの としての欠陥 可能、 最終顧客が発見する前に。 欠陥が発見されステータスに変化するといいます。 一般に認められた 開発者によって認識され、受け入れられたとき
上記のシナリオでは、テスターは Web サイト Guru84 で 99 個の欠陥を発見しました。
次のシナリオを見てみましょう。テストチームが Guru99 Bank の Web サイトでいくつかの問題を発見しました。チームはそれを欠陥とみなし、開発チームに報告しましたが、矛盾が生じています。
このような場合、テストマネージャーとしてあなたはどうしますか?
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%。 これは、テスト実行の品質が低いことを意味します。 これらの比率を減らすための対策を見つける必要があります。
- 向上させる メンバーのスキルをテストします。
- もっと時間をかけて テスト実行、特にテスト実行結果を確認する場合に使用します。
よくあるご質問
クリック こちら ビデオにアクセスできない場合