Every list of QA best practices runs to twenty items because it was written for a QA department. A small web team has none, so most of the list describes roles nobody holds. Three practices carry the rest: a definition of done that names its checks, a triage rule with a clock, and findings that arrive with their evidence.
Twenty practices is a list for a department
Read the lists with a team of four developers and a designer in mind and the items sort themselves. Shift testing left assumes there is a right to shift it from. A test strategy document assumes somebody whose job includes keeping it true. A dedicated QA environment assumes ops time to keep it in step with production. A test case management tool assumes a person writing cases for a living. An automation engineer assumes an engineer.
None of the items is wrong. The list has no ordering, and a team that cannot do twenty things needs to know which to do first and what each of the others is standing in for.
| Practice from the lists | Role it assumes | What a small web team does instead |
|---|---|---|
| A written test strategy | Somebody to maintain it | A definition of done per kind of change |
| A dedicated QA environment | Ops time to keep it current | A preview deployment per branch, staging for the release |
| A test case management tool | A tester writing cases full time | Checks named in the definition of done |
| An automation engineer | A person | Developers own the tests for the code they write |
| A QA metrics dashboard | A manager reading it | A triage clock and a count of what escaped |
| Shift-left testing | A test phase to move | Acceptance criteria written before the story is picked up |
The right-hand column is what the three practices below add up to. Each entry in it is the cheapest thing that does the same job as the entry on the left, for a team that has nobody to hand the left-hand entry to.
Practice one: a definition of done with named checks
Most teams already have a definition of done, and most of them contain the word tested. The word is the problem, because it does not say who tested, in which browser, or against what. Under a deadline a word gets ticked; a named check gets run or gets visibly skipped, and visible skipping is the point.
For a web feature the named checks are short: the happy path walked on the preview deployment, the smoke checks on staging after the merge, the browsers and viewports it was opened in, one pass through with the keyboard only, and a console with no new errors when it is done. The QA checklist carries a fuller set to borrow from; the definition of done takes the handful that apply to this team’s stack and leaves the rest.
Keep it short enough to run on every story. A definition of done with twenty checks is the listicle again, and it fails the same way.
Practice two: a triage rule with a clock
A finding that nobody reads is a finding that gets filed twice, or gets fixed after the evidence around it has gone stale, or gets found again by a customer. On a small team the person who would read it is the person who would fix it, and reading waits for a quiet moment that does not arrive.
The rule that fixes this is a duty with a deadline rather than a process. Every new finding is read before the next stand-up by a named person. That person gives it a severity and, separately, a priority, because how bad it is and how soon it gets fixed are different questions and a team that collapses them argues about both at once. Then the finding is either scheduled or closed with a reason written on it. Bug triage done this way stops the backlog becoming a second product.
The named person needs one qualification: the authority to say the team ships without fixing this. Triage without that authority is a sorting exercise, and the pile it sorts keeps growing.
Practice three: findings that carry their evidence
On a team with no tester, most findings come from people who are not testers: the designer looking at a preview, the founder on a phone, a client during acceptance. What they write is what they saw. Reproduction needs what the page knew: the console error, the request that failed, the browser build, the route with its state. That gap is why a small team’s tracker fills with reports closed as cannot reproduce, and why the same defect comes back under a new title a fortnight later.
The fix is to have the page do the reporting. A designer on a preview or a founder on a phone cannot supply the console error, but the page they are looking at can, and evidence capture has the widget file the report from there with the console log, the network activity, and the browser, device and viewport it was open in already on the ticket. The reporter still says what they expected and what they got; the half they could never have supplied comes with it.
The same practice covers the pass that finds what no checklist named. Once a feature meets its definition of done, somebody who did not build it spends a timeboxed session on it with a one-line charter. That is exploratory testing, and on a small team it is the only place a second reading of the requirement happens. Its findings should arrive the same way, from the page, carrying the same evidence.
What the other seventeen are waiting for
The three practices have a cost the lists do not mention, and it does not go away with process. The developer who built a feature cannot find the defects in their own understanding of what it was meant to do. Somebody else has to walk it, and on a team with no tester that somebody is a colleague whose own work stops for the duration. Every story carries that time, no estimate contains it, and the only alternative is shipping the author’s blind spot.
The remaining practices each wait for a specific failure. A test strategy document is worth writing when two people disagree about what the definition of done means. A dedicated environment is worth the ops time when the preview deployment stops matching production in a way that has let a defect through. A test case management tool earns its place when the checks in the definition of done stop fitting in one file. Automation earns its place when the same manual check has caught the same regression twice. A metrics dashboard earns its place when somebody with budget asks for one.
Adopting any of them before its failure has happened produces a ceremony that the team performs and does not believe in. Adopting it after gives the practice a reason everybody on the team can name, which is the difference between a list and a way of working.
