5 Keys to a Bulletproof Bug: Day #4
Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5The Result should be a clear, simple explanation of exactly what happened and, therefore, what is now affected. State the bug. Write the exact event or behavior that caused you to write the bug.
Key #4: Result
You need to state this Result as well as what is affected because of the Result. If the program crashed, state that. That’s a good start. But make sure you include the “then what does that mean?”If the program crashed, did the user lose any information they were working with? Did the crash cause the computer become non-responsive? You must include the details of what the effect of the bug is. Here you are quantifying the impact of the issue you are reporting. This adds value to your bug. This is where you will separate yourself from the average tester. An average tester will state that the program crashed. That’s all. That’s it. They will write no more. You, on the other hand will use this opportunity to show why you are elite, not average. You will write that when the program crashed, the computer had also frozen. The keyboard and mouse were unresponsive and the computer had to be manually restarted. Of course, only write all of that if it is actually true. I’m sure that’s how you would do it. The Result is also the place to reiterate two things (if they apply): - The Intermittency of the bug or if it has only been Seen Once. If this bug does not occur 100% of the time, then in the Result you should state this. It is a prime location for you to remind the reader how often the bug occurs so that if they don’t see the outcome they expected, they will know why
- The environment in which the bug occurs. If the bug only happens in Win98 SE, this is where you should remind the reader. Again, this is so that if they missed it the first time or forgot, it will be available for them here. Also, some people scan bugs and read the Result first – when they do this they will miss all of the great information you wrote earlier, so here is your chance to put all that information in one place
Here is an example of one poorly written Result and one well written Result: Bad Result: Program crashes intermittently Good Result: Program crashed. Computer froze. Mouse and keyboard are not responsive. Hard reboot necessary and program must be re-launched. **Note: Bug occurs in Win98SE only Bug has occurred in 6 out of 10 attempts Show your worth and write a great Result. Separate yourself from the crowd. Make the rest of your project team happy to deal with your bugs and raise the level of trust they have in you and your work by writing a comprehensive Result. Once you’ve written a great Result, move on to the Expected Result (tune in tomorrow…) Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5Return To Successful Quality Assurance Home

|