Dark patterns: Downsizing QA teams in the age of AI
Why this may be happening and why optimizing for the wrong things could land your teams and orgs in trouble and a pragmatic take on what to do instead.
Disclaimer: This blog reflects my own original thoughts and views and not that of my employer.
I have been observing a disturbing trend in the QA part of the Software Industry for a while now and I don’t see that many people talk about it openly.
Before that, let’s refresh our memory on how the QA landscape has been evolving.
Somewhere around 2019, the narrative was along the lines of encouraging QA teams who focussed their energy on manual testing in favor of learning and developing automated testing.
Multiple incentive structures (better pay, more leveraged work, faster iteration time) encouraged most testers to join the bandwagon and learn how to code, build test frameworks, test infrastructure and shift fully towards becoming Automation Engineers or SDET’s (Software Engineer in Test). Many large companies had both these roles open with a mix of technical depth and breath requirements. I wrote about it in Deep dive into evolution of testing organizations and How WhatsApp tests software?
Some QA engineers found it easy to navigate this change, while others found it quite hard to pick up the required skills.
I kept hearing terms like API first automation, 100% automation, Automation first approach, Shift left, Quality is everyone’s responsibility and also saw extremely skewed Developer to Tester ratios pushed down as org mandates and QA teams still adapted. Somehow…
I now see something entirely different happening since the past 2 years (2024 onwards). As I write this in mid 2026. ChatGPT, Claude Code, Agentic AI and AI Engineering are accepted verbs industry wide and QA is also impacted with this change like any other function.
Although somewhat more disproportionately.
I see an extremely disturbing trend towards companies reducing, laying off or removing individuals who are in QA space, currently working either as a QA Engineer, QA Automation Engineer or in some cases Software Engineer in Test (SDET) as well.
This is happening at companies of all sizes; BigTech, high growth startups and product companies as well. I have seen subtle variations of this, leaders doing silent layoffs, giving a forced mandate to shift to other roles like Developer, Designer or product manager with strict timelines or outright culling the entire department itself.
I’ve talked to many individuals during my mentoring sessions on Topmate either directly impacted due to this or them observing this pattern happening in their companies. This is forcing individuals to either:
Look out for another company with a stronger testing culture and stronger QA leadership where they feel psychologically safer.
Move out of the QA role itself and make a career transition into other areas like Development, DevOps, Security, Product or Engineering Management, many of them considering taking a level and pay cut as well if required to make the initial transition.
Is AI to blame here?
I have not heard concrete reasons for this from the decision makers end apart from reinforcing their own mental models and biases about QA and Testing
Most of the companies doing this move are profitable, some facing market and investor pressures to reduce cost. Reasons are as diverse as they come, like macro economic conditions, end of zero interest rate era and over hiring during covid phases during 2023 and AI. I have also heard few leaders echo thoughts like below (i’m paraphrasing, so please take it with a pinch of salt):
We can automate most of the tasks that QA does now. AI agents have increased coding velocity and brought new capabilities, and our small team of developers should now be able to act as the QA for each change and evaluate/steer or correct AI output.
We can also hand off testing to the Agent itself wherein it writes and fixes tests and having yet another independent layer of human driven testing will just slow down the pace of delivery.
QA has always had to fight to show its value with proof over and over again. I’m not surprised that such bad mental models can be easily reinforced.
The decision makers have often risen through the career ladder as former Developers and have a deep seeded bias for developer testing. When faced with a choice around budget, who do you think the leaders would look to downsize first?
QA seems to be an easy scape goat, often not having a strong voice in senior leadership circles and also not able to articulate their value proposition or deliver business impact that leaders really pay attention to.
This is an uncomfortable truth of the QA industry. I personally don’t agree with this shallow line of reasoning at all and also don’t appreciate the tough spot the entire tech industry is putting QA folks in. Naturally this makes a huge dent in the psychological safety of individuals who have grown to love the craft and feel strongly about testing, its community of fantastic people championing it everyday often with little rewards.
I also fear that this would discourage other people from trying this role in the future.
On one hand, I see leaders calling out that Quality and Security are company wide priorities, on the other hand the focus is mostly on developer testing, enabling product and infra teams to build their way out of the testing hole with more tooling, augmented by AI. Developer driven testing is great, we need more involvement from everyone for sure, but I often find it hilarious when teams feel comfortable shipping products to their customers after writing a few automated unit tests and checking basic happy path and few sad path scenarios by hand in their own dogfood runs. Often with little to no consideration of other functional or non functional aspects or bothering to focus on a holistic testing coverage or strategy.
From the testing practitioner standpoint, AI is the elephant in the room, pre AI many engineers took a lot of pride in being able to not only come up with robust testing strategy and plan, but also hand code the tests. There is a growing anxiety that, If AI can generate automated tests (unit, Integration, E2E) faster and more accurately, how is a testing specialist on the team helping? What value does an independent cycle of testing actually provide?
Everyone understands that Quality is extremely important. You can only ignore it at your own peril and risk eroding trust of your customers and stakeholders, sacrificing growth and of course significant monetary loss. The consequences are real, and when subtle or obvious bugs ship to production, they usually become news for major news outlets, it ends up with someone high up resigning and moving on to save face.
Have we seen this before?
Developer driven testing and automation is not new.
If you see major tech companies, many of them don’t have dedicated QA teams like before and they have mostly delegated responsibility of writing automated tests to developers or outsourcing E2E testing to consulting and outsourcing companies for a lower cost.
I came across Modern Testing as a concept way back in 2014, when Microsoft made the transition to Unified engineering and converged Development and Testing roles into one single role. It proposed principles that Quality engineering teams can follow and which mostly sound reasonable with the caveat that you improve testing culture on the teams to such an extent that your presence may not be needed itself. That may be a bit more idealistic in nature but still sounds reasonable.
As the pace of delivery increases with AI, many leaders in startup and product companies look up to larger scale tech companies or scaled start ups with deeper profit pools to take inspiration from. Most often, they may even try to blindly copy other companies’ playbooks in the hope that they will also scale.
This often does not lead to desired results as you can’t retrofit culture even if you want, it has to be grown organically.
If you are a leader, what should you do?
Depending on the point of view and perspective you are coming from, you may have mixed opinions on the value that a QA team provides to your team and orgs.
Let’s take a step back, keep an open mind and take an honest look at where exactly your company, product and engineering teams are.
Who are your customers? What do they need?
Are you happy with the quality of the products and services you are serving to paying customers?
Where are the gaps?
What bugs and pain points are eroding your customers’ trust every day and leading them to evaluate or choose your competitors? Do you care?
Is your engineering team and processes working well as a cohesive unit?
What is the incentive structure for engineers to produce high quality bug free products?
When an incident or bug is discovered, how do you go about identifying, fixing and then ensuring the same issue does not happen again?
These are only a few of the considerations.
Does QA add value?
For e.g. this blog Who the heck is an SDET? gives intuition on what an SDET can do for the team and the domain they operate in. A skilled SDET is like a supercharged developer who for some reason is extremely motivated to ensure your product, tools, processes are all geared towards producing high quality software even without writing a single line of production code.
Also, a skilled QA is actually a hybrid between a product manager and a developer, able to think in both directions and bridge a lot of discussions connecting user experiences and technology, asking the right curious questions and poking and proding on if the results produced were actually desired.
I can go on and on about this.
Your engineering team is one of the greatest assets you will ever have and also a living breathing organism; don’t treat them like cloud resources from cloud providers. It is not easy to spin up a well oiled, collaborative and productive team. When you have that secret sauce, encourage and nurture it. It may really surprise you what a group of well motivated individuals working well together can produce.
When you make snap judgements and decide to go down a certain direction of laying people off and shifting responsibilities around, you have to understand and appreciate the fact the underlying work still needs to be done.
Someone needs to care enough about Quality and customers to tell you no, that the product quality is not good enough to ship. That person can very well be your developer or even your automated test infrastructure signal but you still need people with experience and conviction to stand up to you. This is the reason why an independent QA pillar sometimes can be a hedge to balance the need for unsustainable speed of delivery.
A developer reporting directly to you or your management chain with N other priorities may not love the idea of pushing back because some pesky tests are still not passing. A QA certainly does. It’s somehow in their core intuition and blood and they are not really afraid to tell you so, in gruelling detail. Well, most of the time, if they have been brought up well by strong mentors.
Should I downsize and not remove?
Say you choose to not remove but downsize your QA team.
Does 10:1 Dev to QA ratio sound fair to you? No person can keep up with 10 developers’ velocity especially with AI acceleration in place. Your QA team will always be in fire-fighting mode and would not have the breathing space to actually do their job, which is to evaluate the product state holistically, mitigate risk, find critical issues, care about the customer experience and help you decide if you can ship or not.
It is also not helpful to always keep your team in perennial distress around deadlines. You may think you are building a high performance culture and you may get the same effect for a period of time, but it’s not sustainable. People will burn themselves out and then move on to greener pastures. Some deadlines are good to motivate, but you should always accept reasonable explanations for why things are not moving at the pace you think they should. If only you were more hands on, you would appreciate the day to day that your team has to go through to get something done.
I see my competitor doing fine without QA
But, what about company X, they seem to be doing fine without QA?
You can try to compare yourself to high adrenaline silicon valley start ups with N million run rates with/without product market fit and say “hey, they are able to do it”.
But … hold on, take a breath.
You are not them. Your context is unique. Respect that and move forward in a way that is fair to your people. If your mental model is that QA does not add value, ask yourself have you tried talking to them 1:1, you may have some inner deep seeded biases and sometimes simply talking to others can give you a lot of clarity.
I’m not against developers testing their code. In fact, when this happens you mostly get better tested code and products, but an independent verification by a person who is passionate about quality does make a difference, the signal generated is really valuable and you should be curating and nurturing a high quality culture in your teams and orgs.
QA also holds a lot of shared context in their brain, a mix of tech and business which is extremely useful to identify failure points in a system architecture way ahead of time and might I say, extremely cheaply.
Move fast, but don’t break things. Always keep the customer in your mind and obsess over their experience.
I’ll leave it at that and hope that this gives you enough food for thought.
If you are in QA, what can you do?
I know this situation sucks, big time.
So far, if you have been reading this blog, you may be raising the alarm bells in your mind and it may have also triggered PTSD (Post traumatic stress disorder), your fight or flight responses.
I apologize, the intent of this blog is not to make a dent in your psychological safety, but make some rational arguments.
Let’s take a couple of deep breaths first, shall we?
Firstly, this is not an industry wide phenomenon, yet. I have come across 5-7 companies in my local context where I have seen this happening by talking to impacted individuals. Overall if you see LinkedIn or other job platforms, many companies and orgs are still hiring for QA folks and the pipeline is healthy.
Social media may be portraying the coming of AGI (Artificial general intelligence), end of jobs or snake oil promises of a brilliant Sci-Fi future where Software engineering let alone testing itself is meaningless and AI will do everything. But, we are not there yet. People making such bold claims either profit from the fear mongering directly or are simply too far removed from the low level details to make anything other than speculation.
Does this mean you can relax and do things as you have been doing forever?
No, that would be bad advice or take to accept.
You should definitely strive to learn and grow your skills to work effectively with automation and AI. These are all tools in your tool kit and you should make ample use of them to make your life easier as well as improve quality across the board. If you are curious about what the different areas could be for you to invest in, you can talk to me on Topmate or LinkedIn and I’m happy to have a discussion or read ⚡️ SDET career roadmap: from entry level to staff engineer. I still feel like while AI augmented workflows are interesting and powerful, we still have a place for human engineers in this world.
If you decide to switch to a different role, it is entirely your choice. No judgement at all. Do what you feel most strongly about.
You will have to pick up the necessary skills, ideally make an internal transition first in your own company and then change companies if required. It won’t be easy but if that is a path you are convinced about, please do whatever makes you feel more comfortable for your own mental health and family. I would advocate for Good habits for Software Engineers and we have to ground ourselves in the fact that it is just a job at the end of the day. Not your whole life.
My only advice would be to pick an area, in which you have genuine interest, curiosity and passion about, without that it may not really stick. If you are not sure what that is, try a bunch of different roles and see which one sticks out for you. Careers are long.
So what now?
I don’t think this is the end of QA.
If anything as more and more of SDLC (Software development lifecycle) gets automated either by sophisticated Engineering systems or AI, it will only generate more need to ensure the outcome produced is high quality. It would be a collective responsibility but someone needs to drive it, to ensure they optimize for “if we have built the right thing or the thing right”.
With more software being produced, more testing would naturally have to happen, although the nature and shape of it may evolve.
Remember, Every non software product that is produced (from your purifier, washing machine, electric/gas meters to even space rockets) are rigorously and meticulously tested either before or by market forces and only the teams that have produced better and higher quality experience would win.
Testing and QA will endure, it’s not going away anywhere. No matter what people selling you their own SAS (Software as a service) may be telling you.
It really takes a village to get such products shipped and I think QA has a major role to play in this journey and I still hope you will choose to be part of that journey.
Disclaimer: This blog reflects my own original thoughts and views and not that of my employer.
I have been observing a disturbing trend in the QA part of the Software Industry for a while now and I don’t see that many people talk about it openly.
Before that, let’s refresh our memory on how the QA landscape has been evolving.
Somewhere around 2019, the narrative was along the lines of encouraging QA teams who focussed their energy on manual testing in favor of learning and developing automated testing.
Multiple incentive structures (better pay, more leveraged work, faster iteration time) encouraged most testers to join the bandwagon and learn how to code, build test frameworks, test infrastructure and shift fully towards becoming Automation Engineers or SDET’s (Software Engineer in Test). Many large companies had both these roles open with a mix of technical depth and breath requirements. I wrote about it in Deep dive into evolution of testing organizations and How WhatsApp tests software?
Some QA engineers found it easy to navigate this change, while others found it quite hard to pick up the required skills.
I kept hearing terms like API first automation, 100% automation, Automation first approach, Shift left, Quality is everyone’s responsibility and also saw extremely skewed Developer to Tester ratios pushed down as org mandates and QA teams still adapted. Somehow…
I now see something entirely different happening since the past 2 years (2024 onwards). As I write this in mid 2026. ChatGPT, Claude Code, Agentic AI and AI Engineering are accepted verbs industry wide and QA is also impacted with this change like any other function.
Although somewhat more disproportionately.
I see an extremely disturbing trend towards companies reducing, laying off or removing individuals who are in QA space, currently working either as a QA Engineer, QA Automation Engineer or in some cases Software Engineer in Test (SDET) as well.
This is happening at companies of all sizes; BigTech, high growth startups and product companies as well. I have seen subtle variations of this, leaders doing silent layoffs, giving a forced mandate to shift to other roles like Developer, Designer or product manager with strict timelines or outright culling the entire department itself.
I’ve talked to many individuals during my mentoring sessions on Topmate either directly impacted due to this or them observing this pattern happening in their companies. This is forcing individuals to either:
Look out for another company with a stronger testing culture and stronger QA leadership where they feel psychologically safer.
Move out of the QA role itself and make a career transition into other areas like Development, DevOps, Security, Product or Engineering Management, many of them considering taking a level and pay cut as well if required to make the initial transition.
Is AI to blame here?
I have not heard concrete reasons for this from the decision makers end apart from reinforcing their own mental models and biases about QA and Testing
Most of the companies doing this move are profitable, some facing market and investor pressures to reduce cost. Reasons are as diverse as they come, like macro economic conditions, end of zero interest rate era and over hiring during covid phases during 2023 and AI. I have also heard few leaders echo thoughts like below (i’m paraphrasing, so please take it with a pinch of salt):
We can automate most of the tasks that QA does now. AI agents have increased coding velocity and brought new capabilities, and our small team of developers should now be able to act as the QA for each change and evaluate/steer or correct AI output.
We can also hand off testing to the Agent itself wherein it writes and fixes tests and having yet another independent layer of human driven testing will just slow down the pace of delivery.
QA has always had to fight to show its value with proof over and over again. I’m not surprised that such bad mental models can be easily reinforced.
The decision makers have often risen through the career ladder as former Developers and have a deep seeded bias for developer testing. When faced with a choice around budget, who do you think the leaders would look to downsize first?
QA seems to be an easy scape goat, often not having a strong voice in senior leadership circles and also not able to articulate their value proposition or deliver business impact that leaders really pay attention to.
This is an uncomfortable truth of the QA industry. I personally don’t agree with this shallow line of reasoning at all and also don’t appreciate the tough spot the entire tech industry is putting QA folks in. Naturally this makes a huge dent in the psychological safety of individuals who have grown to love the craft and feel strongly about testing, its community of fantastic people championing it everyday often with little rewards.
I also fear that this would discourage other people from trying this role in the future.
On one hand, I see leaders calling out that Quality and Security are company wide priorities, on the other hand the focus is mostly on developer testing, enabling product and infra teams to build their way out of the testing hole with more tooling, augmented by AI. Developer driven testing is great, we need more involvement from everyone for sure, but I often find it hilarious when teams feel comfortable shipping products to their customers after writing a few automated unit tests and checking basic happy path and few sad path scenarios by hand in their own dogfood runs. Often with little to no consideration of other functional or non functional aspects or bothering to focus on a holistic testing coverage or strategy.
From the testing practitioner standpoint, AI is the elephant in the room, pre AI many engineers took a lot of pride in being able to not only come up with robust testing strategy and plan, but also hand code the tests. There is a growing anxiety that, If AI can generate automated tests (unit, Integration, E2E) faster and more accurately, how is a testing specialist on the team helping? What value does an independent cycle of testing actually provide?
Everyone understands that Quality is extremely important. You can only ignore it at your own peril and risk eroding trust of your customers and stakeholders, sacrificing growth and of course significant monetary loss. The consequences are real, and when subtle or obvious bugs ship to production, they usually become news for major news outlets, it ends up with someone high up resigning and moving on to save face.
Have we seen this before?
Developer driven testing and automation is not new.
If you see major tech companies, many of them don’t have dedicated QA teams like before and they have mostly delegated responsibility of writing automated tests to developers or outsourcing E2E testing to consulting and outsourcing companies for a lower cost.
I came across Modern Testing as a concept way back in 2014, when Microsoft made the transition to Unified engineering and converged Development and Testing roles into one single role. It proposed principles that Quality engineering teams can follow and which mostly sound reasonable with the caveat that you improve testing culture on the teams to such an extent that your presence may not be needed itself. That may be a bit more idealistic in nature but still sounds reasonable.
As the pace of delivery increases with AI, many leaders in startup and product companies look up to larger scale tech companies or scaled start ups with deeper profit pools to take inspiration from. Most often, they may even try to blindly copy other companies’ playbooks in the hope that they will also scale.
This often does not lead to desired results as you can’t retrofit culture even if you want, it has to be grown organically.
If you are a leader, what should you do?
Depending on the point of view and perspective you are coming from, you may have mixed opinions on the value that a QA team provides to your team and orgs.
Let’s take a step back, keep an open mind and take an honest look at where exactly your company, product and engineering teams are.
Who are your customers? What do they need?
Are you happy with the quality of the products and services you are serving to paying customers?
Where are the gaps?
What bugs and pain points are eroding your customers’ trust every day and leading them to evaluate or choose your competitors? Do you care?
Is your engineering team and processes working well as a cohesive unit?
What is the incentive structure for engineers to produce high quality bug free products?
When an incident or bug is discovered, how do you go about identifying, fixing and then ensuring the same issue does not happen again?
These are only a few of the considerations.
Does QA add value?
For e.g. this blog Who the heck is an SDET? gives intuition on what an SDET can do for the team and the domain they operate in. A skilled SDET is like a supercharged developer who for some reason is extremely motivated to ensure your product, tools, processes are all geared towards producing high quality software even without writing a single line of production code.
Also, a skilled QA is actually a hybrid between a product manager and a developer, able to think in both directions and bridge a lot of discussions connecting user experiences and technology, asking the right curious questions and poking and proding on if the results produced were actually desired.
I can go on and on about this.
Your engineering team is one of the greatest assets you will ever have and also a living breathing organism; don’t treat them like cloud resources from cloud providers. It is not easy to spin up a well oiled, collaborative and productive team. When you have that secret sauce, encourage and nurture it. It may really surprise you what a group of well motivated individuals working well together can produce.
When you make snap judgements and decide to go down a certain direction of laying people off and shifting responsibilities around, you have to understand and appreciate the fact the underlying work still needs to be done.
Someone needs to care enough about Quality and customers to tell you no, that the product quality is not good enough to ship. That person can very well be your developer or even your automated test infrastructure signal but you still need people with experience and conviction to stand up to you. This is the reason why an independent QA pillar sometimes can be a hedge to balance the need for unsustainable speed of delivery.
A developer reporting directly to you or your management chain with N other priorities may not love the idea of pushing back because some pesky tests are still not passing. A QA certainly does. It’s somehow in their core intuition and blood and they are not really afraid to tell you so, in gruelling detail. Well, most of the time, if they have been brought up well by strong mentors.
Should I downsize and not remove?
Say you choose to not remove but downsize your QA team.
Does 10:1 Dev to QA ratio sound fair to you? No person can keep up with 10 developers’ velocity especially with AI acceleration in place. Your QA team will always be in fire-fighting mode and would not have the breathing space to actually do their job, which is to evaluate the product state holistically, mitigate risk, find critical issues, care about the customer experience and help you decide if you can ship or not.
It is also not helpful to always keep your team in perennial distress around deadlines. You may think you are building a high performance culture and you may get the same effect for a period of time, but it’s not sustainable. People will burn themselves out and then move on to greener pastures. Some deadlines are good to motivate, but you should always accept reasonable explanations for why things are not moving at the pace you think they should. If only you were more hands on, you would appreciate the day to day that your team has to go through to get something done.
I see my competitor doing fine without QA
But, what about company X, they seem to be doing fine without QA?
You can try to compare yourself to high adrenaline silicon valley start ups with N million run rates with/without product market fit and say “hey, they are able to do it”.
But … hold on, take a breath.
You are not them. Your context is unique. Respect that and move forward in a way that is fair to your people. If your mental model is that QA does not add value, ask yourself have you tried talking to them 1:1, you may have some inner deep seeded biases and sometimes simply talking to others can give you a lot of clarity.
I’m not against developers testing their code. In fact, when this happens you mostly get better tested code and products, but an independent verification by a person who is passionate about quality does make a difference, the signal generated is really valuable and you should be curating and nurturing a high quality culture in your teams and orgs.
QA also holds a lot of shared context in their brain, a mix of tech and business which is extremely useful to identify failure points in a system architecture way ahead of time and might I say, extremely cheaply.
Move fast, but don’t break things. Always keep the customer in your mind and obsess over their experience.
I’ll leave it at that and hope that this gives you enough food for thought.
If you are in QA, what can you do?
I know this situation sucks, big time.
So far, if you have been reading this blog, you may be raising the alarm bells in your mind and it may have also triggered PTSD (Post traumatic stress disorder), your fight or flight responses.
I apologize, the intent of this blog is not to make a dent in your psychological safety, but make some rational arguments.
Let’s take a couple of deep breaths first, shall we?
Firstly, this is not an industry wide phenomenon, yet. I have come across 5-7 companies in my local context where I have seen this happening by talking to impacted individuals. Overall if you see LinkedIn or other job platforms, many companies and orgs are still hiring for QA folks and the pipeline is healthy.
Social media may be portraying the coming of AGI (Artificial general intelligence), end of jobs or snake oil promises of a brilliant Sci-Fi future where Software engineering let alone testing itself is meaningless and AI will do everything. But, we are not there yet. People making such bold claims either profit from the fear mongering directly or are simply too far removed from the low level details to make anything other than speculation.
Does this mean you can relax and do things as you have been doing forever?
No, that would be bad advice or take to accept.
You should definitely strive to learn and grow your skills to work effectively with automation and AI. These are all tools in your tool kit and you should make ample use of them to make your life easier as well as improve quality across the board. If you are curious about what the different areas could be for you to invest in, you can talk to me on Topmate or LinkedIn and I’m happy to have a discussion or read ⚡️ SDET career roadmap: from entry level to staff engineer. I still feel like while AI augmented workflows are interesting and powerful, we still have a place for human engineers in this world.
If you decide to switch to a different role, it is entirely your choice. No judgement at all. Do what you feel most strongly about.
You will have to pick up the necessary skills, ideally make an internal transition first in your own company and then change companies if required. It won’t be easy but if that is a path you are convinced about, please do whatever makes you feel more comfortable for your own mental health and family. I would advocate for Good habits for Software Engineers and we have to ground ourselves in the fact that it is just a job at the end of the day. Not your whole life.
My only advice would be to pick an area, in which you have genuine interest, curiosity and passion about, without that it may not really stick. If you are not sure what that is, try a bunch of different roles and see which one sticks out for you. Careers are long.
So what now?
I don’t think this is the end of QA.
If anything as more and more of SDLC (Software development lifecycle) gets automated either by sophisticated Engineering systems or AI, it will only generate more need to ensure the outcome produced is high quality. It would be a collective responsibility but someone needs to drive it, to ensure they optimize for “if we have built the right thing or the thing right”.
With more software being produced, more testing would naturally have to happen, although the nature and shape of it may evolve.
Remember, Every non software product that is produced (from your purifier, washing machine, electric/gas meters to even space rockets) are rigorously and meticulously tested either before or by market forces and only the teams that have produced better and higher quality experience would win.
Testing and QA will endure, it’s not going away anywhere. No matter what people selling you their own SAS (Software as a service) may be telling you.
It really takes a village to get such products shipped and I think QA has a major role to play in this journey and I still hope you will choose to be part of that journey.