5 Most Common Bug Writing Errors: Day #1
Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5You 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
- Not Enough Information
- Unclear Reproducibility
- Omitting the Expected Result
- Selecting the Wrong Severity
- 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 5Return To Successful Quality Assurance Home

|