Handing an Engagement Over Mid-Test
Somebody is ill, or a job overruns into another. What the second tester needs in order to carry on rather than start again, and why most handovers lose a day.
Handovers happen mid-engagement more often than anybody plans for, and they usually cost a day. Not because the work is hard to explain, but because the things a tester carries in their head for a week were never written anywhere.
What is actually lost
Findings survive a handover. They are written down, rated and evidenced. What does not survive is everything around them:
- Which areas have been covered and found nothing, as against not looked at yet. This is the big one, and it is why the second tester re-tests things.
- The credentials that work, which of them are for which role, and which one the client reset on Tuesday.
- The three things that looked interesting and have not been chased.
- The one endpoint that returns a 500 for a reason nobody has worked out.
- What the client has already been told, verbally, in a stand-up on Wednesday.
"Tested, nothing found" and "not tested" look identical in an empty report section and mean completely different things. If your notes cannot tell them apart, the second tester either repeats a day of work or signs off coverage that does not exist.
Write the negative results down
Testers record what they find. Almost nobody records what they checked and cleared, because it feels like writing down nothing. It is the single most useful thing in a handover, and it is also what lets you answer "did you test X" three months later without hedging.
It does not have to be prose. A checklist per area with a date and a name against each line is enough, and it doubles as the evidence for your own coverage claims.
The handover itself
Thirty minutes, live, with both testers and the notes open. Not a document thrown over a wall, because the questions the second tester has are not the ones the first thought to answer.
Cover, in this order: what the target is and what matters about it, what is done, what is in flight, what is not started, the access situation, and anything the client has been told. Access last is deliberate, because it is the part most likely to have changed since Monday and it is worth checking live rather than reading out.
Tell the client
Somebody new is going to appear in their inbox and possibly in their logs. Tell them before that happens, with the name, and confirm the authorisation covers the new person. If your authorisation letter names individuals, it now needs amending, and finding that out after the traffic starts is a bad afternoon.
Say it plainly and without apology. Handovers are normal in professional services and clients handle them fine when they are told; what they mind is finding out from a log.
Who writes the report
Decide this at the handover, not at the end. The two workable answers are that the second tester writes everything, using the first tester’s notes, or that each writes their own findings and one person edits the whole for voice. What does not work is both writing separately and stapling it together, which produces the two-voice document a client notices immediately.
The lead named on the report should be whoever will answer questions about it in three months. Usually that is the second tester, and if it is not, the first needs to still be reachable.
Planned handovers are a different problem
Everything above assumes the handover is unwanted. Some are not: a job that deliberately runs across two testers for coverage, or a long engagement where a specialist takes one phase. Those go wrong differently, and the failure is overlap rather than gaps.
Two testers working the same target without a boundary produce duplicate findings with different ratings and different wording, and somebody spends an afternoon merging them badly. Draw the line up front and draw it by area rather than by time: one takes authentication and the user-facing application, the other takes the API and the infrastructure. Time-sliced handovers are what produce the coverage question, because neither tester owns anything end to end.
Then agree one person as the report owner from day one. Not at the end, when both have written in their own voice and the merge is a rewrite. The owner settles the severity calls where they disagree, edits for one voice, and is the name a client comes back to. The other tester writes their findings into the same structure rather than into a separate document, which sounds obvious and is the step that gets skipped every time it is not stated.
The version most firms need
If this is the first handover you have had to do, the minimum that avoids the lost day is: a coverage list with cleared items marked, current credentials with roles, a short list of loose ends, and a thirty-minute call. Everything else is refinement.
Findings, evidence and the phase each one belongs to are on the engagement rather than in a tester’s local notes, so the second tester inherits the work rather than a summary of it. Checklists and runbooks record what has been covered and cleared, which is the part that otherwise lives in somebody’s head, and the lead tester on the engagement is a field you change when the answer changes.
Pental Is Built by the People Writing This
Engagement management for testing firms, on a database you own, under your brand, with the AI running on your key.