Home
Updates! What's New?
Got Questions? Get Answers!
QA Overview What is QA?
QA Employment Jobs
Testing Portfolios
Testing Services
Free Consultation
QA Training Become a Tester!
QA Course List
Testers The QA Elite
The Beta Tester
The Game Tester
The Software Tester
Testing SQA Glossary
Types of Testing
QA Metrics
Forms & Templates
Etc... About Us
Contact Me
Privacy Policy

E-mail Address

First Name (optional)

Then

Don't worry -- your e-mail address is totally secure.
I promise to use it only to send you SQA the Right Way!.

Subscribe To Successful Quality Assurance
XML RSS
Add to Google
Add to My Yahoo!
Add to My MSN
Subscribe with Bloglines
 

5 Keys to a Bulletproof Bug:
Day #4

Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5

The 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):

  1. 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
  2. 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 5

Return To Successful Quality Assurance Home


footer for defect writing page