Release More Defects

What do you think is the biggest thing that holds back the quality of your product? Is it poor code quality?  insufficient testing? Not enough time for testing? Missing designs? Manger, tester or developer apathy? If you had to pick one thing, what would it be?

I don’t know if this is the biggest thing, but one threat to product quality is an inability to release defects.

Stay with me ok? I’ll explain what I mean!

As a tester I’m about making this world a better place one dead bug at time, and in order to kill those bugs you need a few things. You need to find the bug, you need to know that it is making the world a worse place, and you need to get rid of the bug somehow.

Bugs can be very sneaky. Sometimes it’s easy to find them, but let’s be honest, the sheer number of testers employed in the software industry is a good indicator of how hard it can be to find bugs. They like to hide in the most unexpected places and appear at the most unexpected of times.

And there are a few other things you should know about bugs. For example, not all of them make this world a worse place. You can have a bug (something like a logic error) in some code that doesn’t get used and the world couldn’t care less.  You can also have a bug that doesn’t look like a bug. It might be working as designed, but the designer and the user have different perspectives as evidenced by the number of swear words coming out of the user’s mouth. This boils down to the fact that bugs involve a complex relationship between software and humans. It is very hard to know what kinds of bugs make this world a worse place. In fact, just to make things more complicated consider the fact that sometimes a bug for one person is a feature for another!

Customer

So these things leave testers with a challenge. If we fix (or advocate for fixing) the wrong bugs we aren’t achieving our mission. If we miss finding a bug at all, well pretty clearly we aren’t going to get rid of it.

Enter Stage Left: The Customer.  This is the person who’s problem our software system is solving.  This is person who’s life we want to make better. It is through helping and serving this person that we are making the world a better place. This is the person who is the ultimate arbitrator of what in your system is a bug. A bug your customer doesn’t run into isn’t really a bug at all.  A bug your customer doesn’t care about doesn’t make the world a worse place. The customer is the one who should decide what bugs you spend time fixing.

So how do you improve the quality of your product? You fix the problems that your customers care about. Sometimes it is pretty easy to hypothesize that your customer will care about something. A security vulnerability for example. Other times, it is much harder to know. How are they even going to use the product? Is this issue I found going to be relevant? Part of the calling of a good tester to is be able to come up with reasonable answers to those questions. This means we need to put ourselves in the shoes of our customers.  We need to figure out how to think like them and see the product through their eyes.

Tools

If this is indeed one of the primary challenges of the testing profession (and I think it is), what are some tools we have at our disposal to help us with this? Is it all just guess work, or can we approach it in a bit more of a scientific way?  The truth is there are some really good ways to learn more about what your customers care about.  There is a lot of new technology that can help with this, but don’t forget about some of the tried and true methods. There are ways to learn about out customers that we have had for many years. Customer service representatives for example. Or your competitors products.  Why are people buying them? What do they have that you don’t? Then there are customer surveys and usability studies and external bug logs and customer posts on forums, blogs and social media….and the list goes on.

I already mentioned new technology and so let’s not forget about this. We have tools like telemetry and data analysis that can help us answer questions about customer quality. We can log and analyze errors, and automatically alert based on them. We can use tools build right into our cloud hosting systems that give us real time information on what our customers are doing. There is the potential for reams of data that can help us in this quest to figure out what things are causing issues for our customers.

There are many, many places that we can mine for information about the things that our customers really care about, but how does this all relate back to releasing more bugs? Well, remember those tough questions we have to try and answer as testers? The questions about if a bug is really a bug and if it worth fixing?  Well, we know the customer is the best person to ask those questions to right? and letting them see or experience the bug is the best possible way to figure out if it matters to them.  If we think of it this way a released bug isn’t a horrible blight on your ability as a tester, it is a way of asking the questions you need to ask so that you can figure out things you just don’t or can’t know.

Caveats!

I’ve just proposed a controversial thesis, and maybe you buy it or maybe you don’t, but let’s talk together for a few minutes about how to make this strategy work. I hope I have already made it clear that this strategy isn’t for every bug.  The purpose of it is to help you answer the question on those bugs where there is controversy about the ROI to find or fix it.

There is another important caveat though.  If these are a way of asking your customers a question, you need to be able to respond to them with an answer.  If you ask your customer, is this a bug? and the answer clearly comes back as yes! then you need to respond to that and you need to respond quickly.  This is where the technical side of things comes into play.  You know those boring things called release pipelines? Yeah, they are a really important part of this whole process. You need a release process and build pipeline that allow you to respond effectively to the answers your customer are giving you.

In fact, I think the speed with which you can turn around a change, (I would define this as the amount of time your customer is exposed to the issue) dictates the kinds of bugs you can be ok with releasing. If you can turn around a change in minutes or seconds, you can be ok with more serious bugs getting out there. You can also be ok with it if you can limit the number of people affected by it.

We shouldn’t think of testing as a one size fits all process. Your build pipeline actually influences the kind of testing you need to do. The longer the turnaround time the more effort you need to put in up front in finding issues. If you can quickly detect and remedy issues that you customers find, you can actually take a lot less time up front on testing for certain types of issues.

But why do this?  I think it comes down to efficiency.  We want to more effectively and efficiently add value to our customers and taking an approach like this allows us to do that. We will spend less time finding bugs that our customers don’t care about and we will also be able to more quickly find and know about the ones that do matter. This frees us up to spend more time in adding value in other ways.

Now one last caveat and then I’ll close out this article. This doesn’t come for free. Getting your build pipeline to allow for this kind of fast turnaround can be a long and difficult process. Having the monitoring and alerting in place that allows you to actually know what things are affecting your customers is a challenging and time consuming thing (especially at first).  I don’t want to pretend that what I’m talking about here is some fairy land of magic and rainbows where you don’t have real trade-offs. I am arguing that this effort is worth it in the long run (for many companies).

We can often pursue the latest and greatest thing as if it is some kind of magic pill that will solve all the world’s problems (or at least the ones in our software department). The reality is the things I am talking about in this article can (and do!) work, but they need to be done well. They won’t work if we are trying tack them on top of old ways of working. They require mindset shifts and changes in our processes. This is why I talk about it in terms of being able to release more defects. Using these tools effectively will require counter-intuitive thinking. Embrace that and move forward. Pursue the ability to release more defects!

 

Photo by Ankush Minda on Unsplash