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.
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.
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.