Black box software testing: A course by Cem Kaner & James Bach

Bug Avocacy 1

When you report a bug, the goal is to get it carefully analyzed and, if appropriate, fixed. You're not just writing a report--you're writing an advocacy document, a sales piece that presents the bug in its best--scrupulously honest--light. By best, I mean, the nastiest, ugliest, most general variant of this failure that you can coax out of the program. To achieve this, you do follow-up testing when you find a bug, looking for  related failures. The failure is a symptom, perhaps one of many, of an underlying error. We want the most persuasive symptom(s) this error will yield.

Question: what do you report as a "bug"? Is a design error a bug? An "enhancement request" (whatever that is)? A crash? Wrong data? I advocate a broad criterion. Adopting Jerry Weinberg's definition of quality, Quality is value to some person, I define a bug as an attribute or behavior of the program that unnecessarily or unreasonably detracts from its quality.


We are setting up a mailing list for announcements about this course and, perhaps, a tightly focused and moderated discussion of how to teach it or self-study with it. (This won't be a general, high-traffic, intro-to-testing discussion.) If you're interested in the course, please sign up by sending us an email. We will NOT share your email address with third parties or send commercial advertising to you.

We are publishing this course under a Creative Commons license that allows you to freely reuse and distribute the materials and to modify the slides and associated printable materials (but not the videos). We would be appreciate a few mirror sites, to reduce the growing burden on our servers. If you can help in this way, or any other way, please send a note to Cem Kaner.