Last week, I decided to go back in time to revisit a classic work of software testing theory by James Bach, on the subject of risk-based software testing. What I tried to show was that despite tremendous advances in terms of tools, techniques and technology, the fundamentals of software testing essentially remain the same. I hope that was conveyed in the post.
Anyway, in that same spirit, I’m going to quickly bring back another classic work of software testing theory for debate and discussion: Bug Advocacy by Dr. Cem Kaner.
If that name sounds familiar, it’s because Cem Kaner is one of the field’s leading thinkers, teachers and practitioners. He’s also appeared as a guest on our Testing the Limits interview series, which you can find here, here and here.
So what is “Bug Advocacy” all about? The title pretty much says it all (I hope), but let’s take a look at some key excerpts from this 100-page masterpiece to find out more. First the, the premise:
- The point of testing is to find bugs.
- Bug reports are your primary work product. This is what people outside of the testing group will most notice and most remember of your work.
- The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.
- Programmers operate under time constraints and competing priorities. For example, outside of the 8-hour workday, some programmers prefer sleeping and watching Star Wars to fixing bugs.
A bug report is a tool that you use to sell the programmer on the idea of spending her time and energy to fix a bug.
Motivating the Bug Fixer
Some things that will often make programmers want to fix the bug:
- It looks really bad.
- It will affect lots of people.
- Getting to it is trivially easy.
- It has embarrassed the company, or a bug like it embarrassed a competitor.
- One of its cousins embarrassed the company or a competitor.
- Management (that is, someone with influence) has said that they really want it fixed.
- You’ve said that you want the bug fixed, and the programmer likes you, trusts your judgment, is susceptible to flattery from you, owes you a favor or accepted bribes from you.
Overcoming Objections Via Analysis of the Failure
Things that will make programmers resist spending time on the bug:
- The programmer can’t replicate the defect.
- Strange and complex set of steps required to induce the failure.
- Not enough information to know what steps are required, and it will take a lot of work to figure them out.
- The programmer doesn’t understand the report.
- Unrealistic (e.g. “corner case”)
With these selections, you can see where the rest of the piece is heading – and why it matters to YOU as a tester. The art of persuasion is of great importance to software testers, but to fully understand the implications and techniques, you’re going to have to read the rest of Cem Kaner’s Bug Advocacy. Sorry, no shortcuts.
Thanks to uTester Ben Kelly for the link.