Not Testing, but Drowning

Sometimes, I work with a client’s test team. And their work is to get the system to work. Are they testing?

They are. They’re paid to test, they identify as testers, they talk about their work as ‘testing’.

And they’re not. They’re not demonstrating requirements, they’re not digging into system behaviour, they’re not judging the system. The information they gather is generally swiftly forgotten – acted on if necessary, otherwise sunk.

These testers – or at least their actions in this context – are not served by requirements tracing, system exploration, test management and reporting.  They’ve been left behind by tools, left behind by standards, left behind by great chunks of our industry.

Yet their work is still needed, their hard-won expertise still highly valued within their teams. So much so that the chattering end of our industry is only tangentially relevant to teams whose time is spent in getting systems to work.

Working to get something to work has been a part of testing since I first professionally tested a thing which was not my own, in 1986. It’s been a part of testing at pretty-much every client (at least those clients who had something to test) since then. Perhaps my clients form a diminishing cohort of antiquated organisations.

Let’s think, then, about the transferrable skills of wrangling and debugging which underly the daily work of so many testers. I’m not generally a definition-maker, but  to help me (and us) think about this, I'll write next about some of the aims of these activities.

(This is likely to be a four-part post – this one, Wrangling, Debugging, and a last one on what we can do in Testing to help our wrangling, debugging colleagues to move on to work which produces relevant and valuable information)