Why I call myself a tester

I’ve been sadly busy, finishing a cool project with much learning, and preparing to leave my current employer Revolution IT for Aegeon. This means I get to have another crack at building an army of testing ninjas and sending them out into the world to hopefully make it a better place. Hopefully, that means less blogwebs (the digital form of cobwebs) too.

Ben Kelly, testing martial artist (literally, in this case) and recent blogger threw a question my way which I’ve answered before, but hadn’t really ever had to answer for testers in my team. It went something like this:

Ben: If quality can be described as ‘value to some person (who matters) and testing can be paraphrased as ‘questioning a product in order to evaluate it’, would you describe quality assurance as ‘interpreting the answers to said questions in order to provide information about the quality of said product to someone (who matters)’ ?

I rambled:
Quality assurance should be about ‘Is our process appropriate?’ That is, is it providing the right value to the people that matter.

Ben: Hmm, okay. Quality control is probably more appropriate then.

I rambled some more: I see your point though…One of the ways we assess the success of our development approach is by looking at testing. It’s just not the only way. It would more likely start with questions like:

– ‘What questions didn’t we ask’? That is, what problems escaped into the wild?
– ‘What didn’t we do?’
– ‘What are we doing that is a waste of time, or not helpful?’

Ben: I’m trying to condense the definitions of these terms so that they’re not overly verbose and still retain their meaning – I’m still working on that presentation 🙂

Me: So, Quality Assurance is typically assessing the whole software-producing system. Quality control is checking the output of the production process. Quality assurance is checking the process itself. That’s my model, at least.

Ben: That’s inline with what I’m working to. Maybe I don’t need to go into the definitions of these with the new guys right away. Maybe I should let them get their head around the definition of what testing is before I say ‘By the way, testing is not quite the same animal as QA or QC’

Me: It becomes relevant when test groups are called QA and think somehow that they actually do assure quality.
If your team is under that delusion, maybe it’s worth spending some time dispelling it. Testers can provide information about quality. They can’t actually force anyone to do anything with that information.

I want my testers to think:
“I am not assuring quality.”
“I cannot remove bugs.”
“I cannot stop developers creating bugs.”

This is obviously not always true, if we consider our ability to contribute to removal of requirements defects, but that’s not always an area we’re able to contribute to. If we’re not the prime owner of the requirements process, our role is still mostly about pointing out problems and making a compelling case for those problems to be addressed.

It’s potentially problematic for non-testers to think that they have this power though, and it’ s generally bad for the team if testers believe they can do it. Primarily, our role is to provide information to allow others to make good decisions.

Ben: Hmm, I might put it in to my presentation after all.

Me: Yeah, it probably belongs on a ‘What is testing’ slide. It stops your new testers beating themselves up for things that they shouldn’t. It lets your experienced testers defend their practice and not be beaten up by others. Or rather, starts your testers on the path to understanding the scope of their role and communicating that scope to others, setting clearer expectations of what to expect from a tester.

Ben: Something we could stand to do more of here. Excellent. Thanks as always for letting me bother you.

And thanks Ben for bothering me with something that I didn’t realise I needed to. Agile projects change the game a little, but for software, the primary focus of QA is on getting better at producing something that satisfies our customers, through code. Taking on the QA mantle is about telling managers, developers and analysts how to do their job better. And my super powers don’t yet extend that far. I encourage my testers to know their limits too.