Black Box Software Testing – Bug Advocacy
|2011/11/06||Posted by CCAdmin under AST, Learning, Software Testing|
It’s been a busy month or so since my last blog post. The reason you haven’t heard from me is that I was taking another class from the Association for Software Testing (AST).In April I took the Black Box Software Testing Foundations class. This time, I took the second class in the series, Black Box Software Testing: Bug Advocacy. Toward the end of this class, I got the good news Mindjet that I won the October mappie award for best mind map of the month on their mapsforthat.com website. The award was for the mind map explained in my last blog post about personal kanban. Did I mention it was a busy month?
Bug Advocacy is an interesting topic. It is a topic that I really had not given much thought to before, but after going through the class, I realize I was neglecting an important part of the software testing puzzle. As a black box software tester, bug reports are your primary work product. Not only do they shape your co-workers’ (especially your boss) view of you, but they shape the software product heavily. If the bug reports aren’t good, the chances are higher that the bugs won’t get worked (and therefore fixed). Essentially, without good reports that motivate the fixing of bugs, you are pretty much worthless as a tester.
The class broke down into six sections. Each building up the concept of how to write good bug reports that will motivate the right people to fix the bug.
- Basic Concepts – Recap of definitions and basic testing ideas.
- Make people “want” to fix the bug – Bug reporting is a bit like being a salesman. You have to “sell” the bug.
- Dealing with objections (irreproducible bugs) – The second half of sales, after motivating the buyer is to overcome objections. What are some common reasons bugs are difficult to reproduce? What are good tactics to reproducing bugs?
- Dealing with objections (content, clarity, credibility of report) – More on the “dealing with objections” part of sales. Dealing with common reasons that bugs are deferred is covered.
- Credibility and Influence – The reality is that your (the tester) credibility plays a role in the decision whether to tackle a bug or not. How do you, the tester, gain credibility? How do you gain a good reputation?
- Writing clear bug reports – The icing in the cake is writing a good report. What makes a good bug report? What makes a bad one? How do you avoid the pitfalls? What is the structure of a good bug reporting system? How does that bug reporting system help facilitate good reports?
Here are notes from the class in the form of a mind map. The map was created in Mindjet Mindmanager, so you’ll need that tool to open the mind map. Note that you can install Mindmanager for free to use as a viewer (must purchase to create maps after trial period, though). Alternatively, here is an Adobe PDF version of the mind map. To work in Adobe Reader, you will need flash installed on your computer.
Note: The mind map notes are released under the Creative Commons license as specified by the terms of the BBST BA class. See the notes on the main map node for licensing information.