You might be asking why the bug life cycle is such a fascinating subject to write about. We’ve discussed a variety of issues recently, including how to handle testing talent recruitment, how to win over Agile haters, how to create an IEEE compliant Test Plan, and Ken Schwaber’s influence on Scrum.
This diversion usual rank testing themes has been quite enjoyable and educational. We’ve been able to delve deep and address topics that might otherwise go unnoticed.
I’ve had so much fun that I didn’t realize how much I’ve missed going back to the basics of testing. That is, until now.
I’ve recently developed a strong desire to return to blogging about core Software Testing topics.
And now, with this post, I may satisfy my hunger.
In this post, we’ll look at the Bug Life Cycle, which is a fundamental idea in Software Testing. Whether you’re new to testing or a seasoned pro, I’m sure you’ll agree that a refresher on the Bug Life Cycle can’t hurt.
For the more experienced among you, you’ll know that there’s an exasperatingly poor knowledge of the defect life cycle and how a problem progresses from one step to the next in everyday project execution. Your project team’s lack of knowledge with Defects Management methods can result in unneeded pains at critical times, repeatedly delaying and frustrating deployment efforts.
So, let’s get down to business and examine the Defects Tracking Life Cycle. We’ll also look at some of the variants and market practices that can help you get the most out of it.
If you’re new to testing, this article should help you understand the basics of the Bug Life Cycle.
If you’re a seasoned tester or test manager, this is a great opportunity to brush up on essential ideas and discover where you can improve your current testing procedures.
I also hope that if you are a team manager, you can use the information here to educate your team members.
Let’s get started, shall we?
What is Bug Life Cycle?
Bug Life Cycle, in basic terms, refers to the many steps that a bug or defect goes through before being closed or fixed. When a defect is discovered – whether by a Tester or someone else on the team – the life cycle gives a concrete mechanism to track the bug fix’s development.
Many people come into contact with a bug at some point during its existence — either directly or indirectly. It isn’t always the job of a single person to fix a flaw. Various project team members will be responsible for the bug at various phases of the life cycle.
Bug vs Query
There is a fundamental distinction between a bug and an inquiry. And we need to get it over with as soon as possible.
An error in the system is referred to as a bug. When a test case’s expected outcomes are compared to the actual results when the test case is executed, a defect is identified. Expected results are determined from the system’s requirements.
An inquiry is exactly what it says on the tin. When a tester (or anyone testing) comes across a system behavior, they should usually examine ‘What is the requirement here?’ This could be because the specific system behavior isn’t explicitly stated as a need. Or hasn’t been documented as a test case before. Alternatively, for any other purpose. The tester may raise a Query if they believe it is critical to understand expected behavior for that test instance.
A Query can now result in a variety of outcomes:
- It’s possible that the Product Owner realizes there’s a requirement gap, in which case it becomes a Requirements Defect.
- Because the observed behavior appears to be consistent with the original requirements, the Query may be closed.
- Because the observed behavior differs from what is intended, the Query is classified as a Functional Defect.
A Query, as long as it is a Query, does not enter the Bug Life Cycle. When the Query is re-assigned as a Defect, it will do so.
What is the significance of this?
Time and time again, I’ve seen Queries raised as a Bug, resulting in a lot of wasted time for everyone concerned. Queries that are wrongly logged as Bugs generate a lot of angst and time wasted on non-priority topics, especially on large and complicated projects that typically handle hundreds, if not thousands, of faults.
So, before you log anything, think about whether it’s an inquiry or a bug.
Happy Path vs Optional vs Exceptions
Before we delve too far into the complexities of the bug life cycle, I’d want to talk about ‘Happy Path’ for a moment.
Software Testing would be ideal in a basic and uncomplicated world. Every flaw that is raised would be spot on in that simple and uncomplicated world. And all of the flaws will be repaired before the release.
The Happy Path bug life cycle is all you’ll need then. A bug’s progress from New to Assigned to Fixed to Pending Retest to Closure is represented by the Happy Path. In the actual world, a lot of bugs do follow that path.
But the world isn’t flawless. There are faults that do not follow the joyful road – a considerable number of them. There are several causes for this.
- Defects are wrongly raised.
- Defects aren’t usually fixed in the same release that they were reported in.
- Flaws are discovered to be copies of other defects.
- Defects that have been marked as ‘Fixed’ remain in the system.
Such flaws do not lead to happiness. They are unable to follow the bug life cycle’s pleasant route. As a result, you’ll need a more robust life cycle that takes into account unusual circumstances.
We’ll go over the Happy Path Life Cycle stages, as well as Optional and Exceptional ones, in this piece. As a result, you’re ready for anything.
New
It’s that simple!
This is the point at which a bug is discovered and recorded in the system (insert your favorite QA tool). By this point, the tester should be able to distinguish between a query and a defect. Alternatively, a question has been confirmed as a flaw.
It’s important to remember that anyone can report a defect; it doesn’t have to be a tester.
Assigned
What distinguishes Assigned from New? There is a reason for this.
While anybody can report a flaw, not everyone can also fix it. A flaw can be the fault of any one of a number of project stakeholders – both direct and indirect – depending on a variety of variables.
Let’s imagine you’re developing a mobile banking app that gives customers access to all of their accounts and notifications in all of the countries where they bank with you. The mobile app development team is in charge of creating a single front-end experience that unifies internet banking access for all of the customer’s accounts across all countries.
A fault may be noticed in the global accounts view, where a customer’s credit card with your bank in one of the nations is not visible. The problem may not be in the front end (app) at all in this situation. It could be a back-end issue, with the worldwide customer database failing to store the customer’s credit card information with your bank for that specific country. While the bug affects your mobile app development project, it is ultimately the responsibility of stakeholders outside the project team – specifically, the folks who oversee the worldwide customer database system.
As you can see, reporting a defect is not the same as determining who is accountable for fixing it. And this process of identification necessitates both knowledge and competence in the systems and players involved.
This is why identifying a new bug is nearly always followed by Assigned. So, while everyone can report a new fault, not everyone will know and comprehend who is responsible for resolving the issue right away. We allow new faults to be raised and afterwards allocated as an independent activity by giving it its own status.
Fixed
When a defect’s owner or responsible party is assigned, they begin the process of correcting the problem. Technology, skill sets, and a variety of other elements all play a role in how they do it.
When the owner has found and implemented a solution to the bug, they label it as ‘Fixed’ and move it on to the next stage of the life cycle.
Pending Retest
A Development Lead or Tech Lead is normally in charge of this. The Tech Lead is tasked with examining the fix and updating the problem’s status to Pending Retest once the Assigned party fixes a bug and marks it Fixed.
It exists for a reason: to serve as a backup. Use it to ensure that your team keeps track of problems that haven’t been repaired properly before they go public and embarrass everyone.
Deferred
The Deferred status is one of the more unusual statuses, however it is used rather frequently on software projects these days. It’s not uncommon to have tens, if not hundreds, of defects postponed or deferred to later releases, especially if you’re working on major projects.
You might wonder why.
It is debatable. Only major problems that stop stock trips need to be repaired if your team is iterating a new product at rapid speed. You won’t want to release the product until it has a minimal feature set (a topic for another article), and you might want to wait until the MVP is complete before polishing it by fixing medium or low priority bugs. As a result, it’s acceptable to enable the medium to exist.
Alternatively, you can have low- or medium-priority defects that don’t affect the user experience even if you go live with them. When you’re seeking to get into beta testing, for example.
Note: High and critical priority issues cannot and must not be delayed by definition.
Verified (after Pending Retest)
This is more of a mezzanine floor that works as a breakaway area before you reach the landing, and it is an optional status. I wouldn’t recommend adding this to your bug’s life cycle. This one, on the other hand, is for you if you require a speed breaker that allows you to halt and study each bug before it is rapidly closed.
If all circumstances are met, a Tester who retests a problem that has been moved to Pending Retest will move the bug to Verified. For an unskilled Testing team, this could be a safeguard.
Closed vs Resolved
After they’ve been retested, this is where bugs end up. You can ask Test Leads to own the task of checking a defect that’s been moved by a Tester to Verified and pushing it along to the Closed status when they’re satisfied, or you can ask them to own the task of checking a defect that’s been moved by a Tester to Verified and pushing it along to the Closed status when they’re satisfied, just like with the Pending Retest after Fixed.
Rejected, Duplicate, not a Bug, Query
I’m not sure why I’ve grouped these probable outcomes together. Because they all mean the same thing: for various reasons, a bug isn’t truly a bug.
It’s possible that the tester wrote and ran a test case that didn’t conform to the original requirement, then filed a bug report based on their (incorrect) predicted outcomes. You can either reject the bug or label it as Not a Bug.
It’s possible that the tester is in fact submitting a Query to the Business Analyst or Product Owner. It’s possible that they’ll mistakenly log it as a bug. You have the option of rejecting the bug or moving it to the Query status.
It’s possible that the bug is a duplicate of another bug found in the same – or a different – test cycle. You might want to just Reject the bug outright. Alternatively, you could transfer it to Duplicate and link it to the original bug you’re trying to trace. The latter option is a wonderful concept for tracking and reporting the amount of time and resources spent on overlapping, redundant, or duplicate testing.
Re-opened
Oh, this is my personal favorite out of all of them!
As I’ve stated before, testing is the responsibility of everyone, not just the testers. You must test your remedy before pushing it along the conveyor belt, especially if you’re responsible for fixing a bug.
You’d think that because the statement above is so straightforward and rational, people would automatically follow it. You’d be mistaken.
I’ve seen it time and time again how developers and other bug-fixing personnel rush to return a test case to Fixed status without first double-checking their work. Worse yet, if the bug is also moved to Pending Retest. That’s (possibly) two persons that didn’t bother to do the bare minimum to see if there was a problem.
The tester must then devote significant time to ‘rediscovering’ the bug and reverting it to Re-opened with annoyance. Why wouldn’t they be annoyed?
All things considered, when a problem is re-opened, it necessitates immediate attention because it reeks of poor quality on the part of the ‘fixer.’ It’s frequently discovered through a Defects Analysis for feedback and performance enhancement.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html