This week’s Cambridge Tester meetup was a show-and-tell with a theme:
Is there a thing that you can’t do without when testing? A tool, a practice, a habit, a method that just works for you and you wouldn’t want to miss it?
Thinking about what I might present I remembered that Jerry Weinberg, in Perfect Software, says “The number one testing tool is not the computer, but the human brain — the brain in conjunction with eyes, ears, and other sense organs. No amount of computing power can compensate for brainless testing…”
And he’s got a point. I mean, I’d find it hard to argue that any other tool would be useful without a brain to guide its operation, to understand the results it generates, and to interpret them in context.
In show-and-tell terms, the brain scores highly on “tell” and not so much on “show”, at least without a trepanning drill. But, in any case, I was prepared to take it as a prerequisite for testing so I thought on, assuming I could count on my brain being there, and came up with this:
The thing I can’t do without when testing is people.
Why? Well, first and foremost, software is commissioned by people, and built by people, and functions to service the needs of people. Without those people there wouldn’t be software for me to test. As a software tester I need software and software needs people. And so, by a transitive relationship, I need people.
Which is a nice line, but a bit trite. So I thought some more.
What do people give me when I’m testing? Depending on their position with respect to the software under test they might provide
- background data such as requirements, scope, expectations, desires, motivations, cost-benefit analyses, …
- test ideas and feedback on my own test ideas
- insight, inspiration, and innovation
- reasons to test or not to test some aspects of the system
- another perspective, or perspectives
- knowledge of the mistakes they’ve made in the past, so perhaps I need not make them
- the chance to improve my coaching
- satisfy a basic human need for company and interaction
There are methodologies and practices that recognise the value of people to other people. For example, XP, swarming, mobbing, pairing, 3 Amigos, code reviews, peer reviews, brainstorming, … and then there are those approaches that provide proxies for other people such as personas, thinking hats, role playing, …
Interactions with others needn’t be direct: requirements, user stories, books, blogs, tweets, podcasts, videos, magazines, online forums, and newsletters, say, are all interactions. And they can be more or less formal, and facilitated, like Slack channels, conferences, workshops, and even meetups. They’re generally organised by people, and the content created by people for other people, and the currency they deal in is information. And it’s information which is grist to the testing mill.
And that’s an interesting point because, although I do pair test sometimes, for the majority of my hands-on testing I have tended to work alone. Despite this, the involvement of other people in that testing is significant, through the information they contribute.
- Quality is value to some person.
- X is X to some person at some time.
Fair enough, you might ask with a twinkle in your eye, but didn’t Sartre say “Hell is other people“?
Yes he did, I might reply, and I’ve worked with enough other people now to know that there’s more than a grain of truth in that. (Twinkling back atcha!) But in our world, for our needs, I think it’s better to think of it this way: software is other people.
Edit: I’ve listed some of the other things that were suggested at the meetup in Without Which.