Buggy reporting talks about how buggy real bug reports can be. It bugs me a lot to read buggy bug reports which hardly talk about bugs in a understandable way. As testers, we all know that bug reports are important for providing information to the stakeholders. Still, we don’t take any effort to review our own bug reports. If we ourselves are not interested in reading our own bug reports for clarity, how can we expect programmers and other stakeholders to not just read them, but also decide whether to fix problems reported in those bugs? Height of Optimism!
Awesome Titles
“Script warning”“Spelling mistake”
“file not loading” and
My personal favorite “Thomas is a fool!”
“Thomas is a fool” was a real bug in one of my previous organizations. As part of learning a complex component, I was reviewing all the older bugs that were reported and fixed within that component. That’s when I chanced upon this “Antique Piece". Thomas was one of the managers in the organization who may or may not have done anything good to one of the employees who literally reported this bug on last day of his employment. Quite a cool bug, I never know if Thomas was a bug or the guy who called Thomas a bug was a bug. Nevertheless, If you plan to report such a bug, please don’t quote me on that!
Jokes apart, let’s change roles for a moment as we become programmers. If you are entrusted with the responsibility of fixing bugs with bug summaries as above, what would your first thought be? Scratch your head or Trash them? Once, twice, thrice. If I were a programmer, I would trash not just the bugs, but even folks who write such bugs. And yes I am harsh, because every important bug that fails to catch stakeholders attention due to bad reporting is as good as a dead one.
Some of us might wonder “Oh! The product is so buggy that I have to report at least 20 bugs a day. With whatever little time I have, I can only make my bug reports shorter so I can write more bugs in a day”. My question to such testers is “How much are you bothered or not bothered if none of the 20 bugs reported this way are fixed”. Don’t tell me “That’s not my problem”. Agreed that we are information providers and not decision makers. But are we really providing useful information? Just a thought.
Detailed Descriptions
“Why I need to login?”“search for item, I got script error”
“when my transaction failed, link to database cannot establish”
“in payment by debit card the bak name is choosen from the drop down menu , after that there is no requirement in the gateway page to ask the name of the ‘Issuing Bank’”
Don’t be surprised. These are real descriptions of real bugs. In other words, "Steps to reproduce" if that is the word your organization uses. At first sight, it might look like I am making fun of all those non-English speaking testers who confess openly about their lack of good English writing skills. Bug reporting is much more than knowing English well. Can’t we just look back and read/re-read the bug before hitting the submit button? Is that so hard?
“What’s the fun in detailed reporting? Am I so jobless to type tons of information for every bug I report? Can’t programmers figure out such a simple thing? Won’t my expertise go away if I gave all this information out for free? Let’s be honest - I struggled a lot to get here and find this bug, why should I give away information just like that. Let people come back to me, I’ll tell them and I’ll tell them only if I like them”
Some descriptions are so painless. A simple copy/paste of the bug summary. It’s as though the bug reporter was held at gunpoint and asked to report a bug one last time before giving away his life forever and ever. Or maybe his bowel movements didn’t permit him to do so in the time available for him to rush from his desk to the washroom. No offense meant – frankly it’s that annoying to read bad bugs to figure out what’s going on. Total waste of time.
Attachments
We have many free tools to take screenshots, many more to capture videos and above that, we have the freedom to attach logs, xmls, data files, test files and lot more options to help with bug investigation and fixing. Again, the same old question – who has the time? We don’t want to provide anything until the bug goes to “Needs more Information” state. And we would be offended if it’s moved to “Invalid” state, all this for no mistake of folks who read our dead bug reports.Reputation Points
1. Bug reporting skills
2. Investigation skills
3. Ability to provide detailed information so that programmers don’t float between the bug and the bug reporter to get additional information
4. How many bugs are valid versus invalid?
5. Questioning skills (No, not the “why I need to login” type of bugs)
6. How many of the bugs reported did the tester get fixed finally?
All that mattered to the management was Rajesh has reported the highest number of bugs and he should be given the ‘Star Tester of the Quarter’ award in Q4 2010.
What a fishy method to earn reputation? Just because you are testing a buggy product or you find a bug every minute doesn’t mean you have to report bugs in a lousy way. Just because you want to beat your counterpart in the number of bugs reported as part of the bet you had with him or your manager rates you this way, doesn’t mean that you can stoop to any level of lack of quality in your own bugs.
If you are a tester, go back and read your bug reports as if you did not report it at all. Identify the gaps and work on those gaps by practicising writing good bug reports. If you are programmer who is annoyed with your tester’s bug reporting skills, tell them politely about what basic information you expect instead of running to his desk every 5 minutes which wastes not just his time, but yours too!
I recently met up with a CTO of one company whose product was tested by a bunch of testers outside his organization. When I questioned him about what he thought about the bugs reported by independent testers, he just said one thing, “Each time I read the bugs reported by these testers, I often wondered - why aren’t our in-house testers reporting bugs this way…….. " And he kept scratching his head for the next 30 seconds after uttering this. I felt a lot of pain in what he said. I wish he goes back to them and politely tells them that they need to improve in their bug reporting skills.
Happy Bug Reporting,
Regards,
Parimala Shankaraiah
