opinion rant software testing

Leave the testing to the experts!

The truth is, most developers, project managers and business people don’t understand testing in any deep way. Instead they often resort to shallow imitations, an emperors test suite, if you will.

Why is it that in a company almost everyone has an opinion and knows the best way to test? What makes so many of these people feel they know how testing ought to be performed?
Business people tell me, the tester:

“You should be writing test cases and reporting against them”

Developers & technical people tell me to:

” automate the lot using cucumber/PACT/Selenium or some other niche technical tool” 

Test Managers (many who have never tested) tell me:

“You should be following a formalised signed-off testing process”

I find this quite extraordinary. I don’t tell you, oh developer how to code your program. I don’t tell you oh, sales person, how to sell your product.

So why do you think its reasonable and perfectly acceptable to tell me how to test software? 

Perhaps its because we all test to some degree. But just because I can build a car or sell one doesn’t mean I can drive it. Just because I know how to drive a car, doesn’t mean I go and tell a rally driver how to race around a track.

The truth is, most developers, project managers and business people don’t understand testing in any deep way. Instead they often resort to shallow imitations, an emperors test suite, if you will.  That’s partly the fault of the testing profession. We’ve failed to claim our turf and instead tugged our forelock, deferring ideology to those with authority but little understanding.

It’s time tester’s to claim some turf back. I suspect (actually I know) for many places it won’t be given up without a struggle. You’re going to need courage backed by confidence in your ability if you want to claim some of the territory. But it’s worth it. With space comes freedom and the autonomy to drive your testing strategy and process in a way that you know will offer value to your organisation and your clients.

Now, please get out of my way and leave the testing to the experts!

18 replies on “Leave the testing to the experts!”

Thank you for that post, Anne-Marie. This describes perfectly the situation I am in. People from different levels and other silos are telling me how I should do my job. Especially from the dev silo come claims how to work and what artifacts to provide, because that’s how testing at that place worked in the past one and a half decades.If those people know how to test, why do they need me at all? And if they don’t want to change the artifacts they get delivered, do they care at all or do they only want to tick a check box?
And I also add to your claim “most developers, project managers and business people don’t understand testing in any deep way” that too many people filling the role of testers don’t have that understanding as well.
Testers need to learn to provide better value than just fulfilling expectations. The industry (big consultancies, iSTQB and ISO29119 alike) maneuvered itself into a position where it’s more important to generate illusions by producing waste and bill lots of hours, have more people (mostly for importance reasons) doing slow and useless work. That’s why I claim that trends like Agile don’t attack testing, they simply don’t give a s**t about testing. Because they can live without that waste, and obviously many companies succeeding in Agile either don’t miss anything or they involved testers in a useful way.
So testers in general need to show what value they can provide, reinventing the way they work, proving to the other parties of a project that they are here for different reasons than what was perceived in the past.
Yes, we are the experts how to test, and need to better show that. Then other people hopefully stop to tell us how to work!

Thanks Patrick,

So testers in general need to show what value they can provide, reinventing the way they work, proving to the other parties of a project that they are here for different reasons than what was perceived in the past.

I’ve been in situations where I’ve performed valuable work and it’s been hugely beneficial to the company. In other situations I’ve performed valuable work and rather than been recognised it’s been discredited. There’s two ways of looking at this. The first is that even though I thought I offered value I wasn’t, because I wasn’t giving the stakeholders what they wanted, or I can take the view that value is a relationship, and like affairs of the heart, just because you love someone doesn’t mean they’re going to love you back. You can’t control how people will respond to your work and perhaps it’s unrealistic to expect?

I blogged on my response:
It might be that this blog post is about reaction to “strong opinions on stuff they’ve never even tried”, but I also read it as “no advice from beginners”. On the first, we need to encourage people to try. On the second, we need to listen without being offended. We miss a lot if we don’t hear out people just because they use the wrong words to our taste. Which is a problem I feel we’re in middle of a lot with testing, being corrected on words continuously even if the intent is genuine.

Thanks Maaret. I don’t want testers to reject anyone else’s ideas or opinions because they’re from inexperienced or non testers, though I can see now how that might be construed. This post is more than just hearing “strong opinions on stuff they’ve never even tried”, it’s about how these opinions can become reality and start to influence how testing is performed.
Let me explain with an example:

A product owner says to me: “I think we should automate all the testing”. This is a no problem situation. I’m happy to discuss that an explore why she thinks that. We can even experiment with some of her ideas.

But that’s different to this:

a product owner says to me: “All testing should and will be automated”. This is a problem. Now I’m in a position that potentially impacts my ability to make decisions on how testing should be performed.

Do you see the difference?

I hear you when you say we need to listen without being offended though. That’s an invaluable skill and we all need more of that.

Your post has helped me clarify my thoughts so thank you! I’m in the process of responding to it,hopefully my ideas will be clearer once this is posted.

Well said, AM! I will get posters printed of some of the quotes in this post and gives those to testers to place them at their work desks visible to project managers, devs, CIOs and others who have been telling testers how to test.Good work!!

We could always get out of our silo and talk to people. Explain what we do and interact. Might shut them up.

I don’t want to shut anyone up, I want the space to do a good job. People are totally entitled to their opinions, but when they become reality, and affect my ability to do my job, then that’s a big problem for me.

I wonder, why is it that those people tell you to test in a certain way? Could it be that they voice a requirement you neglect, but don’t know this is what they do?For instance, what if the business people ask you to report against a test case because now they feel they can track some imagined progress? What if in such a case you provided them with a more suitable metric? I recall hearing Joel Montvelisky (no links, as writing from my phone is bad as it is, sorry) claiming that testers are like salespeople for our information, and that we should serve it a form that will answer the needs of our consumers.
What if the next time someone tells you how to test you’ll ask them why do they want it. Sometimes you’ll get a response like “because this is how testing should be done”, in which case, showing that person the door is the reasonable response, but if the answer is along the lines of “because this way I could…”, you might have a new requirement, or you could show them a better way testing can help them with their goal.

Thanks Amit, you are right of course. We should check with our stakeholders to see if we misunderstand the mission. But it’s also sometimes a little too easy to put the onus only on the tester to successfully demonstrate value. Value is a relationship, and in any relationship it takes two people to make it work.

Thanks Anne-Marie. Good reading!
Your story is not uncommon in our testing world….and the reason is people always love showing their expertise by tell someone to do something in their ways.


I know what you are getting at, but I am an experienced tester that can grasp the content and overlook the title; however, some might not, and may never read the post, which would be a shame.
The blog title may suggest something you are not wanting to convey. My immediate translation of “Leave the testing to the experts!” was “Only test experts can test!” When opening the article originally, I thought it would be taking the position that you /must/ be a skilled tester to test, which is not true, or none of us would be in the industry. I am familiar enough with your content to know you’d never make such an absolute claim that applies to all contexts; however, some people may not.

So, having read it, I get your gist that those who don’t know a lot about testing are many times directing and prescribing practices that are not beneficial – yes, very common, seen it a lot. But if I read the blog title in my feed and move on, I might do so because I feel that the author is someone who maybe thinks test swarming is a bad idea and leading unskilled testers cannot be done with any success so I (some far off manager, product owner, developer, director, VP, etc.) would take a pass on reading it because the title may give off too much of an ‘ivory tower’-ish vibe.

Thought it at least helpful to know that about the language of the title, as the content is great, and I know you don’t want to convey something that you were not intending. Take this advice and chalk it up to an inconsequential semantic, but I’d hate for those who really need to read this, overlook it instead.

The timing for your post couldn’t be better. I just came from an interview for a test automation (i.e. their words for automation in testing, not mine) position. It was exasperating. I was trying to steer the conversation away from test plans, test cases, and generally following the paint-by-numbers, ISTQB, dumbed-down “process” toward more expansive, constructive subjects like exploration and answering the question of what we are really after when doing these things. I was constantly being pulled back to going down the list of what should be the only thoughts that enter a tester’s mind: “But you haven’t told us yet what should be the process. We can’t complete the check-list of interview questions until you’ve rattled off ‘Requirements, Test Plan, Test Cases, Execution’. Until you say these things, we won’t believe you are a tester, no matter how much you go on about exploration, heuristics, rapid-learning, and viewing automation as one of many tools used by a tester, only according to the context.” Of course this is a paraphrase and I took many of these sentiments to be implied, but this largely sums up the conversation. I wish we could have just talked about testing and whether the position was a good fit for me. I guess it is as you said, a relationship must have two sides. When only one side gives and not the other, it isn’t a relationship, it’s a fantasy.

Leave a Reply

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