Bug Life Cycle – Quick Guide to Defect Life Cycle

You might be wondering what makes bug life cycle an interesting topic to write on. We’ve covered varied topics of late, from how to handle recruitment of Testing talent, to winning over Agile Haters, to creating an IEEE compliant Test Plan and the influence Ken Schwaber’s had in shaping Scrum.

This detour from rank testing topics has been quite fun and interesting. We’ve been able to dig deep and cover areas that normally don’t get the attention they’re due.

I have had so much fun, that I didn’t realise how much I’ve missed going back to classic Testing topics. Until now, that is.

Of late, I’ve begun craving an opportunity to go back to writing about fundamental Software Testing concepts.

And with this post, my craving gets a release.

In this post, we’ll take a close look at an inherently fundamental Software Testing concept – the Bug Life Cycle. Whether you’re nouveau or a master in Testing, I’m sure you agree that a quick review of the Bug Life Cycle can only help.

For the experienced amongst you, you’ll know that in everyday project execution, there’s an exasperatingly poor understanding of the life cycle of a defect, and how a defect moves from one stage to the next. Inexperience with Defects Management processes on the part of your project team can result in unnecessary pains at key moments, constantly delaying and frustrating deployment efforts.

So we’ll get down to look at how the Defects Tracking Life Cycle works. We’ll also consider some of the variations and market practices that help maximise the benefits it offers.

If you are relatively new to testing, this post should help educate you in the fundamentals of the Bug Life Cycle.

If you’re an experienced Tester or Test Manager, this is a good refresher to brush up on key concepts and see where you might be able to tweak your current Testing practices.

And, if you are a team manager, I hope you can use the information here to educate them.

Let’s jump right in, shall we?

What is Bug Life Cycle?

In simple words, Bug Life Cycle represents the various stages a bug or defect passes through before it can be closed or resolved. When a bug is detected – by a Tester or anyone else in the team – the life cycle provides a tangible way to track progress of the bug fix.

During the life of a bug, many individuals touch it – directly or indirectly. Resolving a defect isn’t necessarily the responsibility of one individual. At various stages of the life cycle, various project team members will be responsible for the bug.

Bug vs Query

There is a basic difference between a bug and a query. And we need to get it out of the way soon enough.

A bug is an error in the system. A bug can be deemed a bug by comparing expected results of a test case versus the actual results when executing the test case. And expected results are derived from the Requirements for the system.

A query is just that – a query. Usually, a tester (or anyone that is testing) may want to check ‘What is the requirement here?’ when they encounter a system behaviour. This might be because the particular system behaviour isn’t documented clearly as a requirement. Or hasn’t been previously documented as a test case. Or for any other reason. If the tester feels it is important enough to understand expected behaviour for that test case, they may raise a Query.

Now, many things can happen with a Query:

• The Product Owner may realise it is a miss in the requirement, in which case it becomes a Requirements Defect.
• The exhibited behaviour may be deemed to be consistent with original requirements, so the Query could be Closed.
• The exhibited behaviour may be deemed to be different from expected behaviour, so the Query becomes a Functional Defect.

Note that a Query does not enter the Bug Life Cycle as long as it is a Query. It will do so the moment the Query is re-assigned as a Defect.

Why is this important?

Time and time again, I’ve seen Queries being raised as a Bug, and result in a ton of time being wasted by all involved. Especially on large and complex projects that usually handle hundreds, even thousands of defects, Queries that are incorrectly logged as Bugs cause of a lot of heartburn and time wasted on non-priority items.

So be mindful of analysing whether something is a query or bug before logging.

Happy Path vs Optional vs Exceptions

Before we get too deep into discussing the intricacies of the bug life cycle, I’d like to dwell on ‘Happy Path’ a little bit.

In a simple and uncomplicated world, Software Testing would be perfect. In that simple and uncomplicated world, every defect that is raised would be spot on. And every one of the defects will be fixed before release.

All you need, then, is the Happy Path bug life cycle. The Happy Path represents a bug going from New to Assigned to Fixed to Pending Retest to Closure. And a lot of bugs in the real world do follow that trajectory.

But it isn’t a perfect world. There are defects – a significant number of them – that do not follow the happy path. For a number of reasons.

• Defects are raised incorrectly.
• Defects are not always fixed within the release they were raised.
• Defects turn out to be duplicates of other defects.
• Defects that are marked as ‘Fixed’ continue to persist in the system.

Such defects don’t follow the happy path. They cannot follow the happy path bug life cycle. Hence, you need a more robust life cycle that accounts for exceptional scenarios.

In this post, we’ll cover the Happy Path Life Cycle stages, as well as Optional and Exceptional ones. So you’re prepared for any eventualities.

New

Quite elementary!

This is when a bug is identified and logged in the system (insert your favourite QA tool). Ideally, by this time, the tester knows to differentiate between a query and a defect. Or, a query has been confirmed as a defect.

Remember, anyone can raise a defect – it doesn’t have to just be a tester.

Assigned

Why is Assigned different from New? There is a reason.

While anyone can raise a defect, not everyone can fix a defect. Depending on a varied set of factors, a defect can be the responsibility of any one of a number of project stakeholders – both direct and indirect.

For instance, let us say you’re building a mobile banking app that allows a customer access to all of their accounts and notifications across all the countries they bank with you. The mobile app development team have the responsibility to build one single front-end experience that brings together internet banking access for all of the customer’s accounts in all the countries.

To do this, however, the team may need access to a global customer database that pulls all of a customer’s relationships into a central repository. This may already exist (if you’re a multinational bank, I’m sure it does).

A bug could be discovered with the global accounts view – where a customer doesn’t see the credit card they hold with your bank in one of the countries. In this case, the defect may not lie in the front end (app) at all. It could be identified as a back-end issue and could point to the global customer database not storing the customer’s credit card information with your bank for that particular country. So while the bug affects your mobile app development project, it is really the responsibility of stakeholders that may sit outside the project team – namely, the people that manage the global customer database system.

As you can see, raising a defect isn’t the same as identifying the responsible party to resolve the defect. And this identification process needs both experience and expertise in understanding the system(s) and the players involved.

This is why Assigned is (almost always) a separate task to identifying a New bug. So while anyone can raise a new defect, not everyone can know and understand immediately who is responsible to resolve the defect. By giving it a status of its own, we allow new defects to be raised and later assigned as an independent activity.

Fixed

When an owner or responsible party for a defect is Assigned, they then set about to fix the defect. How they do it is down to technology, skill set and various other factors.

And when the owner has identified a solution to the bug and implemented it, they then mark the bug as ‘Fixed’ to move it to the next stage in the life cycle.

Pending Retest

This one is usually the job of a Development Lead or Tech Lead. After the Assigned party fixes a bug and marks it Fixed, The Tech Lead is tasked with reviewing the fix and changing the status of the bug to Pending Retest.

It exists for a reason – to act as a failsafe. Use it to ensure your team track bugs that haven’t really been fixed before they get out there and embarrass everyone.

Deferred

One of the exceptional statuses, but the Deferred status is invoked quite regularly on software projects these days. Especially if you’re working on large undertakings, it is quite common to see tens, even hundreds, of defects postponed or deferred to later releases.

Why, you ask?

It depends. If your team are iterating a new product at breakneck pace, only critical bugs that block stock journeys need be fixed to keep moving forward. You won’t want to release the product till a minimum feature set (Minimum Viable Product – one for another blog) is built, and may want to wait till the MVP is achieved to polish the product by fixing medium or low priority bugs. So it’s okay to allow the medium or low bugs to keep getting carried over.

Or, you may have non-priority medium or low bugs that don’t hamper customer experience even if you go live with them. Or when you’re trying to go to beta testing.

Note: By definition, high and critical priority bugs cannot and must not be deferred.

Verified (after Pending Retest)

An optional status, this is more like a mezzanine floor that acts as a breakout area before you reach the landing. I don’t recommend complicating your bug life cycle with this one. Yet, if you need a speed breaker that allows you to pause and examine every bug before it is hurriedly closed, then this one is for you.

If employed, a Tester that retests a bug that’s been moved to Pending Retest would then move the bug to Verified if all conditions are met. This could be a failsafe for an inexperienced Testing team.

Closed vs Resolved

This is where bugs end after they are retested. You can either have the tester move the bug from Pending Retest to Closed directly, or as with the Pending Retest after Fixed, you can ask Test Leads to own the task of checking a defect that’s been moved by a Tester to Verified, and push it along to the Closed status when they’re satisfied.

Rejected, Duplicate, Not a Bug, Query

Why have I grouped these possible statuses together? Because they all represent the same thing: a bug is not really a bug – for varied reasons.

It might be that the tester created and executed a test case that doesn’t follow the original requirement, and logged a bug based on their (incorrect) expected results. You could Reject the bug – or call it Not a Bug.

It might be that the tester is really registering a Query for the Business Analyst or Product Owner. They might log it incorrectly as a Bug. You can Reject the bug, or move it to Query status.

It might be that the bug is a duplicate of another bug identified within the same test cycle – or different test cycle. You might want to just plain Reject the bug. Or better yet, you may want to move it to Duplicate, and link it back to the original bug to track. The latter option is a brilliant idea to track and report the amount of overlapping, redundant or duplicate testing that precious time and resource is spent on.

Re-opened

Ah, my favourite among them all!

Testing, as I’ve repeatedly said, is everyone’s responsibility – not just the tester’s. Specifically when you’re responsible to fix a bug, you must test your fix before moving it along the conveyor belt.

You’d think the statement above is so simple and logical that people would intrinsically follow it. You’d be wrong.

Time and time again, I’ve observed how developers and other individuals responsible for fixing bugs hurriedly move a test case back to Fixed without first verifying their handiwork. Worse, if the bug is moved along to Pending Retest as well. That makes (potentially) two people who didn’t put in the minimum effort necessary to quickly check if everything’s all right with the fix.

It is the tester then that has to spend their valuable time to ‘rediscover’ the bug, and move it back to Re-opened with frustration. Why wouldn’t they feel frustrated?

All things said, when a bug goes to Re-opened status, it automatically demands a lot of attention – as it reeks of poor quality on the part of the ‘fixer’. And is usually picked up during Defects Analysis for feedback and performance improvement.

---

Now It’s Your Turn

There could be variations to the defect/bug life cycle I’ve presented above. You might follow one of these variations. And that is okay!

The key to remember, is that the bug life cycle helps everyone prioritise their time towards fixing the most pressing bugs at that moment in time, to move your project along. Design a process that works for your situation, team, project, methodology, technology, organisation. Customise where necessary but then, don’t go overboard. The life cycle exists to optimise your team’s effort – not add to it unnecessarily. Lean and mean is the way to go!

What do you think about this post? Have you encountered other variations and statuses for the bug life cycle? Comment below to let others know!

Found this blog helpful? I’m glad! How about clicking the ‘share’ button as a vote, and to benefit your friends and colleagues?