A tester can open a Test Execution in Jira, see the Tests it contains, and still be unable to execute a run. An unavailable Play action or a read-only execution page does not, by itself, identify the missing permission. The restriction may come from Jira access, an Xray execution prerequisite, or the workflow state of either linked work item.
For Xray Cloud, start with the documented execution conditions: Browse and Resolve access on the Test Execution, an allowed Test workflow state, and an allowed Test Execution workflow state. Diagnose those conditions separately before requesting a change. Giving the tester broader administration access would obscure the cause and could weaken controls that were intentional.
Keep three objects separate. The Test is the reusable specification. The Test Execution provides the context in which Tests are executed. A Test Run is the instance of a Test within that execution, containing its copied definition and result. A Test Run result such as PASSED is different from the Jira workflow status of the Test or Test Execution work item.
Record the affected user's identity, the Test Execution key, the underlying Test key, the operation that failed, and the time of the observation. “Cannot execute REL-62” is more useful than “Xray permissions broken,” but it still needs the particular Test and user. Use the affected tester's context rather than treating an administrator's successful access as evidence about everyone else.
This procedure concerns Xray Cloud, an installed test-management app, rather than a native Jira test runner or Xray Data Center. The Permission Helper procedure below follows Atlassian's company-managed project guidance. Team-managed spaces use a different access configuration, so have the administrator establish that scope before applying a permission-scheme diagnosis.
Current Jira Cloud documentation uses the terms spaces and work items, including Browse spaces and Resolve work items. Xray's execution guide also uses the shorter Browse and Resolve wording, while some troubleshooting instructions retain project and issue labels. Match the permission's meaning and target in the tenant instead of searching only for an older label.
The first question is whether the affected user can browse the exact Test Execution work item. Browse is a visibility prerequisite, not permission to execute every Test Run it contains. Atlassian also documents that work-level security can hide individual work items even when a user has Browse spaces access.
Ask a Jira administrator to use Permission Helper for the affected account and Test Execution key:
The helper is accessible to Jira administrators. That describes who should operate the diagnostic tool; it is not a recommendation to make the tester an administrator. Keep the helper observation separate from any subsequent proposal to change access.
If the user cannot see the work item, preserve the actual visibility symptom and the administrator's diagnostic explanation. Ask the owner to inspect the relevant access and work-item security configuration rather than granting visibility across unrelated spaces. If the user can already see it, record that observation but continue with Resolve and the workflow gates.
Xray documents that an already-started Test Run can be opened in read-only mode without execution permission. A visible execution details page therefore cannot establish that the user is authorized to change its result. The page may be behaving as designed.
Xray Cloud also requires Resolve access on the Test Execution to initiate a Test Run or interact with its execution controls. Repeat the Permission Helper diagnosis using the same affected account and Test Execution key, this time selecting the relevant Resolve permission. Current Jira documentation calls it Resolve work items; older Xray troubleshooting material calls it Resolve Issues.
Retain this as a separate finding. A positive Browse result does not imply a positive Resolve result, and a check against the Test key is not a substitute for the documented requirement on the Test Execution. Using the same account and execution key keeps the two native permission observations comparable.
The permission's name can mislead testers. Checking Resolve access does not mean resolving or closing the Test Execution as a troubleshooting action. Jira's native Resolve permission concerns work-item fields, while Xray uses that permission as an execution prerequisite. Do not change Resolution, close a work item, or record a test outcome to demonstrate that the permission exists.
Also distinguish the operation being requested. Current Xray Cloud permission documentation says the Browse and Resolve permissions support changing a Test Run assignee as well as most run details, subject to the workflow restrictions. It separately identifies Edit Work Items requirements for operations such as editing a run-level dataset or adding Tests to a Test Execution.
The Jira work item's Assignee field and the Xray Test Run assignee are different targets. An assignment or editing problem should be recorded by its exact operation, not folded into a rule that every execution error needs Edit access. If both native checks are positive, continue to the app's state restrictions rather than widening the user's role.
Identify the Test behind the affected run and record its current Jira workflow status. Xray's setting named Disallow executions of Tests with workflow statuses prevents Tests in selected states from being executed or even added to Test Executions. A Test that is still being written can therefore be deliberately ineligible for execution.
Compare the Test's actual state with the effective configured list. Do not infer eligibility from a plausible status name. Draft, Approved, and Retired could be local workflow conventions, but their names alone do not establish which states the administrator has restricted.
This check concerns the Test work item, not the Test Run's result. Changing a run result would neither explain nor safely remove an authoring-state restriction. If the Test is awaiting review, the appropriate next step may be its normal review process, not an exception to the execution policy.
Xray provides workflow restrictions in Miscellaneous settings at global and space scope. Its current Space Settings documentation says spaces inherit the global configuration by default and can use space-level settings to override it. A global screenshot is therefore incomplete evidence when an enabled override supplies the relevant local configuration.
The current documented space route is Space settings, then Apps, Xray Settings, and Miscellaneous. Older support instructions may say Project settings. Have an authorized configuration owner confirm the available route, whether overrides are enabled, and which Test restriction list is effective in the affected space. Do not toggle settings or save changes during diagnosis.
Record the scope and actual list values together. This is the configuration context for the two workflow checks, not an additional native permission that Permission Helper can evaluate. A helper result about Browse or Resolve cannot establish that a Test's current state is permitted by Xray.
Now inspect the Test Execution work item itself. Xray has a separate setting named Disallow executions with workflow statuses. This list concerns the Test Execution's Jira state, whereas the previous setting concerns the Test's state.
The global settings guide gives a configured Done state as an example: when that state is included in the restriction list, Test Runs in a Test Execution that has moved to Done can no longer be executed. The space settings guide uses Closed as an example. Neither name is a universal Xray lock; the effective configuration determines the restriction.
Check the actual execution state against that effective list, including the relevant global or space scope. A permitted Test does not override a blocked Test Execution. Likewise, changing the tester's native permissions would not explain why the execution container is deliberately closed to further results.
If the restriction protects a completed release's evidence, preserve that purpose in the escalation. Ask the workflow or release owner whether further testing belongs in a new authorized execution context or requires an approved change to the existing one. Do not move a work item back to an earlier state merely to make Play available.
Use a compact record so the administrator and QA lead can distinguish native permission evidence from app workflow policy. Each finding should identify what was checked and what remains unproven.
Check | Exact Target | Evidence to Request | What It Cannot Prove |
|---|---|---|---|
Browse | Affected user and Test Execution key | Native Browse permission result and visibility context | Permission to execute the run |
Resolve | Same user and Test Execution key | Native Resolve permission result | Either Xray workflow gate is open |
Test Workflow Status | Underlying Test key and current Jira status | Match against the effective Test disallow list | Test Execution state permits execution |
Test Execution Workflow Status | Test Execution key and current Jira status | Match against the effective execution disallow list | Other operation-specific requirements are satisfied |
For an illustrative, unexecuted diagnosis, suppose the reported problem concerns Test QA-184 inside Test Execution REL-62. The tester reports that execution is unavailable. The administrator has not yet supplied either native permission result, the two current workflow states, or the effective restriction lists. Every finding remains Unknown. The report is enough to start an investigation, not enough to identify its cause.
If the eventual Resolve result is negative, that would identify an unmet documented prerequisite for that account and execution key. If both native results are positive but QA-184 is in a restricted Test state, the evidence would instead point to the Test workflow gate. These are conditional interpretations, not observed helper outputs or results from a real tenant.
A record with one verified finding and unresolved fields is more useful than a premature “permissions fixed” conclusion. Preserve the unknowns until the responsible owner has checked them. Passing these baseline checks also does not establish that every operation-specific requirement or every possible cause of an error has been eliminated.
Send the diagnosis to the person responsible for the layer that remains unresolved. A practical evidence packet contains:
The person approving an access or workflow-policy change may be different from the administrator authorized to implement it. Keep those responsibilities explicit. A QA lead's need to continue testing does not establish permission to relax a release lock or expand another team's access.
When a change is approved, agree on a bounded validation in the intended testing context and retain its evidence separately from this initial diagnosis. Until that validation happens, record the outcome as unverified. Start by identifying the blocked condition and its owner; make the smallest justified change only after the evidence and approval support it.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
