Documenting Bugs
Bug name/short description – You will want to state the basics of the bug some thing simple but descries the whole bug. Like “Crashes when in 2 windows and deleting an object from window 2” Now that does not describe the whole thing but it gives you a basic idea. This is more so you can easily find this bug later.
Found in version – What version did you find it in. This allows the developer to go back to that version and see what happened and if it is in a newer version.
Type of bug – Is it a crash, is it data loss, is it a spelling error, or is it a consistency bug. What type is it?
Severity – How bad is this bug? If it is a spelling error that depends if the client sees it a lot then big if they rarely see it minor. Crashes are big and so is data loss. you have to judge this so they know which bug to fix first.
Reproducible – Is it reproducible or did it just happen this one time. the more reproducible the easier it will be to track down and the bigger and issue it is. If it is complicated then maybe not hit so often so lower. And if it was a on hit wonder then it may never be fixed until you find a way to hit it consistently.
Hardware setup – What is your hardware setup? there might have been something in your setup that is different then what they test and this will show us the key. If you are on a mac instead of windows, safari instead of chrome… that is important knowledge to figuring out what went wrong.
Screen shots and videos – These are life savers always, always have these. When you type out a bug and can’t explain it the screen shots can speak that 1000 words. and videos can show someone just how to reproduce.
Other attachments such as spin dumps, crash reports, and error logs – These are all very important in trouble shooting slowness and crashes and what might have went wrong the programers have these spit out things for a reason. you should learn to read these and I will go over this in the future.
Long Description – This is your brass tax, your meat, this is where you will put everything you can into this ticket so they can figure it out. But remember the Dev might like a lot of info but they don’t want a novel. So be to the point and make sure you are documenting 1 bug and not 3. They may read the first paragraph and find a bug in that one and then fix only that when your ticket was a 3 parter. Then make 3 tickets and not just one to rule them all.
Steps to reproduce – What were the steps the reproduce your bug? This is critical in figuring out what went wrong. Even putting this in a one hit crash is good and ending with can’t reproduce a second time. Any info can help.
Expected results – What were you expecting to happen can help the engineer figure out where it went wrong so always add that if you can.
Also this week on Test Reactor I go over this same thing. So when Wednesday rolls around feel free to check it out at www.testreactor.com