“Add a button to publish a news item” sounds like a small task. Yet at handover, it turns out that the author expected a preview, the editor wanted protection against accidental publication, and the client expected drafts to stay out of the public list. Acceptance criteria help everyone agree on the outcome before code is written. We will explore this in a training editorial system where one news item needs to move from draft to published.
This is a fictional requirements example, not a description of default WordPress or other CMS behaviour, and not a client case study. Below is a specific set of rules that a team can accept or change before estimating the work. The exercise requires a shared document, a client representative, a developer and someone who will check the outcome. Access to a production website, tool installation and changes to real records are unnecessary.
Limit the task to one state transition
Start with a sentence describing the benefit: an editor can publish a prepared news item, while a visitor sees only content approved for public access. This explains the goal, but is not yet a verification criterion. Separately record the boundaries: scheduled publication, approval by several editors, email distribution and automatic social media sharing are outside this task. Otherwise, a single button can quietly turn into an entirely new editorial platform.
For the training example, we agree on two roles. An author creates and saves a draft; an editor publishes it. A visitor who is not signed in cannot access the draft. These are requirements for our fictional system, not a recommendation to change roles on your website. If permissions differ in your real project, correct this agreement first: the subsequent expectations depend on it.
Create a control-data card in the document: news item NEWS-DEMO-01, title “Test news item”, text “Material for verification”, initial state “Draft”. The identifier and content are examples. Also specify an empty published-news list in the test dataset. This card lets two people independently understand which record to look for and why they should not judge the result using an arbitrary item on the live website.
Separately ask what publication means: appearing in a list, opening through a direct link, being available to search, or all of these. For the exercise, we will agree only on opening the page and appearing in the public list. Google indexing is outside the criterion: it is not a direct action of the button that the team fully controls. Do not promise search visibility immediately after a click.
Turn the agreement into observable examples
Instead of “publication works correctly”, write criterion P1: when an editor opens the saved NEWS-DEMO-01 and confirms publication, the system shows the “Published” state; a visitor who is not signed in can open its page and find one entry in the public list. Both views must contain the agreed title and text. This names the initial conditions, action and visible result, rather than the internal implementation.
Criterion P2 covers permission boundaries: an author without publication rights cannot make this news item public. If the action is attempted outside the permitted interface, the server must also refuse it and the record must remain a draft. The absence of a button alone does not prove protection. The developer agrees on the technical verification method; checks use only authorised test accounts, without searching for someone else’s access.
Criterion P3: a visitor who is not signed in receives neither the draft’s title nor its text through a direct link or the public list. Agree separately on the service response or message page to show. Do not leave “the draft is hidden” unexplained: specify where it must be hidden. The check must cover not just the visual card but also the public server response if the system supplies content through a public API.
You can organise these examples using the “Given — When — Then” pattern. Its purpose and corresponding keywords are described in the Gherkin documentation. An ordinary document is sufficient for our exercise; installing Cucumber is unnecessary. A written scenario does not become an executed automated test merely because it resembles that format: automation requires a separate implementation of the checks.
Add two edge cases to the same rules. If the title is empty, publication does not occur, the editor sees an explanation beside the relevant field, and the entered text stays in the form. If the editor confirms an already completed publication again, no duplicate news item is created. These are our agreed expectations, not a claim that every CMS already behaves this way.
Do not mix criteria with implementation instructions. “Add a status column to the table” might be a technical subtask, but does not explain what the editor receives. Likewise, “write three tests” does not prove that P1–P3 are satisfied if those tests cover different branches. Define the observable outcome first; leave the choice of data structures, routes and components to the technical plan.
Run acceptance without changing the rules at the end
Before development starts, ask another person to read the card and explain the expected outcome in their own words. If questions remain about the role, state, required field or visibility location, the task still contains uncertainty. Record the answers and the agreement version. Discuss a new request after implementation as a scope change rather than automatically declaring it a developer error.
For acceptance, use the agreed test copy and training data without personal information. Next to each criterion, record the build checked, the actual outcome and brief evidence. Do not mark success in advance. If a rule is violated, write a separate bug report with reproduction steps and a reference to the specific criterion, so verification does not become another argument over expectations.
In conclusion, acceptance criteria reduce ambiguity when they name a state, role, action and verifiable outcome. For this exercise, readiness means satisfying P1–P3 and the agreed edge cases, not merely making a button appear. If a website task is difficult to estimate because expectations are unclear, AriZone can help separate the requirements, define boundaries and prepare verifiable examples before development.
Leave a comment