The QA to developer handoff checklist, from triage to closing the loop

When a bug bounces between QA and development, the bug itself is rarely the reason. The handoff is. This checklist covers both sides, from the moment a bug is found to the moment its fix is verified.

By the VeoRec team · Oct 3, 2026 · 11 min read

A bug crosses the gap between QA and development at least twice: once when it is reported, and once when the fix comes back for testing. Each crossing is a chance to lose something. The developer gets a ticket that cannot be reproduced. QA gets a fix with no note on what changed. Someone verifies on a build that does not contain the fix and reopens a ticket that was fine. A good QA to developer handoff removes those losses with a few habits that both sides agree on.

This post is a checklist for that handoff, in the order it happens: getting a ticket ready, triage, evidence, test data, questions, the fix, verification and closing. Each section explains why the item is on the list. Use the checklist as it is, or adapt it into your team's definition of ready and definition of done.

Use one QA to developer handoff checklist for every bug

The whole checklist fits on one screen. The ticks are saved in your browser, so you can run through it for the bug in front of you and come back later. The sections below explain each step.

Agree on what "ready for a developer" means

A common handoff failure is a ticket that enters a sprint before it is ready. The developer picks it up, cannot reproduce it, asks a question, and switches to something else while waiting. By the time the answer comes, they have lost the context.

The fix is a written definition of ready that both sides accept, and permission for developers to send tickets back when they do not meet it. "Back to QA: no starting state, no environment" is not rude if the team agreed on it. Without that agreement, developers quietly fill the gaps themselves, and QA never learns which fields matter.

A definition of ready for bugs is short. It is the core of any good report: steps from a clean start, expected and actual results, environment, frequency and evidence. If you need a reference for each field, see how to write a bug report. Score a ticket against it here:

Triage before you hand anything over

Triage decides what happens to a bug: whether it is real, whether it is new, how bad it is, when it will be fixed and who owns it. Skipping triage does not save time; it moves the decision to the developer who happens to pick the ticket up, who has the least context to make it.

Keep two ratings separate. Severity is the impact on users, and the tester who found the bug is usually the best judge of it. Priority is when the team will fix it, which depends on the release plan, the effort and everything else in the queue. Mozilla's bug field definitions are a good public example of keeping them apart:

Triage also has to be allowed to say no. Some bugs will not be fixed: the feature is being replaced, the impact is tiny, the fix is risky for little gain. Close those deliberately, with a reason ("won't fix: old editor is removed in the November release"), and if users will keep meeting the bug, add it to a known issues list that support can point to. A ticket left open forever is a decision nobody made, and it clutters every search the next tester runs.

Run triage on a schedule, not ad hoc: a short daily pass for new critical bugs and a weekly one for the rest works for many teams. Triage is also where duplicates get merged. Search for the error text and the feature name; if a ticket already exists, add the new evidence there and close the newcomer as a duplicate with a link.

Package the evidence in one place

Evidence that lives in a chat thread, a personal folder and someone's memory is evidence the developer will not find. Everything goes in the ticket, or is linked from it:

• The written steps, even if there is a video. Text is what gets searched, copied into a test and checked line by line.
• A short recording for anything involving a sequence or timing, with the failure timestamp next to the link: "0:42, second Save clears the VAT number".
• Exact error text and IDs: the message, the code, the request or trace ID, and the time it happened with the time zone.
• Console errors and the failing request from DevTools, with tokens and personal data removed.
• Screenshots for static problems, annotated so the issue is visible in the ticket preview (which format fits which bug).

A recording is the most compact handoff there is: steps, environment and result in one link. With VeoRec, clicks are highlighted in the video, the tester can drop a chapter marker at the failure, and the developer can reply with a timestamped comment instead of a vague "around the middle". The guide to video bug reports covers what makes a recording worth watching.

When a test run turns up many bugs at once, the temptation is one big ticket: "Checkout test run, 9 issues". Resist it. Nine problems in one ticket get one owner, one status and one priority, and the ticket cannot be closed until the slowest fix lands. File each bug on its own, link them all to the test run or release they came from, and post one short summary in the team channel with the links. Developers can then pick them up in parallel, and each fix gets verified on its own.

Hand over test data and access, not just the bug

A bug that needs a particular account, record or configuration is only reproducible if the developer has the same thing. Name it in the ticket: "Use workspace qa-billing-03, user [email protected]". If the data has to be created, write the setup as steps, or better, keep a seed script that produces it.

• Accounts. Keep a set of shared test accounts by role (admin, member, viewer, free plan, paid plan) and refer to them by name in tickets.
• Secrets. Share passwords and keys through your password manager. A password pasted into a ticket stays in its history forever, and tickets get exported, forwarded and attached to vendor support requests.
• Environments. Say which one: production, staging, a preview build. If staging data resets nightly, say that too, so nobody spends the morning looking for a record that no longer exists. A bug filed at 18:00 against data that vanishes at midnight needs its setup written as steps, not as a record name.
• Flags and configuration. If the bug only appears with a feature flag on, or a particular plan, or a particular locale, that is part of the test data.
• Real customer data. If the bug only shows on a customer's record, describe which property of the data matters ("invoices with more than 100 lines") so a test equivalent can be made, and follow your team's rules on access.

Keep the questions on the ticket

Even a good ticket generates questions. Where they are asked matters more than how. A question asked in a direct message gets a quick answer and disappears; the next person to touch the ticket, or the tester verifying the fix, never sees it. A question asked on the ticket becomes part of the record.

This does not mean banning conversations. A two minute chat at a desk or on a call can resolve what ten comments cannot. The rule is that the outcome goes back on the ticket: "Talked with Priya: only happens with the yearly price note visible. Updated steps." When the question is about a moment in a recording, a comment pinned to that timestamp is clearer than a description of it.

Agree on response times too. If QA answers developer questions within a few working hours, developers will ask instead of guessing. If questions wait two days, developers will guess, and some guesses will be wrong.

Agree on how the fix will be verified before work starts

Many "fixed, then reopened" tickets come from a mismatch between what the developer fixed and what QA expected. The developer fixed the symptom in the steps; QA tested a related path the developer never saw. Settle it up front with two lines on the ticket:

• Fixed means: the original steps, followed from the original starting state, produce the expected result. For intermittent bugs, it means the original attempt count: if it failed 4 of 20 times, 20 clean runs, not 2.
• Also retest: the areas a fix here could plausibly affect. A change to how billing saves addresses should be checked on the shipping address form that shares the code.

The developer adds the other half when the fix is ready: a short note on what changed and where the risk is. "Changed the billing PUT to send only modified fields; also affects the company profile form." That note is the single most useful thing a developer can give QA, and it costs a minute to write.

Write the developer's half of the handoff

Handoffs run in both directions, and the return trip gets less attention. When a developer moves a ticket to Ready for QA, the tester needs a few things that only the developer knows:

• Where the fix is. The build number, the environment it is deployed to, and the merge or pull request, so QA can confirm the build before testing.
• What changed, in plain words. Not the diff, but a sentence on the behaviour: "The billing form now sends only the fields you edited."
• Where the risk is. Other screens or jobs that share the changed code, which become the "also retest" list.
• How to reach hidden paths. If the fix covers an error state or a rare condition, how can QA trigger it? A flag, an admin tool, a test card that always declines.
• What happens to existing data. This one is easy to forget. If the bug damaged records (every VAT number that was wiped in the last month), does the fix repair them, or is a separate data fix needed? QA should check old records as well as new ones.

Five short lines, and they pay for themselves: QA tests what actually changed rather than guessing, and the developer, while writing them, often spots the side effect they had not checked.

Verify the fix on the right build

Verification is where a surprising amount of time goes to waste, often by testing a build that does not contain the fix. A routine that avoids it:

1. Confirm the fix is in the build you are testing Check the build number, commit or deploy log against the fix's merge. "Deployed to staging" is a claim; the build number is a fact.
2. Rerun the original steps exactly Start from the original starting state, with the same account and data. If the steps no longer apply because the UI changed, note how you adapted them.
3. Match the original frequency For intermittent bugs, run at least as many attempts as it took to see the failure before, under the same conditions, including any throttling.
4. Test around the fix Run the "also retest" list from the verification plan, plus one or two edge cases near the change: empty values, very long values, the other role.
5. Record the result Write a short verification note: build tested, steps run, attempts, what else was checked. A quick recording of the fixed behaviour next to the original one makes the note undeniable.

A familiar way this goes wrong: the developer merges the VAT fix at 15:10 and moves the ticket to Ready for QA. The tester sees the status at 15:20, runs the steps on staging, watches the VAT number disappear, and reopens the ticket with a slightly sharp comment. The staging deploy, it turns out, runs every hour and had not picked up the merge yet. Two people lose half an hour each, and the ticket history now says "reopened" for a fix that was fine.

Both halves of the handoff would have prevented it. The developer's note should have said which build would contain the fix ("in the 16:00 staging deploy, build 2026.10.3"), and the tester's first step should have been checking the build number in the app's footer or about page. If your app does not show its build number anywhere QA can see it, that is worth fixing before almost anything on this list; it turns "is the fix even there?" from a guess into a glance.

If the bug is still there, reopen the ticket with what you saw on which build. If the original bug is gone but you found a different one, file a new ticket and link it. Reopening a ticket for a new problem muddles the history and makes it impossible to tell later which change fixed what.

Make the handoff a link Record the bug with your voice and highlighted clicks, mark where it fails, and paste the link that is already copied when you stop. Developers reply at the exact second. See VeoRec for QA teams

Close the loop with the people who care

A bug is not finished when the ticket turns green. Three small things make the difference between a team that learns from its bugs and one that keeps meeting the same ones:

• A regression test, where it makes sense. If the bug could come back, a test that would have caught it is the cheapest insurance against that. If writing one now is not practical, create a ticket for it rather than letting the idea evaporate.
• A word to the reporter. If the bug came from support or a customer, tell them it is fixed and in which release. A support agent who sees their reports lead somewhere has a reason to keep writing careful ones.
• A look at the pattern. Every month or so, look at the bugs that bounced between QA and development the most. The cause is usually a missing field in the template or a missing step in this checklist, and both are cheap to fix. The bug report templates post has fields you can borrow.

Statuses help with all of this, as long as each one has a clear owner and exit condition. A simple set works for most teams: New (reporter), Triaged (triage), In progress (developer), Ready for QA (developer hands back, with the change note), Verified (QA, with the verification note) and Closed. If a ticket sits in Ready for QA for a week, that is a handoff problem worth talking about, not just a busy tester.

What to do next

Pick the handoff step that causes the most friction on your team right now. For many teams it is the definition of ready; for others it is verifying on the wrong build. Write a one paragraph rule for that step, agree on it at the next retro, and run the checklist above on the next five bugs. Then look at what bounced, and adjust the rule.

If tickets keep bouncing because steps do not reproduce, spend an hour with the team on writing steps to reproduce. It is the skill that most improves every handoff after it, and VeoRec recordings of the steps make the gaps visible in seconds.