Experienced test engineers and transparent Quality Assurance (QA) practices are vital to helping ensure that software applications work as they are supposed to, and reducing the risk of nasty surprises. However, poorly planned testing can seriously derail the ability of software companies to deliver products on schedule.
In the past, it was very common to work on a software product for very long cycles. Big software companies would take years to develop large applications, from operating systems to productivity suites. There would be a distinct, dedicated testing phase before release. And once the product was released into the wider world, any problems that emerged would often be blamed on QA teams.
That's a lot of pressure to put on QA. Software applications are complex and will be used in many different scenarios and environments by different users; it's impossible to test every single use case. And there are also hard deadlines to meet; if the software is to be released as planned, there’s only so much testing that can be done.
That's one reason why shorter release cycles became more common, with each new version of a software product having a much smaller scope in terms of changes. But even then, QA teams would still probably be on the hook if things went wrong.
Should we be talking about QA or QE?
In the quest to deliver better outcomes, many development teams are now thinking less about QA and more about QE – Quality Engineering. To understand this shift, it's helpful to clarify the distinctions: QA assures the process and system of work; Testing/Quality Control evaluates the product; QE embeds engineering practices: testability, automation, CI/CD, and feedback loops, so quality is built in, not inspected in.
It's not about abandoning other practices in favour of QE, but rather ensuring quality becomes integral to every part of the development process. And responsibility for quality is shared out, so quality is not the sole task of a single engineer or team.
While changing established ways of working might be a challenge for organisations, the benefits — faster delivery times and better products — are clear, at least in theory. Working smarter, not harder, is the ultimate objective with a QE approach. But there are real challenges that trip up many teams trying to make this shift.
The biggest hurdle is getting people on board. Developers need to care about quality, not just shipping features. If your company only rewards teams for how much code they write or how many features they deliver, quality will always come second. Teams need clear quality goals and responsibility for fixing what breaks in production.
Management support is crucial too. You can't ask developers to own quality without giving them the right tools and time. That means proper test environments, decent build pipelines, and time to improve old code. Without these basics, asking people to own quality is just setting them up to fail.
Then there's the technical reality: old code may be hard to test. Many companies have applications that were built years ago without modern testing in mind. Making these systems testable can take years of gradual improvement before QE practices actually work.
You might already be doing QE without realising it
QE is fundamentally about two things: mindset (shared responsibility for quality) and process (systematic practices to deliver it). You might already be doing QE without realising it.
Smaller companies and startups often have the mindset naturally — with lean teams, everyone feels accountable for quality outcomes. While many struggle with process maturity, some have done a sufficient job implementing quality practices from the ground up.
For larger companies, it depends on culture and team dynamics. Some brilliant engineering teams already practice QE-style development without calling it that — embedding quality throughout their workflow. Others need to make changes on many levels to shift from traditional quality gatekeeping to shared responsibility models.
How companies can change from QA to QE
To change from a 'traditional' QA mindset to a QE approach requires changes in both mindset and procedures.
On the mindset side, bringing in coaches and specialists to run workshops for development teams can help instil shared responsibility thinking through exercises focused on teamwork and collaboration. There may be some hurdles with getting people to embrace these sessions and to be receptive to new ways of working, of course. Everyone should be aware of the need to work on quality before the product is ready, thinking about tests during the planning process, and writing tests alongside the code.
On the procedural side, teams need to focus on several key areas:
Foundational practices. This involves reworking the approach to unit testing and other efforts to improve reliability, code review and static analysis, and treating functional testing as part of implementation. Design for testability — stable test data, environment parity, seams and hooks — so tests are cheap to write and trust. In regulated and safety-critical contexts, you must keep appropriate independence and formal validation, even as you adopt QE practices.
Shift left. Design the system for testability and run fast checks as early as possible – with both developers and testers together – so issues surface when they’re cheapest to fix.
Shift right. QE also extends into production, using observability, canary releases, synthetic monitoring, feature flags, automated canary analysis, rollback procedures, and production feedback loops to continuously validate quality. In larger organisations, Site Reliability Engineering (SRE) or platform teams typically own many of these practices — monitoring, release strategies, and incident response — while QE collaborates with them so pre-production test evidence and production signals form one feedback loop.
Beyond functional testing. QE treats non-functional risks — performance, reliability, security, accessibility — as first-class concerns, with explicit tests and runtime monitoring and observability.
Tooling. You don't need one magic tool that does everything. Instead, think of QE tooling as different tools working together smoothly. Your test management system tracks what tests you have and what happened when you ran them. Your build pipeline (GitHub Actions, Jenkins, and so on) runs tests automatically when code changes. Monitoring tools watch what's happening in production. The key is making sure these tools talk to each other — when a test fails, you should be able to trace it back to the original requirement and see what got deployed. And only automate what you can trust — flaky or unreliable automation is worse than doing things manually because it gives false confidence and wastes everyone's time.
These combined changes will help introduce a QE philosophy, leading to more predictability, less firefighting, and less last-minute testing while running up against tight deadlines. Ultimately, this means higher product quality and faster release times.
Takeaway: Quality is not a phase — it should be everywhere
Quality isn't something you tack on at the end of development — it needs to be part of everything you do. QE makes sure everyone on the team thinks about quality, while the people who actually build and run the code take responsibility for making it work properly. You'll still need specialist testers for the tricky exploratory work that automation can't handle.
The shift from QA to QE is really about changing how you think and work, not just buying new tools. Whether you're a small startup or a large company, QE can work for you if you're willing to adapt it to your situation. Get the mindset right first, then invest in the tools that support it.
Top comments (0)