2.2 Acceptance Criteria
Creating clear and effective acceptance criteria is a crucial step in ensuring the successful delivery of high-quality products. Acceptance criteria define the conditions that must be met for a software requirement to be considered complete and ready for release. Well-crafted acceptance criteria not only serve as a bridge between stakeholders and development teams but also contribute to the overall success of the project.
Understanding Acceptance Criteria
Acceptance criteria outline the specific conditions and functionalities that a feature must satisfy to meet the expectations of stakeholders. Well-crafted acceptance criteria are clear, measurable, and testable, providing a shared understanding of what needs to be delivered.
The Given-When-Then Format
The Given-When-Then format is a structured way of writing acceptance criteria for user stories or features. It helps when defining the behavior of a system from an end user's perspective. The format provides a clear and concise structure that helps stakeholders, developers, and testers understand the desired functionality and expected outcomes.
Here's a breakdown of the Given-When-Then format:
- Given
- This section sets the initial context or preconditions for the scenario. It describes the state of the system or environment before the specific action or event takes place.
- It establishes the starting point for the shopping cart scenario.
- When
- This section describes the specific action or event that occurs. It represents the trigger or stimulus that initiates a change in the system.
- It captures the user's interaction or a system event that is being tested.
- Then
- This section outlines the expected outcomes or results that should occur as a consequence of the action or event described in the "When" section. It represents the system's response or behavior in a particular situation.
- It provides the success criteria for the scenario.
Example Scenario
Putting it all together, here's an example scenario using the Given-When-Then format:
Given a registered user with items in the shopping cart,
When the user proceeds to checkout,
Then the system must calculate the total cost, apply any eligible discounts, and display the final amount for confirmation.
In this scenario:
- Given: The initial context is a registered user with items in the shopping cart.
- When: The specific action is the user proceeding to checkout.
- Then: The expected outcome is that the system calculates the total cost, applies any eligible discounts, and displays the final amount for confirmation.
Best Practices for Creating Acceptance Criteria
- Collaborate with Stakeholders
- Involve key stakeholders, including product owners, business analysts, and end users, in the creation of acceptance criteria.
- Collaborative discussions help ensure that requirements are well-understood and aligned with business objectives.
- Refer to User Stories or Requirements
- Align acceptance criteria with user stories to maintain a user-centric focus.
- Leverage the Given-When-Then format to structure criteria, specifying the initial context, action, and expected outcome.
- Use Concrete Examples
- Provide concrete examples to illustrate expected behavior and outcomes.
- Real-world scenarios help clarify requirements and reduce ambiguity.
- Consider Edge Cases
- Anticipate and include acceptance criteria for edge cases and boundary conditions.
- Addressing edge cases ensures that the software is robust and resilient under various scenarios.
Examples of Effective Acceptance Criteria
- Example for an E-commerce Feature
- Given a registered user with items in the shopping cart, When the user proceeds to checkout, Then the system must calculate the total cost, apply any eligible discounts, and display the final amount for confirmation.
- Example for a Login Functionality
- Given a user with valid credentials, When the user attempts to log in, Then the system must validate the credentials, grant access, and redirect the user to the dashboard.
Examples of Poor Acceptance Criteria
- Vagueness and Ambiguity
- Poor Example: The system should be user-friendly.
- Issues: This criterion lacks specificity and can be interpreted differently by different team members. What defines user-friendly is subjective and unclear.
- Lack of Measurability
- Poor Example: The system should perform quickly.
- Issues: Without a specific measurement or threshold, quickly is subjective. It doesn't provide a clear standard for developers or testers to follow during implementation and testing.
- Unclear Testing Steps
- Poor Example: The system should be tested for security.
- Issues: This acceptance criterion doesn't specify how security testing should be conducted, what aspects of security are critical, or what the expected outcomes are.
- Proscriptive Criteria
- Poor Example: The user will see a lightbox that offers the user a variety of coupons with 15%, 20% and 25% off with red, yellow and green buttons with rounded corners.
- Issues: This acceptance criterion is too specific, because it tells the developer how the criteria is satisfied. The criteria should be narrowed to only essential characteristics.
- Overly Broad Criteria
- Poor Example: After the user views the summary page, the application will allow the user to edit the quantity, description or price of the product on the purchase order before finalizing the submission.
- Issues: There are too many things described at once in this criterion. More effective would be to break this up into separate criteria for each of the editable fields.
Review and Iteration
- Regular Review
- Conduct regular reviews of acceptance criteria with stakeholders and development teams.
- Iterate and update criteria based on feedback, changing requirements, or evolving project needs.
- Adapt to Changes
- Accept that requirements may change over time, and be prepared to adapt acceptance criteria accordingly.
- Ensure that any changes are communicated effectively to all stakeholders.
Conclusion
Writing effective acceptance criteria allows the tester to establish clear expectations for the system. It is invaluable when crafting test cases, which will be explained in the next section, in order to validate the system is performing as expected.
Useful Links: ←Unit 2.1 | Unit 2.3→ | Table of Contents | Canvas