QA in 2026: Panic or Evolution
You arrive at the company’s all-hands meeting: it’s announced that costs need to be cut as revenue isn’t meeting expectations: fewer business trips, the CEO keeping a close eye on spending, and a pay freeze.
Weeks later, another meeting: the measures announced previously aren’t enough. Now words like redundancy, dismissal, or restructuring are entering the conversation.
You’re in QA. You’re as nervous as anyone else.
If this sounds familiar, you’re not alone. According to Manfred’s latest Tech Career Report 2025, QA & Testing is one of the hardest-hit roles in recent years: fewer job openings, falling salaries. And the arrival of AI is only accelerating the trend.
But the data is the consequence, not the cause. Underneath lie real problems that we have been ignoring for years, and which are now taking their toll. The good news: with a few shifts in approach, we can change the perception people have of us.
Nobody knows who we are or what we do
QA Tester. QA Engineer. QA Automation. QE. Quality Coach. SDET, … and keep adding whatever else comes to mind. Every company calls us whatever they like. Sometimes for the hype, sometimes because a fancy title attracts better talent. And if we’ve read it from an American company, all the better.
But the problem isn’t the job titles: it’s that every company interprets the role and what QA does in its own way. In some, you’re the one who breaks things before production. In others, a column in Jira called ‘ready for QA’ (or worse, with your name on it). In others, you’re ‘the quality guy,' but nobody really knows what you do there. Or the one who automates the tests. And the different contexts and interpretations aren’t bad, but they generate different and sometimes contradictory narratives.
And here’s a question I ask myself: are we clear on this ourselves?
Testing ≠ Quality
Before we continue, let’s think: which has higher quality: the €9.99 Ikea table that millions of people have at home, or a €200,000 Ferrari driven by a few thousand?
Almost all of us would say “the Ferrari” without a second thought. And in part, that’s true. But let’s think about the table: it does exactly what it promises, it supports whatever you put on it, costs very little and can be assembled in under 10 minutes. That’s quality too.
Quality isn’t about price. It isn’t about luxury. It isn’t the absence of errors. Yet we still think a product is of high quality when it has no errors. And here lies the main problem: why do we call it quality when we mean testing? And vice versa. They are different things, even though we use them as synonyms.
- Testing: It is an activity: it involves verifying that the product does what it is supposed to do. Running test cases, finding bugs.
- Quality: It is a property: of the product, of the process, of how we work, of the user experience, of the impact on the business, of the culture and of the way the company operates. It is a cross-cutting and overarching property.
Confusing the two is the root of almost all the problems that follow. As a good friend once told me: “Testing ≠ Quality, but quality includes testing”
Everyone preaches about quality. Few practise it.
You’re hired as an expert to add value. In the first few days, you talk to tech leads, developers and the product team. Everything goes well. Everyone wants a quality product; everyone wants to get involved. The alignment seems clear.
Weeks go by. And you remain the only one testing the releases, the only one automating, the only one generating the metrics they asked you to define but which nobody looks at (or which they reject because they keep demanding test coverage, that vanity metric which, without context, contributes nothing).
Months go by. You keep testing, automating, reporting bugs. When you insist on changing something, they tell you that right now the business needs exactly what you’re doing.
Verbal commitment: plenty. Real commitment to changing the mindset/way of working/culture: little.
The problem with navel-gazing
Let’s look at a product team. Each role focuses on its own metrics:
- Business → revenue and users.
- Product → features delivered.
- Development → tickets closed, velocity, development time.
- Testing → tests run, automated tests, bugs found.
And who looks at the overall quality? Who asks whether what is delivered is worthwhile and whether it adds value for our users and the company? No one. And this is where QA needs to step up and lead this cross-functional approach. Shared responsibility, yes, but with QA taking the lead.
What a QA should do, but rarely does
If quality is as defined above, a QA is not ‘the person who tests.' Or not just that. A QA should work on three fronts:
Understanding the business. Do you know how much revenue your company generates? Do you know its churn rate? Do you know how much money is lost for every hour the product is down? If you answered “no” to any of the three, that is exactly why the business doesn’t listen to us.
Understand the system. How the product is built, where the chain breaks, how information flows between roles and departments. Ask uncomfortable questions. Testing, of course. And knowing the technical side too: strategy, shift-left, validation, processes.
Understanding the user. As a person, not as an abstract entity. And translating what happens to that person into the team’s day-to-day work.
We’re not just the ones who click buttons or automate tests. We’re the ones who must champion the importance of quality and testing.
Do we speak the language of the business?
When the CTO or CEO asks, “How’s quality looking?” and we reply:
“We’ve run 450 test cases, 200 of which were automated. There are 23 open bugs and 12 critical bugs resolved in this sprint”
Do we really think they care? Do they even understand it? The business cares about something else:
- Are we going to lose customers because of a bug in production?
- Is time-to-market at risk?
- Are we spending money and time fixing things we could have avoided?
- Do people trust what we’re releasing?
If we QAs only talk to other roles in terms of QA metrics, they won’t understand us. And if they don’t understand us, we’re an expense. Not an investment. And expenses get cut.
The question
Ask your product manager, your tech lead, your CEO:
What is quality in our product?
Let’s see what they say. Let’s see if their answers are similar. Spoiler: they won’t be.
This is where, right here, our real work begins.
And now let’s go back to the beginning. To that meeting. To that nervousness. The next time there’s talk of cuts or situations where our work might be called into question, what will decide our future won’t be how many tests we automate or how many bugs we find. I wonder if anyone in the business can explain, without us being there, why our work matters.
Want to know a little more about who wrote this article? 👇
Quality engineer with 20 years’ experience building QA teams. Specialist in automation, CI/CD and quality strategy integrated from the start of development.