ソフトウェアテストにおける欠陥管理プロセス
トーマス・ハミルトン
⚡ スマートサマリー
ソフトウェアテストにおける欠陥管理プロセスは、バグの特定、分類、解決、検証、クローズ、および報告を行うための構造化されたフレームワークです。これにより、テスターと開発者間の予測可能なコミュニケーションが可能になり、リリース品質が向上し、プロジェクトライフサイクル全体を通して本番環境へのバグ漏洩が減少します。
欠陥管理プロセスとは何ですか?
その 欠陥管理プロセス ソフトウェアテストは、ソフトウェアリリース前にバグを特定、分類、修正、検証するために用いられる体系的なアプローチです。ライフサイクルは、1) 欠陥の発見、2) 分類、3) 開発者による解決、4) テスターによる検証、5) 完了、6) プロジェクト終了時の欠陥報告、という6つの主要な段階から構成されます。
この記事では、欠陥管理プロセスを適用する方法について説明します。 Guru99 Bankのウェブサイトを例として、初心者および中級レベルのテスターが実際のプロジェクトのコンテキストで各ステップを理解できるようにします。
なぜ欠陥管理プロセスが必要なのでしょうか?
チームがテスト中にいくつかのバグを発見したと想像してください。 Guru99 銀行プロジェクト。構造化されたプロセスがないため、テスターと開発者間のコミュニケーションは口頭または散発的なメッセージで行われる。
1週間後、開発者は問題について異なる見解を示した。
翌週、テスターは再び返信し、さらなる混乱を招いた。
欠陥のコミュニケーションが口頭または非公式に行われると、すぐに事態が複雑になります。バグを制御し効果的に管理するには、チームが報告する方法を標準化する明確な欠陥ライフサイクルが必要です。 track、そしてクローズされた問題。
ステップ 1) 発見
プーケットの魅力 フェーズでは、プロジェクトチームは最終顧客が遭遇する前にできるだけ多くの欠陥を特定する必要があります。欠陥は、開発チームによって認識され受け入れられた時点で「発見」されたとみなされ、その時点でステータスが変わります。 受け入れ.
例のシナリオでは、テスターは84個の欠陥を発見しました。 Guru99銀行のウェブサイト。
しかし、テスターと開発者の意見が常に一致するとは限りません。次のケースを見てみましょう。テストチームが、 Guru99 Bankのウェブサイトで報告されているが、開発チームはそれらが欠陥であるかどうかについて異議を唱えている。
このような場合、テストマネージャーとして、あなたはどうすべきでしょうか？
A) テストチームの意見に同意し、これは欠陥であると判断します。
B) 裁判官の役割を担い、その問題が欠陥であるかどうかを判断してください。
C) 開発チームと意見が一致し、これは欠陥ではないと判断する。
正しいアプローチはオプションBです。紛争を解決するために解決プロセスを適用し、テストマネージャーはそれが欠陥として認められるかどうかを判断する前に、問題を公平に評価する必要があります。
ステップ 2) 分類
欠陥の分類は、開発者が作業の優先順位を決定し、ビジネス上最も重要な問題を最初に修正するのに役立ちます。分類は通常、テストマネージャーが行い、深刻度とビジネスへの影響度に基づいて行われます。
欠陥は通常、4つの優先度レベルに分類されます。 重大、高、中、低以下の各不具合に適切な優先度を割り当ててみてください。
- ウェブサイトの動作が遅すぎる。
- ウェブサイトのログイン機能が正常に動作しません。
- ウェブサイトの GUI が正しく表示されません モバイル デバイス。
- ウェブサイトはユーザーのログインセッションを記憶できません。
- 一部のリンクは機能しません。
推奨される回答は以下のとおりです。
| いいえ。 | 詳細説明 | 優先 | 説明 |
|---|---|---|---|
| 1 | ウェブサイトのパフォーマンスが遅すぎる | ハイ | パフォーマンスの問題は、エンドユーザーに大きな不便をもたらします。 |
| 2 | ログイン機能が正常に動作しません | クリティカル | ログインは銀行ウェブサイトの中核機能です。ログインに失敗すると、ユーザーの利用プロセス全体が阻害されます。 |
| 3 | モバイルデバイスではGUIが正しく表示されません | 技法 | この不具合は、スマートフォンでウェブサイトを閲覧するユーザーに影響します。 |
| 4 | ウェブサイトはユーザーのログインセッションを記憶できません | ハイ | ユーザーはログインできますが、それ以上の取引はできません。 |
| 5 | 一部のリンクが動作しない | ロー | 開発者にとっては簡単に修正できる問題であり、ユーザーは引き続きサイトの他の部分にアクセスできます。 |
ステップ 3) 欠陥の解決
欠陥の解決 ソフトウェアテストにおける欠陥解決は、段階的なプロセスです。解決プロセスは、欠陥を開発者に割り当てることから始まり、開発者は優先順位に基づいて修正をスケジュールし、修正を実装し、最後に解決レポートをテストマネージャーに送り返します。この一連の手順により、欠陥は解決されます。 trac透明性と説明責任のある王。
不具合を修正するには、以下の手順に従ってください。
- 割り当て： 欠陥は開発者または技術者に割り当てられ、そのステータスは 応答する.
- スケジュール調整： 開発チームが引き継ぎ、不具合の優先度に基づいて修正スケジュールを作成する。
- 不具合を修正する： 開発者が欠陥を修正している間、テストマネージャーは trac計画スケジュールに対するksの進捗状況。
- 決議内容を報告する： 開発者は、どの不具合がどのように修正されたかを確認するレポートを送信します。
ステップ4) 検証
開発チームが 固定の and 報告 欠陥、テストチーム 検証する 問題は解決済みです。
例えば、開発チームが61件の不具合を修正したと報告した場合、テストチームはそれぞれの不具合を再テストし、元の不具合が発生したのと同じ条件下で修正が正しく機能するかどうかを確認する。
ステップ5) 閉鎖
欠陥が修正され検証されると、そのステータスは次のように変更されます。 休診⽇検証中に不具合が適切に解決されない場合は、開発チームに再度調査を依頼する通知を送信する必要があります。クローズは、システム上で不具合が解消されたことを示します。
ステップ 6) 欠陥報告
欠陥報告 ソフトウェアテストにおける欠陥報告とは、テストマネージャーが欠陥のステータスを準備し、管理チームと共有するプロセスです。管理チームはレポートを確認し、必要に応じてフィードバックや追加のサポートを提供します。欠陥報告はコミュニケーションを改善し、 trac王様、そして欠陥周辺の可視性。
経営陣は、プロジェクトを効果的に支援するために、欠陥状況を把握する権利を有しています。したがって、経営陣が指導やリソースを提供できるよう、欠陥の現状について定期的に報告する必要があります。
重要な欠陥指標
元のシナリオに戻ると、開発チームとテストチームが一緒に不具合をレビューします。その結果を以下に示します。
テスト実行の質をどのように測定・評価できますか？
これは、あらゆる テストマネージャー 答えたい。通常、2つの重要なパラメータが使用される。
上記のシナリオでは、 不良品除去率（DRR） 20/84 = 0.238 (23.8%) と計算されます。
別の例として、 Guru99 Bankのウェブサイトには合計 64 欠陥を検出しますが、テストチームは 44 - 意味 20 欠陥が見落とされた。 欠陥漏洩率（DLR） 20/64 = 0.312 (31.2%) と計算されます。
要約すると、テスト実行品質は以下の2つのパラメータを用いて評価されます。
DRRとDLRの値が小さいほど、テスト実行の品質は高くなります。許容範囲は一般的にプロジェクト目標によって定義されるか、類似プロジェクトとのベンチマークによって決定されます。この例では、推奨される許容範囲は次のとおりです。 5％の10％に現在の実行結果はこの範囲外であり、以下の対策によってテスト品質を向上させる必要があることを示しています。
- 向上させる チームメンバーのテストスキル。
- もっと時間をかけて テスト実行時、特に実行結果を確認する際に重要となる。
効果的な欠陥管理のためのベストプラクティス
体系化されたベストプラクティスに従うことが、成熟した欠陥管理プロセスと混沌としたプロセスを分ける決定的な要素です。目標は単にバグを修正することではなく、バグが本番環境に漏れ出すのを防ぎ、テスターと開発者間のコミュニケーションの断絶を最小限に抑えるシステムを構築することです。
初心者および中級レベルのテスターがすぐに取り入れるべきベストプラクティスは以下のとおりです。
- 欠陥テンプレートを標準化する： 欠陥IDなどのフィールドを含む固定欠陥レポートテンプレートを使用します。 Descript問題の種類、再現手順、深刻度、優先度、環境、添付ファイル。一貫性を保つことで、テスターと開発者間のやり取りを減らすことができます。
- 割り当てる前に優先順位を決めましょう： 開発者に不具合を報告する前に、必ず深刻度と優先度で分類してください。そうすることで、重大な問題が些細な不具合に埋もれてしまうことを防ぐことができます。
- 報告する前に再現してください。 不具合を報告する前に、クリーンな環境で少なくとも2回は再現させてください。再現性のある不具合は解決が早く、不良率も低下します。
- 欠陥を採用する tracキングツール： などのツールを使用します ジラ, Bugzillaまたは マンティス 集中化する trac国王、歴史、そして報道。
- トリアージ会議を実施する： 短時間で集中的な不具合トリアージ会議を実施し、品質保証、開発、製品チーム間の優先順位を整合させる。
- 漏洩と拒否を測定する： Tracスプリントまたはサイクルごとに、DLRとDRRをk単位で測定します。リーク率の上昇は、テストカバレッジが不十分であることを示す早期警告です。
- 根本原因分析を実施する： 繰り返し発生する不具合や重大度の高い不具合については、根本原因分析を実施し、同じ種類のバグが今後のリリースで再発しないようにしてください。
- レポートでフィードバックを完結させる： 問題点を常に可視化し、対応可能な状態にするために、毎週の不具合ダッシュボードを関係者と共有しましょう。
これらの手法を一貫して適用することで、欠陥のライフサイクルが安定し、すべてのリリースの全体的な品質が向上します。
