14.2.7. T - Testable

The story must have clear acceptance criteria to validate completion.

A testable user story is one that comes with defined acceptance criteria. These criteria serve as a guide to understand what 'done' looks like for the story. This means that, upon completion of the development work on the story, testers should be able to run specific checks to confirm that the story functions as intended without ambiguity.

Imagine you're baking a cake. If your recipe (user story) simply says 'Make a cake', you might not know if it should be chocolate, vanilla, or red velvet. However, if it says, 'Make a chocolate cake that is moist and has a creamy frosting', those specifications are clear. You know exactly how to bake it and how to determine if it's successful (by tasting it).

Acceptance criteria define boundaries and conditions that the user story must meet to be accepted as done. They ensure clarity, testability, and shared understanding between stakeholders and the development team.

Acceptance criteria list the specific requirements that must be satisfied for the user story to be considered complete. These criteria help ensure all stakeholders have the same understanding of what the feature should accomplish. They can include functionality, performance, and quality requirements.

Think of acceptance criteria as a checklist for a school project. If the criteria say, 'Include a title, 5 paragraphs, and a bibliography', you'll know exactly what you need to do to finish the project successfully. Without that checklist, it’s easier to miss important components.

✅ A reset password link is sent to the registered email. ✅ The link expires after 24 hours. ✅ The user is prompted to enter a new password upon clicking the link.

These acceptance criteria provide clear, quantifiable conditions that must be met. For instance, stating that 'a reset password link is sent to the registered email' ensures that once the user requests a password reset, they will receive a link in their email. The criteria also define that the link will expire after a specified time frame, which adds a layer of security.

Imagine ordering a pizza with specific criteria: 'The pizza should be large, have extra cheese, and be delivered within 30 minutes.' Each criterion helps ensure you receive exactly what you expect. If the pizza doesn't meet these conditions, it’s clear that there’s a problem.

Gherkin is a structured language used in Behavior-Driven Development (BDD) to write acceptance tests in a readable Given–When–Then format.

Gherkin language helps formulate user stories and their acceptance criteria in a clear, standardized way. The format consists of: 'Given' (context), 'When' (action), and 'Then' (expected outcome). This structure helps anyone involved in the project understand the flow of the feature's functionality.

If you were to describe a day at school to someone unfamiliar with it, you might say: 'Given it’s a school day, when I arrive at 8 AM, then I have math class first.' This format simplifies the explanation and helps convey expectations clearly.

Feature: Password Reset Scenario: Successful password reset request Given the user is on the login page And the user clicks on "Forgot Password" When the user submits their registered email address Then a reset link should be sent to that email And the link should expire in 24 hours

This Gherkin example illustrates a case where a user requests to reset their password. Each part follows the Given, When, Then structure, clearly defining the preconditions (the user is on the login page), the action (clicking 'Forgot Password'), and the expected outcome (receiving a link by email). This format makes it easy to automate the testing of this feature.

Consider an itinerary for a road trip. You might say: 'Given I have a full tank of gas, when I start the trip, then I should be in city X by 3 PM.' Each piece of the statement helps you understand the conditions leading to the expected result.

--