what is defect bug life cycle software testing
欠陥ライフサイクルの概要
このチュートリアルでは、欠陥のライフサイクルについて説明し、テスト環境での作業中にテスターが対処しなければならない欠陥のさまざまな段階を認識できるようにします。
休憩とSOAPWebサービスのインタビューの質問
また、欠陥ライフサイクルに関して最もよく寄せられるインタビューの質問を追加しました。これは、欠陥のライフサイクルを理解するために、欠陥のさまざまな状態について知ることが重要です。テストアクティビティを実行する主な目的は、製品に問題/エラーがあるかどうかを確認することです。
実際のシナリオでは、エラー/間違い/障害はすべてバグ/欠陥と呼ばれるため、テストを行う主な目的は、製品に欠陥が発生しにくいことを確認することであると言えます(欠陥がないことは非現実的な状況です)。 )。
さて、欠陥とは何かという疑問が生じます。
学習内容:
欠陥とは何ですか?
欠陥とは、簡単に言うと、アプリケーションの予想される動作と実際の動作を一致させないことにより、アプリケーションの通常のフローを制限しているアプリケーションの欠陥またはエラーです。
欠陥は、アプリケーションの設計または構築中に開発者がミスを犯した場合に発生し、この欠陥がテスターによって発見された場合、それは欠陥と呼ばれます。
高品質の製品が顧客に届くことを保証するために、可能な限り多くの欠陥を見つけるためにアプリケーションの徹底的なテストを行うことはテスターの責任です。
ワークフローに移行する前に、欠陥のライフサイクルと欠陥のさまざまな状態について理解することが重要です。
したがって、欠陥のライフサイクルについて詳しく見ていきましょう。
これまで、欠陥の意味と、テスト活動との関連でその関係について説明してきました。それでは、欠陥のライフサイクルに移り、欠陥のワークフローと欠陥のさまざまな状態を理解しましょう。
欠陥のライフサイクルの詳細
欠陥ライフサイクルは、バグライフサイクルとも呼ばれ、欠陥のサイクルであり、そこからライフサイクル全体のさまざまな状態をカバーします。これは、テスターが新しい欠陥を見つけるとすぐに始まり、テスターがその欠陥を閉じて、再び再現されないようにすることで終了します。
欠陥ワークフロー
次に、以下に示す簡単な図を使用して、欠陥ライフサイクルの実際のワークフローを理解します。
![]()
欠陥状態
#1)新規 :これは、欠陥ライフサイクルにおける欠陥の最初の状態です。新しい欠陥が見つかると、それは「新規」状態になり、欠陥ライフサイクルの後の段階でこの欠陥に対して検証とテストが実行されます。
#2)割り当て済み: この段階で、新しく作成された欠陥が開発チームに割り当てられ、欠陥に取り組みます。これは、プロジェクトリーダーまたはテストチームのマネージャーによって開発者に割り当てられます。
#3)オープン: ここで、開発者は欠陥の分析プロセスを開始し、必要に応じて修正に取り組みます。開発者が欠陥が適切でないと感じた場合、それは以下の4つの状態のいずれかに移行する可能性があります。 重複、延期、拒否、またはバグではない -特定の理由に基づく。
これらの4つの状態については後で説明します。
#4)修正済み: 開発者が必要な変更を加えて欠陥を修正するタスクを完了すると、開発者は欠陥のステータスを「修正済み」としてマークできます。
#5)保留中の再テスト: 欠陥を修正した後、開発者は欠陥をテスターに割り当てて、最後に欠陥を再テストします。テスターが欠陥の再テストに取り組むまで、欠陥の状態は「保留中の再テスト」のままです。
#6)再テスト: この時点で、テスターは欠陥の再テストに取り組むタスクを開始し、開発者が要件に従って欠陥を正確に修正したかどうかを確認します。
#7)再開: 欠陥に問題が続く場合は、テストのために開発者に再度割り当てられ、欠陥のステータスが「再開」に変更されます。
#8)検証済み: テスターが再テストのために開発者に割り当てられた後、欠陥に問題が見つからず、欠陥が正確に修正された場合、欠陥のステータスが「検証済み」に割り当てられると感じた場合。
#9)クローズ: 欠陥が存在しなくなると、テスターは欠陥のステータスを「クローズ」に変更します。
後もう少し:
- 拒否されました: 欠陥が開発者によって真の欠陥と見なされない場合、開発者によって「拒否」としてマークされます。
- 複製: 開発者が他の欠陥と同じように欠陥を見つけた場合、または欠陥の概念が他の欠陥と一致した場合、開発者は欠陥のステータスを「重複」に変更します。
- 延期: 開発者は、欠陥がそれほど重要ではないと感じ、次のリリースなどで修正できる場合は、欠陥のステータスを「延期」に変更できます。
- バグではありません: 欠陥がアプリケーションの機能に影響を与えない場合、欠陥のステータスは「バグではない」に変更されます。
ザ・ 必須フィールド テスターが新しいバグをログに記録するときは、ビルドバージョン、送信日、製品、モジュール、重大度、概要、および再現する説明です。
xmlファイルを開くための最良の方法
上記のリストに、いくつか追加できます オプションのフィールド 手動のバグ送信テンプレートを使用している場合。これらのオプションフィールドには、顧客名、ブラウザ、オペレーティングシステム、添付ファイル、またはスクリーンショットが含まれます。
次のフィールドは、指定または空白のままです。
バグのステータス、優先度、および「割り当て先」フィールドを追加する権限がある場合は、これらのフィールドを指定できます。それ以外の場合、テストマネージャーはステータスとバグの優先度を設定し、バグをそれぞれのモジュール所有者に割り当てます。
次の欠陥サイクルを見てください
![]()
上の画像は非常に詳細であり、バグライフサイクルの重要なステップを検討すると、それについて簡単に理解できます。
ロギングが成功すると、バグは開発マネージャーまたはテストマネージャーによってレビューされます。テストマネージャーは、バグステータスをオープンに設定したり、開発者にバグを割り当てたり、次のリリースまでバグを延期したりできます。
バグが開発者に割り当てられ、開発者がその開発に取り掛かることができるようになったとき。開発者は、バグステータスを「修正しない」、「再現できなかった」、「詳細情報が必要」、または「修正済み」に設定できます。
開発者が設定したバグステータスが「詳細情報が必要」または修正済みの場合、QAは特定のアクションで応答します。バグが修正された場合、QAはバグを検証し、バグステータスを確認済みクローズまたは再開として設定できます。
欠陥ライフサイクルを実装するためのガイドライン
欠陥ライフサイクルの使用を開始する前に、いくつかの重要なガイドラインを採用できます。
これらは次のとおりです。
- 欠陥ライフサイクルの作業を開始する前に、チーム全体が欠陥のさまざまな状態を明確に理解することが非常に重要です(上記で説明)。
- 将来の混乱を避けるために、欠陥のライフサイクルを適切に文書化する必要があります。
- 欠陥ライフサイクルに関連するタスクを割り当てられた各個人は、より良い結果を得るために、自分の責任を非常に明確に理解する必要があります。
- 欠陥のステータスを変更する各個人は、そのステータスを適切に認識し、その特定の欠陥に取り組んでいるすべての人がそのようなステータスの理由を理解できるように、ステータスとそのステータスを設定する理由について十分な詳細を提供する必要があります非常に簡単に欠陥の。
- 欠陥追跡ツールは、欠陥間の一貫性を維持するように注意して処理する必要があります。したがって、欠陥ライフサイクルのワークフローで処理する必要があります。
次に、欠陥のライフサイクルに基づいた面接の質問について説明しましょう。
バグのライフサイクルに関する重要なFAQまたはインタビューの質問
Q#1)ソフトウェアテストの観点からの欠陥は何ですか?
回答: 欠陥とは、アプリケーションの予想される動作を実際の動作と一致させないことにより、アプリケーションの通常のフローを制限している、アプリケーションのあらゆる種類の欠陥またはエラーです。
Q#2)エラー、欠陥、失敗の主な違いは何ですか?
回答:エラー: 開発者は、開発フェーズでアプリケーションの実際の動作と予想される動作に不一致があることに気付いた場合、それをエラーと呼びます。
欠陥: テスターがテスト段階でアプリケーションの実際の動作と予想される動作に不一致を見つけた場合、テスターはそれを欠陥と呼びます。
失敗: 顧客またはエンドユーザーが、本番フェーズでのアプリケーションの実際の動作と予想される動作に不一致を見つけた場合、それを失敗と呼びます。
Q#3)欠陥が最初に見つかったときの状態はどうなっていますか?
回答: 新しい欠陥が見つかると、「新しい」状態になります。これは、新しく検出された欠陥の初期状態です。
Q#4)欠陥が開発者によって承認および修正された場合の、欠陥ライフサイクルにおける欠陥のさまざまな状態は何ですか?
回答: この場合、欠陥のさまざまな状態は、新規、割り当て済み、オープン、修正済み、保留中の再テスト、再テスト、検証済み、およびクローズです。
Q#5)開発者によって修正された欠陥にテスターがまだ問題を見つけた場合はどうなりますか?
回答: テスターは、修正された欠陥にまだ問題があり、その欠陥が再テストのために開発者に割り当てられている場合、欠陥の状態を「再開」としてマークできます。
Q#6)生成可能な欠陥とは何ですか?
回答: すべての実行で繰り返し発生し、すべての実行でステップをキャプチャできる欠陥。このような欠陥は「生成可能な」欠陥と呼ばれます。
Q#7)再現性のない欠陥とはどのような種類の欠陥ですか?
回答: すべての実行で繰り返し発生するわけではなく、一部のインスタンスでのみ生成され、スクリーンショットを使用して証拠としてのステップをキャプチャする必要がある欠陥。このような欠陥は、「再現不可能な」欠陥と呼ばれます。
Q#8)欠陥レポートとは何ですか?
回答: 欠陥レポートは、アプリケーションの通常のフローが期待される動作から逸脱する原因となっているアプリケーションの欠陥または欠陥に関するレポート情報を含むドキュメントです。
それはデスクインタビューの質問と回答のpdfを助けます
Q#9)欠陥レポートにはどのような詳細が含まれていますか?
回答: 欠陥レポートは、次の詳細で構成されています。
欠陥ID、欠陥の説明、機能名、テストケース名、再現可能な欠陥かどうか、欠陥のステータス、重大度、および欠陥の優先度、テスター名、欠陥のテスト日、欠陥が見つかったビルドバージョン。
そして、欠陥が割り当てられた開発者、欠陥を修正した人の名前、手順の流れを描いた欠陥のスクリーンショット、欠陥の日付の修正、および欠陥を承認した人。
Q#10)欠陥のライフサイクルにおいて、欠陥が「延期」状態に変更されるのはいつですか?
回答: 見つかった欠陥の重要性がそれほど高くなく、後のリリースで修正できる欠陥が、欠陥ライフサイクルの「延期」状態に移行した場合。
欠陥またはバグに関する追加情報
- 欠陥は、ソフトウェア開発ライフサイクルのどの時点でも発生する可能性があります。
- 欠陥が検出されて除去される前に、品質の全体的なコストが低くなります。
- 欠陥が導入されたのと同じフェーズで欠陥が除去されると、品質のコストが最小限に抑えられます。
- 静的テストでは、障害ではなく欠陥が見つかります。デバッグが含まれないため、コストが最小限に抑えられます。
- 動的テストでは、障害が発生したときに欠陥の存在が明らかになります。
欠陥の状態
| S.No. | 初期状態 | 復帰状態 | 確認状態 |
|---|---|---|---|
| 1 | 欠陥の再現責任者のための情報を収集する | 欠陥は拒否されるか、詳細情報を求められます | 欠陥は修正されており、テストして閉じる必要があります |
| 二 | 状態はオープンまたは新規です | 状態は拒否または明確化されます。 | 状態は解決され、検証されます。 |
無効で重複した欠陥レポート
- コードではなく、テスト環境や誤解が原因で欠陥が発生することがあります。そのようなレポートは、無効な欠陥として閉じる必要があります。
- 重複レポートの場合、1つは保持され、もう1つは重複として閉じられます。一部の無効なレポートがマネージャーによって受け入れられます。
- テストマネージャーは全体的な欠陥管理とプロセスを所有し、欠陥管理ツールのクロスファンクショナルチームは一般的にレポートの管理を担当します。
- 参加者には、テストマネージャー、開発者、PM、プロダクションマネージャー、およびその他の利害関係者が含まれます。
- 欠陥管理委員会は、各欠陥の有効性を判断し、いつ修正または延期するかを決定する必要があります。これを判断するには、欠陥を修正しないことのコスト、リスク、および利点を考慮してください。
- 欠陥を修正する必要がある場合は、その優先順位を決定する必要があります。
欠陥データ
- 人の名前。
- テストの種類
- 問題の概要
- 欠陥の詳細な説明。
- 再現する手順
- ライフサイクルフェーズ
- 欠陥が導入された作業成果物。
- 重大度と優先度
- 欠陥が発生したサブシステムまたはコンポーネント。
- 欠陥が導入されたときに発生するプロジェクトアクティビティ。
- 識別方法
- 欠陥の種類
- 問題のあるプロジェクトと製品
- 現在の所有者
- レポートの現在の状態
- 不具合が発生した作業成果物。
- プロジェクトへの影響
- 欠陥を修正するかしないかに関連するリスク、損失、機会、および利益。
- さまざまな欠陥ライフサイクルフェーズが発生する日付。
- 欠陥がどのように解決されたかの説明とテストの推奨事項。
- 参考文献
プロセス能力
- はじめに、検出、および削除の情報->欠陥の検出と品質のコストを改善します。
- はじめに->欠陥の総数を減らすために、最も多くの欠陥が導入されるプロセスのプラエトル分析。
- 欠陥ルート情報->欠陥の理由を強調して、欠陥の総数を減らします。
- 欠陥コンポーネント情報->欠陥クラスター分析を実行します。
結論
これはすべて、欠陥のライフサイクルと管理に関するものです。
欠陥のライフサイクルについての膨大な知識を身に付けたに違いありません。このチュートリアルは、将来、簡単な方法で欠陥を処理する際に役立ちます。
推奨読書
- 欠陥ベースのテスト手法とは何ですか?
- ソフトウェアテストライフサイクル(STLC)とは何ですか?
- Bugzillaチュートリアル:欠陥管理ツールのハンズオンチュートリアル
- メソッドとライフサイクルを備えたJavaスレッド
- ソフトウェアテストはアイデアがすべてです(そしてそれらを生成する方法)
- 初心者向けの詳細なEclipseチュートリアル
- 欠陥管理プロセス:欠陥を効果的に管理する方法
- Webおよび製品アプリケーションのサンプルバグレポート