A release review can show fewer open bugs while regression testing is still incomplete. Developers may have resolved defects that testers have not yet retested, and a test cycle may contain blocked or unexecuted checks. A Jira QA dashboard needs to expose both situations without turning defect counts into an implied test pass rate.
Use six native gadgets for issue data and one installed-app gadget for execution results. Give each a specific question, a defined population, and an action someone owns. The configuration below uses Jira Cloud as its starting point, with deployment differences called out where they affect interpretation.
The same dashboard can legitimately show different totals because its gadgets measure different populations. An unresolved-defect list excludes resolved bugs; a creation-versus-resolution trend needs both. A test execution chart counts execution results in the selected app scope, which may include repeated executions of the same reusable case.
Consider an illustrative checkout team using project PAY and release version 2.8. Replace those values, the Bug issue type, and any status or priority names with values configured in your Jira site. Existing JQL field names remain usable even where the interface now says space and work item.
Save an all-state release-defect filter:
project = PAY AND issuetype = Bug AND fixVersion = "2.8"
Save a second filter for unresolved release defects:
project = PAY AND issuetype = Bug AND fixVersion = "2.8" AND resolution IS EMPTY
Use the first population for historical charts and the second for current defect distribution. Fix Version here means bugs assigned to that target release. It does not mean every defect discovered while testing the release. If that discovery cohort is your intended measure, define an appropriate Affects Version or agreed discovery field instead.
For a high-priority action list, start with the unresolved filter and add priority IN (Highest, High), then ORDER BY priority DESC, created ASC. This assumes those priority names exist. High priority identifies important work, but it does not prove that a defect blocks testing. If your team has a configured Blocked status, create a dedicated blocker filter using status = "Blocked". Otherwise, agree on an explicit local blocker convention before labeling a gadget as a blocker list.
You need an administrator or an appropriately authorized dashboard editor to configure the shared view, plus access to its saved filters and underlying issues. In Jira Cloud, sharing beyond private access requires the relevant global permissions, including Share dashboards and filters and Browse users and groups. Dashboard sharing and filter sharing are separate settings. Neither should be treated as permission to read otherwise restricted issue data.
Check that resolved bugs receive a Resolution value and reopened bugs have it cleared. Audit Done-category issues with an empty Resolution, and non-Done issues with a populated Resolution. A workflow status named Done is insufficient evidence that a resolution-based chart will count the issue correctly. Ask the Jira administrator to investigate mismatches rather than bulk-changing fields to improve the chart.
Atlassian lists all six native gadgets below for both Cloud and Data Center. Matching names do not guarantee identical calculations or configuration screens. For the seventh recommendation, use the current documentation for the installed app and hosting option, not instructions for a similarly named legacy product.
The seven recommendations serve different decisions. Keep the execution gadget visually separate from the defect views so a reader can identify its source and denominator.
Gadget | Data Population | Question to Answer |
|---|---|---|
Filter Results | Explicit blocker or high-priority defect filter | Which issues need action now? |
Pie Chart | Unresolved release defects | How is current defect priority distributed? |
Two Dimensional Filter Statistics | Unresolved release defects | Which owners have work at which workflow stages? |
Created vs Resolved | All-state release defects | Is defect inflow outpacing resolution? |
Average Age | All-state release-defect scope | Is unresolved work ageing? |
Resolution Time | All-state release-defect scope | How long did resolved defects take? |
Test Execution Results by Test Cycle | Selected Zephyr Cloud execution scope | What outcomes are recorded for the test cycles? |
Filter Results displays the issues returned by a saved filter. Put it near the top of the dashboard because a chart cannot tell someone which defect to investigate next.
Select the explicit blocker filter if the team has a reliable blocker convention. Otherwise, use the high-priority unresolved-defect filter and label the view accordingly. Include Key, Summary, Priority, Status, Assignee, and Created where available. These columns let a reviewer identify the issue, see its current owner, and judge whether a recent report or an older unresolved problem needs attention.
Choose a displayed result count that remains readable, and open the full saved filter when the list contains more work than the gadget shows. A short visible list should not be interpreted as the complete backlog.
For example, a payment-sandbox outage might block several checkout checks. The action is to assign responsibility for restoring the sandbox and record which testing can resume afterward. Calling every High-priority bug a blocker would hide the difference between urgent product defects and work that prevents execution.
Configure Pie Chart with the unresolved release-defect filter and select Priority as the statistic type. Jira groups the matching issues into slices, giving the release owner a compact view of the priority mix.
Use the chart to decide what needs triage before the next test session. A substantial High-priority slice may justify reviewing the associated issues, but priority reflects an assigned business decision. It is not automatically a measure of technical severity. If the organization maintains a separate Severity field, confirm its population and gadget support before substituting it.
Read counts alongside proportions. A larger low-priority backlog can make the high-priority share look smaller without removing any urgent bugs. Open the underlying issues before reallocating testing effort or changing the release assessment.
Do not use a pie chart of Jira workflow statuses as a substitute for execution outcomes. A test-related issue moving to Done does not, by itself, establish that a particular test passed on the release build and environment.
Use Two Dimensional Filter Statistics with the unresolved release-defect filter, selecting Status and Assignee as the two axes. The resulting table reveals combinations that a single distribution chart cannot show, such as several defects waiting for retest with the same owner.
Review cells for the work decision they imply. A cluster in a locally configured Ready for Retest status may require tester capacity or missing build information. A cluster in an investigation status may require developer attention. Unassigned issues need an ownership decision before their position in the workflow becomes useful.
Assignee represents the issue's current assignee, not necessarily every person responsible for development, retesting, or release approval. If one person retains assignment throughout the workflow, this view describes that assignment convention. It cannot reconstruct a separate QA owner that the team never records.
Prefer standard fields initially. On Data Center, Atlassian documents restrictions involving statistic-field types, search templates, field contexts, and access permissions. A custom field existing on an issue does not guarantee that it can be selected as an axis. Investigate missing values rather than silently excluding them from the review.
Point Created vs Resolved at the all-state release-defect filter. Choose a useful review period, such as daily buckets across the current testing window. These are configuration choices, not a universal reporting standard.
Avoid using the unresolved-only filter. Once an issue becomes resolved, it leaves that filter's population, undermining the comparison you intended to make. The all-state filter keeps resolved issues eligible while the gadget applies its time-based view.
A sustained gap between created and resolved counts prompts a capacity and scope discussion. Check whether new reports are concentrated in checkout, whether fixes are reaching the test environment, and whether the team is closing duplicates. Resolution can mean outcomes other than Fixed, so the resolved series is not a count of verified fixes.
The chart relies on Resolution semantics. Atlassian documents a specific mismatch for team-managed Jira Service Management projects, where closed requests may be absent from the resolved series. Check your project type and reporting behavior before using the chart as a release gate. Also remember that changing bugs' Fix Versions changes this release population; the dashboard is not an immutable historical snapshot.
Configure Average Age for the release-defect scope and select a period that supports your review cadence. Its purpose is to show the average number of days issues have been unresolved. It does not measure time since the last update, time spent with QA, or the duration of a blocking condition.
Use the all-state base filter rather than adding a recent-created cutoff. An old unresolved defect may still affect the release even if it predates the current reporting window. Check the gadget's time buckets and inclusion rules when reconciling its historical values with a search performed today. Atlassian documents calculation differences between Cloud and older Server implementations, so migration comparisons need more than identical JQL.
If the average rises, open the unresolved filter and inspect older issues individually. Determine whether each needs a fix, a retest, a deliberate deferral, or a corrected release assignment. An average cannot identify the oldest item or explain why it remains open. Closing a few old issues can lower the average even while newer blockers accumulate.
Use Resolution Time with the all-state release-defect filter and a review window consistent with the other trend charts. The gadget reports average resolution time in days for resolved issues. Jira calculates the interval between Created and the latest Resolution date.
Treat this as elapsed defect lead time. It includes waiting and coordination, not only the hours a developer spent changing code. In Jira Service Management Cloud, the native gadget also differs from an SLA-based Time to resolution report: it does not apply SLA pauses or business-hour calendars.
Read it together with Average Age. Faster resolution among completed issues can coexist with a growing set of old unresolved defects because those unresolved issues are outside Resolution Time's completed population. Comparing only the resolved average rewards an incomplete view of the backlog.
Reopened defects require particular care. Their latest resolution date can extend the interval from the original creation date. Agree on how the team interprets reopening and retesting, then verify representative records before treating a trend change as an improvement or regression in delivery performance.
For teams using Zephyr Cloud, add the app-supplied Test Execution Results by Test Cycle gadget. SmartBear's current Cloud gadget documentation names it explicitly. It supplies the execution view that the six native issue-data gadgets do not establish on their own.
The prerequisites are the installed app, accessible test data, and cycles representing the intended release work. Open the dashboard's gadget directory, search for Zephyr, and add the exact gadget. Configure the available criteria to isolate the relevant cycles and inspect the resulting scope before using its totals. Keep unrelated historical cycles out of the release view. SmartBear's related cycle report groups execution results by test cycle, so a cycle-based breakdown helps separate regression work from another testing activity.
Read the app's recorded outcome labels rather than mapping Jira workflow statuses onto them. Preserve visibility of unexecuted and blocked work wherever represented in the selected view. If a pass percentage is reported, establish whether its denominator includes all planned executions or only executed ones. Also establish how the chosen scope represents reruns before adding their totals together.
SmartBear documents an optional Update every 15 minutes setting; without it, refresh the page to obtain updated gadget information. Check freshness before a release meeting.
Zephyr Data Center has separate documentation and a different reporting catalog. Do not assume this Cloud recipe, its controls, or its app-edition availability transfers unchanged. Older TM4J or Zephyr Squad screenshots are not reliable substitutes for the current installed product's guide. If the exact gadget is unavailable, resolve compatibility and access first rather than relabeling a native issue chart as an execution report.
Use an illustrative checkout review to test whether the dashboard supports decisions. Start with the blocker list: can the team identify who will restore the payment sandbox? Then inspect the ownership table: are fixes ready for retest, and is a tester available? Compare defect inflow with resolution, checking whether duplicate closures or release reassignment explain a change. Finally, inspect the execution gadget for the selected regression cycles and identify what remains unexecuted or blocked.
Before sharing the dashboard more widely, complete this acceptance check:
Keep defect health and execution progress separately labeled throughout the review. A resolved bug still needs appropriate verification, and a passing execution set does not establish complete requirements coverage. Build the dashboard around the next decision someone must make, then retain only gadgets whose source data and interpretation the team can explain.
A tester reviewing a Jira issue may need a fresh smoke run without opening GitLab and choosing pipeline parameters. A manually triggered Jira Cloud…
A scheduled QA flow stops updating release-readiness notes. Some work items may already have changed, others may still be waiting, and the last visible…
A sprint can contain carefully estimated testing work and still overload the only person who can perform it. The missing input may be a…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
