Quality is engineered, not tested in.
Our perspective on how Quality Engineering is changing — informed by practitioner experience and ongoing research.
What we mean by this
We think of testing as one input to quality, not the mechanism that produces it. In our view, quality is shaped earlier — in architecture, in how data flows between systems, in how a team decides what "done" means — and testing mostly tells you whether that earlier work held up.
That distinction matters because it changes where attention goes. If quality is something you verify at the end, the natural response to a problem is to write another test. If quality is engineered throughout delivery, the response may instead involve architecture, data, environments, delivery practices, observability — or testing itself.
Testing can provide evidence about quality. It cannot create quality by itself.
How we see the practice evolving
We believe automation, data management and delivery practice are moving closer together than they used to be treated. A test suite that runs reliably but exercises unrealistic data may say less about production risk than its pass rate suggests — that tension shows up repeatedly in the practitioner conversations we have had so far.
We're also watching how AI-assisted and, eventually, more autonomous tooling gets folded into quality engineering work. Our current view is that these tools are additive to existing practice, not a replacement for the underlying discipline — but this is an area we are actively researching, not one where we consider our thinking settled.
Our thinking will continue to evolve as the research develops.