The bug report is your initial contact with a bug and it often heavily influences the way that you approach your investigation. What does a standard, high-quality bug report contain?
- Clear statement of what is wrong
- Steps to reproduce
- Specific version information about relevant software (and possibly hardware).
- Severity of the Problem
Having that information is a great start, but it's not always available, especially 1 and 2. Often instead of a clear statement of the problem, you get a long description of current functionality like, "It prints a biweekly report", or "I get an error when I do (known error-causing action) ". The person making the report really wants it to do something else, but there is no way of knowing what from the report itself.
Instead of steps to reproduce you will get a general statement of what they were doing when it happened: "I was working on my PDQ report when I double-clicked the icon that brings up the report query interface, but it gave me an error and quit." The problem is, it can be hard to understand what they were doing because they don't use the same terms that you would. In this example, you may not have any idea what the "icon that brings up the report query interface" is. Remember that a bug is in the eye of the beholder and will be framed within the user's perception of the system. In these cases, you will need to get a lot more information to determine what is actually going wrong.
Tomorrow: Read the Bug Report and Blink