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
Bug Life Cycle in Software Development
We'll go through the life cycle of a defect in this lesson to help you understand the many phases of a defect that a tester must deal with when working in a testing environment.
On Defect Life Cycle, we've also included the most often requested interview questions. Understanding the life cycle of a flaw requires knowledge of the many phases of a fault. The primary goal of the testing activity is to see whether the product has any flaws or faults.
Errors/mistakes/faults are all known as bugs/defects in real-world circumstances, thus we can say that the basic goal of testing is to guarantee that the product is less prone to defects (no defects is an unrealistic situation).
What Exactly Is a Defect?
In basic words, a defect is a fault or mistake in an application that prevents the program's regular flow by mismatching the intended behavior with the actual behavior.
When a developer makes a mistake during the design or development of an application, and this problem is discovered by a tester, it is referred to as a defect.
A tester's job is to thoroughly test an application in order to uncover as many flaws as possible so that a high-quality product reaches the consumer. Before going on to the process and various phases of the problem, it's critical to grasp the defect life cycle.
As a result, let us go further into the Defect Life Cycle.
So far, we've spoken about what a defect is and how it relates to the testing process. Now let's look at the defect life cycle and learn about the defect process as well as the various phases of a defect.
What is the Life Cycle of a Defect?
In software testing, the life cycle refers to the exact collection of phases that a defect or bug passes through throughout the course of its existence. The goal of the defect life cycle is to make the defect repair process more systematic and efficient by conveniently coordinating and communicating the current state of the problem to multiple assignees.
Status of Defects
Bug or Defect Status The current condition of the defect or bug in the defect life cycle is referred to as status. The purpose of defect status is to accurately represent the current condition or progress of a defect or bug so that the defect life cycle may be tracked and understood better.
From project to project, the number of states that a fault passes through varies. The lifespan diagram below depicts all conceivable states.
New − When a new fault is initially documented and publicized, it is referred to as "new." It is given the status of NEW.
Assigned − Once the tester has filed the problem, the tester's lead accepts it and assigns it to the programming team.
Open − The developer begins researching and repairing the flaw.
Fixed − A developer may mark an issue as "Fixed" after he or she has made a required code modification and verified it.
Pending retest − Once the flaw is repaired, the developer offers the tester a specific code to retest the code. The status issued is "pending retest" because the software testing is still waiting from the testers' end.
Retest − At this level, the tester retests the code to see whether the defect has been repaired by the developer and changes the status to "Re-test."
Verified − The tester re-tests the problem after the developer has solved it. If no bugs are found in the program, the problem is repaired, and the status is changed to "confirmed."
Reopen − The tester updates the status to "reopened" if the problem continues after the developer has solved it. The insect goes through the life cycle once again.
Closed − When a bug is no longer present, the tester marks it as "Closed."
Duplicate − The status is changed to "duplicate" if the defect is repeated again or if the defect relates to the same bug idea.
Rejected − If the developer believes the problem isn't real, the defect is marked as "rejected."
Deferred − If the current problem is not a top priority and is anticipated to be resolved in the future release, it is granted the status "Deferred."
Not a bug − A bug's status is set to "Not a bug" if it has no impact on the application's operation.
The Life Cycle of a Defect
The flaw is discovered by the tester.
The defect has been granted the status of new.
A fault is reported to the Project Manager, who will investigate it.
The project manager determines whether a defect is legitimate.
Because the defect is invalid, the status is set to "Rejected."
As a result, the project manager marks it as refused. If the problem is not rejected, the next stage is to determine if it is within the scope of the project. Let's say we have another function, such as email functionality for the same program, and you discover a flaw with it. When such faults are given a postponed or delayed status, however, it is not part of the current release.
The manager then checks to see whether a similar issue has been mentioned before. If the answer is affirmative, the fault is marked as duplicate.
If the answer is no, the problem is assigned to a developer, who begins working on the code. The fault is given an in-progress status at this point.
Once the code has been corrected. The status of a defect is yet to fix.
The code will then be retested by the tester. The defect is closed if the Test Case succeeds. The problem is reopened and assigned to the developer if the test cases fail again.
Consider a scenario in where a fault in a Fax order was discovered during the first release of Flight Reservation, which was repaired and given a status of closed. The identical bug reappeared on the second upgrade release. A closed fault will be reopened in such instances.
Implementing a Defect Life Cycle: Guidelines
Before beginning to work with the Defect Life Cycle, certain fundamental principles should be followed.
The following are the details −
It is critical that the whole team knows the various phases of a problem before beginning to work on the Defect Life Cycle (discussed above).
To minimize future misunderstandings, the defect life cycle should be thoroughly recorded.
To achieve better outcomes, make sure that everyone who has been given a duty linked to the Defect Life Cycle understands their responsibilities completely.
Each person altering the status of a defect should be fully aware of that status and offer sufficient data about the status and the rationale for placing that status so everyone dealing with that fault can readily comprehend the cause for such a defect status.
To preserve consistency across defects and hence in the Defect Life Cycle process, the defect tracking tool should be used with caution.
What is the main distinction between an error, a defect, and a failure?
Error − When developers discover a difference between an application's actual and intended behavior during the development process, they label it an Error.
Defect − A Defect occurs when testers discover a discrepancy between an application's actual and intended behavior during the testing process.
Failure − Failure occurs when customers or end-users discover a discrepancy between the actual and intended behavior of a program during the production phase.
Defect Reports That Are Invalid or Duplicate
When faults arise due to factors other than code, such as the testing environment or misunderstanding, the report should be closed as an invalid defect.
One duplicate report is maintained, while the other is closed as a duplicate. The Manager accepts certain erroneous reports.
The overall Defect Management & Process is owned by the Test Manager, and the Defect Management tool cross-functional team is in charge of handling the reports.
Test managers, developers, project managers, production managers, and other interested parties are among the attendees.
The Defect Management Committee should assess each defect's validity and decide whether it should be fixed or deferred. Consider the cost, dangers, and advantages of not repairing any issue to arrive at this conclusion.
If the fault must be corrected, its priority must be established.
Additional Details on the Defect or Bug
At any moment throughout the Software Development Life Cycle, a fault might be introduced.
The earlier a defect is identified and corrected, the cheaper the total quality cost will be.
When a problem is eliminated within the same phase in which it was introduced, the cost of quality is reduced.
Static testing identifies a flaw rather than a failure. Because no debugging is required, the expense is kept to a minimum.
When a fault produces a failure in dynamic testing, the existence of the problem is exposed.
Writing a decent bug report: Some pointers!
The ability to produce solid bug reports is one of the most critical talents to have in your tester's toolbox. Finding faults is just half the battle; if developers can't duplicate the issues you discover, they'll have a difficult time correcting them. To ensure that testers provide a thorough report of the fault they found, your bug tracking software should contain a number of essential fields. In addition, testers should improve their descriptive abilities.
383 Views
To Continue Learning Please Login