Software acceptance: What should your business test?
Can users complete their work in the new software? That is the central question of user acceptance testing, usually called UAT. People who understand the business perform agreed scenarios and compare the results.
The question is not just whether individual functions work, but whether they work together correctly in actual tasks. For example, a rescheduling button may work while the teacher’s calendar is not updated or the remaining lesson balance changes incorrectly. UAT checks defined usage scenarios; other technical testing is still needed.
Rather than clicking through every screen, users should perform meaningful tasks from beginning to end and compare outcomes with expectations.
1. Identify who tests and what is in scope
Testers should understand the work the system supports. For class-management software, that might mean registration, scheduling and accounting staff, rather than simply whoever has spare time.
Appoint a coordinator and someone authorized to decide on issues affecting acceptance. A person performing tests does not necessarily have authority to accept scope changes or operational risks.
Before starting, agree on the software version, function groups and readiness conditions. If an integration is not deployed, record the limits of simulated inputs rather than treating them as a complete test of the actual flow.
Acceptance criteria should describe observable outcomes. “Convenient rescheduling” is harder to test than requiring the new session in both student and teacher calendars, with the old session handled under the agreed status rules.
What is requirements analysis? The first step towards clearer development
2. Build scenarios from real work
Start with a common workflow
In a hypothetical example, a staff member enrolls a student in a lesson package, books a session, records attendance and checks the remaining sessions. This crosses several steps and related data, revealing more than clicking “Save.”
Each scenario needs starting conditions, a role, actions and expected results. “Registration successful” alone does not tell testers which statuses, calendars or data to compare.
An example template:
• Scenario ID: CLASS-01.
• Role: scheduling coordinator.
• Starting condition: the student has a valid package with one unused session.
• Action: book an eligible session and confirm it.
• Expected results: the correct student, teacher and status are recorded; reserving or deducting sessions follows the agreed rules.
• Evidence: before-and-after data and any necessary screenshots.
Do not assume the example’s deduction rules apply to every school. Business staff must provide the project’s actual rules.
Add consequential exceptions
After the standard flow, test an expired package, no remaining sessions, a teacher scheduling conflict, an unauthorized user or a resubmitted request.
Also test events after the record exists: cancellation, changing a teacher or time, and correcting an entry. These often reveal how the system manages statuses and related data.
An unlimited list is impossible. Prioritize by impact and frequency, and record what was not checked. UAT findings must be read alongside the scope and conditions tested.
3. Prepare data and the environment
Test data should reflect actual structures: package types, student statuses, roles and important exceptions. A dataset containing only perfect cases is unlikely to represent daily work.
Prefer synthetic or appropriately processed data to reduce disclosure risks. If real data is necessary, its use needs suitable approval and controls for the test environment.
Check whether the environment sends real email, creates real payments or updates external systems. The technical team should configure appropriate safeguards against unintended effects.
Participants also need sufficient guidance to use the software. Otherwise results may reflect missing instruction rather than a functional defect. Confusing interactions should still be recorded as usability or training issues.
4. Execute, record and retest
When a problem occurs, record the scenario, account role, time, steps, actual result and expected result. Screenshots or recordings should contain only necessary information.
“Cannot reschedule” is not specific enough. A better report is: “In CLASS-03, rescheduling a future session to a valid date produces a success message, but the teacher’s calendar still shows the old time.”
Then classify the issue: a departure from requirements, a new request, an unresolved point or a usability difficulty. Discuss classification against the documentation and expected outcome rather than automatically calling all feedback a defect or an extra.
After a fix, retest the original scenario and related areas according to impact. Do not close an issue solely because the development team reports it fixed.
Before each round, announce the version and change list so users do not test the old release. Recreate starting conditions if the data has been reset. Evidence by round helps distinguish an unresolved defect from a new issue introduced later.
5. Decide based on the results
Summarize passed, failed and unexecuted scenarios, together with test limitations. Remaining issues need an owner, action and review date.
Some issues may not prevent use, but acceptance must be decided by an authorized person and recorded. Conditions blocking important business work should be handled against the agreed criteria.
Acceptance and launch are connected but not identical decisions. Alongside test results, consider data, guidance, support contacts and transition readiness.
Launching a new system: How to limit business disruption
Identify testers, important scenarios and acceptance criteria during planning. When acceptance approaches, the project team will have a concrete basis for assessment and resolving disagreements.
