Date: 3rd July 2010
Time: 15:30 – 17:30 GMT
Mission: This week’s mission is Bug Dissection. Let’s improve our own bug reporting by studying bug reports, and analyzing them together. Can we redraft any of these reports to make them clearer and more persuasive? Or does the bug report look pretty good to you already? If so – why? What do you like about it?
Bear in mind that the bugs we’ll be studying may not have been reported by experienced testers. So let’s not be too critical of the bug reporter – they’ve made an important contribution to the open source community by taking the time to note an issue about the product, and they’ll probably have learned a lot themselves by reporting the bug.
Product: Open Office Writer
Anna Baik facilitated the debrief.
Ajay Balamurugadas started the debrief with his lessons learnt. He learnt that Open Office Tracker is a good source to improve your skills. Practice and improve, retrospect. How people other than testers log bugs can be felt. Follow up tests are also important, and notes also help. If someone doesn’t agree with your bug, they just don’t agree with your oracle for the bug.
Alexei Barantsev continued the debrief, stating that good bug description writing is an useful skill for any tester. An especially important skill is extracting the essence of the bug and wrapping it in a short subject line, which saves lots of time for those looking through the bug tracker. For developers though, there are other things more important than that subject line: 1) clear description (RIMGEA), and 2) good reasoning that explains why it IS a bug.