I downed a switch and the GUI hung. Waiting 20 minutes caused it to start responding again, but extremely slowly. Logs attached.
Ick ick ick. We've already talked about poorly-written bugs, and this is a good example of one. So why does this happen?
- Writing up bugs is boring. Freely admitted.
- You know the context, so you don't write it all down.
- When you're logging several bugs in one area, it's easy to cross reference them rather than write each bug up fully.
But... understanding why doesn't excuse it. That's still a slippery slope to go down. The obvious reaction is to state that all bugs must contain certain things:
- setup information (the state you were in when you started reproducing the issue)
- steps to reproduce the issue, including data you used
- logs if the situation is at all time-based or involves multiple steps (e.g., misspellings don't need logs)
- screenshots if there is a GUI
- version of the software in which the bug occurs.
I think this is a pretty good basic list and not overly onerous.
So, having found a good goal, what can we do to help ourselves reach that goal consistently? I've found two big things that help. First, dev should kick back any bug to QA that doesn't have this information. If the person who found the bug is available, there's no reason to start an archeological expedition to figure out what's going on. Second, make getting the defect information very very easy. I've found some tools helpful:
- a log gathering tool is invaluable, particularly in a multi-machine system
- have a fast defect tracking system. Don't put it on some old hardware that will make users wait.
- good easy screenshot tools are helpful. SnagIt is better than printscreen.
- If the situation is complicated, a recording/playback tool is useful. They make these for GUIs, and you can also make one for your own system.
Long and short, logging bugs isn't the most fun part of QA, so make it easy to do it right. Then, keep doing it right. Use your team and use your devs and keep yourself taking all the steps.