How to keep testers, developers and managers on the same page, from the bug someone finds to the fix that ships.
Ask a team why a release slipped and you rarely hear "we didn't test." You hear something closer to "we didn't know." Nobody knew the bug had been fixed. Nobody knew which version of the spreadsheet was current. Nobody knew whether the thing the customer reported last week was the same thing a tester found yesterday.
The testing happened. The information just didn't travel.
Where it breaks down
Most teams will recognise at least one of these:
- Bugs live in chat. A screenshot in a thread, a message in a DM. By Friday it has scrolled out of sight, and nobody can find the steps to reproduce it.
- Spreadsheets drift. Someone copies the test sheet for the new release. Someone else keeps editing the old one. Nobody is sure which row is the current one.
- Fixes go unannounced. A developer merges the fix and moves on. The tester who found it never hears, so it's never checked again, or it's checked weeks later.
- Release day is a guess. A manager asks whether it's ready. The honest answer is "probably," because nobody can see the whole picture in one place.
None of these are failures of skill. They're failures of hand-off: work passing between people and tools, and losing something on the way.
Turn the hand-offs into a loop
The fix isn't another place to copy things into. It's connecting the places your team already works, so the status moves by itself.
That's how QA Runbook works with GitHub, which is where most teams' code and developer work already lives:
- A tester raises the bug in QA Runbook, in their own words, against the check it's about or on its own for a live app. It gets a short code, like QA-13.
- It's filed in GitHub automatically, as an issue with the code in the title and a link back to every detail. Developers see it where they already work.
- The developer fixes it, and the pull request says so: "Fixes #8" or "Fixes QA-13". When it merges, GitHub closes the issue.
- QA Runbook marks it fixed on its own, links the pull request, and tells the tester it's ready to check.
- The tester confirms it on the real app. Fixed doesn't count until someone has seen it work.
Nobody had to chase anybody, and everyone saw the same status in both places.
The same loop for every kind of testing
The loop doesn't care what you're testing:
- A release you're about to ship: every check, every result per platform, and who found what.
- A new feature: a plan for just that feature, worked through by the people who know it.
- A live app: bugs from users and support, tracked from report to confirmed fix.
It fits the rest of the team
Testing touches more people than testers:
- Your AI assistant can connect over MCP, read what's failing, and record the results of the checks it can run itself.
- Your support desk can send customer reports straight in through the API, with the reporter attached.
- Managers get one report of what passed, what failed and what's fixed, ready to download or share.
You don't need to integrate everything
It's tempting to think a tool is only useful once it connects to everything. In practice, most teams' work meets in one place: GitHub. Get that connection right, and the loop from bug to verified fix closes itself.
That's the whole idea: testing, simplified and effective.
See it in two and a half minutes, all real footage: https://youtu.be/fFviMrot078
Set it up with the guide: https://qarunbook.com/docs/guides/github. There's a free plan, no card needed.
Top comments (0)