QA and software testing

Enough that the paths which are expensive to get wrong are checked automatically on every release, and not much more than that. We risk-rank first: what costs money when it breaks, what breaks often, what is tedious to verify by hand. A payments flow deserves thorough automated coverage. A marketing page that changes monthly deserves almost none. The failure mode we see most often is a uniform coverage target — chasing eighty percent everywhere produces a great many tests on trivial code and a false sense of safety.

Usually, and the diagnosis is nearly always the same: too many end-to-end tests, too few unit tests, and shared state between tests so they interfere with one another. The fix is to push coverage down the pyramid — replace slow browser tests with fast tests on the same business rules — and to make every test set up and tear down its own data. Flaky tests get quarantined immediately rather than re-run until they pass, because a suite people re-run on failure has already stopped being a signal.

Yes, against WCAG 2.2 AA. It is worth being honest about the split: automated tooling catches roughly a third of real problems — missing alternative text, contrast failures, unlabelled form controls. The other two-thirds need a person to navigate the whole task by keyboard, listen to what a screen reader actually announces, and judge whether the focus order makes sense. We do both, and the report ranks issues by how much they block a real user rather than by how many instances of each there are.

Yes, and it is often more useful than testing our own work, because we come to it without assumptions about how it is supposed to behave. We start with a risk-ranking exercise and an exploratory pass, which typically surfaces a set of issues within the first few days. You get a defect report with reproduction steps and severity, plus a recommendation on where automation would pay for itself if you want to go further.