How to run user acceptance testing for custom software
User acceptance for custom software is the intended user working through the acceptance list, line by line, and recording each result as pass, defect, scope change, or misuse. Sign-off covers only the lines that have evidence from that run. A line with no evidence stays unaccepted.
On this page
- Start from the list, then run the cases
- The syllabus places user acceptance inside acceptance testing
- Each case points at one line on the list
- Separate the person who operates, the person who records, and the person who signs
- Keep defects, changes, and misuse apart
- Keep evidence before sign-off
- Sign only the lines that have evidence
- When to leave the round unsigned
Start from the list, then run the cases
The acceptance list says how each outcome will be shown in a demo or in a user run. How that list is produced from the spec is covered in How to write acceptance criteria for custom software. How the spec names outcomes, owners, and what sits outside the scope is covered in How to write a custom software requirements spec. This note covers only how to run user acceptance after that list already exists.
A wish, during the run, to change an outcome does not edit the list in the room. That is a scope change, covered in How to control scope changes in custom software. The delivery scope sits under Custom software, websites, and applications. If there is no list, or the list cannot name a spec version, do not start the run.
The syllabus places user acceptance inside acceptance testing
The revision history of the ISTQB Certified Tester Foundation Level Syllabus v4.0.1 dates CTFL v4.0.1 as an errata on 15 September 2024, and CTFL v4.0 as the general release on 21 April 2023. Section 2.2.1 says acceptance testing focuses on validation and on demonstrating readiness for deployment, which means that the system fulfills the business needs of the user. Ideally, acceptance testing should be performed by the intended users. The same section lists the main forms as user acceptance testing (UAT), operational acceptance testing, contractual acceptance testing, regulatory acceptance testing, alpha testing, and beta testing.
The same section says test levels are distinguished by the test object, the test objectives, the test basis, defects and failures, and the approach and responsibilities, so that the activities do not overlap. That passage does not list the columns of a user-acceptance record, and it does not state a pass rate or a time limit. This note does not add columns the passage does not state. The cases and the log below are the way a buyer runs the round after the acceptance list already exists.
Each case points at one line on the list
Each case names eight things: the spec version, the acceptance-list line, the role that operates, the starting data, the steps, the record the system should keep, who runs it, and the date. Leave any of the eight blank and the case stays a draft.
A case covers only a line already on the list. A sentence added in chat, or a screen someone asks to see in passing, does not open another case. To put it on the list, add the line in the acceptance note, or open a request in the change note. A step the list does not name is not a failure of this run.
Separate the person who operates, the person who records, and the person who signs
The person who operates is the intended user already named on that line. The person who records writes what was shown and the identifier of the record the system kept, and does not declare a pass in the operator place. The person who signs is the person the spec already names as the one who may accept this version. The three roles may overlap. The record still has three columns.
When the intended user is absent, that line waits. A developer, or anyone else in the room, does not operate it and then tick pass. A developer may sit beside the user and point at the screen. The pass is the result the operator writes on the record.
Keep defects, changes, and misuse apart
A defect means the operator followed the case and the system did not keep the record that line requires. A scope change means the operator wants an outcome different from the line. Open a change request. Do not rewrite the line to match the sentence just spoken, and do not count the change as a defect. Misuse means the run left the steps or the starting data the case names. Record the misuse on the same case. Do not mark the line failed, and do not widen the list in the meeting.
Each of the three results keeps its own identifier and points back to the same case. Writing all three as “a problem” leaves the next round unable to tell a fix, a spec change, and a rerun apart.
Keep evidence before sign-off
Each case that was run keeps the operator, the date, the case identifier, what was shown, the identifier of the record the system kept, and one of pass, defect, change, or misuse. The evidence is a screenshot from that run, or an export from the system, that matches that record identifier.
Until a spoken “yes” is written in those fields, the line stays unaccepted. A screenshot with no record identifier is marked short of evidence, or the identifier is added, before it can enter sign-off.
Sign only the lines that have evidence
Sign-off names the spec version, the lines that passed with evidence, and the lines still open. Open lines include those not run, those short of evidence, defects not run again, and lines that now have a change request. Sign-off does not mean every sentence from the meeting is in scope.
A defect becomes a pass only on a later run that shows the record the line requires. Until a change request is approved, the signed version stays the spec version of this run. Writing a pass so that it matches a screen already built removes the baseline for the next round.
When to leave the round unsigned
When the acceptance list cannot name a spec version, the intended user is not yet named on the line, or a case that was run has no record identifier, leave the round unsigned. Complete the list, the role, or the evidence first. A wish, in the meeting, to edit a line so that it matches what was just shown is a change request.
This note does not state a defect count, a pass rate, or a number of days. If you set a number, it comes from your own rule, with a date. This note does not fill one in. The syllabus errata is dated 15 September 2024. Until this round has a record, check acceptance by whether every case points at a list line, whether each result is a pass, a defect, a change, or misuse, and whether sign-off covers only lines that have evidence.