Bloggo back to the blog
Eat your greens, or there is no pudding-->
Ask anyone who works with me what makes me happy, and they will tell you, “Being miserable”. I love bearing bad news, Oh, I pretend I am concerned about ensuring quality, protecting the organisation and adding value, but really I just love to find fault. I love to say “I told you so”, or “Your all a bunch of cowboys” or “This is simply not fit for purpose” But for a tester just to go about finding fault and telling anyone that will listen that the code is a pile of ‘doo-doo’ is a bit like a child that refuses to eat their greens and is allowed to go straight for the pudding. It really isn’t healthy.
I would like to suggest two fundamental and basic areas of test discipline we need to adopt as part of a healthy ‘eat your greens’ approach to testing,
I believe we have a responsibility to really understand both, what are the requirements, and what we are testing. I know it sounds obvious, but I can’t count the number of times I have seen bug reports raised which totally misses the point. I have seen functionality reported as a bug, which is actually the exact functionality the business asked for. I have seen bugs raised, against functionality that is not due to be delivered. I have even seen a bug raised against a system we were not even testing!
Raising invalid bug reports helps no one, and adds administrative overheads. Testers have a responsibility to fully understand what is being tested and what it is being tested against. Test managers have a responsibility to ensure that they don’t rush testers into writing and executing tests without enough time to prepare and to get up to speed on the system.
Within this area of understanding what is being tested, I think there is another area that indicates a maturity of testing (and tester) which has to do with discernment, making correct judgements and applying an intelligent and critical evaluation of the merit of the test being undertake. This involves not simply blindly following a test script, but thoughtfully deciding when to deviate from the script, either because the deviation is likely to reveal issues with the system, or because the test itself in inadequate or wrong is some respect.
If we raise a bug, we have a responsibility to give the developer as much information as we can to assist them with understand the bug and working towards its resolution. Depending on the tester, there will be more or less information that we can give, ranging from a full account of what the bug is and how it can be recreated through to suggesting root causes and avenues of investigation or corrective action the developer can take.
I have seen some truly appalling bug reports in my time, and have had to sit and take the justified criticism of development leads on the chin and then go and have stern words with the team. As a test manager, it is your responsibility to ensure your team are eating their greens.
If there was a light bulb joke for testers it might go like this.
How many testers does it take to change a light bulb? None, they only point out that it is broken!
Simply writing the bug report is not enough, like many things we say, it’s not what we say, but how we say it that counts. Mature testers, (who eat their greens) take time to read through their bug reports to make sure they make sense, are well structured, are devoid of accusations and confrontational tones and give as much relevant information as possible. Certainly a bug report should only contain one issue, not two or three (or more!). Top tip for bug reports…… screen shots.
I am sure others could come up with additional items, which though not quite as fun as raising the bug, are none the less critical to a healthy mature test process and test team. In fact why not suggest some via the comment section, that way we can all come up with clean plates and be ready for some jelly* and ice cream.
* For American readers, that’s Jello not what you think of as jelly but that the rest of the English speaking world rightly calls jam!