acceptance-test-writing

Given-When-Then is a structured format for acceptance criteria: Given describes the initial state, When specifies the user action, and Then defines the expected outcome. Write each scenario with one trigger per When clause using domain language and measurable results, avoiding implementation details.

BDD (Behavior-Driven Development) and ATDD (Acceptance Test-Driven Development) both use Gherkin syntax and Given-When-Then scenarios. BDD emphasizes collaboration and shared language across teams; ATDD focuses on writing tests before implementation to drive development from acceptance criteria.

Yes. Rule-Oriented format structures acceptance criteria as testable business rules rather than scenarios. This format suits checklist-style requirements and is particularly useful when multiple conditions must be validated independently from user workflows.

Extract the user perspective and measurable outcome from the story. Map the user action to When, the preconditions to Given, and the success criteria to Then. Use active voice, domain terminology, and one action per scenario to keep tests maintainable and reusable.

Avoid UI-specific details, implementation-specific language, and multiple triggers in a single When clause. Don't use passive voice or vague outcomes. Focus on functional behavior and testability rather than how the system should build the feature.

Yes. Well-written Gherkin scenarios and Rule-Oriented criteria act as living documentation and can be automated directly in test frameworks. This dual purpose enforces clarity, reduces documentation drift, and aligns stakeholders on expected behavior.