In March 2023, job listings platform Indeed laid off 15% of its workers and eliminated the QA role at the company. An anonymous software engineer at Indeed told Gergely Orosz, the technology writer behind The Pragmatic Engineer, that since the layoffs, “The overall quality of tests has nosedived.”
On July 2, 2024, Dylan Field, CEO of design software company Figma, temporarily disabled a freshly debuted AI feature called Make Design. In a Twitter thread, Field defended the feature against controversy — namely, people accusing the feature of having been trained on user designs — but took the blame for the apparent issue, writing, “Ultimately, it is my fault for not insisting on a better QA process for this work and pushing our team hard to hit a deadline.”
In both examples, we have a case for and against the value of the QA role. On the one hand, we can see the importance of QA; test quality immediately suffered at Indeed, and Figma walked into a PR nightmare. On the other hand, we can see the “death of QA” that thought leaders are always predicting — both companies, in the end, devalued QA.
QA was once a starring role in the tech industry, and its importance was never questioned. Now, however, its importance is frequently doubted, if not outright ignored. Predictions about the imminent end of QA betray a shallow understanding of QA and the value it offers, which is far beyond the role we take for granted.
QA: “My death has been greatly exaggerated”
It might be cold comfort to aspiring and junior QA engineers, but it’s true: There are always predictions that the QA role will die, that the industry will disappear, and that this way of working will be displaced. Almost all of them are untrue.
Think about ATMs. When the ATM debuted in the 1970s, many people predicted they would put bank tellers out of work. The logic made sense despite being wrong. In reality, the rise of ATMs meant a rise in bank tellers because more people had access to banks.
Similarly, people once predicted that eReaders would displace and destroy the traditional publishing industry. Again, the logic made sense, but reality proved it wrong: 2023 research showed that print book sales rose 10-14% over the three previous years.
Closer to home is low code — a broad category of tools that help people create software with little to no code. Various low-code hype cycles have risen and crashed over the years, but developers are still in demand.
As Jody Bailey, CTO of Stack Overflow, says, “I’ve been hearing about low-code solutions for 30 years, only they had different names back then [...] Is it going to replace developers? Not in the near future. [...] But just like we still have developers writing assembly and C code today it is hard to imagine a time when we don’t have people writing ‘real’ code themselves.”
There are two takeaways from these examples: Big technological and industry shifts rarely displace job roles as much as people predict, but — and this is a big but — they do create significant change.
QA has changed and will continue to change, but we should be skeptical of any claim that it will die any time soon.
QA has never been just QA
When ATMs, eReaders, and low code tools transformed without replacing the work that came before them, we experienced what economists call “creative destruction.”
During creative destruction, a new technology (or way of working with technology) emerges that “destroys” the old way but opens the way toward creating new technologies, roles, and businesses. Despite the name, creative destruction often destroys less than people predict because the atomic unit of work is not a job title — it’s a task.
The many faces of QA
Job roles are inherently unstable and tend to evolve over time.
For example, in years past, a “backend developer” role might have asked for Java; now, it might ask for Rust. Similarly, in the past, an IT person might have been asked to manage racks of physical servers, but they’ll now be asked to manage servers hosted hundreds of miles away via the cloud.
As the changes happen, the job title in question may or may not change. QA is a prime example. If we consider the QA role as assuring quality and managing or running tests, then we can see the other faces the QA role has assumed over time.
The SDET role, first developed by Microsoft, for example, tasked SDETs with writing automated tests and building and managing testing systems alongside developers.
The test engineer role, as another example, focuses on developing automated tests and building tools to support integration and regression testing. At Mozilla, for example, this team will also “monitor the DevOps pipeline, improve the tests, and write new tests.”
There are also roles that are nominally QA but don’t take on work that QA engineers are typically associated with. Rouan Wilsenach, a software engineering consultant, writes about how developers and QA teams can do QA in production via logs, metrics, and other production data, for instance, which is not manual testing.
When people assume QA is dead or dying, they often don’t realize that any decrease in the sheer number of QA roles doesn’t necessarily correlate with the value and presence of QA skills.
Microsoft: A case study
In the 1990s, Microsoft popularized the SDET role, which the company later retired in 2014.
According to Orosz, who worked at Microsoft for a time, an SDET is a software engineer who focuses on “writing automated tests” and “building and maintaining testing systems.” SDETs didn’t write production code, but they worked on the same team as the engineers while writing test code.
Until 2014, the ratio of engineers to SDETs at Microsoft was typically 2:1 — that’s a lot of SDETs! On Orosz’s team, the SDET team owned and managed everything involving testing, including:
- Manually verifying new features and edge cases
- Building integration and end-to-end tests
- Creating and running manual tests
- Working alongside developers and managers to plan features
In 2014, however, after multiple teams independently started merging development and testing roles, Microsoft retired the role and laid off 18,000 people (many of which were SDETs).
The company was shifting from hosted software to SaaS, and it needed rapidity and flexibility. Over time, multiple balances shifted: More developers tested their own code, and unit tests became more popular than end-to-end tests.
Though the SDET role changed, QA remained.
As Ars Technica reported at the time, the Bing team, which inspired the closure of the SDET role, still prized QA: “QA still exists and is still important, but it performs end-user style ‘real world’ testing, not programmatic automated testing. This testing has been successful for Bing, improving the team's ability to ship changes without harming overall software quality.”
At a high level, this case study is scary: There are no more SDET roles at Microsoft, after all. But when you dig deeper, you can see how the QA role (writ large) is changing. Tests are more important than ever (even if developers are running more of them themselves) and the role didn’t change because it became irrelevant — the role changed due to larger trends that modern QA engineers can still capitalize on.
QA after Agile, DevOps, and the ongoing shift left
If the current questioning around QA seems fresh, it’s because the role is facing a combination of challenges from new technologies and new workflows. The further automation of tests that used to be manual, the continued dominance of Agile workflows, and the trend to shift more work left have made many QA professionals wonder if they’ll still have a place.
Agile and Scrum
There’s nothing in the Agile Manifesto about eliminating QA, but the workflow’s spread from nascence to dominance has displaced a lot of QA work, nonetheless.
Dustin Moris G., a software developer, makes the point that when Agile came to his work, the distinction between developers and QA “caused a lot of friction in our Scrum process,” and his team ended up with a few issues, including:
- QA often had little work to do at the beginning of a sprint
- QA often had too much work to do at the end of a sprint
- QA was rarely able to finish its work before the end of the sprint
QA, after all, came to prominence during the waterfall era, when software was built by developers, thrown over the wall to QA, and finalized before delivery via hard disc to customers. In Agile, which prioritizes rapid iteration and a close relationship between developers and customers, QA wasn’t a natural fit.
“Through the separation of roles,” Moris G. writes, “We ended up with a lot of difficulties, bottlenecks and inefficient use of resources.” As a result, more pressure was put on developers to build, test, and own the code from planning to delivery.
A key takeaway here is that QA wasn’t displaced because it didn’t provide value but because people couldn’t find ways to fit it into Agile — at least at first. Since then, people like Elisabeth Hendrickson, an Agile expert, have helped organizations distinguish between automated testing and human-led checking.
“Automated tests are dumb,” writes Rouan Wilsenach, summing up some of Hendrickson’s thoughts. “Automated tests check your system for bugs that you already know could exist. It is manual exploratory testing that finds the bugs you don’t know about. Automated testing frees you up to do more of this kind of testing, instead of the rote checking that you used to do.”
As developers take on more of the automated testing work, we don’t have to assume a zero-sum mindset for quality. A rise in developer-led automation can and should lead to a rise in QA engineers performing exploratory testing.
DevOps and the shift left
“Shift left,” which can often feel like a buzzword, can be summed up in one idea: It’s cheaper to fix issues earlier in the software development lifecycle than later.
While this is true, the pressure to shift can also be leveraged to deprioritize or cut work done toward the right side of development. David Caudill, Senior Engineering Manager at Capital One, argues that over the years, DevOps practitioners optimized delivery pipelines until the slowest part of delivery was testing.
As a result, the industry tried to “squish” integration and end-to-end tests down to unit tests and change the workforce to reflect this priority. “At the personnel level,” Caudill writes, “We decided that testing might not be the bottleneck…the QA team was. The industry began to treat the people in these roles worse and worse. Expectations for them went up, salaries went down.”
But while many parts of development can shift, not all of them can. “Unsurprisingly,” Caudill continues, “Developers did not readily assume the duties of the role without any additional compensation, recognition, or reward. [...] Newer engineers and managers aren’t able to tell what’s missing.”
The solution, of course, isn’t to “shift right” and return to the way development and QA teams used to work. The attempt to shift work left was a worthwhile experiment, and the industry has, collectively, learned that a lot of work can indeed be shifted left and that there are many benefits to developers taking on broader responsibilities over the code they write.
But the results of that experiment have also shown that developers can’t shoulder all responsibilities and that, like with automation, the shift left has relieved QA of some work so that QA can do better higher-level work.
Will Larson, CTO at Carta, argues, for example, that shifting testing left is good but that this “doesn’t mean that QA-led testing isn’t valuable.” Instead, he writes, QA-led testing is “very valuable for managing the sort of cross-feature bugs that an engineer with narrow context would not know to test for.”
As Wilsenach writes, the shift left means “Automation can take care of the repetitive checking you’re often stuck with. This will free you up to use your creativity to explore new ways to test a system.” In other words, QA can survive and thrive in a different and better form — if we let it and if we advocate for it.
The future of the QA role is concentrated and dispersed
You should doubt anyone who offers a precise prediction about the role of QA (or any role).
The closest thing to a prediction that’s worth considering is the further progression of two already proven trends: QA will become more dispersed as developers take on more testing, and QA will become more concentrated as new technologies free QA engineers to do higher-level work.
The first trend has been rolling on for years: Developers are familiar with many kinds of testing tools and run unit tests all the time. QA, or, as Michael Lopp puts it, the QA mindset, will keep spreading throughout organizations as more and more people take a role in guarding and pushing quality.
The second trend — a complement, not a contradiction — will result in QA engineers shifting to higher, ops-level roles.
We can find an analogy in IT Ops, where, with infrastructure as code, IT went from managing “pets” (individually cared for servers) to managing “cattle” (platforms of cloud resources, services, and processes). IT wasn’t displaced but evolved, ascending a level from managing resources to managing the platforms that managed those resources.
This has always been the Qase stance: Automation and AI should not and cannot replace humans. Instead, automation and AI augment QA workflows, allowing QA engineers to oversee entire better and broader test suites, react rapidly to new quality concerns, and invest all the saved time in the rare but deep moments when exploratory testing is necessary.
