A user reports that an approval button does nothing. Is that a software defect, a missing permission, an unclear requirement or a request for another feature? During user acceptance testing (UAT), all four can look like a failure. For a small software house, the useful outcome is not a board full of red and green tickets. It is an evidence-backed business decision about what has been tested, what remains uncertain and whether the proposed release can be accepted.
The difficult bit is that the person testing a system knows the business task but may not know how the application is built. Developers know the implementation but should not independently redefine the promised business outcome. A disciplined process lets both perspectives contribute without pretending that a ticket label settles the matter. It starts before the first bug report and continues through retesting, unresolved exceptions and the eventual release handover.
Agree what users are supposed to accept
Start with a real task and its expected result. A purchase-order approver, for example, needs to know which record should change, which authorised person can approve it and what evidence should appear afterwards. A statement such as 'the approval function works' is too vague to verify. Record the criterion, the required user role, the environment and a representative test-data reference. Business owners decide whether the criterion describes the intended work; engineers can explain feasibility and dependencies.
Identify anything that makes the test conditional. A sandbox payment callback may prove one interface route without demonstrating real payment settlement. A supplier may provide a test response with behaviour different from production. A report generated from prepared data can establish a calculation for that data, but not every possible data quality condition. Mark the boundary clearly so the eventual acceptance decision does not silently grow beyond the evidence.
Let testers describe their experience without diagnosing code
A good feedback form asks what the person attempted, the steps involved, what they expected, what happened instead and when the problem occurred. Include the build or environment where available. Screenshots and correlation references can help, but personal records, full payment credentials and passwords do not belong in an unrestricted ticket. Tell testers how to submit sensitive evidence through the approved route rather than demanding uploads to a public issue tracker.
Consider the difference between 'approvals broken' and 'finance reviewer selects Approve for a submitted order, the page returns to Draft and no approval is recorded'. The latter gives an engineer a starting point without assuming the cause. If a problem is intermittent, retain the conditions and actual frequency as observed. One unsuccessful attempt to reproduce it should not be presented as proof the reporter imagined it. Ask for one more distinguishing fact if it will change the investigation route.
Classify the issue provisionally, then confirm its owner
A defect means actual behaviour contradicts an agreed requirement or another legitimate product obligation. An enhancement adds or changes functionality. An environment blocker prevents reliable testing. A usability concern can remain significant even when the technical implementation follows the initial specification. Classification helps work move forward, but it must remain challengeable when new evidence appears. A security or accessibility issue should not be downgraded merely because the test script omitted it.
Give each report a stable identifier and link the relevant acceptance criterion. The technical owner investigates confirmed defects; the product owner resolves disagreements about requirements, changes and release scope; the test-environment owner addresses access and setup blockers. A supplier-dependent case needs an internal coordinator who knows when to follow up. A board column saying Waiting is not an owner. Where a request would alter the agreed project, assess its cost, impact and approval rather than quietly implementing it under a bug label.
Preserve duplicates, configurations and test evidence
Several testers may report what appears to be the same problem. Linking them is often useful, but do not delete the role, browser, version, data or outcome that makes a report distinct. Two identical error messages might arise from different permission rules. Equally, five reports could describe one confirmed regression affecting several teams. Connect observations to a parent issue while preserving each material condition and the testers who will need to verify the result.
Track the actual deployed build, relevant configuration and feature flags. A fix committed to a branch is not necessarily installed in the UAT environment, and a stale session can produce confusing results. Confirm where testing occurred before changing application code. If the test environment was reset, identify whether previously established data and evidence still apply. Reproducibility includes test data and permissions as well as click sequences.
Retest the business journey, not merely the implementation
When a developer marks a correction ready, record the intended fixed version, steps to repeat and the result expected from the original failing task. Ask an authorised tester to check that behaviour in the relevant environment. Include nearby regression checks where there is a plausible connection: changing approval logic may affect rejection, audit history or notifications. The purpose is not to retest the entire system for every minor issue, but to examine the consequences of the actual change.
Microsoft's Azure Test Plans documentation describes how test cases, runs, results and requirements can be linked, along with manual and exploratory testing. Those are useful traceability capabilities; they do not confer business acceptance automatically. A test can pass at the technical level whilst the authorised product owner still needs to decide whether an untested scenario, a limitation or an open high-impact defect is acceptable. Do not translate 'developer fixed' or 'test tool green' into an unsupported release guarantee.
Make priority and the go/no-go decision explicit
Business impact matters more than an impressive number of closed tickets. A single issue preventing a core financial approval may outweigh many cosmetic defects. Identify the affected workflow, users, data integrity, security implications, available safe workaround and likely release consequence. Do not copy a generic severity scale into the project without checking what those categories mean to its business. A quick-to-fix issue can have high impact, whilst an intricate technical concern may not block the agreed first release.
Before acceptance, list the essential scenarios actually run, the result and version for each, unresolved defects, accepted constraints and untested dependencies. The business authority should decide what can ship and who owns the remaining exposure. Where a supplier prevents a final test, state that plainly. UAT evidence informs but does not replace production monitoring, rollback planning, support-readiness checks or any required security review. A release can be conditionally accepted only with real authorisation and clear boundaries.
Hand over findings and improve the next test cycle
Provide support with known issues, user-facing changes, approved workarounds and a route to escalate new problems. Distinguish what is resolved for a particular version from what remains under observation. Ask whether repeated reports were caused by unclear instructions, stale environments, inaccessible test accounts or a real shared defect. Improve the next cycle's examples and intake questions accordingly. The same confusion should not recur simply because the ticket board was archived.
The aim is a trustworthy decision. If users can reproduce the task, the team can investigate the report, the product owner can distinguish scope from defects and the release owner can describe remaining risk, the process has done useful work. It does not need to promise every request will be implemented or every bug will vanish before release.
Sources: Microsoft Learn, What is Azure Test Plans? describes traceable test cases, executions, configurations and stakeholder feedback; Atlassian Support, User acceptance testing for migrations describes real-user task validation and feedback, within Atlassian migration scope. The operational recommendations above are not claims that either vendor has tested this project's software.
Use one acceptance reference for each observed issue
Keep the tested role, intended result, actual result and environment connected to the relevant criterion. Where an intended outcome remains disputed, assign a product decision rather than silently turning the report into an engineering task.
Separate test completion from business sign-off
A developer may supply a fixed build, while an authorised business tester still needs to repeat the original workflow. Keep the versions and outcomes visible, and record genuine external dependencies. A passing technical test is evidence for a decision, not the decision itself.
UAT feedback: defect correction or product-scope decision?
Two legitimate responses can follow the same tester complaint. The evidence determines whether engineering should restore already-agreed behaviour or a product owner should decide on changed requirements. Setup blockers form a third route that must not be disguised as either.
| Criterion | Defect against agreed behaviour | New or disputed requirement |
|---|---|---|
| Evidence to obtain | Original criterion, steps, expected/actual result, build and affected role. | Requested difference, business purpose, existing scope and approval owner. |
| Next accountable owner | Engineer investigates; tester validates corrected behaviour. | Product owner decides scope and acceptance implications before implementation. |
| When access is missing | First verify entitlement and test setup; do not infer a code defect. | Clarify whether new permissions are actually authorised, not merely desired. |
| How to validate | Retest failing scenario on the fixed deployed build, plus relevant regression cases. | Approve measurable revised criteria and plan testing for the changed scope. |
| What can be closed? | Confirmed defect correction within the tested conditions. | Documented product decision; implementation may remain a separate open task. |
Practical decision: When a report contradicts an approved criterion, capture a repeatable case and investigate. When it asks for different behaviour, request a business-scope decision. If a prerequisite is missing, restore valid testing conditions first. Treat all classifications as subject to new evidence and make the final acceptance owner explicit.
Source A: Microsoft Learn, Azure Test Plans overview — platform-specific linkage between tests, requirements, bugs, execution and results, current documentation checked 2 November 2026. Source B: Atlassian Support, UAT for migrations — first-party guidance on asking representative users to verify normal work and collect feedback; applies directly to migration scenarios and is used here only for the general business-testing principle. The classification table is original editorial guidance, not a vendor-prescribed severity scale.
Frequently asked questions
Should every UAT complaint become a software defect?
No. Compare the observation against agreed requirements and environment conditions. The report may identify a defect, missing access, an unclear criterion or a proposed change needing product approval.
What evidence helps a developer reproduce a UAT problem?
Capture the business task, expected and actual result, relevant steps, environment and version, time, test data reference and appropriately restricted logs or screenshots. Avoid exposing credentials or live personal data.
Can several similar UAT reports simply be deleted as duplicates?
No. Link them where they genuinely share the condition, while preserving different roles, versions and outcomes that may reveal distinct faults or required retests.
Does developer completion mean the tester has accepted the fix?
No. Verify the correction reached the relevant test environment, repeat the original failing journey and obtain the appropriate business acceptance decision.
When can the project close UAT feedback triage?
When critical tests and decisions are evidenced, remaining defects and limitations have approved ownership, and the responsible business authority can make a transparent release recommendation.