Direct answer
A criterion someone cannot test is a wish. Good acceptance criteria are short statements, attached to one piece of scope, that describe an observable result so clearly that two different people would reach the same pass or fail verdict. If the only way to check a criterion is to ask someone how they feel about it, rewrite it until it can be checked by doing something and looking at what happens.
The point is agreement before the work, not argument after it. Criteria written into the scope turn 'is it done?' from an opinion into a test. They also give you the material for the later user acceptance testing checklist, where you run them against the finished software.
What an acceptance criterion is
An acceptance criterion states a condition the software must meet for a piece of scope to be accepted. It belongs to one feature or user story, not to the project in general. It describes behaviour visible to a user or an administrator, not the technique used to build it.
It is different from a requirement and different from a test case. A requirement says what must be true at a higher level; the criterion pins down the boundary of acceptance for that item; a test case is the detailed procedure for running the check. Criteria sit between the two, and they are the part the buyer should be able to read and challenge without technical knowledge.
Wording that can be tested
Testable wording names who does what and what is seen afterwards. A few habits make most criteria testable.
- Name the role: 'a sales manager', not 'the user'
- Use a concrete action and a concrete visible result: saved, listed, rejected, emailed, hidden
- Avoid vague adjectives such as fast, easy, intuitive, modern or robust unless you define how they will be judged
- One condition per criterion, so a failure points at one thing
- State the data or starting position the check needs
- If a number matters, agree it in writing with the builder; do not leave a number implied
Given / when / then
The given / when / then pattern is a simple way to keep criteria honest. Given a starting situation, when the person does something, then a specific result follows. It forces you to state the starting position, which is where most hidden assumptions live.
For example: given a customer record with no assigned owner, when a manager assigns an owner and saves, then the record shows that owner and the owner receives the notification agreed in scope. You do not need to use the pattern for everything. Simple statements are fine where the situation is obvious. Use it where the outcome depends on state, roles or sequence.
Good versus weak examples
Weak criteria usually fail one of three ways: they describe a feeling, they bundle several conditions or they hide the starting state. Compare these.
- Weak: 'The order form is easy to use.' Better: 'A customer with a saved address can place an order without retyping the address.'
- Weak: 'Reports load quickly.' Better: agree the acceptable wait with the builder in writing and test it on the agreed data set, or drop the criterion rather than leave it vague.
- Weak: 'Users can manage their profile.' Better: split into what they may change, what only an administrator may change, and what is validated on save.
- Weak: 'The system sends notifications.' Better: name the event, the recipient, the channel and where the message text is set.
Permissions and negative cases
Most acceptance gaps are in what should not happen. For every action, ask who must not be able to do it, and what should happen when input is wrong. A criterion about the happy path only proves the software works when everything goes right.
Write the negatives explicitly: a user without the right role cannot open the page or see the record; an empty required field is rejected with a message that says which field; a duplicate is caught or merged by a stated rule; a failed integration call leaves the record in a visible, recoverable state. Our page on roles and permissions in a web application lists the role questions worth settling before you write these.
Non-functional criteria
Some expectations are not features: which browsers and devices must work, how access is controlled, whether changes are recorded, what happens to data on deletion. They still need criteria, or they get discovered at the end.
Keep the same rule: testable and agreed. If you cannot say how a quality would be checked, you cannot accept it. Where a quality genuinely cannot be measured cheaply, say so and agree a lighter check, such as a walkthrough on named devices, rather than an unverifiable promise. The non-functional requirements checklist lists the categories to cover.
Who signs, and tracing to scope
Name who accepts each item. It should be a person on the buyer side who understands the work being checked, and who has the authority to say yes, not a committee. A backup person prevents the project stalling when the named person is away.
Trace every criterion to an item in the software project scope, and every scope item to at least one criterion. Items with no criterion are the ones that will be disputed; criteria with no scope item are scope creep waiting to be invoiced. When a criterion changes, record the change and its effect on the plan instead of editing the text quietly.
Where LATYNEX fits
LATYNEX builds custom web applications remotely, in English, and agrees one scope and one price in writing before work starts. Acceptance criteria are a natural part of that written scope. If you are preparing a project, start from web application development and bring the workflows you want covered.
Questions
How many acceptance criteria should each feature have?+
As many as it takes to make acceptance testable, and no more. A small feature may need a handful; a feature involving roles, money or integrations needs more. If a list becomes long, the feature probably should be split.
Should the buyer or the builder write them?+
Draft them together. The buyer knows what a correct outcome looks like; the builder knows which cases are easy to miss. Whoever drafts, the buyer must be able to read and approve every line.
Are acceptance criteria the same as a test plan?+
No. Criteria say what must be true for acceptance. A test plan or checklist describes how to run the checks, including data, steps and who does them.
What if the criteria change during the build?+
Changes are normal, but they should be recorded and agreed, with their effect on scope and order of work stated, rather than absorbed silently on either side.
Can we write criteria after the build?+
You can, but it weakens your position: criteria written after seeing the result tend to describe what was built. Writing them first is what makes them useful as a test.