Blog

Magnificent Bugs and Where to Find Them

Posted by Aleksandar Ristić on Feb 13, 2018 3:04:41 PM

Have you ever been asked if you can achieve zero bugs in a product? A younger me would have laughed and said it’s not possible, but not all projects are the same. We once worked on a military project where budgeting is on another level and where there was no expense spared starting from documentation and planning (both under heavy testing and monitoring). Or you might be dealing with the medical industry, where a bug doesn’t mean an angry customer but the difference between life and death.

But in most regular projects…

There is simply not enough time to test everything you want and you need to learn where to focus and look for bugs.

A common mistake that occurs in test planning is that planning itself is being done by using input from small number of people working on your team. And when you use that approach, you are cooking without an important ingredient! Let me elaborate …

The Pareto principle states that 80% of the effects comes from 20% of causes. In our world that means that 80% of your customers are using 20% of your features. It also means that 20% of your code is hiding 80% of the bugs. That doesn’t mean that you will test only that 20% of code, but if you can locate it then you should definitely make sure to cover it properly.

Customers from different industries are paying attention to different parts of the product – for example, gamers see graphic as extremely important while gamblers like nice graphics but are more focused on the mathematics. If you are building storage systems, your customer might be happy with an API (without a UI) just as long as they can be 100% confident that their backup is safe. So, you need to find what is the most important aspect of your product to your customers before you start planning how and where to test!

Of course, you could go out and talk to them or you could rely on your own colleagues – the support team!  

Talk to them and find out which areas/features receive the highest numbers of complaints. That probably means that your customers are mostly using those areas and that’s where you need to focus. Using this data, build the map (product features/modules – testing levels – number of submitted issues) and see where you need to increase coverage. Perhaps you could use something like this …

 

Component 1

Component 2

Component 3

Product A

25

2

10

Product B

28

1

12

Product C

22

3

13

It is obvious that Component 1 needs more testing, and as you move forward, every new feature that will be developed in that area will require more detailed testing.

Another important thing - now that you are using support input in planning, start tracking how things are changing in the number of complaints in support forms between releases.

There is another side benefit to this. Support is one of the most stressed positions in most companies. Asking them for input will certainly help you understand the importance of the position – not only are they fixing customer’s problems, they are also an important factor in building the future quality of the product.


 So, when was the last time you talked to your support team? Ask them what is the first thing that pops into their mind when a new bug appears – ‘Who tested this’ or ‘Who coded this’? :)

 

Topics: Software Testing, Tips and Tricks, Zero Bugs

HITCHHIKER’S GUIDE TO AGILE TESTING & RANDOM THOUGHTS BY ALEKSANDAR RISTIC 

Whether starting or experienced test engineer, this straightforward book will help you thrive in your day-to-day work.
 
Backed by years of experience, Aleksandar's book is full of examples of best practices for efficiently executing your tasks in scrum and enhanced with advice on how to build up your team.

DOWNLOAD THE E-BOOK

Subscribe to Email Updates

Recent Posts