Jira review for QA teams: pricing, alternatives and setup

Everything in Jira is a work item, formerly called an issue, of a given work type such as Bug, Story, Task or Epic, inside a space, formerly a project. Software spaces include Bug by default; business spaces start with only Task and Subtask. Each work type has a set of fields, a screen layout and a workflow, assigned through schemes that can be shared across spaces. That scheme model is why two spaces that look identical can behave differently, and why one change to a shared scheme can alter dozens of spaces at once. The renames are cosmetic: the REST API and JQL still use issue.

A workflow defines statuses and the transitions between them, and each status belongs to a category: To Do, In Progress or Done. Separately, the resolution field records why a work item ended, such as Fixed, Duplicate or Cannot Reproduce. Atlassian’s guidance is explicit that Jira considers a lifecycle finished when resolution has a value, and that Unresolved simply means it is empty. Reports such as Created vs Resolved, the Open Issues filter and resolution = Unresolved queries all depend on it. A workflow that moves bugs to Closed without setting a resolution therefore leaves them open in every metric, which is the most common cause of wrong defect numbers.

Jira Query Language is a structured query syntax over fields, such as issuetype = Bug AND resolution = Unresolved AND priority in (Highest, High). Saved as filters, queries drive boards, dashboards, gadgets, subscriptions, automation conditions and API searches, so most of Jira’s reporting is JQL in some form. That is why consistent field use matters: a filter can only find what was recorded the same way every time. JQL has traps of its own. A not-equals comparison such as resolution != Fixed skips work items with no resolution, so it needs OR resolution IS EMPTY to include them.

Jira has no test case entity, so test management comes from Marketplace apps. Some, such as Xray, add new work types like Test and Test Execution, so tests are Jira work items queryable with JQL. Others, such as Zephyr, keep test cases in their own store and link them to work items. On Cloud, an app’s data can live with its vendor rather than in Jira: Xray Cloud, for example, documents that its data sits on its own infrastructure. Licensing follows the host: Marketplace apps for Jira are priced on the number of Jira users on the site, at the same user tier and billing cycle, whether or not each user tests.

Start with as few statuses as the team will actually use: Open, In Progress, In Review or Ready for Test, and Done, with a separate resolution for each way a bug can end, such as Fixed, Won’t Fix, Duplicate and Cannot Reproduce. Resist a status per team handover; it multiplies transitions and makes cycle time meaningless. Require only the fields that drive decisions: environment, severity or priority, the version where the bug was found, and steps to reproduce. Agree which of priority and severity you use, because teams that record both inconsistently cannot report on either. Make reopening an explicit transition that clears the resolution, so reopened bugs count as open again and can be measured.

A small set of shared filters answers most questions about quality and keeps everyone looking at the same numbers. Save them with clear names, share them with the space, and build one dashboard from them for release readiness. Prefer functions such as unreleasedVersions() and startOfWeek() over hard-coded versions and dates, so the filters stay correct without editing. Remember the not-equals trap: any condition that excludes a value also excludes empty fields unless you add an IS EMPTY clause.

A nightly suite that fails should leave a trace someone will triage, not a red build nobody opens. Atlassian’s own GitHub Actions for Jira, the gajira family, are deprecated and unmaintained, so call the REST API directly. Version 3 expects the description in Atlassian Document Format, a JSON document structure rather than plain text or wiki markup. Authenticate with an Atlassian account email and API token stored as secrets; tokens expire within a year, so put renewal in someone’s calendar. Raise one bug per failing run rather than per test, link to the run, and label it so a filter can find automated reports.

Use automation for the repetitive mechanics of defect handling: assign new bugs by component, add the reporter’s environment, transition a bug to Ready for Test when its pull request merges, and comment on linked stories when a bug is resolved. Keep each rule small, give it an owner and a description, and scope it to the spaces that need it rather than the whole site. On Cloud, every executed trigger, condition, branch and action counts as a step against a monthly allowance pooled across the organisation: 150 for the whole site on Free, and 400, 750 or 1,000 per user on Standard, Premium and Enterprise. Check the usage page monthly, because a rule that fires on every field edit can consume an allowance quickly, and extra usage becomes billable from 3 December 2026.

When the team needs test cases, runs and coverage, choose a test management app rather than modelling tests as custom work types. Xray stores tests as Jira work items, which suits JQL-heavy teams and regulated traceability; Zephyr keeps a separate test library linked to work items, which keeps spaces cleaner. Either way, budget for licences sized to every Jira user on the site, and connect automation results through the app’s API so executions are not entered by hand. If you are on Data Center, plan now: there are no new subscriptions after 30 March 2026, expansions end on 30 March 2028, and end of life is 28 March 2029. Check that your apps, including test management, have Cloud equivalents and a migration path before committing to dates.