Bugs are an important part of the work of testers, but for some reason, we tend to take them for granted and don’t invest the proper value and thoughts to them.
I am not saying they are the most important part of the process, but they are an incredibly useful output and measurement if you manage them correctly and know what you are looking for.
Bugs are also the cause of anger and miscommunication between teams, and when approached lightly can cause as much harm as good.
But let’s be clear, it’s fairly inevitable that your software has bugs in it…..almost all software does
Today we want to start talking about some important points that relate to bugs, not sure how much time we will have to talk about most of them, but we will start to review them together 🙂
Should we define what a bug is?
Anything that threatens the value of the product. Something that bugs someone whose opinion matters.
Our definition: A mismatch between what was expected and what we have created
Let’s start with the good and bad when bug reporting
- Good bug reports start by understanding who you are writing the bug for. It is not only the developer who will fix it, but also the manager who needs to appraise it, the documentation person who needs to add it to the notes, the tester who will re-test it, and the support person who will check it vs something reported from the field. And even you in 2 years time, who needs to try and remember what you wrote there in the first place.
- Do not write a bible, enough means not less than needed, but definitely not more.
- Context!!! Not only how but where you found it.
- Facts are important, but your opinions are also needed – why it should be fixed? Why do you think this is happening? Is it related to other issues or areas? Who will suffer from it?
- Don’t shy away from the technical stuff, if you think you can suggest a fix, go for it!
- Should we report bugs we believe will not be fixed???
How about some metrics and what can we learn and maybe what we can’t learn from bugs
- Do we care how many bugs are being found on a specific date or period? We should care based on context…
- Ask your team what they are trying to keep track of and what they are trying to improve and then come up with the measurements.
- Bugs are outputs, not reasons. Just like a fever is an indicator, and as much as you may want to treat the fever, you need to treat the illness and only control the fever in as much as it may cause harm or discomfort to the person.
- Examples I like to measure:
- Bugs per functional areas, functional areas where we are doing changes should obviously have more bugs than those where we are not making changes.
- The rate of detection vs solving of bugs, to show if the project is in a convergence path.
- Escaping defects, differentiating between bugs that were found internally and then found by users, and those that we were not aware of before they were detected.
- Also not measure but keep track, especially on critical bugs, where was it found vs were we wanted to find it – to validate the different testing efforts.
To be continued….