October 15, 2026 · Faith Forge Labs Editorial Team
How to Check New Software Before You Sign It Off
A polished demonstration is a useful start. Acceptance testing asks whether the people doing the work can complete the agreed tasks, including the awkward cases.
A demonstration can show that a feature exists. It is harder to tell from a demonstration whether your team can use it to get through a normal working day. Before signing off new software, set aside time for the people who will rely on it to try the agreed work themselves.
This is often called user acceptance testing. The name sounds formal, but the central question is straightforward: does this version support the tasks we agreed it would?
Turn the agreement into tasks people can try
Start with the project brief and the decisions made during development. For each important task, write a short scenario with a starting point, an action and an expected result.
For a hypothetical booking tool: a staff member opens an existing booking, moves it to an available slot and checks that the revised time appears in the right places. A separate scenario checks what happens when the requested slot is unavailable. Neither scenario needs to read like a programming test.
The GOV.UK Service Manual describes acceptance criteria as observable outcomes used to check whether a user need has been met. Keep that outcome focus when writing your own scenarios.
Test the inconvenient cases as well
Ask people who actually do the work which situations tend to need extra attention. A manager, a new starter and a busy administrator may notice different problems.
- What happens when a required detail is missing or entered incorrectly?
- Can a user correct a mistake without starting the whole task again?
- Does a restricted user see only what their role allows?
- What appears after a slow connection, interrupted task or repeated click?
- Can people complete the task on the devices and input methods they need?
Use fictional records in a suitable test environment. Agree how email, payments and connected systems will behave so a rehearsal does not send real notifications or change live business records. If a test requires specialist setup, ask the delivery team to arrange it before the session.
Record what happened so someone can fix it
A useful issue report includes the task, the steps taken, the expected outcome and what actually appeared. Add the relevant browser or device and a safe screenshot if it helps. Remove personal information and secrets before sharing evidence.
Separate a blocked task from a small cosmetic problem and from a request for a new feature. All three may deserve attention, but they lead to different decisions. Agree who sets priorities and who confirms a correction worked. Retest the affected task after a fix, along with closely related steps that could have changed.
Make sign-off a recorded decision
List which agreed tasks passed, which remain open and what the open issues mean for launch. A decision to release with a known limitation should identify its owner, workaround and next action. If a core task cannot be completed reliably, make that visible before launch pressure turns it into an assumption.
User acceptance testing is one part of release readiness. It does not replace application security testing, technical checks or specialist accessibility work. It gives the business its own evidence that the agreed workflow is usable. If you are approaching handover without that plan, discuss the acceptance steps before treating a successful demo as the finish line.