The shifting role of QA: who should be in charge of software testing?

Nocnica Mellifera
US-based Nocnica Mellifera

As software teams continue to push testing earlier into the development life cycle, a movement known as ‘shifting left’, the question of who should actually own and run tests has become more urgent, according to one industry insider.

For Nočnica Mellifera, an independent software testing consultant based in Portland, Oregon, the answer lies not in removing QA roles, but in evolving them.

“QA is a funny thing,” Mellifera shared in a recent note. “It has meant everything from ‘the most senior engineer who puts the final stamp on all code’ to ‘the guy who just sort of clicks around randomly and sees if anything breaks.’”

She has seen QA positioned in various ways across organisations, sometimes embedded within development teams, and sometimes as a disconnected, external function.

As testing responsibilities move closer to the product teams, Mellifera believes the fundamental question is really, who should own the tests?

Different approaches

In an era where even the largest tech companies disagree, Microsoft retired its dedicated SDET (Software Development Engineer in Test) role in 2014, while Apple and Amazon continue to maintain dedicated QA teams, Mellifera sees ambiguity. “If the FAANG companies cannot decide whether we need dedicated QA roles, how can the rest of us answer the question?”

Drawing from her own experience at New Relic, Mellifera recalled asking a Ruby development team who their QA person was. “There is not one,” the team lead replied. “Rails doesn’t require QA.”

This, she noted, is a familiar refrain among developers who believe the newest language or framework has solved testing challenges by design. But over the last decade, Mellifera said, it has become clear that no language or stack is immune to bugs, failures, or unintended behavior.

“In the decade since this conversation, it’s become clear that no language or framework is free from the need for testing,” she explained. Whether testing is distributed across developers or centralized in a dedicated team, it remains a non-negotiable pillar of software quality.

Importantly, Mellifera pushed back against the common myth that testing was once solely the responsibility of QA.

“Back in the days, QA was responsible for running all the tests and developers just wrote code. This was never true,” she stated.

From the earliest days of computing, developers have always engaged in basic forms of validation, printing debug logs, watching console outputs, or clicking through their local builds.

What shifting left really means, she argued, is providing developers with full access to comprehensive, accurate tests, namely tools that give them confidence their code is working before it’s even merged.

Still, she draws a clear line: “QA shouldn’t be testing code that devs haven’t tested.” When QA uncovers problems that developers could have easily caught with basic checks, the cost in delays and feedback loops grows unnecessarily.

Mellifera pointed out that many organisations continue to rely on a separate team for integration testing, often leaving developers unaware of issues until much later in the cycle.

“Without access to full and accurate integration tests,” she warned, “developers are creating a situation where many surprises lurk ahead.”


“As QA embeds itself within teams and more developers know how to run high-quality tests, is that QA ends up doing more, not less.”

– Nočnica Mellifera

Rather than operating as a separate entity, Mellifera sees the future of QA in embedded roles: professionals working side by side with developers, helping shape testing strategy from the beginning.

“An approach that may work well in a microservice environment is embedding QA professionals and/or SDETs within teams,” she stated.

These embedded QA professionals are not just test executors; they are test architects. They write complex test suites, identify regressions, and assess the testability of codebases.

“An engineer shouldn’t be the one to test code they are too close to,” Mellifera explained. Instead, QA brings objective evaluation and a strategic lens to the process.

Their contributions go far beyond debugging. By encouraging better architectural practices, like encapsulating business logic, QA makes it easier for teams to test, optimise, and refactor code.

“For example,” Mellifera noted, adding that “this approach allows for swapping out database services as needed for financial optimization, beyond just improving testability.”

In the complex world of micro-services, where individual teams may have tunnel vision for their own services, QA plays an especially vital role.

“QA professionals play a critical role in overseeing the interactions between these services,” Mellifera said. While each team focuses on its own components, QA can take a broader, systemic view: identifying points of failure that may only emerge in cross-service communication.

Far from becoming obsolete, Mellifera argues that QA is growing in strategic importance. “The change, then, as QA embeds itself within teams and more developers know how to run high-quality tests, is that QA ends up doing more, not less.”

She outlined key responsibilities that include defining testing strategies, building frameworks, selecting tools, and focusing on complex end-to-end automation. In short, as the push for development velocity and reliability accelerates: “QA will become more valuable than ever.”

In Mellifera’s view, the debate is no longer whether QA should exist. It is about where it sits, how it operates, and what it enables.

Embedded within teams and focused on strategy, modern QA professionals are becoming architects of quality in a world where velocity can no longer come at the cost of reliability, she concluded.


THIS MONTH


Why not become a QA Financial subscriber?

It’s entirely FREE

* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *

REGISTER HERE TODAY



REGULATION & COMPLIANCE

Looking for more news on regulations and compliance requirements driving developments in software quality engineering at financial firms? Visit our dedicated Regulation & Compliance page here.


READ MORE


WATCH NOW