How product quality is affected by the test automator role
What is happening to product quality?
Throughout my career as a quality engineer, I have developed a deep passion for quality. This passion goes way beyond the quality of software products. It is also about the quality of all interactions, quality of processes, and quality of work and life experience. I strive to bring excellence to every aspect of my life, and it hurts to see when greatness is lacking.
In my working life, I’ve seen the market focus shift more and more from quality to speed. We build more products than ever before; unfortunately, many of them are not up to par.
How IT organizations have tried to fix the degradation of quality until now confuses me sometimes.
The encounters with a test automator
It happens from time to time: I join a new team, and one of its members introduces themselves as a ‘test automator’ (or, more commonly, a ‘test automation expert’). Not all organizations have them; they don’t seem to be a mandatory part.
So, why do some teams need them where others do not? There must be some decisions leading up to these team compositions. What drives your hiring choices? How do you define roles for your teams? Is it all about following a market trend? And above all, do you get the expected value?
The rise of the test automator
I remember teams that were slow. They cared a lot about the quality, and therefore all of them had testers, doing exploration and manual regression testing. As products grew, the regression testing duration was becoming longer and longer. Regression testing was a visible constraint in the process. They couldn’t continue like that anymore; they wanted to go faster.
“If I had asked people what they wanted, they would have said faster horses.”Henry Ford
Well, we want faster testers! What is the car equivalent to that? – Test automation! The test automator was born – a tester who is not only doing testing faster but doing it automatically.
Wearing two hats
As a tester, now all of a sudden, you’re expected to be a car. You’re getting a tune-up, learning some automation skills, devour one tool after another. The transformation is complete. Now you can proudly call yourself a test automation engineer. What is expected from this transformed person, the test automator?
A brief look at job listings will reveal that the expectation is to do both – automation and exploration. Some of the descriptions are specific enough to say that you should have an ‘automation first’ attitude. So it is safe to assume that in most teams, a test automator is responsible for doing both.
How do you prioritize and balance between the automation and exploration of the product? Is it ok to do only one? Or both but partially? What do you leave not done? You can only spend time once.
We value speed over quality attributes so much that we confuse the people guarding the quality of our product. We create a disbalance by prioritizing the automation of checks, that promise a future increase in speed by being repeatable, and we forget about building an actual quality product.
Blame the bottleneck
Every approach has its pros and cons. While having automation engineers has many benefits, it also has some downsides. The biggest issue with this approach is that it creates silos, a single person in the team gets a monopoly on test automation. When something goes wrong with the automated tests, and it does often go wrong, the whole unit depends on this one silo to fix it. Over time distrust builds up in the team, and they condemn the tests.
It turns out that instead of removing a bottleneck, we have now created a new one. The test automator is not like a car. The role is not even as good as faster horses. The distrust diminishes the potential value of a test automator.
It seems obvious that having a single point of failure is undesirable, and yet so many companies design precisely that.
The fall of the test automator
There is a solution to this silo problem – a team approach, testing as a team effort. Quality should be a team responsibility! Both quality and speed are possible.
When it comes to test automation, developers are better skilled in designing and writing software, and test automation is nothing but software.
Teams still need a quality-oriented perspective to identify what to test, so developers should be actively involved in the process, working in close collaboration with testers.
Epilogue: The rise of the tester
When I think of a tester, I think of someone who guards the quality of the product throughout the whole process, from idea to production.
A good tester does that by bringing quality perspective to various team events.
A great tester also pairs up with developers on the story and continuously explores the product.
An excellent tester, a quality guardian, makes quality a team responsibility and coaches developers to be better testers.
Co-written with Jochum Börger.