The Defect Expiration Date

(Originally Posted on CrossBrowserTesting.org) To understand how to reach a zero defect status quo, think about defects like you might think about bread. Bread is the absolute best right out of the oven. Slather it with butter and pop it into your mouth. It’s heaven. The worst bread can get is when it’s molded over and completely inedible, but it can also be helpful. 

Defects are often seen as bad things. That’s not necessarily true. Defects tell you something about what’s going on with the state of the application. If defects were to equal hot, tasty bread you pop right into your mouth, would you think about avoiding them? Maybe, maybe not. 

There are probably plenty of reasons to avoid bread. Allergies. Carbs. Gluten tolerance. Those reasons are absolutely respected. Replace the idea of bread with anything that works just as well. Suggestions are welcome!

Measuring The Freshness Of A Defect

Let’s consider the bread analogy a little further. Bread goes through states of change. That’s how we can talk about piping hot bread and moldy bread. Now if I shift that to talking about defects using a bread timeline it looks something like this:

Bread vs Defect

Hot Out Of The Oven	Less Than An Hour Old
Fresh	Less Than A Day Old
Stale	Less Than 2 Weeks Old
Moldy	More Than 2 Weeks Old
Is It Still Bread?	Older Than A Month

Looking at defects with a very visible time measurement makes them valuable in gauging the health of an application. 

If you have a low number of defects waiting for a while due to complexity or dependencies, that’s probably OK. If you have a large number of defects that could have been resolved within hours of them being found but they are so stale no one really knows if they are still defects, then that would indicate there are some issues in how defects are being handled. 

It’s a balancing act. You want to handle each one correctly and in their own time, but trying to discover what that time frame is and how quickly it needs to be handled is always a trial and error approach. The best way to start surfacing wait times and delays would be to create some rules around defect types or flavors. 

Here is an example of some defect flavors and handling rules to go with them:

Severity (functional issues usually)

▪  High – don't log it–fix it!

▪  Med – log it (but make the logging relevant - make a new story.)

▪  Low – why bother logging it? Note it on the current story card and move on.

Priority (business rules issues usually)

• ▪  High - Get it into a sprint stat! ▪  Med – Put it into the next sprint or you might as well delete it. ▪  Low – ask a PM. If they don't care, don't bother. Note it somewhere and move on.

Relevance (relation to current feature work/business goals)

▪  High – Three Amigos time – make a decision and go with it. ▪  Med – Next standup – make a decision and go with it. ▪  Low – If there isn't a stakeholder, even a hidden one, no defect needed.   Note it in your testing logs and move on.

There should be some initial discussion about what defects are ranking where. That’s important. 

Also note that the information should be documented somewhere, either in testing logs or the story card. 

Don’t let the information get lost. If the defect suddenly becomes relevant or someone wants to know why no one found it before, you can point back to your logs or a story and then move it into a card or a defect management system. Before that point, defects that don’t rank high enough are only creating noise. 

Why Defect Backlogs Cost Money And Time

On a maturity model for a company, one of the things that can be seen as a sign of development lifecycle maturity is how quickly and efficiently defects are handled. 

If you are not using a zero defect approach of immediately resolving or working towards resolving your defects; you, your team, or management are probably engaged in doing two or three of these things:

 

• A triage meeting to groom the defects which haven’t been resolved or are not in flight

• Maintaining a backlog which needs updating and managing 

• Paying or upkeeping a defect management tool (If you are only using story cards, you are moving in the right direction).

If no one is reviewing defects or maintaining them, the management tool and the backlog are basically where defects go to die. The company engaged in this unfruitful process is wasting money and time. It’s an act of literally writing something that will never be used into a tool that the company is paying for, whether that’s an open source tool on a server or a cloud product, which has no meaning to anyone because no one is looking at it. 

Defect backlogs or management systems are only helpful if they are kept current and folks are reviewing them on a regular basis. This costs money to have meetings, upkeep tools, and make sure defects are being handled properly. This method can cost more than the leaving the defects to die because people are engaged in the process. That’s OK. When there is complexity or necessity, this isn’t a bad process to have, but it’s a lot to maintain and threatens slipping back into the habit of the defect graveyard.

Moving to a zero defect process can do a couple of things for a software development lifecycle.

 

1. It lets people quickly make a decision about how to handle the defect. 

2. It uses the original story as a reference for the bug OR turns the defect into a story which goes into the backlog for a sprint and is handled like a STORY instead of a defect.

3. Defects passed to teams from other teams like Customer Service have an answer immediately instead of waiting for someone to tell them it’s fixed, they know it will be resolved by the next release, or never.

Setting Standards For A Zero Defect Process

The goal of a zero defect process is to reduce the time in the backlog or management of a defect to zero by either fixing, converting, or closing the defect. Using the example standards above you’ll want to target at least three areas for setting standards for the following defect types:

• Defects which originate from within the team

• Defects which originate from external teams but involve your team

• When a Defect presented (either internal or external) is changed to a story or closed.

Enhancements Are Not Defects

Some organizations like to lump enhancement requests in with defects, mostly because they are generated from the same place, the customer. 

When a customer asks for an enhancement request, that information shouldn’t be hanging out in a defect management tool or story backlog, it should be handled with a weekly report or some kind of hand off to the Product Management folks. Leaving it in a backlog means that someone is missing trends, customer requests, or possibly the next big feature idea. 

Customers can ask for some pretty crazy things, but if your business model is centered around reporting and they are asking for a reporting feature, it might be important to tell someone rather than write a bug and close it as “enhancement request.” 

Find a different handling method for those requests. Get Product Management to reply to customers directly. You’d be surprised how much customers like being acknowledged even if they know they aren’t going to get exactly what they wanted.

Always Have A Plan

Whether you are moving towards a zero defect practice or dealing with defect graveyards, having a plan is better than no plan at all. Communication is very key in dealing with any defect of any severity. Create standards, tweak them, change them when they stop working, make every effort to make backlogs and graveyards disappear. 

Another alternative is to go for the radical option and declare defect bankruptcy and start over! At least then it would be a clean slate for your team or all the departments that want to take that route. 

Are there other methods or approaches which have led you to a zero defect practice? Comment here or blog about them. It’s not impossible. It’s much like losing weight or going gluten free, you need to commit to the process and move forward, that’s the only way it gets better.