What good QA handover notes look like

Whether it's holiday cover, an offboarding, or just passing a feature to a teammate, the handover note is one of the highest-leverage documents in QA — and one of the worst-written. The usual failure is writing a diary ("tested login, tested checkout, filed three bugs") when what the reader needs is an operating manual: how do I pick this up and not break anything? Good handover notes are written for the person arriving, not as a record of the person leaving. The test of a good one is simple — could someone competent but unfamiliar take over from it alone?

What the next person actually needs

Forget the chronology of what you did. Document the things that are hard to rediscover:

Current state and what's in flight. What's tested and stable, what's mid-test, what hasn't been touched. The reader's first question is "where are things right now?" — answer it first. Lean on your running test notes for this; they're the raw material.

How to set it up. The painful, undocumented stuff: which environment, which accounts/credentials, which feature flags, what data you need and how to create it. This is what costs a newcomer a day to rediscover and a sentence for you to write down.

Known issues and their status. Open bugs that matter, with where they stand — fixed/verifying/won't-fix/deferred. Crucially, the judgement calls: "this is a known issue we're shipping with, agreed with the PM." Without that, the next person re-reports it or panics over it.

Risk areas and gotchas. The fragile parts, the things that look broken but aren't, the flaky test everyone re-runs, the integration that breaks if you test it in the wrong order. Your hard-won "watch out for" knowledge is the most valuable and most easily-lost thing here.

Where everything lives and who to ask. Test cases, automation, the relevant tickets, and the one or two people who know this area. A pointer saves an hour of hunting.

QA handover notes

• Current state: what's stable, what's in progress, what's untouched
• Setup: environment, accounts/credentials, feature flags, required test data and how to create it
• Known issues with status — including deliberate "shipping with this, agreed" decisions
• Risk areas, fragile spots, and gotchas ("looks broken, isn't"; "test X before Y")
• Pointers: where test cases/automation/tickets live, and who to ask about this area
• Anything time-sensitive (a release date, a pending decision, a deadline)
• Written for the arriver to act from alone — not a diary of what you did

The test of a good handover

Here's the check I apply: could someone competent but unfamiliar with this area pick it up from these notes and not get stuck or break something? If the answer needs "well, they'd have to ask me," the notes have a gap — fill it. That reframes the whole exercise away from "summarise my work" toward "remove the need for me to be reachable," which is the actual point of a handover.

A diary of activity fails that test instantly; an operating manual passes it. Spend the effort on setup, known-issue judgement calls, and gotchas — the things that are genuinely hard to rediscover — and keep the "what I did" to a minimum. The best compliment a handover note can get is that nobody needed to message you while you were away.