Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Different Participants of Defect Life Cycle
What Exactly is a Defect?
A fault or error in an application that restricts the usual flow of the application by mismatching the expected behavior of an application with the real one is referred to as a defect.
A defect happens when a developer makes a mistake when developing or constructing an application. When a tester discovers this error, it is referred to as a defect.
A tester must thoroughly test an application to identify as many flaws as possible to guarantee that a quality product reaches the consumer. Before going on to the workflow and different phases of the defect, it is critical to grasp the defect life cycle.
Let us go deeper into the Defect Life Cycle.
So far, we've spoken about what a defect is and how it relates to the testing process. Let's take a look at the defect life cycle and learn about the defect process as well as the many stages of a defect.
Defect States
New − In the Defect Life Cycle, this is the first state of a defect. When a new flaw is discovered, it is marked as 'New,' and validations and testing are conducted on it in the later phases of the Defect Life Cycle.
Assigned − At this point, a newly produced defect is assigned to the development team, who will work on it. The project manager or the manager of the testing team assigns this to a developer.
Open − Here, the developer begins the process of assessing the issue and, if necessary, working on its resolution. Suppose the developer believes that the fault is inappropriate. In that case, it may be shifted to one of the four states listed below, namely, Duplicate, Deferred, Rejected, or Not a Bug, for various reasons. We'll get to these four states in a minute.
Fixed − When a developer completes the job of resolving a defect by implementing the necessary modifications, he can designate the defect's state as "Fixed."
Pending Retest − After resolving the issue, the developer submits the defect to the tester, who will retest it on their end. The defect's status stays "Pending Retest" until the tester works retesting the defect.
Retest − At this stage, the tester begins the job of retesting the defect to determine whether or not the fault was corrected properly by the developer in accordance with the requirements.
Reopen − If the defect still has a problem, it will be sent back to the developer for testing, and the status of the defect will be changed to 'Reopen.'
Verified − If the tester finds no difficulties with the defect after it has been assigned to the developer for retesting and feels the fault has been resolved repaired correctly, the defect's status is changed to 'Verified.'
Closed − The tester changes the defect's state to "Closed" when the flaw is no longer present.
Guidelines for Putting a Defect Life Cycle in Place
Before beginning to work with the Defect Life Cycle, a developer who is working should follow certain key criteria.
These are some of the criteria −
Before beginning work on the Defect Life Cycle, the entire team must know the various phases of a defect (discussed above).
To minimize future misunderstandings, the Defect Life Cycle should be thoroughly documented.
To achieve better outcomes, ensure that each employee who has been assigned a duty linked to the Defect Life Cycle fully understands his or her responsibilities.
Each individual who changes the status of a defect should be adequately informed of that status and should offer sufficient data about the status and the rationale for placing that status so that everyone working on that particular fault understands why it is in that state.
The developer should use the defect tracking tool with caution to preserve consistency across defects and, as a result, in the workflow of the Defect Life Cycle.
Report of Invalid and Duplicate Defects
When a defect occurs that is not caused by code but by the test environment or a misunderstanding, the report should be closed as an Invalid defect.
In the instance of a duplicate report, one is retained and the other is closed as a duplicate. The Manager accepts some incorrect reports.
The overall Defect Management & process is owned by the Test Manager, and the Defect Management tool cross-functional team is typically in charge of handling the reports.
Participants include Test Managers, Developers, Project Managers, Production Managers, and other relevant stakeholders.
The Defect Management Committee should assess the validity of each defect and decide whether to remedy or postpone it. Consider the cost, hazards, and advantages of not correcting any problem to arrive at this conclusion.
If the fault must be repaired, its priority must be established.
Defect Data
- The Person's Name
- Testing Varieties
- Problem Summary
- Defect Description in Detail
- Steps to Recreate the Life Cycle Phase
- Work product in which a flaw was introduced
- Priority and severity
- The subsystem or component into which the flaw is introduced.
- When the Defect is introduced, Project Activity occurs.
- Method of Identification
- The Kind of Defect
- Projects and products that have issues
- The current owner
- The current state of the report work product in which the defect occurred.
- The Effect on the Project
- The risk, loss, opportunity, and advantages of correcting or not fixing the issue
- Dates when distinct stages of the defect lifecycle occur.
- Description of how the problem was fixed and testing suggestions
References
Capability in Process
Introduction, Detection, and Removal Information -> Improve Defect Detection and Quality Cost.
Introduction -> Praetor study of the process that introduces the most flaws in order to decrease the overall number of defects.
Defect Root Info -> Locate and highlight the reasons for the defect in order to decrease the overall number of faults.
Defect Component Information -> Defect Cluster Analysis
The defect life cycle usually varies from one organization to another and is regulated and controlled by software testing methodology the organization or project follows or defect tracking technology generally used. There are various players of defect life cycle that make the procedure effective. These participants are listed below.
Defect Reporter
As the name implies, a defect reporter is someone who reported a defect, i.e., the person who detected a defect. The primary function of a defect reporter is to validate, i.e., to confirm the validity or correctness of the defect. After verifying, the reporter adds all the data and information connected to the defect tracking tool. These detail and information can include defect priority, defect severity, defect impact, test environment, defect description, module, kind of defect, resources needed to repair it, stages of replication, etc. Tester occasionally has to provide an associated screenshot to verify and explain all specifics of the issue.
Defect Tracking Tool
As the name implies, defect tracking tools are tools that are used to detect or track problems. It usually helps to record, report, allocate, identify, discover, and monitor fault if present in software development projects. In simple terms, we may state that the better the bug tracking tool, the better the product will be. The defect is typically recorded in a defect tracking tool that assists typically in reporting. These tools may be Jira, Assembla, etc.
Defect Group
As the name implies, a defect group is a group of individuals who are authorized to view the complete information connected to the defect. A defect group is usually responsible for any action associated with the defect, beginning from detection until resolution. These groups may include a tester who finds and verifies defects, a test lead who supervises testers and defect reports. This end-user reported a defect, a developer to whom defect is assigned by test lead, project manager, QA manager, QA team, etc. In simple terms, a defect group is a group of individuals who can monitor all defect actions.
Defect Owner
As the name implies, the defect owner is the one who is accountable for evaluating and own defects. They are usually responsible for verifying, validating, and guarantee that the information being given linked to the fault is complete and adequate. If the information presented is not full and is not satisfactory, then the defect is assigned back to the defect reporter who reported the defect to provide more and extra information to it. Based on the priority given to each defect, the defect owner then further resolves and repairs the problem within the deadline.
Frequently Asked Questions
- What is the status of a defect when it is discovered?
Answer − When a new flaw is discovered, it is in a new condition. This is the initial condition of a freshly discovered flaw.
- What are the various phases of a defect in the defect life cycle when a developer approves and fixes a problem?
Answer − New, Assigned, Open, Fixed, Pending Retest, Retest, Verified, and Closed are the different statuses of a bug in this example.
- What happens if a tester discovers an issue with a defect that a developer has resolved?
Answer − The tester might indicate the defect's condition as. If the tester still discovers a problem with the repaired defect, the tester should reopen it, and the defect should be assigned to a developer for retesting.
- What exactly is a producible defect?
Answer − A fault that frequently occurs in each execution and whose stages can be caught in each execution is referred to as a "producible" defect.
224 Views
