When software testers find a bug in the system they’re testing, they record information about the bug in a bug tracking tool. These bug tracking tools are essentially a database with a user interface. There are many commercial and Open Source bug tracking tools you can obtain. At Microsoft, most testers currently use an internally-developed bug tracking tool called Product Studio. When entering a new bug, based on my experience, I’d say the two most important fields of a bug report are the Title and the steps necessary to reproduce the bug, or Repro Steps for short. Click on the image at the bottom of this blog entry for a screenshot of a dummy bug.
A good bug Title is obviously important because it’s the first field most testers search on to determine if the bug they just found has already been entered into the bug tracking tool. The Repro steps are hugely important. A bug can’t be fixed unless the cause of the problem is found, and the problem can’t be found unless it can be reproduced. There’s nothing more irritating to a developer than to attempt to replicate a system problem, but not have enough information in the bug tracking tool. Writing good repro steps is part art and part science. Suppose you’re a tester. If you enter every conceivable bit of information as part of the repro steps, your repro steps would be pages long for each bug. Entering not enough information is even worse. As a really, really crude rule of thumb, most of the bugs I record generally have about 8-12 steps.
The hard part is figuring out the context of who will be trying to reproduce the bug. By that I mean, a developer who works very closely with you will understand all kinds of information about the system under test that you don’t need to place in the repro steps. For example, a closely-aligned developer will know where the drop point is, the build numbering system, and so on. But suppose you are outsourcing the bug fixing process to a third party development team. In a situation like that, you can’t make nearly as many assumptions about what the developer knows.
All repro steps should have Expected Result and Actual Result information. Some bug tracking tools have explicit fields for this information, but if your tool does not, you need to include expected and actual information somewhere. Some of the product groups I worked in use a single Result field instead of separate Expected and Actual fields. The need to tell the developer who is reproducing your bug, what is supposed to happen after your repro steps may seem obvious, but it’s something new software testers often don’t do.
By the way, the new Visual Studio 2005, Team System version (VSTS) contains really many new features including a bug tracking component based on Product Studio. Active development of the internal-to-Microsoft Product Studio tool has stopped and eventually most Microsoft product groups will use VSTS. So, you now have the ability to use the same bug tracking system as that used by Microsoft engineers.