Wednesday, September 11, 2013

How to Write a Good Bug Report (and be a Bug Advocate)

For the previous BBST classes I made the mistake of not writing about what I learned and the value the classes provided me. To an organization who might consider sponsoring someone (a programmer, analyst...)  or to a fellow tester who is looking for a step in the right direction I have no story to tell, until now.

For Software Testers bug reports are one of our most visible work products - something tangible that comes from our efforts of investigating the system. How well testers write a report can effect how we are perceived (to those who read them) which in turn effects our credibility and influence among those same people (especially programmers). Specifically for development and testing groups, bug reports are important communication mediums (think about the amount of time you spend reading and writing them) and as such an emphasis on understanding bug reports and improving writing skills is important. This is why I took the  Bug Advocacy course through AST and here's what I learned.

How to Write a Good Bug Report

Writing a bug report seems simple. People in many roles (programmers, testers, internal and external customers, analysts) write them without much, if any, experience but just because something is easy to do doesn't mean its easy to do well.

So what's the point of writing a bug report? To get the bug or problem fixed! That's why the lead author of the material, Cem Kaner, calls it Bug Advocacy - we are advocating for a fix. Programmers are busy people, with lots of things going on and plenty of demands on their time. They don't want to look at a bug report that doesn't make sense, requires too much work on their part to understand or is offensive. Let's be honest, if a bug is fairly obvious a programmer isn't likely to need much information, motivation or influence to fix it. They might not even require a bug report to be written. Those aren't the bugs we are interested in advocating for. We're advocating for the bugs or problems we understand to be important (for some reason) but might not be easily understood as such.