Bug fix release process (software release swimlane)
This swimlane diagram shows how a bug fix moves from report to production across four roles: QA, Developer, Reviewer and Release Manager. It is for team leads and process owners who want a clear view of who owns each step, where the hand-offs happen and where work can loop back.
Example: Swimlane diagram for a bug fix release: click to open it in the editor and change it.
Roles and what each lane owns
| Lane (role) | Steps owned |
|---|---|
| QA | Report bug, Verify fix, Pass? decision |
| Developer | Fix bug, Open pull request |
| Reviewer | Code review, Approve? decision |
| Release Manager | Deploy to production |
Steps and decisions in order
- QA logs the issue in Report bug, then hands it off to the Developer.
- Developer completes Fix bug and then Open pull request, handing the change to the Reviewer.
- Reviewer runs Code review and makes the Approve? decision.
- If the answer is Changes, the work goes back to the Developer at Fix bug. If the answer is Yes, it is handed to QA.
- QA performs Verify fix and decides Pass?
- If No, the fix returns to the Developer at Fix bug. If Yes, it is handed to the Release Manager.
- Release Manager completes Deploy to production.
There are four forward hand-offs: QA to Developer, Developer to Reviewer, Reviewer to QA, and QA to Release Manager. There are also two rework loops that send work back to the Developer.
Where this process usually slows down
- Code review queues: pull requests wait until a Reviewer is free, and this approval often has no SLA.
- Rework loops: each Changes or No outcome restarts the cycle at Fix bug, so the fix goes through review and verification again.
- Verify fix: QA may be busy reporting new bugs while fixes are waiting to be checked.
- Single owner for deployment: if only one Release Manager can Deploy to production, that role becomes a bottleneck.
How to adapt it for your project
- Rename the lanes to match your own roles, such as Support Agent instead of QA, or Change Advisory Board instead of Release Manager.
- Add approval limits, for example letting low-severity fixes skip a second approval while critical fixes need sign-off.
- Add an exception path for urgent hotfixes, and record an SLA for each hand-off.
- Name one owner per step so it is clear who is accountable for each decision.
Tip: Count how often the Changes and No loops are used. A high rework rate usually means unclear bug reports or acceptance criteria, not slow developers.
Frequently asked questions
What roles are in a software release process flowchart for a bug fix?
This diagram uses four lanes: QA, Developer, Reviewer and Release Manager. Each lane owns specific steps, from reporting the bug through deploying to production.
What decision points are in the bug fix release process?
There are two. The Reviewer decides **Approve?** after code review, and QA decides **Pass?** after verifying the fix. A negative answer at either point sends the work back to the Developer.
Who deploys the bug fix to production?
The Release Manager owns **Deploy to production**. This step happens only after the Reviewer has approved the change and QA has confirmed the fix passes.
Make your own swimlane diagram with AI →