Writing a good bug
What does it take to write a good bug? There is a lot of time where a bug comes in from a somewhere else and you have no idea what they are talking about or what was tried. How can you reproduce it if you are unsure about where the bug is?
Here are some must haves for a bug.
Here are some must haves for a bug.
- Short Description/Title – This is where people will look to see a summery of the bug, it is very important as people will look here to find the bug when searching.
- Description – Now this is the brass tax. This is the meat. Here you will enter all you can, and give a lot of detail. The more detail the better. But keep in mind that developers will only pay attention to the first paragraph or so. So remember if you have multiple issues make multiple tickets instead of just one giant ticket. Also give any workarounds or steps you tried so that the engineer will know.
- Expected Results – This is where you explain what you were expecting to happen vs what did.
- Steps to Reproduce – How did you recreate this so we can? This tells us the steps you took to get to the bug, and is very important.
The rest are going to be drop downs based on the software. Make sure you select the appropriate one.
Attachments are a huge help. Even the worse bug can be trumped by a great video or screenshot. I have gotten bugs where I had no clue what they were talking about until the video played. Once you get good at putting in usability and functional bugs you can step using some awesome tools. We can go over that in a later blog.
I wrote some tips on defect reporting a while back, that might serve as inspration for those reading up on defect reporting:
http://testing4tw.blogspot.dk/2014/11/tips-for-registering-defects.html
Have a nice day!
/Nicolai