A refund feature can pass technical tests while leaving a finance team unable to complete its daily work. The calculation may be correct, but the approval handoff may be unclear or the support role may see an action it should never perform. User acceptance testing, or UAT, asks whether the delivered system supports agreed business needs when representative users perform realistic tasks.
Running UAT in Jira means organizing that evaluation so someone can reconstruct the scope, assignments, results, defects, and acceptance decision. Internal QA and system testing provide technical evidence; business users contribute operational knowledge and judge fitness for their work. QA can coordinate the cycle without becoming the default person authorized to accept business risk.
The workflow below uses an illustrative refund release, not a documented customer case. It focuses on Jira Cloud coordination. Exact settings depend on your project or space type, permissions, and installed apps, so confirm the configuration with your administrator before inviting participants.
Start a UAT plan in a Jira work item or an approved document linked from it. Identify the release candidate, the business processes being accepted, the user groups represented, and the person authorized to decide the outcome. Record what is excluded and why. A label such as “UAT complete” cannot explain whether finance reconciliation, support handling, and customer notifications were all evaluated.
For the illustrative release, assume the agreed rule is that a finance user can refund a settled order, a support-only user cannot issue that refund, and the completed refund appears in the finance reconciliation view. These are example requirements to replace with your own approved rules. A successful button click alone would not establish that the business process works.
Define acceptance criteria before participants execute the checks. Each criterion needs an observable outcome and a source, such as an approved requirement or user story. If “refunds reconcile correctly” leaves the required record fields unspecified, ask the business owner to resolve that ambiguity before assigning a pass or fail.
Give the cycle named responsibilities:
One person may hold several roles in a small team. Keep the responsibilities explicit, including who can accept an unresolved defect and who can only report it. Set a decision date and reserve time for investigation and retesting rather than scheduling sign-off immediately after the last planned execution.
Native Jira work items, assignees, descriptions, comments, attachments, links, and workflows can coordinate a small UAT cycle. Atlassian offers a UAT template that provides a starting point for planning and tracking work. That does not establish a universal native test-case repository, execution-history model, or dedicated UAT approval screen.
Choose how you will represent the following artifacts before creating assignments:
Artifact | Native Jira Coordination | Test Management App Route |
|---|---|---|
UAT plan | Work item containing scope, criteria, participants, and decision references | App plan or run linked to the business scope, where supported |
Check definition | Agreed description template or linked specification | Reusable case with app-specific fields and review controls |
Execution attempt | Separate cycle item or clearly identified attempt record | Run result tied to the case and release context |
Defect | Linked Jira bug with reproduction details | Jira bug connected to the app execution, if supported |
Acceptance decision | Authorized decision recorded against the identified evidence | App evidence plus the organization's agreed approval record |
For a native-only pilot, create one parent work item for the cycle and separate tasks for assigned checks. Use a consistent cycle label or another agreed scope field so the coordinator can find them together. Store the requirement reference, setup, expected result, and result-recording instructions in each task. These are proposed conventions, not built-in UAT entities. Avoid repeatedly rewriting one task across releases without preserving the earlier attempts.
Agree on a lightweight coordination flow, such as Ready, In Progress, and Awaiting Review, with blockers made visible. Ask an administrator to check the workflow and board mapping. Jira columns represent mapped statuses; renaming a column does not establish a controlled approval transition. Keep the execution outcome separate from the coordination state so an item awaiting review can still contain a failed result.
If reusable cases and release-specific execution history are important, an app can provide a more structured model. Sherlock Test Management describes human-reviewed test baselines and release-specific runs with assignments, recorded Pass, Fail, or Blocked results, and linked Jira defects. For the refund cycle, reviewers can approve the role and reconciliation expectations before users execute the selected cases. Those are app capabilities: AI-proposed cases still require human review, and recording a run does not itself authorize business sign-off or establish autonomous execution against the application.
Set entry criteria that protect the business users' time. The candidate should have completed the agreed internal testing, with known issues disclosed and any mandatory blockers resolved. Do not adopt a generic rule that every defect of a particular severity must always be absent. Agree on the consequences that prevent this cycle from starting, such as an unavailable refund service or an unresolved authorization failure.
Before releasing assignments, confirm:
Application permissions and Jira permissions are separate. A finance user may be able to refund an order but lack permission to attach evidence in Jira. Equally, a Jira assignee may have the wrong application role. Test the actual handoff with a participant account before the session. Jira's assignment and assignable-user permissions also differ; asking an administrator to assign a task is not proof the user can perform every needed action.
Use approved synthetic or appropriately protected data and safe dependency endpoints. For the refund example, reserve a settled test order with no existing refund and separate finance and support identities. Another participant's refund must not consume the starting state needed by the next check. Document how to reserve or reset those records; the test data management guide develops this isolation and repeatability problem in more detail.
If reconciliation uses a simulated downstream service, record that limitation. A pass in that environment supports the conditions exercised there, not proof of the untested production connection. Decide whether additional evidence is required before acceptance.
Begin with a business journey such as “Support escalates a refund request to finance, and finance completes and reconciles it.” Then derive checks for the important conditions: permitted action, forbidden action, and the downstream record. One broad journey may require several focused checks. The distinction between test scenarios and repeatable test cases helps keep the business objective visible without leaving testers to invent inputs and expected results.
For each assigned check, record the requirement reference, business role, preconditions, data reference, actions, expected outcome, and evidence needed. Identify who will execute it and who will review an ambiguous result. Include relevant exception paths; a refund workflow that only covers an authorized user's successful attempt leaves the permission rule untested.
Assume case UAT-REF-01 uses a reserved settled order with no prior refund, a finance identity, and an agreed reconciliation view. The approved requirement specifies what a completed refund record must contain. The following actions are illustrative, not instructions for a particular application's interface:
Create a separate check using the support-only identity to verify the forbidden action and the expected unchanged business state. Do not change the account's permissions midway through the finance check and treat that as an independent result.
Ask a business representative to review the checks before assignment. They may identify a missing handoff or a reconciliation condition that technical testers would not infer. Brief participants on how to report an unexpected outcome without changing the acceptance criterion to match it.
Start the session by confirming the build, assignments, expected evidence, and route for getting help. Let users perform realistic tasks rather than demonstrating the workflow and collecting verbal agreement. When a user explores a relevant alternative path, retain the path and outcome as additional evidence rather than claiming that an unspecified area has been fully covered.
Use consistent outcome definitions. Pass means the observed outcome met the agreed criterion under the recorded conditions. Fail means it did not. Blocked means the check could not reach a meaningful conclusion because a prerequisite was unavailable. Not Run means execution has not occurred. A missing account or broken test fixture must not become a pass because the feature looked plausible elsewhere.
Record at least the case or check version, cycle, application build, environment, tester, execution time, data reference, actual outcome, and supporting evidence. In a native-only setup, use your agreed task template and attempt records; in an app, confirm where its result model stores these details. Avoid screenshots containing customer information or secrets.
An illustrative result might state: “UAT-REF-01, candidate RC-2: finance completed the refund, but the reconciliation view showed no matching record after the agreed processing interval. Fail; defect linked; evidence attached.” The processing interval must come from the actual requirement or environment agreement, not an invented waiting period.
Preserve that result when the check is repeated. A later pass should identify the corrected build and a new attempt. Replacing the original failed observation with “works now” removes evidence needed to understand both the defect and the acceptance decision.
Review findings with business representatives, QA, and developers while there is still time to act. Separate a failure against an agreed criterion from a new enhancement request, an unclear requirement, or an environment problem. All may need work, but they imply different decisions. A new preference should not silently expand this cycle's committed scope, and an inconvenient defect should not be renamed an enhancement to clear the board.
A useful Jira defect identifies the affected requirement and attempt, build, role, starting data, reproduction steps, expected and actual outcomes, evidence, and business consequence. Link it to the check so reviewers can follow the path from requirement to result to unresolved work. Agree on an owner and priority based on impact and urgency, not solely on how strongly a participant phrases the report.
After a proposed fix:
If a requirement changes during triage, record who approved the change, revise the affected checks, and identify which earlier results no longer support the new expectation. A pass on an older build or obsolete criterion cannot automatically approve the revised release candidate.
Prepare a decision record that a business approver can evaluate without interpreting a wall of green cards. Show the release candidate, agreed scope, required journeys, results, retest evidence, unresolved defects, and blocked or unexecuted checks. Include environment limitations and any behavior outside the cycle's coverage.
Use a UAT sign-off checklist that asks:
Conditional approval needs conditions someone can enforce. “Accepted with known issues” is too vague when nobody knows which users are affected or what must happen before release. Mandatory security, regulatory, or organizational controls remain subject to their responsible owners; a UAT approver cannot waive them merely by moving a task.
For an illustrative decision, the finance owner could approve the identified candidate for the tested refund scope while recording an untested reconciliation export as excluded and requiring its acceptance before that export is enabled. If the missing export is essential to the agreed refund process, the decision should instead remain blocked or rejected until suitable evidence is available. The same missing result can imply different decisions depending on the scope and business consequence.
Close the cycle only when the decision and its supporting records are linked and retained. A Jira status change can communicate that decision, but cannot substitute for it. For your next cycle, start with one critical business journey and check whether a different reviewer can reconstruct what users tested, what remains uncertain, and who accepted the outcome. Fix those gaps before expanding the plan.
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.
