Should testers sit in one QA team or inside product squads? An org-design choice, not a tooling one — it shapes when QA gets involved, how consistent the bar is, and whether testers grow as a craft. The trade is proximity vs consistency.
How to scope a regression pass to the change in front of you instead of re-running the entire suite by hand.
The API ships weeks before the screen. Test it directly from the contract — the whole bad-input, auth, and edge class is open at the API and invisible once the UI hides it.
A test strategy is a short set of project-specific decisions, not a generic thirty-page document. Scope, risk, levels, automation split, data, ownership, and what "done" means.
A 30-second readiness check before accepting a ticket into QA — testable criteria, defined edge cases, reachable build, known data — that replaces a day of back-and-forth.
The working log that isn't a bug report or a test case — coverage, open questions, un-reproducible anomalies, painful setup — that makes a tester faster and more credible.
Automate the mechanical (axe/lint: alt, labels, contrast) and spot-check the obvious in a PR; route keyboard, focus, and screen-reader testing to QA on a real build.
A security report has extra duties: private channel, impact over exploit, test data only, redacted evidence, clear severity — getting it fixed without making it worse.
A dated June 2026 retrospective: shift-left landed as a sensible default oversold as a revolution — real early-bug wins, real damage where it meant 'delete QA'.
The 40-page IEEE 829 test plan: written once at kickoff, opened twice during the project, abandoned after release. There's a single-page replacement that teams actually update.