Reading some of the problem descriptions posted by people who are supposed to be QA professionals in a technical specialist forum always gives me a chuckle. “Uggg. Test tool no work with Java applets”. I love irony. A big part of their job is to find and raise defects. Sometimes it seems that their employers would get better value by sending them on a quest for fire.
Just as everyone should read the guidelines before posting to a technical forum, Eric S Raymond’s page on How To Ask Smart Questions and Simon Tatham’s essay How to Report Bugs Effectively should be required reading for any software professional.
When it comes to raising and tracking defects, one of my pet annoyances are people who attach a screenshot of their defect, but do not include a text version of the error message. This means that you cannot do keyword searches effectively. It’s probably worth your time to spend five minutes learning the features of your defect tracking tool before you start using it. My favourite new feature in TestDirector is the System Information tool, which can extract a detailed configuration report for your computer to attach to the defect you are raising (Add Defect > Attach SysInfo).
A co-worker pointed out to me that I tended to raise defects that were too technical, or that provided enough technical information, but not enough “big picture detail”. The developers could understand them, but the defect manager and project managers were having trouble determining if my priority and severity assessments were correct in their daily defect meetings. I changed the way I raised defects after that.
Just like any other business communication…
- Write to your audience
- Make it as complete as possible
- But still try to be concise and on-topic
- Try to anticipate (and answer) obvious follow-up questions
Addendum: I recently had a string of problems with my virtual hosting company. I raised several problem tickets providing details of exactly what my problems were. From the names on the replies, it looks like the hosting company has outsourced support to India even though the servers are still in the US (the traceroute ends in the United States). Even though the replies were in perfect english, I regret using so many large words in the problem descriptions. No one should have to try to interpret that in their second language. Newspapers write to a 13 year-old reading level, perhaps bug reports should too. It all comes back to knowing your audience.
Related Posts
One Comment
Comments are closed.
On the subject of defects and load & performance testing I am now of the opinion that whilst trying to identify real defects/bottlenecks the scope of the load and performance tester should be greater than this. I believe there is a fine line between actual and percieved performance issues from an end-users point of view. Consequently system/software responses that result in percieved performance issues should be raised as defects.
Examples of perceived performance issues can be found when a system times out on a response but provides no feedback of such to the end-user or when a response is expected to take a relatively significant time without appropriate ‘time-taken’ feedback.
Although this may appear to be under the umbrella of user-acceptance testing I believe that the responsibility of raising such defects actually falls under the jurisdiction of the load and performance tester. Whether perceived or real the end-user will state “It’s slow!” & the fingers will immediately point to the load & performance testers.