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 Most Common Bug Writing Errors: Day #1

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

You should now know 10 Critical Elements of a Bug and 5 Keys to a Bulletproof Bug. You are on your way!

In this course I will detail the most frequent mistakes that testers make when writing bugs and how to avoid them. This will help you NOT make the mistakes that so many before you have.

This puts you WAY ahead of the average tester. Learn what these errors are and how to avoid them and you will save yourself a great deal of time and frustration in your testing career!

There are many errors that Quality Assurance testers make daily when writing bugs. Keep these points in mind when you enter your bugs and you will sidestep the most common pitfalls that many testers make.

5 Most Common Bug Writing Errors

  1. Not Enough Information
  2. Unclear Reproducibility
  3. Omitting the Expected Result
  4. Selecting the Wrong Severity
  5. Assigning Bug to the Wrong Person

Now let’s break each of these Errors down so that you can understand and avoid them.


Error #1:
Not Enough Information

A bug is useless if it does not contain enough information. It is not a rare occurrence for a bug to be missing the necessary Setup information or to not list all of the Steps.

As we covered when learning to write a bug, if a bug does not include the necessary information for Setup and Steps to Reproduce, there is no way for anyone to ever be able to replicate the bug with accuracy.

Remember that the goal is for anyone to be able to reproduce the bug with only the information contained within it. Any other scenario is going to make someone else do more work to be able to understand what you have done.

Don’t be the person who creates more work for others. Be someone who creates solutions, not obstacles.

As noted before, simply stating in the Result that the program crashed is not enough information. You must add the important details of the result(s) of that crash. Add what the effect of the bug was: “Result ‘X’ means that the user cannot do ‘Y’” – that sort of thing.

After you write a bug, read through it. Read it as though you know nothing about the bug. Did you include all of the necessary information? When you read the bug, does it make sense?

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

Return To Successful Quality Assurance Home


footer for defect entry errors page