One of the most important tasks in the testing role is to identify alternative interpretations of apparently clear and simple statements. Uncle Bob’s statement appears clear and simple, but as with any sentence that can be read by a human, it affords multiple interpretations. One interpretation might be that “when programmers do their jobs, testers find nothing and therefore have nothing useful to contribute“. I’m pretty sure Uncle Bob didn’t mean to say that, although it seems that at least one of my colleagues might have taken that interpretation. I prefer to think Uncle Bob’s intention was to remind programmers to take responsibility for the integrity and quality of their work, and not to slight testers.

As a tester, part of my job to help reduce the chance that statements could be misinterpreted or taken in an overly simplistic way. I think Uncle Bob probably meant the first item on this list of a few possible interpretations (and I hope he’d agree with the other ones that I offer here, too):

When programmers do their jobs, testers find nothing that takes the form of blatant coding errors.

When programmers do their jobs, testers find nothing inconsistent with what the programmers have been asked to do—although the testers might discover problems in the design or the requirements that were given to the programmers to implement.

When programmers do their jobs, testers find nothing that indicates the programmer has been negligent or sloppy, although even the best programmers are not perfect.

When programmers do their jobs, testers find nothing that makes the product hard to test; instead, they receive a highly testable product that provides access to things like log files and testable interfaces.

When programmers do their jobs, testers find nothing problemmatic, although they might discover unanticipated value in the product.

When programmers do their jobs, testers find nothing that interferes with deep testing—looking for rare, hidden, subtle, or platform-related problems that could escape even the most diligent programmers.

When programmers do their jobs, testers find nothing that slows them down in developing a more comprehensive understanding of the business needs, making their testing more relevant.

When programmers do their jobs, testers find nothing that takes time away from developing rich test ideas, scenarios, and experiments that yield a deep understanding of the product and its emergent behaviours.

When programmers do their jobs, testers find nothing more to ask for in terms of useful tools that would aid testing.

In the same thread, James Bach pointed out that even when programmers do their jobs, testers find that the product is doing its job, and that testers find important truths about the product. Neither of these is exactly “nothing”. So…

When programmers do their jobs, testers shine light on exactly how well the programmers have done their jobs.

When programmers do their jobs, testers identify ways in which other people might have different interpretations of a job well done.

When programmers do their jobs, testers have more time to compare our product with competitors’ products, pointing out areas of strengths and weaknesses in each one.

Programmers are also in the business of clearing up misinterpretations. I posted a simpler version of one of the ideas above on Twitter:

That sentence was limited by Twitter’s 140-character limit, and limited further by the Twitter handles of couple of addressees to whom I was responding. Ron Jeffries, on a mission similar to mine, pointed out that some testers find deep, rare, hidden, subtle, or platform-related problems. I agree with Ron, and I’ll add that even the best testers—just like the best developers—are human, and limited, and can occasionally miss problems. So:

Testers (and programmers) who focus on excellence, craftsmanship, skill, and collaboration will help each other, and will tend to find problems that can be addressed before the product is released—and will tend to produce more valuable products as a result.

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website

Notify me of follow-up comments by email.

Notify me of new posts by email.

Past Presentations

You can find an extensive list of presentations and courses that I've taught, including the slides and speaker notes for many of them, here.

Coming up—let's meet!

Check out my schedule, and drop me a line if you'd like to get together when I'm in your part of the world. If you'd like me to work with you and it doesn't look like I'm available, remember that my clients' schedules are subject to change, so mine is too. Finally, note that some conferences offer discounts—and even if they don't advertise it, maybe we can work something out.

February 28, 2019

Wherever you are!

A takeover of the Techwell Hub #testing channel. I'll be asking questions interactively all day. Find out more and sign up here.

March 6, 2019

Wherever you are!

An online webinar, Higher-Value Checking. This webinar is based on the session of the same name that I presented at EuroSTAR 2018.

April 1-4, 2019

San Francisco, California, USA

The Software Test Professionals Conference (STPCon). I'll be giving two one-day workshops: Critical Thinking for Testers, and a Rapid Introduction to Rapid Software Testing. Then there's a keynote talk on Testers as Their Own Worst Enemies, and a track talk on Rapid Software Testing in Agile Contexts. More information here.

XP 2019 - The 20th International Conference on Agile Software and Systems Development. I'll be offering a one-day workshop on Analysis for Agilists, and a talk on Refactoring the Agile Testing Quadrants.