Benefits of SGWTAB Notation

In the world of agile development, user stories play a crucial role in defining what needs to be built, who it's for, and why it's important. However, even the most well-crafted user stories can fall short without clear, comprehensive acceptance criteria. This is where the "Scenario, Given, When, Then, And, But" (SGWTAB) notation, derived from the Behaviour-Driven Development (BDD) approach, comes into play. This structured format provides a clear, concise way to articulate acceptance criteria and bridge the gap between developers, testers, and business stakeholders.

One of the primary benefits of using Scenario, Given, When, Then, And, But notation is that it provides a structured framework for expressing acceptance criteria with clarity and precision. The format encourages a step-by-step breakdown of conditions and outcomes. For example:

• Scenario: Describes the user’s goal or behavior to be tested.
• Given: Sets up the initial context or state of the system.
• When: Defines the action that triggers the behavior.
• Then: Specifies the expected result or outcome.
• And/But: Adds further detail or variations to the conditions and results.

This level of granularity leaves little room for misinterpretation, ensuring that everyone involved—developers, testers, and product owners—has the same understanding of what constitutes "done."

Because the SGWTAB format uses simple, non-technical language, it becomes an effective tool for collaboration between technical and non-technical team members. Product owners, developers, testers, and even stakeholders can contribute to or validate the acceptance criteria without getting bogged down by jargon. By using this shared language, it promotes discussions that drive a deeper understanding of user requirements and potential edge cases early in the development process.

The Given, When, Then structure naturally aligns with test-driven development and automated testing practices. Each scenario can be translated directly into test cases, and tools like Cucumber and SpecFlow can automate the execution of these tests. This reduces the manual effort required for testing while ensuring consistent test coverage.

Moreover, writing acceptance criteria in this format forces the team to think about test cases right from the start. This results in a robust, testable design that minimizes rework, as any potential issues are addressed early in the development process.

The SGWTAB notation provides a clear and unambiguous record of the intended behavior of a feature. This acts as living documentation that remains relevant throughout the development lifecycle. As the system evolves, the scenarios can be updated to reflect new requirements or changes, providing a continuous reference point for future iterations.

For QA teams, this serves as a useful foundation for regression testing. Since each scenario ties back to specific business rules or requirements, it’s easy to track which behaviors are expected and ensure they remain intact as the system changes.

Another key benefit of this notation is its ability to explicitly capture edge cases and negative scenarios using the "And" and "But" extensions. For example:

• But: The system should handle errors gracefully if the input is invalid.
• And: The user should receive a confirmation email upon successful registration.

This helps teams go beyond the “happy path” and ensure the system behaves as expected in all scenarios, leading to a more resilient solution.

By standardizing the way acceptance criteria are written across stories, the SGWTAB notation ensures that all team members approach requirements with the same mindset. This consistency makes it easier to review user stories, estimate work, and onboard new team members. Furthermore, it encourages a disciplined approach to story refinement, ensuring that no critical details are left out.

Using Scenario, Given, When, Then, And, But notation for acceptance criteria transforms vague user stories into actionable, testable, and clearly defined requirements. It improves clarity, fosters collaboration, and helps teams build with confidence by providing a comprehensive view of the system’s behavior. By integrating this practice into agile development, teams can not only build the right product but also ensure it's built right from the very start.

As a registered user, I want to reset my password so that I can regain access to my account if I forget my credentials.

Acceptance Criteria:

Scenario 1: Successful Password Reset

• Given: The user is on the "Forgot Password" page and is a registered user with a valid email address.
• When: The user enters their email and clicks the "Reset Password" button.
• Then: The system sends a password reset link to the user’s email.
• And: A confirmation message is displayed, stating, "A password reset link has been sent to your email."

Scenario 2: Invalid Email Address

• Given: The user is on the "Forgot Password" page.
• When: The user enters an email that is not associated with any registered account.
• Then: The system displays an error message, "Email not found. Please try again."
• But: No email is sent to the unregistered email address.

Scenario 3: User Clicks Expired Reset Link

• Given: The user has received a password reset email.
• And: The reset link in the email has expired.
• When: The user clicks the expired link.
• Then: The system displays an error message, "The password reset link has expired. Please request a new one."

Scenario 4: Password Reset Link Already Used

• Given: The user has already used a password reset link to successfully reset their password.
• When: The user tries to use the same link again.
• Then: The system displays an error message, "This password reset link has already been used. Please request a new link if you need to reset your password again."

User Story:

As an online shopper, I want to add items to my shopping cart so that I can purchase them later.

Acceptance Criteria:

Scenario 1: Adding an Item to the Cart

• Given: The user is viewing the product page of an in-stock item.
• When: The user clicks the "Add to Cart" button.
• Then: The item is added to the user’s cart.
• And: The cart icon in the header updates to reflect the new item count.

Scenario 2: Out-of-Stock Item

• Given: The user is viewing a product page where the item is out of stock.
• When: The user attempts to click the "Add to Cart" button.
• Then: The system displays a message, "Item is out of stock."
• But: The user is not allowed to add the item to the cart.

Scenario 3: Adding Multiple Items

• Given: The user has already added an item to the cart.
• When: The user selects the same item and clicks the "Add to Cart" button again.
• Then: The item quantity in the cart is updated, and the user sees the message, "Quantity updated."

User Story:

As an admin, I want to deactivate a user account so that they can no longer access the platform.

Acceptance Criteria:

Scenario 1: Successful Deactivation of Active User

• Given: The user is logged in as an admin.
• When: The admin selects an active user and clicks "Deactivate Account."
• Then: The selected user's account is deactivated.
• And: The user receives an email notification about the deactivation.

Scenario 2: Deactivation of an Already Deactivated User

• Given: The user is logged in as an admin.
• And: The selected user’s account is already deactivated.
• When: The admin clicks "Deactivate Account."
• Then: The system displays a message, "This account is already deactivated."

Scenario 3: Admin Tries to Deactivate Their Own Account

• Given: The user is logged in as an admin.
• When: The admin selects their own account and clicks "Deactivate Account."
• Then: The system displays an error message, "You cannot deactivate your own account."

• Clarity: Each scenario clearly defines the context and expected outcomes, reducing ambiguity.
• Edge Cases: The use of "But" allows edge cases, such as expired links or out-of-stock items, to be captured.
• Testability: Each scenario aligns with automated test cases, making it easy to implement in TDD.
• Consistency: Using the same structure across all user stories ensures that the entire team approaches each feature in a similar way, improving quality and understanding across the board.

These examples demonstrate how Scenario, Given, When, Then, And, But notation makes it easy to define acceptance criteria with precision and completeness, fostering better communication and collaboration between teams.