Dear Agony Ant,
My team is split over manual vs. automated testing.
The manual testers feel undervalued, and the automation folks think they’re the future.
How do I mediate this brewing war?
4 Likes
They’re both right. How to mediate depends on your current strategy.
Why do you have manual testers?
Why do you have automated testers?
Are the manual testers the remnants of a previous strategy? Or does your current strategy utilise both?
Is this a cultural problem? Potentially toxic elements within it? Or is it the natural consequence of your strategy and quality process?
So many questions here 
1 Like
There shouldn’t be such a “war” in a professional environment. This conflict likely indicates underlying issues within the team. Make all team members feel valued and appreciated. Both manual and automated testing play crucial roles in the overall testing strategy. Manual testing offers insights that automated scripts might miss, while automation increases efficiency and coverage. The future is uncertain and both approaches are essential for success. Let’s work together, recognizing the strengths each brings to the table. I would handle such a situation like that - simply straightforwardly and cut out any nonsense harshly 
2 Likes
I don’t think vague statements of idealism are very helpful.
1 Like
If you have them doing the same things and working to the same strengths where they are both focused on known risks and test in a way suited to machine strengths the reality is that the value of those not using automation is likely to be less.
That is often the starting point, now if hopefully you can rule that out you can then take a step back and look at the very different things they can bring to the table so that both roles are highly valuable in their own right.
Automation generally suits the model of testing like a machine so when you build those tests you look to get the most out of that model. Known risks, high volume, speed cases, large data sets, scripted, repeatability, broad re-use, optimised coding practices, maybe broader coverage.
Here you are building something that leans towards machine strength and you will be mixing test design and coding skills to achieve those goals.
If you are a manual tester and your coverage looks the same as what the automation engineer is aiming to cover, testing like a machine, scripted, repeatable known risk coverage I can clearly see where that feeling of undervalued is coming from.
It’s very different though if your manual testers have a very different model that has a very strong bias towards human strengths rather than machine strengths.
Embracing the unknowns, context aware, variability, exploration, discovery, learning, evolving, investigation, experimentation, choosing the right tools for job at hand, a large toolbox to support this, collaboration, empathy and bringing these very human strengths to your testing.
If your manual testers are going down that latter boldly embracing the unknowns path then it usually just enough to get awareness and understanding of the very different goals and value and how both are warrented.
If its the former though, then likely change is required as you could be testing like an inefficient machine rather than a very human tester. On the plus side humans are very good at learning and evolving.
Seems like they might have forgotten that they have a shared goal and are part of a team. Whenever one person or group claims to be the sole provider of the be-all, end-all of solutions it’s bound to alienate people and make them defensive. That’s not the right attitude to have; it’s not a competition.
If it were me, I would put together a workshop to help them rediscover their shared goals, and how they both have a valuable part to play in that.
2 Likes