Modern engineering teams don't want a QA counterpart

In 2015, it made news when Yahoo did away with its QA team.

Now, the same step would be greeted with crickets. The industry has shifted its perspective on dedicated QA teams to the point where "No QAs" is now utterly unremarkable.

How did we get here? When we talk to engineering leaders, we hear about both the negatives of separate QA teams and the positives of integrating testing directly into the development process.

Why the best companies don't have QA orgs

If you're a QA, this r/ExperiencedDevs thread is a sad read. The tl;dr is that there simply isn't the talent within the current QA pool for QA teams to bring value to an organization.

But the problem goes deeper than QA simply becoming an entry-level, stepping-stone role. The traditional model of separating development and QA teams-developers coding in a silo, then throwing their work over the wall to the QA team-is now a relic. For high-performing teams, the entire concept of a separate QA role just no longer makes sense.

Problem #1: The disconnect

The fact that we talk about "QA orgs" should be a red flag. As a separate entity, QA teams mean that application and QA engineers are disconnected. This means that the two teams operate through a "handoff model," where developers complete their work and pass it to QA for testing. This separation creates several critical issues:

Delayed feedback: Bugs are often discovered late in the development cycle, leading to costly fixes and delayed releases.
Reduced ownership: Developers may feel less responsible for the quality of their code and rely on QA to catch issues.
Knowledge silos: QA teams may lack a deep understanding of the codebase, while developers may not fully grasp testing methodologies.
Inefficient communication: Requirements and expectations can be misinterpreted between teams, leading to misaligned testing efforts.
Slower time-to-market: The back-and-forth between development and QA extends the release cycle.

Modern engineering practices like CI/CD expose these inefficiencies. In a world where code can be deployed multiple times a day, a separate QA phase becomes a bottleneck and adds to the deployment process's opaqueness.

But the problems don't stop there. This separation breeds a culture of "not my problem." Free from the burden of testing, developers may ship code with a "QA will catch it" mentality. Meanwhile, QA teams, disconnected from the development process, struggle to understand the intricacies of the system they're testing.

Problem #2: The costs

Maintaining separate QA teams incurs significant financial and operational costs. These costs are often overlooked but substantially impact a company's bottom line and overall efficiency.

The financial implications of dedicated QA teams are considerable:

Headcount: QA salaries represent a significant portion of engineering budgets.
Tooling: Test management systems, automation frameworks, and issue tracking add to infrastructure costs.
Training: Like any team, QA has to keep up with evolving technologies and methodologies.

If you have an NA-based team of five QA engineers, the all-in cost could easily push $2 million.

Beyond that, the opportunity costs of maintaining separate QA teams are also overlooked. If QA is 25% of budgets, rerouting these resources could have a massive effect on building new features or improving existing ones. Slower time-to-market means competitors can outpace you in releasing new features, potentially costing market share. Separate QA teams can also stifle rapid experimentation and iterative development, hindering innovation.

There are also hidden costs to consider:

The lack of developer involvement in testing can accumulate hard-to-test code, increasing technical debt.
Siloed teams often lead to reduced job satisfaction and higher turnover.
Customer satisfaction can suffer due to slower release cycles and potential quality issues impacting user experience.

Companies can significantly reduce these costs by integrating QA responsibilities into the development process. This shift allows for more efficient resource allocation, faster release cycles, and a more competitive market position. This approach's financial and operational benefits often outweigh the perceived safety net of a dedicated QA team.

Problem #3: The agility factor

High-performing teams are teams that deploy more. Removing QA silos significantly enhances team agility, as without the traditional QA bottleneck, teams can achieve faster iteration cycles. Features move from concept to production more quickly, allowing for more frequent releases. This increased release cadence enables quicker response to customer feedback, a critical factor in maintaining product-market fit and customer satisfaction.

This shift towards integrated QA and agile testing practices improves speed and enhances quality. By making testing a continuous, integral part of development, teams catch issues earlier, reduce the cost of bugs, and ultimately deliver better software faster.

For engineering leaders, the agility factor should be a compelling reason to reconsider traditional QA teams. The ability to move quickly, respond to market changes, and continuously improve the product gives companies a significant competitive advantage in today's rapidly evolving tech landscape.

You build it, you own it

The alternative is to integrate testing into the development process. Developers own testing alongside the code they create, making them responsible for both writing code and ensuring its quality.

Outcome #1: Faster feedback loops

When developers own testing, the disconnect between development and quality assurance disappears. Bugs and quality issues become immediate concerns for the developer, not problems to be caught by a separate team. This integration creates several advantages:

Immediate detection: Developers can identify and fix issues as they code, reducing the time between bug introduction and resolution.
Comprehensive understanding: With full knowledge of the code and its tests, developers can create more effective test cases covering edge cases and potential vulnerabilities.
Increased accountability: Developers take full ownership of their code's quality, leading to more careful development practices and higher overall code quality.

Outcome #2: Lower costs

Shift-left testing and the lean model of integrated QA lead to significant cost reductions. First, we're reducing the headcount. Eliminating separate QA roles allows for a more efficient allocation of developer resources.

The efficiency also flows through to individual developers. Developers' time is used more efficiently when they can switch between coding and testing without context-switching delays. Some might find it difficult to ramp up to including tests with their code initially, but compared to being pulled out of the flow by pings from QA, it is a much more efficient workflow.

We should also see lower bug fix costs. Early detection of issues during development is far less expensive than fixing bugs found in later stages or production. Fixing in production is the most costly fix (as CrowdStrike just found out),

Finally, we're decreasing tooling costs. Many QA-specific tools become unnecessary when testing is integrated into the development process.

Outcome #3: Quality as a mindset

Incorporating testing earlier in the development process fosters a quality-first mindset and increases team agility.

You want your developers to think about testing and quality from the outset. This leads to more testable and robust code. Instead of developers writing janky code that they don't personally have to think about testing, you get a dev cycle that goes like this:

Developer considers testability while breaking down user stories.
Developer plans code structure with testing in mind, ensuring modular and easily testable components.
Developer writes code in small, testable units.
Developer creates and runs unit tests for each component as it's built.
Developer integrates new code with the existing codebase, running integration tests.
Peers review both code and tests, ensuring comprehensive coverage.
Automated tests run with each commit, catching issues early.

This cycle promotes faster iteration, as teams can quickly adapt to changing requirements or discovered issues. The developers who wrote the code are immediately available to address problems, enhancing overall team adaptability.

This integrated approach transforms quality from a separate concern to an inherent part of the development process, ultimately leading to faster delivery of higher-quality software.

Testing accrues value

This isn't about eliminating QA teams—it's about recognizing that testing accrues value over time. When testing is embedded in the development cycle, benefits compound. You get continuous quality improvement as each test written adds to a growing suite that catches regressions and ensures consistent behavior. You get institutional knowledge as tests serve as living documentation, capturing business logic and edge cases that might otherwise be lost. You get faster debugging when issues arise, and well-structured tests pinpoint problems quickly, reducing time-to-resolution.

This accumulation of value transforms testing from a cost center to a core asset. For engineering leaders, the focus should shift from managing QA processes to fostering a culture where testing is viewed as an investment that pays dividends in code quality, team velocity, and product reliability.

Momentic is part of the toolset that supports modern engineering teams. To see how your developers can use Momentic within their workflow, contact us to set up a demo.