Acceptance testing for custom software needs an agreement on which tasks must succeed, which users perform them and which results can be observed. These are acceptance criteria. Write them before testing: opening a screen or watching a supplier demonstration is not enough to decide whether your team can start using the system.
The guide to designing custom business software covers analysis and the first version. This article addresses a separate decision: turning the agreed scope into evidence and a decision about operational use.
Cover: an authentic public screenshot of Carbonetica Registry from the authorised portfolio archive. The test scenarios below are teaching examples, not acceptance test results from that project.
Start with the people who will use the system
Involve someone from each essential role: the person entering a request, the person approving it and the person checking the outcome. User acceptance testing, or UAT, reviews the system from its intended users’ perspective. ISTQB’s acceptance testing documentation emphasises collaboration between those defining the business need and those testing the product.
A requirement such as “manage requests” is too broad. Ask the process owner to describe the expected result: one saved request, an assigned owner, a visible status and a record that can be found again. Agree on expectations for actions that should be refused as well.
Turn the requirement into a repeatable test record
This fictional example concerns an internal request portal. It does not describe a feature already available in an E-ROE product.
- Starting situation: a purchasing user has a draft request.
- Action: the user submits the completed request and repeats submission after a connection interruption.
- Expected result: only one request exists; the user can check its status and reference.
- Saved evidence: case reference, version, result and a screenshot without confidential data.
- Owner: the business representative who can confirm the expected behaviour.
Add the date, test data, actual outcome and a linked defect when the case fails. Another colleague should be able to repeat the test without reconstructing a conversation.
Check permissions and exceptions
One successful path does not cover every working condition. Select exceptions according to their frequency and consequences. Prioritise situations that could lose data, grant inappropriate access or prevent an essential task.
- Situation: Required information is missing
Question to check: Does the system explain what to fix while keeping the draft? - Situation: A user cannot approve requests
Question to check: Is access still refused when the user opens the function directly? - Situation: A connected service is unavailable
Question to check: Can the operation be identified and recovered? - Situation: A defect has been fixed
Question to check: Do the corrected path and related paths still work?
If the project imports existing data, check a deliberate sample of records, relationships and permissions. Row counts alone are insufficient: two datasets with the same number of records can still contain incorrect associations.
Prepare suitable test data and an environment
Use synthetic or anonymised data and test connections to avoid unintended real orders, emails or payments. Record the version under test, relevant configuration and known differences from the operational environment. Changes during acceptance testing may require affected tests to be repeated.
Microsoft’s test planning guidance for Dynamics 365 links test cases to business processes and the solution version. This principle also helps when preparing custom software acceptance tests; the tools and details depend on the project.
Agree what allows the team to start
Decide in advance which defects prevent launch. Access to another customer’s data or an essential operation that loses information, for example, requires correction and another test. An unclear label may have a different priority if the team can still work and the responsible owner accepts that limitation.
The acceptance record should identify completed tests, outstanding issues, correction owners and the business owner’s decision. Tests cannot establish the absence of every error; they make the behaviour observed within an agreed scope assessable.
If you are preparing a business application or portal, bring an anonymised process and its exceptions to an E-ROE feasibility assessment. Agreeing how to recognise an acceptable result also helps make the development proposal clearer.
