Tag Archives: Role of Testers

Ledge Psychology

Sometimes being a tester feels like being a ledge psychologist. You know? The folk who talk would-be jumpers back from the ledges of tall buildings.

I’m sure you’ve been there. Perhaps it was a project manager planning a project with barely any testing. Perhaps it was an executive balking at the cost of even a minimal strategy. Perhaps it was a product manager who wanted to ship IMMEDIATELY and not after those scary bugs got fixed. Maybe it was even a manager demanding metrics that made little sense to you.

You may feel like a ledge psychologist, but you aren’t. It’s not up to you talk the jumper down. You are an information provider, and your role is to help the jumper make an informed decision. How high is the ledge? How fast would a typical body be traveling when it reaches the ground? What are the chances of survival?

Project managers, product managers and executives are grown ups. They get to make their own decisions, are paid to do so, and ultimately will be held accountable for their mistakes

This doesn’t mean you are powerless. Even if your jumper goes over the edge, YOU can always decide not to grab on to their shirt tails and follow them over. There are always other buildings.


Selling Tobacco

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.