Why Removing QA Requires Building a New Quality Framework

Many companies discuss cutting functional QA and focus on the immediate budget reduction of removing a team of dozens, which looks good on quarterly reports and gains applause in management meetings. The real issue is not whether a role can be cut, but whether the risks previously handled by that role are reassigned.

If a company reduces QA headcount without simultaneously strengthening development self‑testing, automation coverage, quality gates, production monitoring, and defect post‑mortems, the result is not higher quality but a transfer of quality debt to production. On paper the testing cost is saved, yet the hidden cost appears as online incidents, user churn, and rework. The first quarter may seem fine because system inertia masks the problem, but delayed consequences emerge as more frequent emergency fixes, longer rollbacks, and production‑interrupting iterations. By the time management notices, the saved labor cost is often consumed by compensation for major incidents and reputation loss.

The prerequisite is clear: before cancelling functional QA, a new quality system must be built to take over responsibilities. This system should cover development self‑testing, automation coverage, a test‑data platform, stable test environments, CI/CD quality gates, code‑review standards, gray‑release and rollback mechanisms, production monitoring, defect post‑mortems, quality metrics, and risk assessment. Without these, risks move from the test stage to production, exposing users directly. The goal is not to eliminate functional QA, but to establish embedded quality capabilities, with clear governance answering who can block risk, who is accountable for outcomes, and who turns experience into future mechanisms.

Organization Captures Quality Risks

Who should own this quality system? Large companies cannot rely solely on each business line’s self‑discipline because scale makes consistency hard. When delivery pressure conflicts with quality, teams tend to sacrifice quality without external constraints. Therefore, a dedicated quality governance team—often called a Quality Chapter —is formed.

This team does not necessarily execute every functional test; its value lies in defining cross‑team quality standards and risk controls: setting quality standards and metrics, managing release admission, coordinating defect and incident post‑mortems, overseeing cross‑team quality strategy, focusing on core‑link coverage, and governing test assets. In other words, the governance team manages the baseline, rules, and closed‑loop processes, not the day‑to‑day testing work of product teams.

A concrete release admission checklist might look like:

[ ] Core‑link automated test cases all pass
[ ] Unit test coverage meets team‑defined threshold
[ ] Static analysis shows no high‑severity issues
[ ] Changed interfaces have passed contract testing
[ ] Gray‑release switch is configured
[ ] Rollback plan is in place and verified executable
[ ] Critical business metrics have monitoring and alerts
[ ] Change risk assessment completed (impact, rollback cost, worst case)
[ ] High‑risk changes approved by quality / risk / compliance review

Each item corresponds to a concrete checkpoint; failure to meet any item blocks the release. These checkpoints are not invented arbitrarily—each stems from a real incident. For example, the item “Rollback plan verified executable” addresses cases where teams promised a rollback but discovered database schema changes or untested scripts during an outage, causing the issue to expand. Another example is “Contract testing,” which prevents silent interface changes in a micro‑service that break upstream callers in production.

The checklist is only the first step; the real challenge is assigning ownership. Who checks core‑link automation? Who judges incomplete risk assessments? Who can pause a release? Who updates admission rules after an incident? Without clear responsibility, the checklist becomes a formality where everyone nods but no one can be held accountable when something goes wrong.

Designing quality metrics is equally critical. Metrics should go beyond “how many tests were run” to assess “how good the quality is.” Before release, teams can track defect escape rate (defects that reach production), automation coverage, and pipeline stability. After release, they monitor online defect density, mean time to detect, mean time to recover, and repeat‑incident rate. Metrics are not for individual performance evaluation but to give the organization a clear view of quality trends. When metrics become personal KPIs, they are gamed—developers may hide defects, and post‑mortems turn into blame sessions. Mature organizations treat metrics as a “thermometer” rather than a “report card,” focusing on trends such as whether defect escape rate is converging, if repeat incidents are decreasing, and whether failures concentrate on specific change types.

One sentence summarises the difference between small teams and large organisations: small teams can rely on strong individuals, while large organisations must rely on mechanisms. In small teams, one or two experienced engineers can keep quality because information density is high and communication cost low. In large teams, turnover and drifting standards make it impossible for personal vigilance to scale; therefore, standards, admission gates, metrics, and post‑mortems must be institutionalised so that quality does not collapse when senior engineers leave.

Quality governance does not stop at release. Historically, many quality problems were resolved in test environments, with the assumption that “test passed = no problem.” As gray‑release, monitoring, rollback, and alerting become routine, the battlefield extends beyond launch. This post‑launch quality work relies on SRE and production quality systems: production monitoring, capacity assessment, fault‑injection drills, circuit‑breaker and degradation, gray‑release, rollback mechanisms, and incident response with root‑cause analysis.

Complex systems cannot rely solely on pre‑launch testing to eliminate risk. Real traffic, data, concurrency, and third‑party dependencies cannot be fully reproduced in test labs. Mature organisations adopt a two‑leg approach: reduce risk before launch and detect, contain, and learn quickly after launch. The aim is not “zero‑risk deployment” but to maximise discovery and recovery speed.

High‑Risk Industries Validate Organizational Capability

Fintech companies illustrate this shift. Quality issues in financial systems affect funds, compliance, and regulation—not just UI glitches. Problems such as duplicate charges, settlement errors, KYC/AML violations, or audit evidence gaps are hidden errors in data correctness and process compliance, not obvious functional failures.

These risks cannot be caught by traditional functional QA alone. Manual testing cannot reveal accounting imbalances under extreme concurrency, nor can it verify regulatory reporting requirements. Addressing them requires collaboration among payment engineers, accounting, risk, compliance, SRE, testing platform, and quality governance teams.

Consider a gray‑release where payment success rate drops from 99.6% to 99.1%. The small dip may not trigger immediate complaints, but at scale it translates to thousands of failed payments. Without production monitoring, the issue may go unnoticed until massive user complaints arise. Without gray‑release and rollback, fixing the problem becomes costly; with them, impact is limited and rollback can be executed within minutes. Without defect post‑mortems, the root cause is not recorded, leading to repeat failures.

Quality governance is therefore a closed loop from pre‑release admission, through gray‑release, to post‑incident monitoring, rollback, and knowledge‑capture. The most valuable yet often ignored loop link is the post‑mortem knowledge capture, which turns each incident’s root cause into a new admission rule, alert, or automated test, tightening the quality gate over time.

Ten Questions Before Dropping Functional QA

Before a company decides to eliminate functional QA, it should answer these questions:

Who owns the requirement acceptance criteria?

Who is responsible for development self‑testing quality?

Who maintains automated test cases?

Who governs test data?

Who ensures test environment stability?

Who defines release admission criteria?

Who tracks production quality?

Who leads incident post‑mortems?

Who records quality metrics?

Who identifies major business risks?

These responsibilities were often implicitly handled by QA; removing the role without assigning clear owners creates gaps that shift risk to production. The key is not who does the work, but that each responsibility has a designated owner with the authority, tools, and cadence to enforce it. Otherwise, “shared responsibility” often means “no one is responsible.”

In summary, mature companies do not merely “de‑QA”; they compress low‑value functional testing roles while strengthening engineering quality, production quality, and risk governance. The presence of a robust quality system, not the existence of a QA team, determines organisational maturity.