Defect Management Policy
Version: 1, effective date: 02-Dec-2022
Contents
1 Document description
This document defines the standards and specifications to be used during software project testing withing JTI.
2 Document objectives and benefits
2.1 Objectives
Objectives of the document are:
-
Define defects
-
Define properties of defects
-
Identify the priority of a defect
-
Identify the severity of a defect
-
Identify Post detection processes
-
Identify Ticket Management processes
-
Identify Post-fix processes
-
Define Defect Reports
2.2 Benefits
The document helps to describe test automation processes. While doing so will benefit with below:
-
Standardization of Defect Management
-
Common Language within SW teams
-
Prevention of Miscomminication within Organization
-
Improved way of Defect management
-
Improved project management
3 Definitions
| Abbreviation / Term | Explanation |
|---|---|
| QA | Quality Assurance |
| PM | Project Manager |
| PO | Product Owner |
| SDLC | Software Development Life Cycle |
| ROI | Return on Investment |
| UAT | User Acceptance Testing |
| ASAP | As soon as possible |
| SLA | Service Level Agreement |
Please refer to IT Glossary in the IT P&P portal for further definitions.
4 Roles & Responsibilities
Accountable: Approves the activity or recommendations from a person or team.
Responsible: Responsible for doing the work associated with an activity, either by completing personally or through sole accountability for a team’s output.
Consulted: Reviews the output of an activity and provides input but has no approval authority. Provides support to activity and may be consulted by the team during the course of the activity.
Informed: Is informed about activities to aid in planning own work.
| # | Activity | GDC T&T | BTS T&T | GSC CP |
|---|---|---|---|---|
| 1 | Define and maintain standard | A/R | C | I |
| 2 | Apply the standard in the T&T Implementation process | A/R | C | I |
5 Introduction to defect management
5.1 Defining defects
A defect is any discrepancy between a functional test’s expected and observed results. Other names can be used as well for example Bug, Error, Fault, or Failure.
5.2 Necessity of defect management
Insight into the quality is essential to provide advice and information concerning risks. Having a system in place to track a defect’s progression through its lifespan and identify the people responsible for fixing it is a key component of defect management. Likewise, it reveals how serious a flaw is. Damage to an operational business may be classified as “Critical” or “Minor,” for example.
Also, the number of defects detected during testing and the number of unresolved bugs that remain in the code are both metrics that may be derived from defect management (or documentation) later can be use as indicators about other aspects of the project, provider, or business.
5.3 Defect classification
Defects in quality are often categorized as minor, major, or critical by quality assurance experts. The severity and kind of a flaw are what put it into one of the three categories.
5.3.1 Minor defect
Minor defects are flaws too tiny to notice or too inconsequential to change the item’s function or appearance. In nature minor defects should not be a hindrance to progress of the project can be accepted for a later fix after post-deployment.
5.3.2 Major defect
When a feature considerably deviates from either the business requirements or the product specifications, we call this a “major fault,” which is far more problematic. If a product has a major flaw, it may have serious consequences for how it works, how it looks, or both.
Any user would easily spot these issues. The user would likely raise a complaint, seek a support due to these defects. No deployment until fixed should be accepted.
5.3.3 Critical defect
Of the three defect categories, critical defects are the most severe. When a system has a critical flaw, it is either rendered useless or poses a risk to the entire system or business.
Due to these defects, businesses are placed in danger, either because they are unable to carry out everyday functioning or because they are unable to operate at all. When it comes to severe defects within their software solution, many businesses have a “zero tolerance” policy.
5.4 Defect prioritization
Defect or Bug Priority denotes the significance or urgency of addressing a defect. Though priority may be originally defined by the Software Tester, it is typically confirmed by the Project/ Product Manager.
-
Urgent: Must be fixed ASAP, disastrously urgent, stop all other parallel work if needed.
-
High: Must be fixed before the due date of new sprint or version.
-
Medium: Must be fixed but can be fixed pre-release or next release.
-
Low: May or may not be fixed at all. Waits in backlog queue, test rapidly without feeling the pressure.
5.5 Levels defect life cycle
Each defect needs to be put under a status indicator to provide visibility on their progress. The more proper term is “State”. Though working with vendors may provide some difficulties because of the different naming or processes followed by the other party.
5.5.1 Discovery state
Defect discovery is crucial at the beginning of the defect management process. If the vendor side acknowledges recorded defect it will materialize as a legitimate detect. Discovery State has a workflow consisting of three actions.
-
Defect Identification: Tester finds a defect during the test execution
-
Defect Reporting: Tester: reports the defect via using defect management tool.
-
Defect Classification: Project Manager reviews the ticket and decides the severity and priority of the defect found.
-
Defect Acknowledgement: Defect is reported to the vendor side and responsible team is notified.
5.5.2 Defect resolution
After the vendor side is acknowledged, the bug goes through a couple of processes as below.
-
Defect Review: The defect report is reviewed and analysed by the point of contact, it can be closed immediately if the problem did not classify as a defect, state turns into” Rejected”. If the problem identified as a defect, then the state turns into “Accepted”
-
Defect Prioritization: Bug will be prioritized internally within vendor team. This state may not be visible.
-
Schedule Defect Fix: The vendor fixes the defects in descending order of severity and priority
-
Defect Resolution: The vendor notifies project team about the fix applied.
-
Fix Verification: Bug Fix Verification is the process of determining whether an issue has been fixed. Therefore First, tester performs a retest if the bug is fixed or else determines if new bugs have been introduced since the prior problem was resolved. If not fixed as expected defect returned to the vendor side for further work.
-
Defect Report Closure: If the bug fixed and no new defects introduced. Defect is closed.
5.6 Planning for severity classification
Ideally a clean classification for business requirements as a baseline will provide a better understanding for defect management and help with the time management as well.
5.6.1 Defect matrix
5.6.2 Risk handling
PM/PO are responsible to provide a healthy software release and delivery in time. Although mostly subjective it’s always imperative to have a baseline for the project risks to be able to prevent any delay or business risk by having classified the defects found and communicate with the development team accordingly. By combining the severity and priority of the defects found it’s possible to have good insight on the risks shown as
5.6.3 SLA and penalties
A Service-Level Agreement (SLA) is a legally binding contract between the development team and the quality team (the supplier) (the client). The goal of the SLA is to make it clear to everyone what the scope of the engagement is, what kind of work will be done, and what the provider’s responsibilities are. This lets the QA team determine what to focus their efforts on, cutting release costs, enhancing quality, and making it more robust.
Therefore, risk estimation of the defects found should be addressed and processed according to the SLA made with provider and treated as such. If SLA is breached penalties should be applied firmly.
6 Document owner
The owner of the document is Berhan Cem Ozelbicer.
7 Document control
7.1 Contact person
Questions and feedback regarding this standard should be submitted to Olga Ovchinnikova.
7.2 Sign off
| Name | Title | Function | Signoff Date |
|---|---|---|---|
| Avni Cengel | GDC T&T Delivery Center Director | IT T&T Delivery Center | |
| Sergey Khitrin | BTS T&T Service Director | IT BTS T&T |
7.3 Revision History
| Version | Effective date | Purpose of change | Author |
|---|---|---|---|
| 1 | 02-Dec-2022 | First draft of the document | Berhan Cem Ozelbicer |
8 References
ANY QUESTIONS?