--- source_url: "https://betterqa.co/jira-workflow-example/" title: Jira workflow examples for QA teams (2026) mirrored_at: 2026-08-25T01:02:29.431Z host: betterqa.co cited_in_42a: true mirror_canonical: "https://index.42a.ai/betterqa.co/jira-workflow-example/index" --- > **Original source:** https://betterqa.co/jira-workflow-example/ Overview 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. 40% Less time hunting for ticket status 6 Essential QA workflow states 2x Better burndown accuracy The Problem ## 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. The Core Issue 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. Workflow Design ## 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 Open Backlog 2 In Development Dev owns 3 Ready for QA Handoff 4 In QA QA owns 5 QA Passed Release ready 6 Done In production 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 Transitions ## 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. In Dev Ready for QA Cannot skip directly to QA Passed Ready for QA In QA, In Dev Cannot skip directly to Done In QA QA Passed, In Dev Requires test execution before pass QA Passed Done, In QA Cannot reopen without justification Jira Tip 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. Bug Classification ## 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. Critical System crash, data loss, security breach Major Core feature broken, no workaround Minor Feature impaired, workaround exists Trivial Cosmetic issue, no functional impact Blocker Fix immediately, blocks release High Fix this sprint, significant impact Medium Schedule soon, moderate impact Low Backlog, fix when convenient The Gap ## 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? Jira Knows Ticket Status Open, In QA, Done What was tested? Missing Code Changes Commits, branches, PRs [BetterFlow](https://betterflow.eu/) 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. Feature Commit Correlation See all commits linked to a Jira ticket, with timestamps and author information. Feature Post-Test Changes Get alerted when code changes after QA marks a ticket as passed. Feature Time Tracking Correlate logged hours with actual development activity for accurate billing. Implementation ## 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. 1 Audit Your Current Workflow Document your existing statuses and transitions. Identify where QA work is hidden, where handoffs get stuck, and where tickets skip validation steps. 2 Design QA-Specific Statuses 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. 3 Configure Transition Rules Set up validators to prevent shortcuts. Require comments for backwards transitions. Add automation rules to notify QA when tickets become ready. 4 Integrate with Source Control Connect Jira to GitHub or GitLab to correlate commits with tickets. For deeper traceability, set up [BetterFlow](https://betterflow.eu/) to track what code was tested. 5 Train Your Team 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. FAQ ## Frequently asked questions How do I handle tickets that need to go back to development after QA finds bugs? Configure a transition from “In QA” back to “In Development” that requires a comment explaining the bug. This captures context without creating a separate bug ticket. The same ticket moves backwards through the workflow until it passes QA. Should QA engineers have separate sub-tasks or use the main ticket? For most teams, testing should happen on the main ticket using the “In QA” status rather than creating sub-tasks. Sub-tasks add overhead and fragment the ticket history. Only create separate QA sub-tasks if you need to track QA hours independently for billing purposes. What is the difference between “QA Passed” and “Done”? “QA Passed” means testing is complete and the ticket is ready for production deployment. “Done” means the code is actually deployed and verified in production. This separation lets you batch releases while still tracking what has been validated. How long does BetterFlow integration take to set up? [BetterFlow](https://betterflow.eu/) integrates via OAuth with both Jira and GitHub. Initial setup takes about 30 minutes. Historical data correlation begins immediately, and you will see commit-to-ticket mappings within your first day of use. ### 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. [Book a discovery call](https://calendly.com/betterqa) _Tudor B. is founder of [BetterQA](https://betterqa.co/), 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.