User acceptance testing questionnaire: 37 UAT questions for testers, and a printable tally sheet
A UAT questionnaire asks the business users who ran your test cases what they finished, whether the results were right, how bad the worst problem was and whether the release should go live. Send the core 12 when a round closes, then add the set that fits your stage of testing.
- 37questions
- 12in the end-of-round core
- 4 minto answer the core
- 5sets for each stage
By Michael Hodge, BSc Psychology Updated September 2026
All 37 UAT questions, by stage of testing
The end-of-round core is ticked. Add the session log for daily use, the screens or data sets when those areas are in scope, and the readiness and sign-off sets near cutover. Each row lists the options a tester picks from and what a given answer tells the test lead.
End of round: the core 1212 questions
Coverage first, then seven statements a business tester can judge from the cases they ran, the worst problem in plain words, a go-live view and two open questions.
-
How many of your assigned test cases did you finish?
AllMostAbout halfA fewNoneCoverage. Read every rating below against how much of the script this person actually ran.1
-
I could finish my everyday tasks from start to end.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeThe heart of acceptance: does the build carry a whole piece of real work, not just single screens.1
-
The totals and records it produced were correct.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeCorrectness on real cases. Wrong output that looks right is the costliest fault to miss.
-
The screens follow the order I do this work in.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeFit to the real process. A build can meet the spec and still make people work backwards.
-
Error messages told me how to put things right.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeThe unhappy path. Testers who only saw clean runs tend to answer neutral, so read it next to question 1.
-
Screens loaded fast enough for my normal pace.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeSpeed as a user feels it. A low score earns a proper performance test before anyone argues about it.
-
The test cases covered the work I really do.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeChecks the script, not the system. Low agreement means the round skipped tasks that matter.
-
I am ready to use this system for real work.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreePersonal readiness, the rating that sits closest to the go-live decision.
-
How serious was the worst problem you found?
Stops my workNeeds a workaroundSlows me downCosmetic onlyNone foundSeverity described by its effect on the work, so two testers who hit the same fault pick the same level.1
-
Should this release go live on the planned date?
YesYes, after fixesNot yetCannot sayEach tester's recommendation. Count the Not yet answers by role before the go or no-go meeting.
-
Which problem should be fixed first, and where did you see it?
Open answerOne priority per person, with a location. It turns a long defect list into an order of work.
-
What would stop you using this system on go-live day?
Open answerFinds blockers that are not defects: missing access, training, data or a report.
After each test session5 questions
A two-minute log testers fill in every time they finish a session. It sits next to the test log and catches faults nobody recorded.
-
Which test case or scenario did you run?
Open answerTies the answers to a script ID so they can be matched with the test log.
-
What was the result?
PassedPassed with a workaroundFailedBlockedThe four outcomes a test manager counts. A pass with a workaround is a warning, not a pass.
-
Were the test steps clear enough to follow alone?
YesMostlyNoUnclear scripts produce false failures. A No here means rewrite the script before the next run.
-
Did you log a defect for this session?
YesNo, nothing to logNo, not sure howChase the third answer: a fault someone saw that nobody has written down.
-
Defect ID, or what you expected and what happened
Open answerExpected result against actual result is the part of a defect report developers need to reproduce it.1
Data, reports and other systems4 questions
For releases that move records, change reports or pass data to other systems. Ask testers to check records they know well.
-
Records moved from the old system arrived complete.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeMigration checked by the people who know the records best, one familiar customer or order at a time.
-
Reports showed the figures I expected to see.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeReports are often tested last and used first. A mismatch here stops month end.
-
Data reached the other systems I checked correctly.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeIntegrations from the business side: did the order, invoice or record arrive where it should.
-
Did you find records that were missing, doubled or wrong?
Yes, severalOne or twoNoDid not checkCounts data faults apart from screen faults, because a different team fixes them.
Screens and ease of use5 questions
Add these when the release brings new screens. They point to the screen or label to fix, rather than giving one usability number.
-
How easy was it to find the option you needed?
Very difficult12345Very easy1 = Very difficult, 5 = Very easyNavigation. Low scores here explain slow sessions better than any timer.
-
How easy was it to correct a mistake you made?
Very difficult12345Very easy1 = Very difficult, 5 = Very easyRecovery. People make errors in their first week; the question is what each one costs them.
-
How easy were the field names and labels to follow?
Very difficult12345Very easy1 = Very difficult, 5 = Very easyWording on screen. Business testers spot jargon the build team stopped hearing months ago.
-
Compared with the old way, this task is:
Much harderA bit harderAbout the sameA bit easierMuch easierA before and after in one question. Watch whether the harder answers fade by the second round.
-
Which screen slowed you down most, and why?
Open answerSends designers to one screen at a time instead of a pile of general complaints.
Training and go-live readiness4 questions
Send these about a week before cutover, to testers and team leads. They show what support people need on the first day.
-
The walkthrough before testing was enough to start.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeShows whether testers were set up to succeed. Weak preparation looks like weak software in the scores.
-
I know where to report a problem after go-live.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeThe support route after launch. One clear email before cutover fixes a low score.
-
My team can switch over on the planned date.
Strongly disagree12345Strongly agree1 = Strongly disagree, 5 = Strongly agreeTeam readiness, a wider view than the tester's own readiness in the core.
-
What help would you want in the first week?
Someone on the floorA quick reference sheetShort videosA help lineNonePeople pick the support format, so the first-week plan matches what they will use.
Sign-off (the business owner answers)4 questions
For the person who accepts the release on behalf of the business. Send it before the go or no-go meeting, with the round results attached.
-
Were the agreed acceptance criteria met?
All metMet, with agreed exceptionsNot metAcceptance rests on criteria agreed before testing started, not on impressions afterwards.1
-
Which open defects are you accepting for go-live?
Open answerPuts accepted risk in writing with the owner's name against it.1
-
What is your decision on this release?
AcceptAccept with conditionsRejectThe formal answer. Conditions go in the next question, so none are lost in email.
-
Conditions, fixes or dates that go with your decision
Open answerEach condition becomes a task with an owner and a date on the cutover plan.
About you (optional)3 questions
Two splits that make the ratings easier to read, and the team name for releases shared by several areas.
-
Which best describes your part in this test?
Daily user of this processTeam lead or approverSupport or adminOtherThe split to read every rating by. Approvers and daily users often disagree, and both views count.
-
How long have you done this work?
Under a year1 to 3 yearsOver 3 yearsLong-serving staff test the exceptions; newer staff test whether the training works.
-
Which team or area do you work in?
Open answerLets you report by area when several teams share one release.
Paper beside the keyboard in the test room
For a test room where people work through scripts at shared machines, paper beside the keyboard works well. Both files fit US letter or A4.
Testing in a shared room? and leave one by each machine.
UAT questionnaire
Name, system and date at the top, the core 12 first, then the session log, screens, data, readiness and sign-off sets.
Download PDF
Round tally sheet
Count finished test cases, tally every core statement, find the number agreeing and mark what to fix before the retest.
Download PDFThe right set for each point in UAT
One questionnaire at the end is too late to fix a script. Spread the sets across the cycle instead.
| When | Who answers | Send |
|---|---|---|
| After each test session | The tester who ran it | After each test session (5) |
| When a round closes | Every tester | The core 12, plus Screens or Data if in scope |
| A week before cutover | Testers and team leads | Training and go-live readiness (4) |
| Before the go or no-go meeting | The business owner | Sign-off (4) |
Run the core again after every retest round, with the same wording, so you can put the two rounds side by side. Once the system is live and settled, the post implementation review asks the wider questions about the project. If outside customers will try a near-final version before a public launch, that is a different job with different respondents: use the beta tester questions for it.
Feedback a test lead can act on
Four habits that turn tester feedback into a clear list of fixes and a decision people trust.
Share of usability problems found, by number of test users
Recruit three testers per role, not one per team
Each extra tester finds fewer new problems than the one before. Usability research gives a handy rule of thumb: one person finds almost a third of the problems, five find 85%, and it takes about 15 to find them all.2 When distinct groups use the system, Nielsen suggests at least three people from each.2 Three daily users, three approvers and three support staff will surface more than a single star tester from every department.
Send it the day the round closes
Which case failed, and why, is clearest in a tester's mind on the day. Send the core the afternoon the round ends, and ask for the session log after every sitting. The script ID in the first log question lets you match each answer to the test log, so a low rating always points to a case you can rerun.
Describe severity by what it does to the work
Critical, High and Medium mean different things to a developer and an accounts clerk. The syllabus defines severity as the degree of impact on stakeholders,1 so the options here describe that impact: stops my work, needs a workaround, slows me down, cosmetic only. Two testers who hit the same fault now choose the same level, and the count of Stops my work answers goes straight to the go-live meeting.
Agree the exit criteria before anyone tests
Decide in advance what counts as done: planned test cases run, no blocking defect open, and how many testers must say ready. Typical exit criteria include coverage, the number of unresolved defects and the number of failed test cases.1 Write yours on the first page of the test plan. Each core question maps to one of them, so the results read as a checklist rather than a debate.
At the wrap-up meeting, take the temperature before the full results go up. Put the go-live question to everyone as a live poll they answer on their phones. Putting it on the meeting screen is covered in our poll set-up guide.
Where the round fell short
For the seven core statements, type in how many testers landed on each of the five answers. Agreement means the build passed on that point, so the smallest bar becomes the first fix before the retest.
- 1For each statement, count how many testers gave each answer. The bar is the share of them who gave a 4 or a 5.
- 2Read the first three bars together: they are the business fit. A short bar on the test cases statement means the script missed work, not that the system failed.
- 3Take the two shortest bars to the defect triage meeting, with the matching answers to the two open questions.
- 4Retest, send the core again to the same testers, and show them both rounds side by side.
Core statements, this round
Reading the answers as a go or no-go call
The questionnaire does not make the decision. It puts the testers' evidence next to the exit criteria you agreed at the start.
A worked example
Say 12 testers answer the core after round two. Eleven finished all or most of their test cases. Ten of 12 agree the totals and records were correct, nine agree the screens follow their process, and seven of 12 say they are ready for real work. One tester chose Stops my work, three chose Needs a workaround. On the go-live question, six chose Yes, four chose Yes, after fixes, and two chose Not yet. Both Not yet answers came from approvers.
| Exit criterion | Questions | In the example |
|---|---|---|
| Planned tests run | 1 | 11 of 12 finished all or most |
| No open blocking defect | 9 and the defect log | One blocker to confirm and fix |
| Fits the business process | 2 to 4 | 9 to 11 of 12 agree |
| Users ready | 8 and the readiness set | 7 of 12: plan training |
The recommendation writes itself: go after fixes. Close the blocker, retest that case with the tester who found it, and run a short session with the approvers on what worried them. Then send the core once more to the same 12 people. The ISTQB syllabus lists unresolved defects and failed test cases among the typical exit criteria, and notes that stopping early can be acceptable when stakeholders have reviewed and accepted the risk of going live.1 The sign-off set records that acceptance in the owner's own words.
A five-question UAT feedback form
Mid-round, or for a small fix release, five questions are enough: coverage, whether real work gets done, the worst problem, the go-live view and the first fix.
- 01How many of your assigned test cases did you finish?
- 02I could finish my everyday tasks from start to end.
- 03How serious was the worst problem you found?
- 04Should this release go live on the planned date?
- 05Which problem should be fixed first, and where did you see it?
Need a benchmarked usability score? Add the SUS
The Screens set on this page tells you where to fix. A standard scale tells you how the whole system compares.
The System Usability Scale, written by John Brooke in 1986, has ten statements on a five-point agree scale. Odd items are worded positively and even items negatively, and the total converts to a score from 0 to 100.3 Its strength is the benchmark: across 500 studies, the average score was 68.3
Scoring it
For each odd item, subtract 1 from the answer. For each even item, subtract the answer from 5. Add the ten results and multiply by 2.5.3 A system scoring 74 at the end of UAT sits above that average; one scoring 55 sits well below it, and its screens deserve a closer look before launch.
If you add it, use Brooke's published statements word for word and credit him, because the benchmark only holds for the original wording. We do not reprint them here, and none of the questions on this page is an SUS item.
UAT questions that need a second draft
Home-made UAT forms keep making four mistakes. Here is each one with a rewrite that gets a usable answer. For question wording in general, read the survey question guide.
Did the system work?
I could finish my everyday tasks from start to end.
Worked for which task? The better item names a whole piece of work the tester can judge.
Rate the quality of the application from 1 to 10.
The totals and records it produced were correct.
The screens follow the order I do this work in.
Quality is several things. Split it into correctness and fit, and each score tells the team what to change.
Were there any critical bugs?
How serious was the worst problem you found? (Stops my work, Needs a workaround, Slows me down, Cosmetic only, None found)
Critical means something different to each tester. Impact in plain words gives one scale everyone reads alike.
Are you happy to sign off?
Should this release go live on the planned date?
A request for sign-off invites a polite yes. A question tied to a date lets testers say not yet without refusing anyone.
Test leads ask these about UAT surveys
For test leads, business analysts and project managers running acceptance testing.
What is a UAT questionnaire?
A short set of questions business testers answer after running their test cases: how much they finished, whether results were correct, how serious the problems were and whether the release should go live. It sits beside the defect log and the test log, and it collects the views those two cannot.
What should a UAT feedback form ask?
Coverage, a few statements on correctness and fit, the worst problem described by its impact, and a go-live recommendation. The five-question form above covers exactly that, and the full core adds speed, error messages, script coverage and readiness.
Who should fill in a user acceptance testing questionnaire?
The business users who ran the test cases: people who do the work every day, the approvers who accept it and the support staff who will field questions. The ISTQB syllabus says acceptance testing should ideally be performed by the intended users.1 Developers and QA testers report through the defect log instead.
What is the difference between UAT and beta testing?
Both are forms of acceptance testing.1 UAT is run by business users, usually in a test environment, against criteria agreed before it starts. Beta testing hands a near-final version to outside customers. For that job, the beta testing survey asks the right people the right things.
Should UAT feedback be anonymous?
Usually not. The test lead needs to follow up on each problem, so testers add their name. Report the ratings by role rather than by person, so nobody is singled out for a low score.
Send the questionnaire when round one closes
Put your system name into the builder, keep the sets your round needs, then send the link to your testers or hand out printed copies in the test room.
