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.
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:
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.
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:
There are endless possibilities for using given-when-then tests, particularly in scenarios where human users are interacting with the system or app.
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.
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.
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
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.
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
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.
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:
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.
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.
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.
There are more and more Android testing tools available for mobile app developers. These are our favorites for performance, accessibility, and security.
Regression testing and retesting are essential methodologies testers employ to ensure software quality. If you’re new to both or aren’t sure when to use which technique, this article should help. We’ll discuss the importance of regression testing in software testing. ...
DevOps test automation enables teams to work faster and create better products. These best practices and tools make it easier to implement test automation.
