I recently watched a presentation that Lee Copeland gave in 2007: The Nine Forgettings, which touches on a number of things that he feels that testers often forget.

One thing in particular jumped out at me: “forgetting the boundaries”. In this section, Copeland discusses the problems that arise when testers consistently compensate for unacceptable behavior by other project members – such as BAs writing poor requirements, developers handing over code that isn’t unit tested, and PMs who call for insane hours.

I can relate to this, having frequently witnessed the kind of codependent behaviour that Copeland is talking about: testers who shrug and say “that’s just the way it is” are testers who have given up thinking about how things could be better for their customer, the project. Perhaps there are some lines that testers need to draw, some things that we need to push back on.

This left me trying to square a circle.

I also support the context driven view that as testers we provide a service to the project, that we need to adapt our testing to suit the context within which we operate, and that we should do the best testing that we can with what we are given.

So how do I reconcile these seemingly conflicting views?

Here’s a few heuristics that help me:

Selling tobacco: Sometimes other members of the project will ask us to do something that we disagree with, that we believe will harm the effectiveness of our testing; our customers are asking us to sell them something that we don’t feel is in their interests. However, our customers are responsible adults, and are entitled to make their own decisions. Like selling tobacco, it is appropriate to give a health warning, then make the sale.

Selling crack: Sometimes (and hopefully rarely) we are asked to do something that is simply unethical – such as suppressing information or providing dishonest reports. Just say “no” to drugs.

Selling miracle cures: Last, but by no means least, sometimes we are asked to do the impossible – “ten days testing by this afternoon?”. Agreeing to unrealistic expectations is a recipe for disappointment. A grown up conversation about alternatives is called for.

So, what have you been asked to sell today?

Update; since writing this, I’ve been rereading The Seven Basic Principles of the Context-Driven School. The heuristics above map well to part of Kaner and Bach’s commentary:

Context-driven testing has no room for this advocacy. Testers get what they get, and skilled context-driven testers must know how to cope with what comes their way. Of course, we can and should explain tradeoffs to people, make it clear what makes us more efficient and more effective, but ultimately, we see testing as a service to stakeholders who make the broader project management decisions.

• Yes, of course, some demands are unreasonable and we should refuse them, such as demands that the tester falsify records, make false claims about the product or the testing, or work unreasonable hours. But this doesn’t mean that every stakeholder request is unreasonable, even some that we don’t like.
• And yes, of course, some demands are absurd because they call for the impossible, such as assessing conformance of a product with contractually-specified characteristics without access to the contract or its specifications. But this doesn’t mean that every stakeholder request that we don’t like is absurd, or impossible.
• And yes, of course, if our task is to assess conformance of the product with its specification, we need a specification. But that doesn’t mean we always need specifications or that it is always appropriate (or even usually appropriate) for us to insist on receiving them.

There are always constraints. Some of them are practical, others ethical. But within those constraints, we start from the project’s needs, not from our process preferences.