When to Use “Given-When-Then” Acceptance Criteria

Aug 12, 2023 | Best Practices

Give When Then

When it comes to testing for user experience (UX) and product functionality, it’s hard to go wrong with given-when-then testing in Gherkin. During development and QA, using given-when-then acceptance criteria allows your entire team to stay on the same page with expectations for how your software is supposed to work.

Automated testing software like DesignWise can make setting these tests up even easier. Let’s explore some examples of given-when-then acceptance criteria, and how these tests can be automated to make your product even better.

What Is a Given-When-Then Acceptance Criteria?

Given-when-then acceptance criteria is a type of syntax that is meant to define the context, action, and expected outcome in a specified scenario. In most cases, it breaks down in the following pattern:

  • The interface is given context for the acceptance test it’s supposed to run.
  • An action is carried out when the system encounters specific trigger criteria.
  • Then comes the effect of the trigger criteria being acted upon in that particular context.

In simple terms, given-when-then tests follow the logic of cause and effect, with the addition of the action leading to the effect. These tests are frequently used in Behavioral Driven Development (BDD) and can be automated with DesignWise, Selenium, Cucumber, and other common developer tools.

Some Given-When-Then Examples

The structured nature of given-when-then makes it an ideal method for testing user experience and platform functionality. Here are some basic given-when-then examples and their criteria in the context of UI and UX:

Forgotten Password

  • Given: The user navigates to the login page
  • When: The user selects the “Forgot Password” option and enters a valid email or phone number for password recovery
  • Then: The system sends the password recovery link to the entered email

User Login with Correct Password

  • Given: The user arrives at the login page
  • When: The user enters the password of [Ex@mpLePa$$w0rd1] and clicks the login button
  • Then: The system redirects them to the dashboard page

User Attempts to Leave a Comment without Adding Their Name

  • Given: The user fills out the comment form without filling out the [Name] field
  • When: User selects “Add Comment” button
  • Then: The system delivers the message, “ERROR: Please fill in required fields (name).”

There are endless possibilities for using given-when-then tests, particularly in scenarios where human users are interacting with the system or app.

Where to Use Given-When-Then Tests

Some of the most common instances where a given-when-then test can be helpful are ones focused on user behavior. These tests are especially useful when you’re working in line with BDD testing principles.

Ultimately, given-when-then tests are an easy way to test different functions of your software and how it responds to human interaction in plain, clear language. This makes it easier not only for everyone on your team to understand the desired results of working with any given part of the UI, but also for your stakeholders and executives to understand results and provide feedback.

How to Write Given-When-Then Acceptance Criteria

When approaching how to write acceptance criteria in the given-when-then format, it’s essential to remember the three different sections of the criteria and write them out accordingly.

1. Given

This initial phase sets up the conditions for the test scenario. It establishes the factors that need to be true before the action can be triggered.

When writing the “Given” criteria in a given-when-then test, be sure to describe the relevant context, conditions, or data. When writing out the language, be sure to keep the description concise and use specific details to establish the trigger criteria for the test.

As an example of what the “Given” criteria can look like in a language like Gherkin, here is one common scenario:

Scenario: Successful User Registration
Given a new user is on the registration page

2. When

The second phase of the test covers the action or event you’re testing—what happens after all the “Given” criteria are in place.

To write this phase of the criteria, clearly and explicitly state the action being performed. Be sure to write the language of the test with the interaction or event that triggers the behavior.

Here is what the “When” criteria might look like when added to the given-when-then Gherkin code we’ve been using:

Scenario: Successful User Registration
Given a new user is on the registration page
When the user submits valid registration information

In this particular scenario, other parts of the application will also check to make sure the registration information—such as the user’s email address, name, date of birth, and other data—is valid on the form. If it’s not valid, the test will not go forward.

3. Then

The final phase of the given-when-then acceptance criteria covers the results or consequences of the test scenario. Think of it as the verification step where you check to make sure the action in the “When” section had the outcome you were looking for.

When writing the “Then” criteria for the test, be sure to include the expected outcome or behavior you were looking for with clear, explicit terms. Your description should also stay focused on the observable result of the action.

In the sample Gherkin code we’ve been using, here is the example of the final product with the directions the program needs to follow in the “Then” scenario:

Scenario: Successful User Registration
Given a new user is on the registration page
When the user submits valid registration information
Then the user should receive a confirmation email
And the user should be redirected to the login page

Using DesignWise for Gherkin Given-When-Then Tests

DesignWise is a testing optimization tool from Ranorex that allows users to integrate automated acceptance tests in Gherkin syntax and use the parameters from these tests on future projects they’ve done previously.

This standalone testing tool allows developers to write high-quality, automated tests within the given-when-then acceptance criteria in Gherkin, along with other BDD tests. This allows your developers and testers to run fewer tests while uncovering more potential bugs in the software’s UI, saving the company money on labor costs without sacrificing quality.

DesignWise is built to automatically run given-when-tests on your software and other applications. Once the system knows the criteria it’s supposed to meet, it can do so automatically—saving your team even more time.

Additional DesignWise Features

In addition to testing the functionality of your given-when-then criteria on a specific test, DesignWise can also run other automated tests to help you optimize, debug, and polish your software before its release. Some of the other testing tools it offers to cover high-risk scenarios include:

  • Functional testing
  • Regression testing
  • Black box testing
  • Cross-browser testing
  • Data-driven testing
  • Keyword-driven testing
  • Selenium
  • And more

This battery of tests allows users to automate the testing process with Gherkin, making the product easier to use and allowing developers to release their product to clients and the public even sooner.

Executive Tests with Ranroex

Ranorex’s suite of GUI and intelligent test design tools allows your team to detect bugs before they become potentially serious problems that delay product launch or hinder your customers’ ability to use it.

Whether in the development phase, during QA testing, or after CI/CD, Ranorex Studio, DesignWise, and Selocity allow your team to streamline your product quickly and easily.

Start a Free Trial

Ready to streamline your QA processes and deliver your product at or under budget? Start a free trial of DesignWise today and see how easy the testing process can truly be.

Related Posts:

7 Types Of Penetration Testing

7 Types Of Penetration Testing

Penetration testing, also known as a pen test, pentest, and type of application program interface testing (API testing), is a kind of simulated attack on a computer system. The goal of this kind of cybersecurity testing is to evaluate the overall security level of the...

What Is Code Profiling and How to Choose the Right Tool?

What Is Code Profiling and How to Choose the Right Tool?

Developers and programmers have long been resorting to tools, techniques, and methods to help them better create software applications, with one of them being code profiling. But what is code profiling, and how can it enhance your IT programming projects? Our...