The Lifecycle of a Testing Bug
The Lifecycle of a Testing Bug
There are many different phases when testing a bug.
Join the DZone community and get the full member experience.Join For Free
A software bug is an error or fault in a computer program making it behave in unexpected ways. Bugs can be present at any stage during SDLC (software development lifecycle), or at the design, development, or user-acceptance testing phase. Whether you are testing a web portal for general bugs or for browser-compatibility issues, proper understanding and elimination are necessary.
Bugs can never be eliminated completely. No software can turn out to be 100 percent bug-free. But the testing team can adopt certain practices so that the elimination of bugs from software becomes easy. A good management system ensures that most bugs are found and fixed well before it enters production. If the testers and developers work efficiently, the time period from a bug’s discovery to its abolition can be minimized.
Defect lifecycle, also called the bug lifecycle, is a specific convention of states through which a bug passes beginning from the phase of discovery to defect fixation. The number of states that a defect is meant to pass through varies from organization to organization and project to project. The following are the basic stages of the lifecycle of a bug:
When a bug is first detected in an application, it is assigned a status called ‘New.’ This implies that the defect found is yet to be approved or studied. Following this, proper defect documentation is submitted to the development team so that they can reproduce and fix this defect. This ‘New’ defect further undergoes many status updates.
The defects assigned a status ‘New’ are further put through approval study by the test lead, project lead, or development lead to check if it is valid or not. In case the bug is found valid, it is assigned to a member of the development team. This is where the ‘New’ status is changed to ‘Assigned.’ The developer further fixes this defect and updates the status to ‘Complete.’
At this stage, the development team begins scrutinizing the bug. After the ‘Assigned’ stage, or at this level, the bug is further categorized into states such as Duplicate/ Deferred/ Dropped/ Not a bug.
At times, the ‘Assigned’ bug status may be updated to ‘Deferred’ by the lead. This happens due to the following reasons:
- If the bug is found to have a minor or unimportant fix, or if it is found at the end of a release.
- If the bug is not associated with the current build.
- If the defect seems to get fixed by the next release.
- Often, the customer thinks of changing the requirement. Thus, the status is changed to “deferred” and planned to be fixed in the next release.
Dropped or Rejected
If the bug assigned or opened is logged due to certain misinterpretation (a reference to some old requirements or features), despite the system working in accordance with the specifications, then the team lead marks such a bug as ‘Rejected.’ Along with the status update, the team lead should provide a specific reason for the above action.
A defect that is repeated or is corresponding to the same concept of the bug is changed from the ‘Opened’ status to ‘Duplicate’ by the development team.
Once the necessary changes in the code are performed and verified by the developer, then the status of the bug is changed to ‘Fixed.’ This bug is then passed onto the testing team.
Once the developer has fixed the defect, they submit part of the code for retesting. Since the test is to be performed on the tester’s end, it holds a ‘Pending Retest’ status.
The tester performs retesting at this stage to check the existence of the defect fixed by the developer and alter the status as ‘Re-test.’
If the defect is found to exist fully or partially after the retest, then the tester updates it using defect retesting document with the status back to ‘Reopen.’ Again, the bug is driven through the same procedure lifecycle to be fixed and completed again.
Luckily, if after retesting the bug fixed by the developer no defect is spotted in the software, then the bug is said to be fixed and the status assigned at this stage is ‘Verified.’
If the tester or lead finds that the bug no longer exists, then the status of the bug is changed to ‘Closed.’ This makes the end of the bug life cycle.
At times certain, variations are found related to the statuses in the cycle. These can include:
- Cannot be fixed: If the bug is not technology supporting, or there is a certain problem of the product the status of a bug is termed as ‘Cannot be fixed.’ Sometimes, this happens if the cost of fixing a bug is high.
- Need more information: If a developer is not able to coordinate with the tester by working according to the assigned steps, then the developer changes the status to ‘Need More Information.’
Although most companies prefer to work on preventing a defect, which is more effective than decreasing the number of defects, following a structured plan to remove bugs has proved to be helpful across many organizations.
Published at DZone with permission of Arnab Roy . See the original article here.
Opinions expressed by DZone contributors are their own.