Quality engineering

The useful question is not how much of the code is tested but which failures would be caught. A suite with high coverage and no assertions about behaviour passes happily while a checkout charges twice. The tests worth writing are the ones that encode a rule someone would be fired for breaking: money is never charged twice, a user cannot see another tenant's data, a submitted order cannot vanish. Those are few, they are slow to write, and they are the entire reason the suite exists.

A flaky test is worse than no test, and this is the failure mode most suites die of. Once a test fails intermittently, people rerun it; once people rerun it habitually, they rerun the real failures too, and the suite has quietly become decoration. The only sustainable policy is that a flaky test is fixed or deleted the same week, and that a red build genuinely blocks — a rule which is easy to state and requires actual discipline to hold.

Load testing and accessibility are the two audits most often deferred and most expensive to defer. Load problems are architectural, so discovering them the week before a campaign leaves no time to fix the cause — only to buy larger servers. Accessibility is the same shape: it is inexpensive when it informs the design and a rebuild when it is retrofitted, and in a growing number of markets it is also a legal requirement rather than a courtesy.