thrumeYou found the bug.
Make the handoff count.
Finding the bug should not mean a second job explaining it. Show the failing path, mark the unexpected result and hand engineering the selected evidence from the same take.
Make the bug
hard to misunderstand.
Follow one failed invitation from the first reproduction to a reviewable retest.
Keep the step everyone would have missed.
Show the path into the failure, explain the expected result, and mark the moment. Your report preserves the sequence while it is still fresh.
A visible reproduction, not a memory test.Give the next person somewhere to start.
Select and connect relevant debug sources before recording. Share the visible failure with the nearby events, so engineering can inspect the same moment.
One reference for what happened and what was captured.Show what changed. Let the team judge it.
Record the scenario again after the change. Link the original report in the new recording’s description, so reviewers can compare the behavior and your result.
A retest someone else can actually review.Make room for
your next teammate.
Invitation could not be sent.
The failure.
And the evidence beside it.
“Invitation could not be sent.”
POST /api/invites · HTTP 500
Expected an invitation confirmation.
The story now has
a second take.
00:24 · Error on screen
00:19 · Confirmation shown
“Repeated the same invitation flow. Confirmation appeared. Original report linked below for review.”
Keep testing.
Stop reconstructing.
Exploratory testing finds the unexpected. Thrume gives those discoveries a clear path into engineering—and keeps your explanation useful after the handoff.
Answer the first follow-up in the recording.
Show the reproduction from the start, say what you expected and mark where it failed. Add the tested build, environment and reproducibility to the description. Give engineering the details they would otherwise ask you to repeat.
Hand over the failure and its clues.
Connect and select the relevant debug sources before the take. Share the recording and appropriate logs with engineering, so the developer can inspect the marked moment or retrieve its evidence through an authorized coding assistant.
Keep the path you took during exploration.
When an unexpected behavior appears halfway through a session, memory is a poor bug report. Record as you explore and mark discoveries, preserving the clicks and decisions that led there.
Show what changed in the retest.
After the fix, record the scenario again and reference the original report in the description. Name the build you tested and show the outcome. The reviewer gets a visible account of the check; you make the acceptance decision.
Bring your next
handoff into focus.
Start with a recording. Give the next person the context to move forward.