agile opinion

Nuance on leaving testing to the experts

Non testers will always have views and opinions on testing. But it’s a problem when those opinions start impacting my testing in a negative way. Then I’m failing in my responsibility to perform testing to my best ability. The intent of control is to do a job well, not to hold power over people.

Yesterday I wrote a blog post entitled “Leave Testing to the Experts” to which Maaret quickly reacted online and by a post where she strongly disagreed with the sentiment.  Disagreement is a very useful tool to clarify your thinking, so thanks Maaret!.
It’s allowed me the opportunity to explain in more detail, why I think what I do, and to investigate some of the nuances on this topic.

Maaret, counter-argued with a convincing description of her egalitarian work place where opinions are offered and accepted in good faith. In truth it left me feeling a little envious, and a commitment to work harder on taking ‘being told’ as “bad communication with good intent”.

But I think this post misses a vital point and that is responsibility.

Taking on a role³ of tester comes with a responsibility to have testing performed to your best ability. So, if I listen to an opinion and follow it, knowing its wrong, I call that irresponsible. If I hire a tester based on likability over capability, that’s irresponsible. If I fail to highlight risk for fear of upsetting team members? Well, you get the point¹.
Perhaps you might say that testing is a collective responsibility, and we all own the decision. After all, in an egalitarian team such as Maarets, doesn’t everyone own quality? Isn’t everyone responsible for testing? Well, yes and no. Let’s explore that a bit by taking the pilot example.
It takes a crew to fly a large plane. There’s the engineers, the pilots, the cabin crew and many more. The pilot happily takes on other crew member’s opinions and ideas. Perhaps she listens to the engineer’s advice not to fly above a certain height. Or maybe she nods when a cabin crew member tells her that people like to hear from her voice more often. Perhaps her junior suggests a flight plan for the journey. She hears all this and takes it into consideration, but flying the plane is ultimately her responsibility². Even if part of that decision is to allow the junior to fly the plane for some of the journey. The buck stops with the pilot.
The crew is responsible for the whole flight experience, but the pilot is responsible for flying the plane.
Similarly, in a team, we’re all responsible for quality, each person may even be responsible for their own bit of testing but ultimately the testing buck stops with the tester.
Notice that everyone got to have an opinion? Similarly on a team, many people can perform testing and offer ideas on testing. This can be incredibly invaluable to testing as a whole. For example, developers have a keen insight into technical risk which can really help identify/dismiss areas that require testing. Teams that are test infected and have this testing mindset are often a joy to work with.
You don’t get a testing mindset if you’re prevented from exploring ideas, so I agree with Maaret that people should be allowed to offer opinions and experiment.
I worked with a team who wanted to implement BDD. I was skeptical. BDD seemed to me a bad fit for the context in which we were developing. There’s nothing like self discovery though and so the team went ahead and tried it out. It turned out to be a dud idea and it was dropped. It’s good to experiment and encourage exploration but there needs to be a proviso here and that is when the risk is low and the impact to the company is minimal.  
Back to the pilot. You don’t handover control of a plane to a junior pilot just as turbulent weather conditions hit. You might if they have more experience in flying, but as the senior pilot you will know when to take the wheel and when to allow practise. Someone who knows what they’re doing needs to make these decisions.
Also performing a small experiment when the risk is low is very different to adopting a strategy company wide. Dictating cucumber as a tool across an organisation is very different to performing an experiment within a team. To clarify, my lament on testing experts is in the context of organisations adopting ‘best practise’ strategies.
Maaret talks about everyone on her team ‘tests like an expert’. I think that’s great, her very capable team means she doesn’t have to exercise responsibility. She’s still responsible for the testing though, just as carrying a plane full of pilots doesn’t absolve the actual pilot of responsibility.
I’ll end this post with the comment about sales people. Maaret says she constantly offer views to developers and sales people. The truth is I have done that too. I guess everyone feels in some way their idea is good and has value and its nice to have your opinions heard.
I remember once querying a company’s sales strategy. I couldn’t understand why we only aligned with partners instead of also focusing on location. I brought this up with the sales manager who listened and then dismissed it explaining why. Personally, I still don’t agree with the approach, but I’m fine with his decision. Why? Because ultimately the buck stops with him. I’m cool with that.
Non testers will always have views and opinions on testing. That’s not a bad thing. In fact, part of me is glad they feel responsibility about testing. But it’s a problem when those opinions start impacting my testing in a negative way. Then I’m failing in my responsibility to perform testing to my best ability. You see, the intent of ‘claiming territory’ is to do a job well, the job I was hired to do, not to hold power over people through control.
I hope this makes sense. Like I said, I’m grateful to Maaret for her response and the opportunity to deepen my ideas on the topic.
³I considered adding the word specialist here as the concept still holds. A specialist (of testing) still holds the ultimate responsibility for testing, even if they don’t perceive themselves as a tester.
¹Many of these decisions are nuanced and are rarely black and white. For example, hiring a tester for a team fit is really important, but if you do so over capability you need to be able to back your decision with some sound logic. Context is important here.
²many people inside and outside a team test, so a tester isn’t responsible for doing all the testing, but they are responsible for the strategic direction and process of testing.

4 replies on “Nuance on leaving testing to the experts”

I already shared a comment on the first post, and this excellent one made me want to share another one. I like the way you precise your experience and the example you chose. I have a very high opinion of Maaret and I’d say she did a great job in the last years to help create a team like that. And she goes out and tells people that it’s possible.Yesterday I got a mail from Lisa Crispin in response to my blog post, and she also wrote about the influence she took on the development of Agile, and Lisa is a person who can do that and does a great job preaching those values.
But, there is the but again, reality looks different. And it’s about the 80-90% of the projects where things go wrong and responsibility is not shared and so on. It’s fantastic that it can work, that it only makes it worth more fighting for. But first we need to show the world the pain to make them want to change. Showing them how the world could be is usually not a good motivation for change. Showing them the reason why it would be good to change away from the status quo is usually better.
So let the experts do their job and drive the projects in a safe way to a better way of working.


I read your original post (and this one) as telling non-testers, “Don’t dictate to me about how to test.” That’s not nearly the same thing as saying, “Don’t bother to give me your ideas about how to test, because you’re not an expert and I won’t listen.”
Of course, I will listen to anyone’s ideas. Under normal circumstances, I will seek them out and consider them — and I expect you will, too, Anne-Marie.

But I’m sick of people who know zilch about testing telling testers what they must do, and expecting to be obeyed. It’s a thing I’ve been fighting for decades — mostly successfully, but it’s still a tiresome fight.

OTOH I’m delighted for those, like Maaret, for whom that fight doesn’t exist. That represents true progress in the industry, and a place we’d all like to get to.

It’s still pretty rare, though.

Thanks Fiona, I think you hit the nail on the head, with your distinction.
I think Maaret does battle, but it’s on a team level and she chooses(wisely I suspect) to approach it in good faith and in a more collaborative way.

But in many companies, I see testing as a battleground of ownership often between business and engineering. For business its a method of controlling and ensuring they get what they asked for. For engineering, its control over how they deliver. Both want it, and now some lowly tester enters the fray demanding to have say? These are big battles and if we are going to fight we need to be fully prepared. My experience is ‘good faith’ doesn’t always cut it. I’d like to be proven wrong in this.

Having read both posts I think there are some excellent points in each, and I must say the phrase ‘anyone can test’ is one the most annoying phrases to me as in my opinion it shows a lack of understanding of testing and what we’re trying to achieve.Having said that there are so many people around us who can offer such valuable support to testing in terms of suggestions/ideas/areas of high risk that can all help us use our skill and experience to figure out what to do with that information and use it in the most effective way.
There are always going to be ‘battles’ with various people or departments and every work place is different but I feel you have to learn how to manage this is the best way you can to ensure you get all the information you need without being ‘told’ how to do your job, especially as far more teams are working in an agile way it becomes even more important that (for example) you can go and sit with a developer and work through what they’ve done, understand what testing they’ve done and then figure out what you need to do next to ensure you are comfortable that testing has been completed to a high standard. As you said, ultimately the book stops with us but delivery is a team effort

Leave a Reply to Anne-Marie Cancel reply

Your email address will not be published. Required fields are marked *