Some time ago I was invited to talk to a group of testers at a big consultancy firm in the Netherlands. They wanted to learn more about context-driven testing. I do these kind of talks on a regular basis. During these events, I always ask the audience what they think testing is. It surprises me each time that they cannot come up with a decent definition of testing. But it gets worse when I ask them to describe testing. The stuff most people come up with is embarrassingly bad! And it is not only them, a big majority of the people who call themselves professional testers are not able to explain what testing is and how it works…
How can anybody take a tester serious who cannot explain what he is doing all day? Imagine a doctor who tells you he has to operate your knee.
Doctor: “I see there is something wrong there”
Patient: “Really? What is wrong doctor?”
Doctor: “Your knee needs surgery!”
Patient: “Damn, that is bad news. What are you going to do doctor?”
Doctor: “I am going to operate your knee! You know cut you with a scalpel and make it better on the inside!”
Patient: “Okay… but what are you going to do exactly?”
Doctor: “Euh… well… you see… I am going to fix the thingy and the whatchamacallit by doing thingumabob to the thingamajig. And if possible I will attach the doomaflodgit to the doohickey, I think. Get it?”
Patient: “Thank you, but no thanks doctor. I think I’ll pass”
But it is much worse… Many testers by profession have trouble explaining what they are testing and why. Try it! Walk up to one of your tester colleagues and ask what he or she is doing and why. 9 out of 10 testers I have asked this simple question begin to stutter.
How can testers be taken seriously and how they learn a profession when they cannot explain what they do all day?
Only a few testers I know can come up with a decent story about their testing. They can name activities and come up with a sound list of real skills they use. They are able to explain what they do and why. At any given time they are able to report progress, risks and coverage. They will be happy to explain what oracles and heuristics they are using, know what the product is all about and practice deliberate continuous learning. In the Rapid Testing class (in NL) we train testers to think and talk about testing with confidence.
How about you? Can you explain your testing?
Interesting article.
I think it is also important to be able to explain what competence a tester brings to an Agile team. Why does an Agile team need a tester on it?
I think the key is to get to the bottom of what test competence actually is.
Started thinking about it and tried to summarize my current thoughts in a presentation:
http://www.slideshare.net/JohanHoberg/defining-test-competence
Then you also need to be able to show that and how you add value as a tester, but that is another topic in itself.
Best regards,
Johan
Nice post. It’s embarassing if people can’t explain what they actually do all day. But I’d also want to know who’s asking?
If it’s you or a fellow tester their answer should be easy enough to give. If the CIO asks, the answer is a bit more complicated (Keith Clain did a great short video about it). If it’s the PM, what are they asking?
Getting testers to be able to explain what they’re doing is a necessary first step, no question about it. I’m also wondering though why is that? Is no one in their company actually interested in testers explaining what they’re doing? My experience is that no, people outside testing just don’t want to know. They want to know if there are “qualtiy” problems (often without knowing what quality is) or when they can ship waiting for testers to say OK, done our bit (whatever that is). Questening testers may result in answers that people actually don’t want to know. So there is no culture of deep discussions about quality, risk and customer value.
Once testers can phrase what it is they are doing the next step is to start discussions with the business and educate (where necessary) about how testing can actually help the business. Once that happens testers are in the business of breaking illusions which in this context is a good thing, especially if the business asks for it in order to change and improve.
Thank you Thomas. I think any tester should be able to tell a compelling story to any of his/her colleagues: testers, devs, pm or managers. And yes, that will be a significant different story, since they all want different information.
If no one in a company is actually interested in testers explaining what they’re doing, the tester is doing it wrong! They ARE interested, but we need concise, compelling and tailor-made stories that meet the information needs of the receiver. That takes a lot of practice.
And I agree, once the testers is able to get peoples interest by being able to explain, we start to add value!
Great post, Huib.
I cannot deny the fact you have presented and the point you have made here. Why nobody takes tester’s job seriously most of the times comes down to the fact that majority of us are unable to explain plainly as to what we exactly do… I have met testers on both extremes of this spectrum…
Stephen Janaway has a similar post on this topic: http://stephenjanaway.co.uk/stephenjanaway/experiences/talking-testing/