The Ping-Pong Bugs are driving me nuts
I have been troubleshooting some website registration issues at work, some solution bugs as part of the course I am enjoying this week and at home. The computers at home always seem to start and automatic countdown when I leave home, only to start failing one by one as soon as I have crossed the border. What makes it difficult is that many of the reported issues are reported in a very vague format … some classic examples that require artificial intelligence and/or endless guesswork:
- Cannot access site.
- Can logon to site but cannot access.
- It worked yesterday.
- I attached the revised document …. no idea why you got the one dated two years ago.
- Game installation failed.
- No idea what happened … it just blew up.
- … and so forth … you should recognize some of the gems.
Most of the above can be frustrating, often irritating to address, because it requires excessive investigation and communication to just get an idea of what the actual problem is, before the energy can be invested in the resolution.
This is where the ping-pong effect #1 comes into play …
- Ping: Cannot access site.
- Pong: What site and why can you not access the site??
- Ping: Site XYZ.
- Pong: Why can you not access the site … have you got details on the error?
- Ping: Error 5.
- Pong: Can you please give me more detail.
Another ping-pong effect #2 occurs when testers and developers talk past each other …
- Ping: Cannot access site XYZ.
- Pong: Tested site XYZ and it passes our unit and manual tests. Close bug as “cannot reproduce”.
- Ping: Re-open bug. Cannot access site XYZ.
- Pong: Tested site XYZ and it passes our unit and … to be continued until the budget, time or patience is used up.
Makes me think of the infamous problem report I remember from 1994 … “the foot pedal is not working” … reported by a user who thought the mouse was a foot pedal.
So, what should we consider when raising bugs?
When you report a problem, you should simulate a black box on a interstellar probe that only has one chance to gather and convey the problem information. What should be in the error/bug report is the following:
- Information on how the problem can be reproduced.
- Prerequisite environment and software.
- Steps that occur before the problem jumps up. See the tool PSR here for a cool gadget that allows you to easily gather this information.
- Information on what was expected to happen and what actually happened. This would have simplified the foot pedal support call immensely 🙂
- Screenshots, pictures, sketches … “visualization” speaks a million words.
Before you send off your report, please make sure it makes sense to you and if possible, give it to someone else to read as well. An incomplete, confusing, incomplete or illegible report will simply unpack the ping-pong balls … may the games begin.
Any help from Visual Studio Team System (VSTS) 2010?
The question is whether Visual Studio Team System (VSTS) 2010 will be bringing any bug busting features. Well, if we zoom into one of the 101 guidance posters we notice the following great news: