How to run regression test cycles in Jira every release

You wrote your regression tests once. Now you need to run them again for every release and still know what passed last time. The usual problem is that a Test in Jira has one status, so the new run overwrites the old one, or an old "passed" shows up as if it were today's result. Here is a no-app setup that keeps each release separate, its limits, and when a test management app is the better fit.

This guide assumes you already keep test cases as their own work type with a regression label. If not, start with managing test cases in Jira without a plugin.

The idea: separate the test from the run

• Test (your library): what to check and the expected result. It never stores a pass or fail.
• Test Cycle: one work item per round of testing, for example Regression 4.2, with the release in Fix versions.
• Test Run: a sub-task of the cycle, one per Test, holding the result for that round only.

Because every round gets new Test Run sub-tasks, results from release 4.1 stay on the 4.1 cycle and release 4.2 starts from Not run.

Step 1: add the work types and a run workflow

1. Ask a Jira admin to add a Test Cycle work type (a standard type) and a Test Run sub-task type to your QA project in Settings > Work items > Work types.
2. Give Test Run a small workflow: Not run, Passed, Failed, Blocked and Skipped.
3. Optional fields on Test Run: Environment (select) and Build (short text), so a failure can be traced to where it ran.

Step 2: create the runs with Automation

Creating 80 sub-tasks by hand each release is where most teams give up. One Automation rule does it from the cycle work item:

1. Trigger: Manual trigger, so a tester starts it from the Test Cycle when the round begins. Add a condition that the work type is Test Cycle.
2. Branch: Related work items with JQL, for example project = QA AND issuetype = Test AND labels = regression ORDER BY key. Inside the branch, {{issue}} is each Test and {{triggerIssue}} is the cycle.
3. Inside the branch, add Create work item: work type Test Run, parent set to the trigger work item (the cycle), summary {{issue.key}} {{issue.summary}}, description {{issue.description}}, and Fix versions copied from the trigger work item.
4. Optional: in the same action, link the new run to the Test with a link type such as "tests", so each Test shows its runs across releases.

Run it on a cycle with a few tests first and check the audit log. Keep Automation's service limits in mind: a rule can fetch at most 5,000 associated items per run, the Lookup work items action only uses the first 100 results, and every run counts toward your plan's monthly Automation usage. For a large suite, split the JQL by component and use one rule per area.

Step 3: run the cycle

• Testers work through the cycle's sub-tasks and move each Test Run to Passed, Failed, Blocked or Skipped.
• For a failure, create a Bug from the Test Run and link it, so the developer sees exactly which test and release found it.
• Use a board filtered to issuetype = "Test Run" AND parent = QA-123 (your cycle key) with columns for the run statuses, so progress is visible at a glance.

Step 4: report on the release

• This round: save parent = QA-123 as a filter and show it in a Pie chart gadget grouped by status shows passed, failed, blocked and not run.
• Per release: issuetype = "Test Run" AND fixVersion = "4.2" AND status = Failed lists every failure for the release, across cycles if you ran more than one.
• Who is doing what: a Two dimensional filter statistics gadget with status against assignee shows each tester's open runs.
• Release sign-off: export the cycle's runs from the search view, or attach the dashboard to the release notes.

Where this setup breaks down

• Work items pile up. 150 regression tests run twice a release for ten releases is 3,000 Test Runs a year, all in your search results and Automation counts.
• Steps are copied, not linked. Each run gets a copy of the description, so a fix to a Test after the cycle starts does not reach the open runs.
• One result per run. You cannot mark step 4 failed and steps 1 to 3 passed without more custom fields.
• No trend view. "Which tests failed in three of the last five releases" needs an export and a spreadsheet.
• Automated results stay outside. CI runs cannot update Test Runs without custom scripts against the Jira REST API.
• Rule upkeep. Someone has to maintain the JQL, the work types and the rule as the suite grows.

For a few dozen manual checks and one or two releases a month, this setup can work well. Larger suites, several releases in flight or CI pipelines usually make the upkeep cost more than an app.

When a test management app is the better fit

A test management app stores cycles and runs outside your work item list and keeps each round separate by design. Proofline builds a cycle from a folder or a selection of test cases, with an optional version, and every test in a new cycle starts as not run, so last release's pass never counts for this one. Testers run it step by step, mark pass, fail, blocked or skipped, add comments and defect keys, and jump to the next test. Reusable steps live in one test case and are called from others instead of copied. The issue panel shows each story's linked tests and latest results, and the coverage report shows what is passing, failing, not run or untested for any JQL, such as a fix version. Automated suites can post results straight into a named cycle from CI (JUnit, Playwright or Cypress). Proofline runs entirely on Atlassian Forge, is free for up to 10 users and is pending Atlassian Marketplace review.

Whatever you choose, try it with your real regression suite and one full round before you commit. Moving from a spreadsheet or another tool? See migrating test cases from CSV or TestRail.

Frequently asked questions

Related guides

• How to manage test cases in Jira Cloud without a plugin
• How to import JUnit or Playwright test results into Jira
• How to set up test traceability in Jira
• How to evaluate Zephyr Essential vs a lighter Jira test management approach