pingpong

Software projects

Write an acceptance test script for a business user

An acceptance script walks a business user through a real task, from a defined starting state to an expected result. Write each step in the words the user already uses, say what they should see afterward and leave space to record what actually happened.

A text to start with

Our software should let [type of user] do [real task]. Before they start, the system holds [starting data and settings]. Write an acceptance test script in plain language with a scenario name, the starting state, numbered user steps, the expected outcome for each step and a blank to record what they saw. Avoid technical terms. Add a way to report anything unexpected.

Example request. Change the details to fit your situation.

Acceptance test script

Scenario name: [ ] User role: [ ] Real task being checked: [ ] Starting state, including test data: [ ] How the tester sets up that state: [ ] Step number: [ ] What the user does: [ ] What they should see: [ ] What they actually saw: [ ] Matches expectation (yes or no): [ ] Unexpected result: [ ] Where it happened: [ ] How it differs from the usual way of doing this task: [ ] Tester name and date: [ ] Who decides if it blocks release: [ ]

Developer assumptions in the steps

Scripts written by the builder often assume knowledge the tester lacks, such as which menu to open, what a field name means or what test data to use. Read each step as someone who has never seen the screen. Check that the tester can actually set up the starting state and that expected outcomes describe something visible, not a database change. Make sure there is a place to record surprises, including results that look fine but differ from how the tester does the task today.

Ask another agent to check the result

Read this script as a business user who has never seen the software. Remove technical wording and developer assumptions, point out steps that cannot be followed without insider knowledge and add a clear place for the tester to report unexpected results.

Run it once with a real user

Have one business user follow the script while you watch without helping. Note every pause, question and wrong turn, then rewrite those steps. Reset the test data before each run. Agree beforehand who decides whether an unexpected result blocks release, and keep the completed scripts as a record of what was checked.