More and more software teams—especially those working in DevOps and CI/CD environments—are choosing to operate without a dedicated QA or tester role. This approach often raises concerns and misunderstandings. Does it mean testing is neglected? Does quality suffer?
In practice, teams without QA are not teams without testing. Instead, quality becomes a shared responsibility, embedded directly into the daily work of engineers. This model is widely used across Big Tech companies such as Microsoft, Google, Meta, and Netflix, but it only works under specific conditions. In this article, we will look at how testing works in teams without QA, explain the role of SDET, and draw conclusions from real-world examples at large technology companies.
What Does It Mean to Have a Team Without QA?
A team without a dedicated QA role does not remove testing from the development process. It removes the idea that testing is something done after development or by someone else. Developers are expected to validate their work through automated tests, and quality checks are built directly into the CI/CD pipeline.
In such teams, testing is part of the definition of “done.” Code that is not covered by meaningful tests or that breaks existing behavior simply does not move forward. The responsibility for quality is collective, not delegated. This shift requires a change in mindset: instead of saying “QA will catch it,” teams assume that quality must be ensured before code is merged.
Why Do Companies Move Away from Traditional QA Roles?
Modern software delivery is fast. Continuous delivery, frequent releases, and small incremental changes leave little room for long manual testing phases. In this context, a separate QA step can easily become a bottleneck.
Organizations that adopt this model usually invest heavily in test automation and fast feedback loops. The goal is not to test more at the end, but to test earlier and continuously. By integrating testing directly into development, teams reduce handovers, shorten feedback cycles, and detect issues when they are still cheap to fix.
The Risks of Working Without QA
Removing a dedicated QA role does not come without risks. Developers naturally focus on implementing functionality and often validate only the expected, happy-path behavior. Edge cases, negative scenarios, and unusual user behavior can be overlooked.
This is where traditional testers bring unique value. Their strength lies in thinking about risk, misuse, and failure modes rather than confirming assumptions. Teams without QA must consciously compensate for this by planning exploratory testing, reviewing test coverage critically, and continuously discussing quality risks during refinement and retrospectives.
Without these safeguards, the “no QA” model can quietly turn into “no real quality control.”
Can Developers Really Replace QA?
Developers can successfully take responsibility for testing, but only if testing is treated as a first-class engineering concern. Automated tests must be mandatory, not optional. CI pipelines must fail fast and block changes that reduce quality. Teams must understand the purpose of different test levels and use them intentionally.
Most importantly, quality cannot rely on individual heroics. It must be enforced by process, tooling, and team culture. When this foundation is missing, the absence of QA becomes visible very quickly—in the form of regressions, flaky releases, and growing technical debt.
What Is an SDET?
SDET stands for Software Development Engineer in Test. The role emerged most prominently at Microsoft and represents an engineer with strong development skills who focuses on testing-related problems.
An SDET does not primarily perform manual testing. Instead, they design and maintain automated test frameworks, build testing tools, and ensure that quality scales with the product. They operate closer to developers than to traditional QA, often contributing production-quality code that supports testing, reliability, and CI/CD integration.
The SDET role exists to solve a specific problem: how to maintain high quality in large, complex systems without relying on slow, manual testing cycles.
Microsoft and the Evolution of SDET
Microsoft was one of the pioneers of the SDET role, creating a clear career path for engineers specializing in test automation and quality tooling. Over time, however, the company began to evolve its approach.
In many teams, especially those building web-based and cloud services, testing responsibilities were gradually absorbed by developers themselves. The formal SDET role was reduced or removed in parts of the organization, but testing did not disappear. Instead, quality ownership moved closer to the teams building the product, supported by strong automation and shared engineering standards.
This evolution reflects a broader industry trend: fewer specialized testing roles, but higher expectations for every engineer when it comes to quality.
How Other Big Tech Companies Approach QA
Companies like Google, Meta, Netflix, and Uber are often cited as examples of organizations where many teams operate without dedicated QA roles. In these environments, developers are expected to write extensive automated tests, and quality is enforced through tooling, code reviews, and sophisticated CI systems.
At the same time, not all large companies follow this model. Amazon and Apple, for example, continue to use more traditional QA structures in many areas, especially where hardware, security, user experience, or regulatory constraints play a major role. This highlights an important point: there is no single “correct” QA model that fits every product.
QA as a Platform, Not a Team Member
An increasingly popular compromise is to remove QA from individual product teams while retaining strong quality expertise at the organizational level. In this model, QA or Quality Engineering teams act as a platform. They build tools, define testing standards, and support teams rather than executing tests themselves.
This approach aligns well with the ideas behind Team Topologies. It allows product teams to move fast while still benefiting from deep testing expertise and shared infrastructure.
When Does a No-QA Model Actually Work?
Operating without dedicated QA makes sense only when teams have reached a certain level of maturity. Strong automation, stable CI/CD pipelines, and a culture that values quality are non-negotiable. Teams must be willing to reflect on failures, improve their testing practices, and treat defects as learning opportunities rather than inconveniences.
Without these foundations, removing QA is not a strategic improvement—it is simply a hidden cost that will surface later.
Conclusion
Eliminating a dedicated QA role is not a goal in itself. It is an organizational decision that shifts responsibility for quality directly to engineering teams. Big Tech companies demonstrate that this model can work, but only with significant investment in automation, tooling, and culture.
Quality does not disappear when QA disappears. Instead, it becomes part of the product—and part of the job of every engineer involved in building it.
