·
9 min
How to run user acceptance testing: a step-by-step guide for regulated projects
Roman Kirchmeier - Autemos
Acceptance testing is the test level where the intended users check whether a system meets their business needs and is ready for deployment. In projects it often goes by UAT. The ISTQB syllabus lists six forms of this test level, and UAT is one of them. Solid UAT starts with testable acceptance criteria and ends with a documented sign-off. Under German and Swiss contract law, that sign-off is not automatically the legal acceptance (“Abnahme”), which under the BGB makes payment due. For banks, DORA and FINMA Circular 2023/1 add testing and approval duties.
TL;DR: UAT checks whether a system meets its users’ business needs; the ISTQB syllabus names six forms of acceptance testing (ISTQB CTFL v4.0.1, 2024). You need testable acceptance criteria, entry and exit criteria and a written sign-off. Legal acceptance under § 640 BGB or Art. 367 to 370 OR is a separate act with its own legal consequences.
Figure 1: The six forms of acceptance testing in the ISTQB syllabus; roles reflect typical practice.
What is acceptance testing (UAT)?
UAT is one of six forms of acceptance testing, the test level that shows a system meets its users’ business needs and is ready for deployment. The ISTQB syllabus says this level focuses on “demonstrating readiness for deployment, which means that the system fulfills the user’s business needs” (ISTQB CTFL v4.0.1, 2024).
Syllabus v4.0.1 describes five test levels: component, component integration, system, system integration and acceptance. Many older articles still show four.
“Ideally, acceptance testing should be performed by the intended users,” the syllabus states. System testing may be done by an independent test team. Our guide to functional testing covers all levels.
Which forms does the ISTQB syllabus list?
The ISTQB syllabus names six main forms of acceptance testing: UAT, operational, contractual and regulatory acceptance, alpha testing and beta testing (ISTQB CTFL v4.0.1, 2024). In projects, the term usually means UAT.
Form of acceptance testing | Typical testers | Banking example |
|---|---|---|
UAT | Business unit, future users | Advisers open an account in the test system |
Operational | IT operations | Backup, restore and user management before go-live |
Contractual | Client, often with the supplier | A bought lending module checked against the contract |
Regulatory | Business unit with compliance | Retention and reporting checked against the rules |
Alpha testing | Selected internal users | Staff test a new mobile banking app in-house |
Beta testing | Customers in their own environment | A pilot group uses the app before rollout |
Testers and examples reflect typical practice; the syllabus does not assign roles.
Does passing UAT count as legal acceptance under German or Swiss law?
No, a passed UAT is a test result, whereas legal acceptance (“Abnahme”) under a contract for work is a legal act by the customer with its own legal consequences, under the BGB for payment, risk and limitation periods. Handle the two separately in contract and test plan.
Figure 2: A UAT sign-off and legal acceptance under a contract for work are separate acts (not legal advice).
What does the German Civil Code (BGB) say?
Under § 640(1) BGB, the customer must accept work that conforms to the contract, and “Wegen unwesentlicher Mängel kann die Abnahme nicht verweigert werden” [acceptance cannot be refused for minor defects] (§ 640 BGB). Under § 640(2), the work counts as accepted if the contractor sets a reasonable deadline and the customer does not refuse within it, naming at least one defect.
Payment falls due on acceptance: “Die Vergütung ist bei der Abnahme des Werkes zu entrichten” [remuneration is payable on acceptance] (§ 641 BGB). The contractor bears the risk until acceptance (§ 644 BGB). For defect claims under § 634a(1) nos. 1 and 2, the limitation period starts “mit der Abnahme” [on acceptance] (§ 634a BGB).
What does the Swiss Code of Obligations (OR) say?
Under Art. 367(1) OR, the customer inspects the delivered work as soon as practicable and reports defects. Skipping the required inspection and notice triggers Art. 370(2) OR: “Stillschweigende Genehmigung wird angenommen” [tacit approval is assumed] (OR, Fedlex, 2026).
Approval releases the contractor from liability, except for defects not recognisable on acceptance and proper inspection, or intentionally concealed (Art. 370(1) OR). Defect claims become time-barred “mit Ablauf von zwei Jahren nach der Abnahme des Werkes” [two years after acceptance of the work] (Art. 371(1) OR).
Aspect | UAT (test activity) | Abnahme (legal act) |
|---|---|---|
Basis | Test plan, acceptance criteria | § 640 BGB, Art. 367 to 371 OR |
Result | Test report, defect list, sign-off | Acceptance, deemed acceptance (BGB), tacit approval (OR) |
Minor defects | Assessed against exit criteria | No refusal (§ 640(1) BGB) |
Consequences | Internal release decision | BGB: payment due, risk passes, limitation starts; OR: liability release, two-year limitation |
In our assessment, a passed UAT is not automatically legal acceptance, and a failed UAT is not automatically a refusal. Whether a software contract is a Werkvertrag at all depends on the contract. Have clauses that link sign-off and legal acceptance reviewed by a lawyer. This section is not legal advice.
How do you write acceptance criteria?
You write acceptance criteria scenario-oriented (Given/When/Then) or rule-oriented, as a verification list or an input-output table. The ISTQB syllabus describes them as the conditions a user story’s implementation has to meet for stakeholders to accept it (ISTQB CTFL v4.0.1, 2024).
Scenario-oriented: Given, When, Then
Daniel Terhorst-North and Chris Matts developed Given-When-Then as part of behavior-driven development (Martin Fowler, 2013). Given sets the context, When the action, Then the expected outcome. Cucumber calls such examples “an executable specification of the system” (Cucumber). See our articles on behavior-driven development and Gherkin syntax.
E-banking example for the criterion “daily transfer limit”:
Keyword | Wording |
|---|---|
Given | a customer with a daily limit of CHF 10,000 who has already transferred CHF 9,500 today |
When | she approves another transfer of CHF 800 |
Then | e-banking rejects the payment |
And | shows the remaining daily limit of CHF 500 |
Rule-oriented: a verification list
The daily limit applies per customer and calendar day.
A payment above the remaining limit is rejected.
The rejection appears with a reason in the payment overview.
In ATDD, teams write these tests from the acceptance criteria before the functionality is implemented (Agile Alliance). So the tests exist early in the project; users run them after implementation.
How do you run UAT step by step?
UAT can be run in seven steps, from criteria to sign-off. The ISTQB syllabus recommends entry and exit criteria for each test level (ISTQB CTFL v4.0.1, 2024).
Figure 3: UAT in seven steps, from acceptance criteria to the sign-off record.
Set acceptance criteria. Each requirement gets testable criteria, each criterion at least one scenario. A traceability matrix records the mapping.
Check entry criteria. Syllabus examples: available people, environments and test data, testable requirements, passed smoke tests.
Prepare scenarios and test data. As a rule, EU financial entities may keep only “anonymised, pseudonymised, or randomised production data” in non-production environments (Delegated Regulation (EU) 2024/1774, Art. 16, 2024).
Have the intended users run the tests. The test team logs result, date and tested version.
Log deviations and retest. Each defect gets a severity and a link to its scenario; confirmation testing follows the fix.
Assess exit criteria. Examples: all must-have scenarios passed, no open critical defects. Per the syllabus, used-up time or budget only counts as an exit criterion if stakeholders accept the risk.
Record the sign-off. The approver confirms in writing which version they accept and on what basis.
What belongs in a sign-off record?
For audits, a sign-off record should contain:
tested version and test environment
scenarios with results and a reference to the requirement
open defects with severity and decision
status of the exit criteria and justified deviations
name, role and date of each approver
a reference to the related change
What do DORA and FINMA require before go-live?
DORA, Delegated Regulation (EU) 2024/1774 and FINMA Circular 2023/1 require ICT systems and changes to be tested and approved before go-live. DORA and the Delegated Regulation never use the term UAT, and neither does the quoted FINMA requirement. In our assessment, a documented UAT sign-off is one common way to evidence that approval.
DORA applies from 17 January 2025 and requires changes to be “recorded, tested, assessed, approved, implemented and verified in a controlled manner” (Art. 9(4)(e), DORA, EUR-Lex, 2022). It binds EU financial entities; Swiss banks, supervised by FINMA, come under it through EU subsidiaries or EU business.
Rule | Content (shortened) | Possible UAT evidence |
|---|---|---|
DORA Art. 9(4)(e) | Changes tested and approved | Sign-off record with change reference |
Regulation 2024/1774, Art. 16(2) | “testing and approval of all ICT systems prior to their use and after maintenance” | Risk-based scenarios, test report |
Regulation 2024/1774, Art. 17(1)(b) | Approvers independent of requesters and implementers | Approver outside the delivery team |
FINMA Circular 2023/1, change management | Requirements defined, approved and tested according to criticality | Traceability to test result |
FINMA Circular 2023/1, in force since 1 January 2024, requires functional and non-functional requirements to be “klar definiert und genehmigt und gemäss ihrer Kritikalität getestet und validiert” [clearly defined, approved and tested according to their criticality] (FINMA Circular 2023/1, 2022). More in our article on testing in regulated industries.
Which parts of acceptance testing can be automated?
Execution of stable scenarios, test data, traceability and reporting can be automated; people decide whether a system is accepted. The ISTQB syllabus calls regression testing “a strong candidate for automation” (ISTQB CTFL v4.0.1, 2024). Good candidates are:
Figure 4: What can be automated in UAT and which decisions stay with people.
passed acceptance scenarios that rerun as regression tests after every change
loading and resetting test data
linking requirement, test case and execution
test reports as evidence for audits and sign-off
People judge whether a workflow fits daily work, rate open defects and sign the release. Some guides list load tests as a UAT method; they are non-functional tests with their own plan.
Autemos, the AI-assisted test automation software from selementrix, handles the automatable functional part. Business users build scenarios in visual drag-and-drop workflows without code. The AI drafts an executable workflow from a Jira story, and the team must approve every AI-generated step before it runs. The Jira/Xray integration syncs test cases and executions both ways; Allure reports and the audit trail provide evidence. Autemos does not approve releases or run load, performance or security tests.
Frequently asked questions
How does UAT differ from system testing?
System testing checks the whole system against its specifications and may be done by an independent team; UAT checks business needs, ideally with the intended users (ISTQB CTFL v4.0.1, 2024).
Who performs UAT?
Ideally the intended users perform UAT; in banks, typically the business unit. The German Testing Board offers the CT-AcT specialist syllabus (English version 1.0, 2019) for everyone involved in acceptance activities (GTB, 2019).
Does UAT cover every form of acceptance?
No, in ISTQB terms UAT is one of six forms of acceptance testing; everyday usage often treats UAT and acceptance testing as the same thing.
Can UAT be fully automated?
No, execution of stable scenarios can be automated; the acceptance decision stays with people.
Does a passed UAT count as acceptance under the BGB?
Not automatically: whether a UAT sign-off has the legal effect of acceptance under § 640 BGB depends on the contract and the circumstances, so have such clauses reviewed by a lawyer.
Conclusion
UAT shows that a system meets its users’ business needs. It’s well prepared when every requirement has testable acceptance criteria, entry and exit criteria are set in advance, and the sign-off names version, results, open defects and approver. Keep UAT separate from legal acceptance under the BGB or OR, which has its own legal consequences. Banks can use the same record as one piece of evidence for DORA and FINMA testing and approval duties. Recurring scenarios can be automated; the release decision stays with people. If you want to derive acceptance scenarios from Jira stories and document results in Xray, talk to our team about your acceptance process.
