One of Waterfall's Most Resilient Artifacts

The waterfall model of software development was formally described in 1970. It was critiqued decisively by the early 1980s. It was officially succeeded by iterative and incremental methods through the 1990s and rendered obsolete, in many professional contexts, by the Agile Manifesto of 2001.

However, it is still alive and embedded in the structure of the work in many organizations, not as a named process but as an unexamined assumption. Not "we do waterfall" — nobody says that. But: "the feature goes to QA when development is done." "The sprint doesn't end until QA signs off." "We're blocked on QA." "QA found twenty bugs; we can't ship until they're resolved."

These phrases are not descriptions of Agile. They are descriptions of waterfall with a two-week cycle time. The phase is still there. The hand-off is still there. Testing still follows development, a verification step rather than a continuous property.

This article examines why the phase assumption is so persistent and what it costs in organizational terms. It also addresses the difficulties of the transition from quality-as-phase to continuous quality.

Why the Phase Persists: A Structural Analysis

The persistence of the QA-as-phase model is not irrational. It has structural causes that are worth understanding, because understanding them is the prerequisite for addressing them.

Organizational Gravity

Testing-as-phase is the default because it maps onto the most natural division of labor in software development: some people build things, other people check them. This division is intuitive, easy to staff, manage, and account for. You know who the developers are, you know who the QA engineers are. You also know when one group's work ends, and the other's begins. The hand-off is the organizational seam.

Quality as a continuous property has no equivalent seam. It is distributed across the team. It is harder to manage, harder to staff, and harder to account for. Organizational gravity pulls toward the legible structure — even when the legible structure is less effective.

Measurement Gravity

The phase model produces measurable outputs: test cases executed, bugs found, bugs resolved, pass rate. These can be counted, tracked, reported, and displayed on dashboards. A VP of Engineering can look at a sprint report and understand, at a glance, the state of QA.

Quality as a continuous property produces outputs that are distributed, contextual, and harder to aggregate: a requirements ambiguity caught in review, a design flaw surfaced before implementation, a unit test that prevented a defect from propagating, an exploratory session that identified a risk the team had not considered. These are real contributions to quality. They are almost impossible to count in a way that maps onto an existing reporting structure.

Organizations have traditionally measured the output of a phase. So the phase persists.

Skills Gravity

Testing-as-phase concentrates quality skills in a specialist function. QA engineers know testing. Developers know development. The specialization is clean, and the skills are developed within it.

Quality as a continuous property requires that testing thinking is distributed — that developers write meaningful tests, that product owners specify with testability in mind, that architects consider failure modes, that DevOps engineers understand quality signals in production. This requires a different skills profile across the entire engineering organization, not just in a QA function. Building that profile takes years of deliberate investment.

Most organizations have not made that investment, because the phase model did not require it. The result is a workforce that is structurally dependent on the phase: remove the QA checkpoint and quality does not become everyone's responsibility; it becomes no one's.

The Cost of the Phase: Where the Damage Accumulates

The QA-as-phase model does not produce a single, dramatic failure. It produces a chronic, compound cost that accumulates across the SDLC in ways that are individually explainable and collectively damaging. The following four cost categories are where most of that damage concentrates.

The Rework Cost

When quality is a downstream phase, defects discovered during that phase require rework. This is often more expensive than prevention. This is the oldest argument in software quality economics, and it remains true: a requirement misunderstood at the requirements stage costs almost nothing to correct before any code is written. However, it takes significant time to correct after the code, tests, and potentially dependent features have been built around the misunderstanding.

The phase model makes late discovery structurally inevitable. Testing does not begin until development is complete. By the time testing begins, the cost of correction is already elevated. By the time testing finds a defect in a dependency, the cost is elevated further. By the time a defect reaches production — as some always do — the cost is at its maximum.

The insidious quality of this cost is that it feels normal. Teams that have always operated in the phase model have calibrated their expectations around a level of rework that they could reduce substantially by shifting quality earlier. To them, the excess cost is not an excess. It is a natural difficulty of software development.

The Context-Switch Cost

In the phase model, there are cases when a defect discovered during QA requires a developer to return to code they wrote days or weeks ago. The developer must reconstruct the context of that code, understand the failure, and fix it — without introducing new defects in the process. This context reconstruction is expensive since context switching is one of the most significant drains on engineering throughput.

The cost is not just the time to fix. It is the time to remember, to understand, and to re-enter a cognitive state that the developer was in when the code was written. For complex code, in a complex system, this can take hours before a line of correction is written. In a continuous quality model, where defects are caught by a failing unit test, by a CI failure, or by a developer's own review, the context is immediately available. In this case, the cost of correction is a fraction of the phase-model equivalent.

The Blocking Cost

When QA is a terminal phase, it is also a bottleneck. The rate at which software can be released is limited by the rate at which QA can process it. In organizations where development outpaces QA capacity — which is most organizations, because QA headcount is typically smaller than development headcount — a queue forms. Work in progress accumulates. Developers complete features that cannot be tested, so they pick up new features, creating more work in progress and deepening the queue.

This queuing dynamic has consequences beyond the immediate delay. Work sitting in a queue is work that simultaneously creates risk (it may depend on other work, accumulate merge conflicts, or become outdated relative to the codebase) and consumes organizational attention (it must be tracked, managed, and prioritized when it eventually moves). The phase model does not just slow release — it creates inventory of partially-complete work that costs money to maintain.

The Signal Latency Cost

The most consequential cost of the phase model is one that rarely appears in project management reports: the latency of quality signals. In a phase model, information about defects travels slowly — from the moment of injection during development, through the queue, through the testing phase, back to the developer through the defect report, and eventually to the fix. This latency can span days, weeks, or, in organizations with long release cycles, months.

During that interval, the defect is not idle. If it is a requirement misunderstanding, other features may have been built on the same misunderstanding. If it is a design flaw, other components may have been built to interface with the flawed design. If it is a logic error, other code may have been written that depends on the erroneous behavior. Late signals are not just expensive to act on — they are expensive because of everything that has been built on top of the undetected problem before the signal arrives.

Why The Transition Is Hard

Understanding why the transition from quality-as-phase to continuous quality is genuinely difficult is not an excuse for not making it. It is a prerequisite for making it successfully.

The Skills Gap

Continuous quality requires that developers write tests that are meaningful, not merely present. Most developers were not trained to do this, and many have spent careers in environments where testing was delegated downstream. Writing tests that cover critical behavior, that are maintainable, that fail for the right reasons, and that are specific enough to be useful diagnostically — these are skills that must be developed deliberately, and they take time.

Attempting to move to a continuous model without investing in developer testing capability produces a predictable outcome: developers write tests, the test suite grows, CI runs the tests, and the organization believes it has achieved continuous quality. What it has actually achieved is a large, expensive, poorly designed test suite that provides weak evidence and incurs high maintenance costs. This is coverage illusion at the process level — the phase is gone in name, but the quality of the testing has not improved.

The Short-Term Productivity Hit

When a team transitions from phase-based to continuous quality, the short-term impact on delivery velocity is negative. Developers are spending time on tests they previously delegated. Requirements reviews take longer because testability is now considered. CI pipelines are slower because they run more tests. The work that was previously concentrated in a downstream phase is now distributed across the cycle, and the team feels the additional load before it feels the reduction in rework.

This short-term hit is real, predictable, and temporary. It typically resolves as the team develops the practices and the test infrastructure matures. But it requires leadership to hold the course during the transition — to resist the pressure to revert to the phase model because "it felt faster" — and to communicate clearly that the short-term cost is the price of the long-term gain.

The Accountability Gap

In the phase model, quality accountability is clear: QA is responsible for it. When a defect escapes to production, there is a function whose remit includes finding that defect. In the continuous model, quality accountability is distributed. It belongs to the team. And distributed accountability, without careful organizational design, can become no accountability — everyone responsible could mean no one responsible.

Avoiding this requires that the continuous model includes explicit quality accountability at the team level — that retrospectives include quality evidence review, that release decisions require documented risk assessment, and that escape rates are tracked and discussed as team metrics, not as QA metrics. Quality becomes no one's job title and everyone's job responsibility. That transition requires deliberate structural design, not just an announcement that quality is now everyone's concern.

Wrapping Up

The QA-is-a-phase assumption is one of waterfall's most resilient artifacts. It survived the transition to Agile because it maps onto natural organizational divisions, produces measurable outputs, and concentrates quality skills in a specialist function. These are real advantages, but they are outweighed by the structural costs they impose.

The phase model makes late discovery structurally inevitable. It creates bottlenecks that cannot be solved by hiring. It produces signal latency that allows defects to compound before they are detected. It concentrates quality accountability in a function that cannot own it alone. And it measures quality through metrics that are legible but poorly correlated with actual system reliability.

Continuous quality is not a methodology or a tool. It is a structural property of the development process: quality evidence is generated at the stage where it is cheapest to act on, by the people who are in the best position to generate it, as a non-negotiable part of the definition of done. Achieving it requires skills investment, process change, infrastructure investment, and leadership commitment to absorb a short-term cost for a long-term gain.

The QA phase is not a safety net. It is a delay mechanism that makes defects more expensive without making them less frequent.