Jira’s default workflows assume every ticket follows the same linear path. For QA teams, this creates invisible bottlenecks and that persistent question: what exactly did we test? This guide walks through building Jira workflows purpose-built for QA teams, with clear status visibility and proper separation between development and testing phases.
Less time hunting for ticket status
Essential QA workflow states
Better burndown accuracy
Why default Jira workflows fail QA teams
Standard workflows treat testing as a single checkpoint. Where does QA fit? Usually crammed into “In Progress” alongside development. This collapses the entire testing process into an invisible phase, making it impossible to track how long testing actually takes, who is blocked waiting for builds, or whether a ticket is ready for release.
The result is poor sprint visibility. Burndown charts become meaningless when 60% of your work is hidden inside a single status. Developers mark tickets “Done” when code is complete, but QA has not even started. Product managers cannot tell what is actually ready for release versus what is still being validated.
Default Jira workflows were designed for development, not quality assurance. QA teams need dedicated states that make testing work visible on the board, in reports, and in sprint planning.
Essential statuses for QA workflows
A well-designed QA workflow separates development from testing with explicit handoff points. Each status should answer a specific question: who owns this ticket right now, and what needs to happen next?
1
2
3
4
5
6
| Status | Owner | Exit Criteria |
|---|---|---|
| Open | Product Manager | Ticket is groomed with acceptance criteria, assigned to sprint |
| In Development | Developer | Code complete, PR merged, build deployed to test environment |
| Ready for QA | Developer (handoff) | QA engineer picks up ticket and begins testing |
| In QA | QA Engineer | All test cases pass, no blocking bugs found |
| QA Passed | Release Manager | Deployed to production and verified |
| Done | Archived | Ticket complete, available for reporting |
Workflow transitions and rules
Transitions control how tickets move between statuses. The key is preventing shortcuts that skip QA validation while allowing legitimate backwards movement when bugs are found.
Use workflow validators to enforce transition rules. Require comments when moving tickets backwards (from In QA back to In Development) so bug context is captured automatically.
Setting up bug priority levels
Priority and severity are distinct concepts that often get confused. Severity measures technical impact – how badly is the system affected? Priority measures business urgency – how quickly must this be fixed? A typo on the homepage might have low severity (no functional impact) but high priority (brand reputation). A critical database bug might have high severity but low priority if it only affects an internal admin tool nobody uses.
System crash, data loss, security breach
Core feature broken, no workaround
Feature impaired, workaround exists
Cosmetic issue, no functional impact
Fix immediately, blocks release
Fix this sprint, significant impact
Schedule soon, moderate impact
Backlog, fix when convenient
What Jira workflows cannot answer
Even a perfect Jira workflow cannot answer one critical question: what code was actually tested? Jira tracks ticket status, but it has no visibility into commits, branches, or test coverage. When a developer marks a ticket “Ready for QA,” did they push one commit or twenty? Did the codebase change after QA started testing?
Open, In QA, Done
What was tested?
Commits, branches, PRs
BetterFlow addresses this gap by correlating Jira data with GitHub activity. When a QA engineer opens a ticket, they see exactly which commits are associated with that ticket and whether the code changed after testing started. This correlation turns abstract ticket statuses into concrete traceability – you can prove which version of the code passed QA.
See all commits linked to a Jira ticket, with timestamps and author information.
Get alerted when code changes after QA marks a ticket as passed.
Correlate logged hours with actual development activity for accurate billing.
Getting started with QA workflows
Start with a pilot project rather than rolling out workflow changes across your entire organization. Pick a team that is already frustrated with their current process – they will be motivated to try something new and give honest feedback.
Document your existing statuses and transitions. Identify where QA work is hidden, where handoffs get stuck, and where tickets skip validation steps.
Add the six essential statuses: Open, In Development, Ready for QA, In QA, QA Passed, and Done. Define clear ownership and exit criteria for each.
Set up validators to prevent shortcuts. Require comments for backwards transitions. Add automation rules to notify QA when tickets become ready.
Connect Jira to GitHub or GitLab to correlate commits with tickets. For deeper traceability, set up BetterFlow to track what code was tested.
Walk through the new workflow with developers and QA engineers. Explain why each status exists and what triggers each transition. Run a sprint with the new process and gather feedback.
Frequently asked questions
Need help optimizing your QA workflows?
Our team of 50+ QA engineers has built workflows for teams of all sizes. Talk to us about your specific challenges.
Tudor B. is founder of BetterQA, a software testing company that builds its own tools.
Need help with software testing?
BetterQA provides independent QA services with 50+ engineers across manual testing, automation, security audits, and performance testing.
