Hello everyone! I’ve been involved in test automation for over 10 years. I can’t say that I have a full view of the entire market — after all, I work on my own projects for long periods of time rather than jumping between them. So, even after a decade, I haven’t seen that much. But recently, I’ve started noticing a trend that I don’t really like — testing is increasingly shifting towards developers.
Perhaps the reality is different, and it’s just a cognitive bias where I look for confirmation of my theory in everything around me. Do you see the same thing that I do?
How a neural network envisions the shift of the testing pyramid towards development
Disclaimer
I’ve been working on my project for a long time. I attend conferences and occasionally read articles, but I don’t claim to have an objective view of the market. What I’ll describe below is solely my opinion and by no means a comprehensive analysis. Please correct me if I’m wrong.
The Testing Pyramid
We all know this image:
Some aspects of testing, like unit tests, have always been the responsibility of developers. You could imagine that somewhere between unit and integration testing was the level where responsibility was divided between developers and testers. However, I’ve noticed that recently, the higher levels of the testing pyramid are also being pushed onto developers. It’s as if the pyramid is shifting towards development.
I see this as a violation of the principle that everyone should focus on what they do best, as they are likely to excel in it. Of course, developers are offered some courses in this setup, which introduce them to the basics of testing — how to write test cases, how to apply them to the application. But is that enough?
I love my profession and firmly believe that while you can become a developer, you have to be born a tester. Some skills can’t be taught — you need to have a certain mindset. A tester needs not only a technical background but also attention to detail, persistence, and critical thinking. There are plenty of attentive people who aren’t persistent, and vice versa — persistent people who aren’t particularly attentive (even though these traits seem connected at first glance).
It’s great if testing tasks happen to fall on a developer who has the right qualities but just chose a different path at some point. However, that’s often not the case. I’ve seen people who are passionate about testing but don’t necessarily have all the required skills.
Developers shift
It seems that the number of developers has been steadily increasing over the years. This makes sense — companies now have the money and the understanding that this work is truly worth the investment. They offer more and more jobs with good salaries, so graduates (and not just graduates — anyone with the drive) are flocking to development.
Some public figures have even stated that the market is nearing saturation. I remember one big guy comparing the situation with developers to the rise in popularity of lawyers and economists in the late 90s. It’s a debatable claim, but perhaps he knows better.
Whether there’s saturation in development or not, I won’t speculate. But in testing, there’s definitely no saturation — there has never been an oversupply of qualified testers in the market. It feels like the number of testers hasn’t changed at all. Still, since there are more and more developers, the proportion of testers naturally decreases.
Perhaps the transformation of testing from a specialized profession into a role that can be assigned to a developer, analyst, or even a technical writer is driven by the desire to cover existing tasks with a small number of qualified specialists. The tester (as a specialist) begins to oversee quality, while tasks related to test automation are assigned to colleagues.
Practice
I get the feeling that teams experimenting with testing aren’t entirely sure what they want. It’s as if the tester (who, as I mentioned earlier, oversees quality) is expected to walk up to the developer, give them a punch on the head, and say, “Do it right!” — and then everything will work smoothly. It seems like the tester, who was “born to be a tester,” is supposed to teach the developer to be “born” the same way. To me, this outcome seems doubtful.
From the developers’ perspective, the situation seems equally strange. Development is already being pushed to speed up in every possible way — market competition is fierce, and companies are trying to capture a larger share of customers by releasing solutions as quickly as possible and with as many features as possible. Developers are already handling this heavy workload without even considering testing. When part of the testing tasks is shifted onto developers, they still have to spend time on their own tasks — building those very features that are in ever-increasing demand. Where is the time for all this?
As a result, I see an overall decline in quality across the market. In apps used by millions, bugs emerge like bubbles and take months to fix. That’s a huge delay for such solutions. I notice this not in just one company’s app, but across the board.
I don’t have an answer for how this should actually work in today’s business environment. Maybe this is how it’s supposed to be, and in that case, the shift of the testing pyramid is perfectly normal.
What do you think?
Author: Vladimir Vasyaev, Maxilect
PS. Subscribe to our social networks: Twitter, Telegram, FB to learn about our publications and Maxilect news.
