Quality Is Not a Phase, It Is a Property

Open any sprint board and look at where "QA" sits. Almost always it is a narrow column wedged between "Code Review" and "Deploy," three or four days squeezed in before release. A phase.

Now try the same thing with security. Imagine a column called "Security Phase," three days near the end, where a team injects safety into a system that was built for two weeks without thinking about it. You would call that negligent. Nobody ships a system and then adds security as a step. Security is a property of the system: specified up front, designed in, and measurable throughout.

Quality is exactly the same kind of thing. Treating it as a phase quietly assumes you can build for two weeks however you like, then have a team walk in on the last three days and pour quality into the finished object. You cannot. A property is not a step you perform; it is a characteristic the system either has or does not.

A Phase Is a Point in Time, a Property Is Everywhere

The difference is not semantic. A phase happens once, in a fixed slot. A property has to hold across the whole system, at every point, under load. This is why the "quality attributes" of software, testability, resilience, observability, behave like security and performance and not like tasks:

• Testability is decided before a line is written. Tightly coupled classes, hidden state, and unmockable dependencies cannot be made verifiable during a test window. The seams have to be designed in.
• Resilience is a shape, not a check. If a retry creates a duplicate record, finding it at sprint's end does not make the system resilient. It only exposes that the design was not.
• Observability is built or it is absent. Testing a service with no structured logs, metrics, or tracing is walking a dark room without a flashlight, and no amount of test-phase effort adds the light later.

Make It a Requirement, Not a Column

If quality is a property, it belongs where properties are defined: in the design. The first technical design document should state how the system will be observed and how it will be isolated, in the same breath as its latency budget and its security model. A quality attribute you can name and measure is a requirement. A "QA phase" on the calendar is just a place to discover, in a panic, everything the design left out.

Squeeze quality into a phase and you turn the quality engineer from an architect who raises the system's safety into an expensive alarm that reports the fire too late. This is where the problem ends and the craft begins. So in the projects you work on: is QA still a stop you visit after the code is done, or an engineering discipline that starts when the system is designed?