Jira workflow examples for QA teams, with statuses and transitions
Short answer
A Jira workflow is the set of statuses a ticket moves through and the transitions allowed between them. A basic software example is To Do, In Progress and Done. QA teams add Ready for QA, In QA and QA Passed, so testing shows on the board instead of hiding inside In Progress.
Below are three Jira workflow examples you can copy: the default software workflow, a QA workflow with explicit testing states, and a bug workflow. Each has a table of statuses and transitions, followed by the rules that stop tickets skipping testing, how to set it up, and what Jira cannot tell you.
What a Jira workflow is made of
A workflow has three parts. Statuses say where a ticket is (for example In QA). Transitions are the moves between statuses (for example from In QA to QA Passed). Every status belongs to one of three status categories: To Do, In Progress or Done. Boards and reports use the category, so a new status you add still needs to sit in the right one.
In company-managed projects a transition can also carry conditions (who may use it), validators (checks that must pass, such as a required comment) and post functions (actions after it runs, such as setting a field). Those are the tools that stop shortcuts.
The simple software workflow
A new software project in Jira starts with three statuses, one in each category. It is fine for a small team, but testing has no place of its own, so it ends up inside In Progress.
| Status | Category | What it means |
|---|---|---|
| To Do | To Do | Waiting to be started |
| In Progress | In Progress | Being built and, usually, tested too |
| Done | Done | Finished |
The usual result is poor sprint visibility. A ticket can be marked Done when the code is complete and QA has not started, and the burndown chart cannot tell the difference.
A QA workflow with six statuses
This is the workflow we recommend when a team has dedicated testers. It splits development from testing with an explicit handoff. Each status answers one question: who owns the ticket right now, and what has to happen next?
| Status | Category | Owner | Exit criteria |
|---|---|---|---|
| Open | To Do | Product manager | Groomed, with acceptance criteria, assigned to a sprint |
| In Development | In Progress | Developer | Code complete, pull request merged, build deployed to the test environment |
| Ready for QA | In Progress | Developer (handoff) | A QA engineer picks the ticket up and starts testing |
| In QA | In Progress | QA engineer | All test cases pass and no blocking bugs remain |
| QA Passed | In Progress | Release manager | Deployed to production and verified |
| Done | Done | Nobody (archived) | Complete, available for reporting |
Transition rules
The rules prevent shortcuts that skip testing, while still allowing a ticket to move back when a bug is found.
| From | Allowed to | Blocked |
|---|---|---|
| In Development | Ready for QA | Cannot go straight to QA Passed |
| Ready for QA | In QA, In Development | Cannot go straight to Done |
| In QA | QA Passed, In Development | Needs test execution recorded before pass |
| QA Passed | Done, In QA | Cannot reopen without a reason |
Jira tip. Add a validator that requires a comment when a ticket moves from In QA back to In Development. The bug context is then captured on the ticket without creating a second one.
A bug workflow
Bugs need a different path from stories, because they can be rejected as duplicates, cannot be reproduced, or come back after a fix. Many teams give the Bug issue type its own workflow.
| Status | Meaning | Moves on to |
|---|---|---|
| Open | Reported, not yet looked at | Triaged, Duplicate, Cannot reproduce |
| Triaged | Severity and priority agreed, an owner assigned | In Fix |
| In Fix | A developer is working on it | Ready to retest |
| Ready to retest | Fix deployed to the test environment | Verified, Reopened |
| Verified | Tester confirmed the fix, ready to release | Closed |
| Closed | Released or consciously not fixed | Reopened |
| Reopened | Fix failed, or the bug returned | In Fix |
Severity and priority
These are two fields, and keeping them apart makes triage faster. Severity is technical impact. Priority is business urgency. A typo on the homepage can be low severity and high priority; a database bug in an internal admin tool can be the opposite. Agreeing the scales early is the first step of defect management.
| Severity (technical impact) | Priority (business urgency) |
|---|---|
| Critical: crash, data loss, security breach | Blocker: fix now, blocks the release |
| Major: core feature broken, no workaround | High: fix this sprint |
| Minor: feature impaired, workaround exists | Medium: schedule soon |
| Trivial: cosmetic, no functional impact | Low: backlog, fix when convenient |
For writing the ticket itself, see how to write bug reports that get fixed.
How to set up a QA workflow in Jira
- Audit the current workflow. List the statuses and transitions you have, and note where testing is hidden or tickets skip validation.
- Pick one pilot project. Choose a team that already feels the pain. They will give honest feedback before you change anything company-wide.
- Edit a copy. In a company-managed project, open Project settings, then Workflows, and edit the workflow. Jira works on a draft until you publish it. Menu names change between Jira versions.
- Add the statuses and transitions from Example 2, and put each status in the right category.
- Add the rules. Conditions on who can move a ticket, a validator that requires a comment on backward moves, and an automation rule that notifies QA when a ticket reaches Ready for QA.
- Publish and map. If tickets already sit in a status you removed, Jira asks you to map them to a new one. Do this on a quiet day.
- Run one sprint, then adjust. Explain why each status exists, and review the board with developers and testers at the end.
Keep the status count small. Every extra status is another handoff and another place a ticket can sit unnoticed, so add one only when someone owns it.
What a Jira workflow cannot tell you
A perfect workflow still cannot say which code was tested. Jira tracks ticket status, but it does not see commits, branches or what changed after QA began. When a developer moves a ticket to Ready for QA, was it one commit or twenty? Did the code change after testing started?
BetterFlow, one of our tools, correlates Jira data with GitHub activity. A tester can see which commits belong to a ticket and whether code changed after QA marked it as passed. That turns a status into evidence of which version passed.
How BetterQA runs QA workflows in Jira
Our engineers work inside your Jira, with your statuses. We add the QA states from this guide only where they are missing. We write each bug so a developer can reproduce it from the report alone, and we agree the priority and severity scales with your team early on. That is the core of our defect management work.
If nobody on your team owns this workflow day to day, QA outsourcing puts it in the hands of testers who run it every day.
Frequently asked questions
Need help with your QA workflow?
Tell us what you are testing and we reply within one business day. Our engineers can set up and run the workflow inside your Jira.
