Here’s where the Serenity BDD framework could close the gap. When utilized properly, technical teams and non-technical stakeholders can be on the same page about what is going on in the software project.

In this tutorial, you can get answers to questions like:

— What is Serenity BDD?

— Why should teams use Serenity BDD?

— How to solve challenges with best practices and tips?

… as well as find more useful information on BDD tools

Serenity Framework Overview

Serenity is an open-source testing framework designed to automate the testing of Java-based applications. With this systematic method, testing, QA, and development teams can create automated tests and check the quality and dependability of the produced code.

Furthermore, combining the principles of Behavior-Driven Development and the Screenplay pattern helps technical specialists write readable and scalable tests.

Let’s reveal some key features of the Serenity framework:

• Feature Files. Written in Gherkin syntax, these files provide information in a human-readable way so that everyone can understand how the app should work.
• Scenarios. Scenarios embedded into the files represent specific behavior examples, structured into Given-When-Then steps.
• Step Definitions. Step definitions provide the connection between feature files in the Given-When-Then syntax.
• Actors. They are users or personas that interact with the system and perform by applying their knowledge and skills needed for various actions.
• Tasks & Actions. Tasks define the actions that should be performed by users – scrolling through a page, clicking buttons, or submitting a form. With the Screenplay pattern, tasks help create more understandable test code.
• Questions & Assertions. They help you compare the actual app state to your expected results. When using questions, you can validate the application behavior during test execution quickly.
• Test Execution. With a test runner included, Serenity allows teams to execute defined scenarios and produce detailed reports. Throughout test execution, it logs steps, takes screenshots, and tracks performance metrics.
• Reporting. Based on test reports, teams can analyze outcomes, identify failures, and monitor testing progress in order to make changes and produce better testing results.
• Integrations with Selenium WebDriver and Cucumber Libraries. When integrating with mentioned libraries, you get the necessary browser control and interaction features for testing web applications.
• Test Data Management. With Serenity, you get tools for managing test data, creating data sets, and handling dependencies as well as using different data sets each run.

Serenity BDD: Definition, Key Features & Architecture

Previously known as Thucydides, BDD Serenity is used as an open-source testing framework and is designed to simplify the way of writing automated acceptance tests and regression tests. With its help, developers and testers can create complex tests and apply well-illustrated test reporting and living Serenity BDD documentation options.

With the Gherkin language, an ordinary language parser, when complex testing information might be scripted almost in English. Also, it is important to mention that Serenity BDD not only reports on what requirements were tested, but how they were tested. It truly documents what your application does with optional screenshots that present step-by-step details of how a test played out.

Key features of Serenity BDD are presented below:

• BDD principle. With a specific Given-When-Then format, it helps create test scenarios written in human-readable statements for better understanding.
• Test Automation. Thanks to this feature, you can carry out automation for web, mobile, and API tests.
• Report Generation. With Serenity BDD, you can visualize rich and informative reports based on test results and identify areas that need to be improved.
• Parallel Test Execution. When running multiple tests in parallel, it generates unique reports for each test and provides a clear overview.
• TCMS Integration. This feature allows you to integrate it with popular test management tools (e.g. testomat.io).
• Custom Reporting. With this feature, you can choose how to format and aggregate test results by customizing reports.

What Are Key Components of Serenity BDD Architecture?

• Page Objects. They include all available actions within the entire application that are performed with certain page elements.
• Steps. A place where web elements and methods are declared and can be used for further manipulations.
• Requirements. They specify what the app must do and include acceptance criteria to determine whether the app meets the required functionality.
• Tests. Designed to exercise the app functionality, they are specific scenarios that check if the app meets the acceptance criteria.
• Reports. All the results of the runs can be found here and analyzed.

What is the main difference between Serenity BDD and Cucumber?

They are both from the Behavior-Driven Development (BDD) ecosystem and support Gherkin syntax and Scenario outlines — yet they serve different roles and provide unique features. Cucumber is just a BDD execution tool for Gherkin-written BDD scenarios, while Serenity BDD, which can leverage Cucumber for scenario execution, extends this with test automation, out-of-the-box reporting, and integration capabilities.

BDD Scenario Execution	Supports Gherkin syntax	Primary function
Detailed Reporting	Advanced HTML reports with screenshots & execution details	No built-in reporting, so needs third-party tools
Test Reusability	Allows modular test reusing	Requires manual structuring
Feature File Management	Yes, organizes feature files	No built-in management
Parallel Test Execution	Yes	Requires extra setup
Step-by-Step Execution Tracking	Yes	No
Defect Analysis, Debugging	Yes, it provides detailed failure insights	Requires third-party tools
Jira Integration	Possible	Possible also with third-party tools
Integration with CI\CD Tools	Works with Jenkins, GitHub Actions, etc.	Yes, but manual setup required

Why QA teams need BDD framework

BDD framework can bridge the gap between software engineers, QAs, and business stakeholders. With BDD, QA teams can:

→ Talk with technical teams and business stakeholders about user needs and software requirements in a business readable language (Gherkin) created especially for describing users’ behaviors.

→ Create user stories and scenarios to define acceptance criteria for specific software features that are understandable to all stakeholders.

→ Test business scenarios from the start and identify bugs early in the development cycle.

→ Turn business requirements into a clear format for the tests that should be executed to minimize or avoid bugs and errors.

Why use Serenity BDD in automated testing

The BDD approach fits well with test automation because the scenarios created in business-written English can be put in a feature file and used for test automation. The technical people on the team can implement each scenario in the tech specification files and take full advantage of it:

• With its clear reporting, teams can collaborate and understand the overall testing progress more easily.
• When applying plain Gherkin language, teams can describe test scenarios so that both technical and non-technical teams can understand the expected/actual outcome of automated acceptance testing.
• Serenity BDD as a powerful automation framework helps streamline the test automation process, saving time and effort for the teams.
• It generates detailed reports from the box that provide insights into automated test execution, failures, and performance metrics.
• With the App’s growth, Serenity’s modular approach makes it easier to maintain and update automated test cases.
• Its ability to create complex test scenarios guarantees comprehensive automation test coverage.

Linking User Stories With Tests Through Serenity

In Agile projects, teams mainly register requirements through User Stories. They represent a description of a business need in requirement through a user perspective while written in BDD acceptance criteria to check if those business needs or requirements are met. The basic format of a User Story is simple:

Who: As a [user type]
What: I want [action to perform]
Why: So that [the desired outcome]

In Serenity BDD, you can link User Stories with test cases. It can be done through annotations or tags in order to associate specific test cases with particular user stories.

Also, you can use test case management systems like testomat.io In the mentioned TCMS, you can link your requirements to test cases within the system and manage them there.

Another variant is to customize Serenity’s reports to display information about linked user stories or configure the Serenity reports by including links to your test management or other relevant documentation.

How to Get Started with Serenity BDD Framework – Tutorial

Requirements and Steps

When working with Serenity BDD, you need to take into account that requirements are organized into three levels – capabilities, features, and stories. This means that each capability consists of many features, and features are explained in detail by user stories.

Also, Serenity BDD framework applies the following concepts:

• Story represents a small workflow unit business functionality.
• Scenarios display how the system functions.
• Steps are used to represent actual behavior using classic Given-When-Then keywords.

In a Gherkin file, an app feature needs to be described for testing. The file should contain the Feature keyword at the very beginning with the feature name going after it on the same line. An optional description may cover a few lines below.

Here is a simple Gherkin document example:

Feature: User Authentication

Scenario: Logging in with the correct credentials
  Given the user has an existing account
    And the user is on the login page
   When the user enters a valid username and password 
   Then the user is redirected to their dashboard

Scenario: Logging in with the incorrect password 
  Given the user has an existing account
    And the user is on the login page
   When the user enters a valid username and an incorrect password 
   Then the user sees an error message

Setting up Serenity BDD and Java Configuration

Before getting started with Serenity BDD example, you need to install:

• JDK 1.8 or higher should be fine (you can choose Linux, Mac or Windows)
• Java Development Environment such as IntelliJ or Eclipse
• Maven/Gradle build tools, we used Homebrew and Maven now for this purpose
• Also, you need a basic understanding of Git.

First UI Test with Serenity BDD

Now we will be using the Serenity BDD with JUnit template project to get a simple project up and running quickly as recommended on the GitHub repository page.

1. 1. Download the Serenity JUnit Screenplay Starter project, unzip it
   2. Enter into it cd and execute framework with the next command:

      mvn clean verify

   3. After the tests have been completed, you can check the generated test report in the target/site/serenity directory. If you open the index.html file in your browser, you can view the test results.

In the build-in Serenity test report, you can find out this:

• The passed/failed/ignored/skipped tests
• Duration of tests.
• Images and videos of test runs.
• Comprehensive details about the test data.

Testing with Serenity BDD

As you can see Serenity BDD allows writing tests in a Given-When-Then format, translating user actions into the GWT format can you reflect the Steps. As tests go along with @Steps, you need to create a scenarious that tells a simple user story carried out using certain Steps.

src
├── test
│   ├── java
│   │   │   ├── pages
│   │   │   │   └── GoogleSearchPage.java
│   │   │   ├── steps
│   │   │   │   └── GoogleSearchSteps.java
│   │   │   ├── steps
│   │   │   │   └── GoogleSearchStepDefinitions.java
│   ├── resources
│   │   ├── features
│   │   │   └── GoogleSearch.feature

Let’s create one more test, we will search for a request by entering a keyword on the Google page:

File GoogleSearch.feature

Feature: Google Search
  As a user, I want to search on Google
  so that I can find relevant information.

  Scenario: Search for a keyword on Google
    Given I am on the Google search page
    When I search for "Serenity BDD"
    Then I should see results related to "Serenity BDD"

Step Definition File GoogleSearchStepDefinitions.java

package com.example.steps;

import io.cucumber.java.en.Given;
import io.cucumber.java.en.When;
import io.cucumber.java.en.Then;
import net.thucydides.core.annotations.Steps;
import com.example.steps.serenity.GoogleSearchSteps;

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.containsString;

public class GoogleSearchStepDefinitions {

    @Steps
    GoogleSearchSteps googleSearchSteps;

    @Given("I am on the Google search page")
    public void iAmOnTheGoogleSearchPage() {
        googleSearchSteps.openGoogleHomePage();
    }

    @When("I search for {string}")
    public void iSearchFor(String keyword) {
        googleSearchSteps.searchForKeyword(keyword);
    }

    @Then("I should see results related to {string}")
    public void iShouldSeeResultsRelatedTo(String keyword) {
        assertThat(googleSearchSteps.getFirstResultText(), containsString(keyword));
    }
}

Steps Class GoogleSearchSteps.java

package com.example.steps.serenity;

import com.example.pages.GoogleSearchPage;
import net.thucydides.core.annotations.Step;

public class GoogleSearchSteps {

    GoogleSearchPage googleSearchPage;

    @Step
    public void openGoogleHomePage() {
        googleSearchPage.open();
    }

    @Step
    public void searchForKeyword(String keyword) {
        googleSearchPage.enterSearchKeyword(keyword);
        googleSearchPage.submitSearch();
    }

    @Step
    public String getFirstResultText() {
        return googleSearchPage.getFirstResultText();
    }
}

Page Object Class GoogleSearchPage.java

package com.example.pages;

import net.serenitybdd.core.pages.PageObject;
import net.serenitybdd.core.annotations.DefaultUrl;
import org.openqa.selenium.By;

@DefaultUrl("https://www.google.com")
public class GoogleSearchPage extends PageObject {

    private By searchField = By.name("q");
    private By firstResult = By.cssSelector("h3");

    public void enterSearchKeyword(String keyword) {
        $(searchField).type(keyword);
    }

    public void submitSearch() {
        $(searchField).submit();
    }

    public String getFirstResultText() {
        return $(firstResult).getText();
    }
}

To run your Serenity BDD tests, you need to execute the following command in the root directory of your project again

mvn clean verify

Customize Serenity Test Results Report With Testomat.Io

When tests have been executed, you can download your Serenity results report in .XML format, also generate a report and synchronize your automation testing with manual testing. It provides technical and non-technical teams with more detailed test analytics based on retrieved test results. With its help, you can select widgets’ relevance and organize them in the preferred order to conduct data analytics effectively. With the intent of meeting user requirements, you can select analytics widgets for displaying – test coverage, automation rates, defect distribution, or execution timelines. It will let teams apply the option to derive required information and reach their testing goals more easily.

When using testomat.io TCMS, you can group test results into Assignees, Labels, Priorities, Custom Statuses to grasp the main points of testing efforts. Also, you can display test outcomes organized by test suites to understand their quality.

To do this, first, create a new project in the test management system and make an import as it looks like in the next image:

Challenges, Tips, and Tricks in Serenity BDD

When working with any framework, teams may recognize the limitations and face some challenges:

• It is hard to work on the project if there is a misunderstanding between the person who produces the automation code and the person who writes the feature files.
• There is a need to install and update libraries and add-ons for mobile testing as it only supports web and API testing.
• Your teams require strong technical knowledge to integrate additional tools into the development workflow and adapt in accordance with their needs.
• It is inefficient for a short project as teams need a lot of time and effort to create scenarios and maintain the files.

To solve these problems, you need to follow tips and tricks and then get the most out of Serenity BDD:

• You need to remember that each feature should focus on a single user story or functionality.
• You need to create names for tests that describe what the test case does.
• You need to write clear Gherkin scenarios and keep your steps organized.
• You can use the @Step annotation to mark individual test steps and the @WithTag– to categorize tests.
• You need to regularly review and update test reports to make sure they are accurate.

Bottom Line

With Serenity BDD framework, programmers, testers, and business stakeholders are on the same page on the features that should be developed, without bridging the gap between techies and non-techies.

When people have clarity about what feature is going to be developed and have enough understanding of why it should be done, there is a possibility to deliver a software product that meets or exceeds users’ expectations.

Drop us a line, if you need more information about Serenity BDD and testomat.io integration.

The post Introduction to Serenity BDD Framework – Tutorial appeared first on testomat.io.

What is a Behavior?

Behavior is the action and interaction of an individual according to the environment. Simple, it is scenarios. An application or a feature exhibits some scenarios and due to this calls behavioral responses => behaviorlicity.

Examples:

• logging into a web page
• follow the links for navigation
• submitting forms
• receiving expected errors

Different people have different behavior. Sometimes responses depend on particular conditions when doing actions within our examples.

How Different scenarios may lead to the same result. One more example

If you are reading this article, you have found it one of two ways on our site:

1. You have found it using the search field, typing here interesting keywords.
2. You have found articles using the pagination option on the Blog page.

This approach defines various ways to develop a feature based on appropriate behavior. That is the essence of BDD Agile – adapting user behaviors into flexible development patterns.

What is BDD?

Behavior­ Driven Development (BDD) is an Agile software development methodology that encourages cooperation between software developers, business stakeholders, QA team, and different roles involved in the project. The main concept is to combine an engineering component with a business goal to succeed, a principle that’s fundamental in BDD in Agile development.

BDD is a test-centred software development approach. Mainly tests are based on desired systems behavior, written in terms of business value. BDD focuses on Test First Development conception. It means a Shift Left Approach because we try to start testing before the development phase.

Behaviour scenarios are the cornerstone of Behavior­ Driven Development

• Scenarios focus on the expected behaviors of the product
• Each scenario focuses on one specific feature
• Scenarios can be run manually (Manual Testing) or automatically (Automation Testing)

User Story

In the BDD Agile development process, requirements should be converted into user stories. Quality Assurance Engineers strive to use a shorter user story format. Business analysts, product owner, and software development team collaborate to ensure a shared understanding of the problem. It’s therefore imperative to adopt a BDD Agile methodology to get all the requirements right from the outset. Mostly, one user story equals one product functionality, a crucial aspect when applying BDD Agile frameworks.

Gherkin BDD

Gherkin is one of the most popular languages describing systems behavior. It represents behaviors as scenarios.

Features are the highest-level description of the desired product functionality.
Feature File is a file that contains one feature. Also it includes information for each feature scenario.

Scenarios answers on ques: Would be? What happens? Why? And what should the application do according to the user story?
Behavioral specifications are formalized expected outcomes, explaining what it they actually does.

GivenThe initial condition. If there are several initial conditions, then each new condition is added from a new line using the And keywordButAnother outcome

The key goal is to implement in live that not only a Quality Assurance Engineers’ team but anybody from team members, like BA, PO, DEV can write BDD scenarios as well since they are just English phrases.

Key Behavior Driven Development Benefits

• The major benefits of BDD are better team collaboration and shared understanding among stakeholders.
• Customer-oriented, consequently BDD helps to reach a wider user-ends audience, focusing on the business’s needs and user experience. This makes the product more successful.
• With the help of automation tools, Gherkin BDD scenarios can easily be turned into automated test cases.
• Code reusability, you can assign variables.
• Speed up the development process and delivery of the products.
• More reliable outcomes of testing.
• Reducing rework and ambiguity during development.

4 Reasons Why is BDD an Excellent Pair to Agile & Scrum?

1. BDD is flexible, changes made easy
2. BDD is a refinement of the Agile process, not an overhaul
3. It formalizes Acceptance Criteria and Test Coverage
4. BDD is like a third layer between business stakeholders and test automation.

Testomat.io supported BDD

• Advanced BDD, Gherkin implementation
• Auto formatting and enhancement in BDD Editor
• Autogenerated living BDD documentation
• Autoconverting classical test cases to BDD test cases

Technology Stack Support:

BDD frameworks and tools support multiple languages like Java, JavaScript, Ruby, and can be integrated with Visual Studio.

BDD plays a crucial role in the software development lifecycle by promoting clarity, reducing compatibility issues, and ensuring product quality at the right time using best practices promoted by organizations like Agile Alliance.

…more details about BDD support

The post BDD & Agile Methodologies in Quality Assurance appeared first on testomat.io.

You are right, Three Amigos are friends, not enemies in any case. Yeah, this is a partnership comparison.

In the Software Development Process mean — the three primary roles of colleagues who are involved in software development process.

Business – represented by the role of Business Analyst (BA) or/and Product Owner (PO). The business role clears what problem the whole team needs to solve. They provide business requirements for the solution.

• Business Analyst collects the feedback and reviews comments from the other team members. Find out missing information and remove the ambiguous information from the Requirement if any.
• Product Owner defines Acceptance Criteria. Next review the test cases and whether the test cases meet these Acceptance Criteria. Make sure what is being built matches business stakeholder expectations.

Together BA and PO see that everyone in the team has the same understanding of each User Story and Requirements Specification.

Typically, the business role is non-technical.

Development – represented by Software Developer (Dev). Decides how might build a solution to solve a problem set to the team.

• For Devs are important to have clarity on the scope of the tasks announced by PO.
• Also determination of how the code must be written. It’s often likely that certain detail will influence the development process.

The development role must be technical, and highly professional.

Testing – Quality Assurance role (QA), verifies that the delivered software product works correctly.

• Quality Assurance team elaborates on test artifacts such as test cases, check lists, test plan etc. These are their key duties.
• QA Engineer looks at context, tries to find defects and always helps predict what could happen.

The tester‘s role must be somewhat technical.

The Development team members might share their knowledge of technical restrictions which could lead to testing constraints.

Conclusion:

 3 Amigos — method of communication “being on the same page” for a delivery quality product.

The key to this is understanding that excellent products don’t stem from a wide group of experts or one individual. But from close collaboration and good organization across different specialists. The impact of team voice, have you ever heard about?

Deep into the link, there is an interesting example of how Three Amigos play roles: Request, Suggest, To protest.

Sometimes it is possible to expand the “Amigos group” to 4-5 amigos where necessary. A good example of this would be expanding with a Designer, Digital Marketing Manager. They are often a necessary 4th, 5th Amigos. They usually come to about 50% of “Three Amigos” meetings.

Why number 3-4-5 people only? Because such quantity delegated team members will work more quickly than 13 people.

They are a much more efficient use of time than traditional grooming sessions, which run the risk of extending for hours by involving a large number of participants (perhaps even the entire team).

Like Agile and Scrum, the flexibility and speed in “Three Amigos” are primary.

Also quite difficult to determine “3 Amigos” whether it is a framework, approach, method, strategy or principle. There are a lot of mentions on the internet. “Three amigos” also known as Story Kick-Off huddles or the Triad.

Nowadays, “Three Amigos” is used not only in Software Development. Mentioned in Digital Marketing, Design, Creative, Engineering as well. Anywhere there are the needs something to delivery clients.

3 Amigos Agile Session

The “Three Amigos” meeting is a major component of the testing process. It is a way of interacting together. On “3 Amigos” meetings workshops, brainstorms and especially mapping takes place. It helps think up cool test scenarios and develop cool user stories.

Mapping examples are easy to turn into Gherkin scenarios. It is an advantage.

“Three Amigos” sessions are usually conducted in the previous development Sprint. But, not before because the basic details may change.

It is a shift left practice because we try the Test First Development approach. To find out more detail, please follow the next article on this testing blog Shift Left & Shift Right approaches in Software Testing 

The recommended time of the Agile sprint planning session is 35 – 60 minutes. If it takes more time, the story is way too big and needs to be broken down into a few stories.

Three Amigos applying BDD

In order to build a really shared understanding, there is a perception to formalize requirements suitable for automation in a manner accessible to both technical and non-technical project members. This is where Behavior Driven Development with Gherkin Syntax comes in.

In the post Behavior­ Driven Development & Agile Methodologies in Quality Assurance we talk about how according to the Agile BDD development process, BA or QA should convert requirements into user stories. They strive to use a more short user story format. Mostly one user story equals one product functionality.

Next 3 Amigos during the “Three Amigos meeting” take this user story and think of all possible test scenarios of how an application might respond.

Let’s start studying Behaviour Driven Development from a simple example!

To illustrate let’s take a simple login form example with separate fields such as username, password and a submit button. Brainstorming might produce the scope like this.

Participants wrote it on paper or on board:

• Scenario 1: User enters correct details and clicks submit
• Scenario 2: User enters the correct username and incorrect password and then clicks submit
• Scenario 3: User enters incorrect username and correct password and then clicks submit
• Scenario 4: User clicks submit with empty username and password fields

This list above is not necessarily exhaustive but illustrates the concept of scenarios and their usefulness in terms of thinking about the login story we are implementing.

The point here is to check how the software should behave in each scenario. This is Behaviour Driven Development in action.

Once the team has done an initial brainstorming in terms of scenarios, they need to translate these scenarios into Gherkin Language.

Gherkin Syntax is basically a format for expressing software behaviour using a convention known as “GIVEN, WHEN, THEN”. We use this convention when we describe our scenarios. In abstract terms, it looks something like this…

  Given some initial state
   When an action is performed
   Then this happens

Let’s try this out on one of our bdd test examples from earlier:

Scenario: User enters correct details and clicks submit
  Given I am on the login form
   When I submit my correct username and password
   Then I am logged in successfully
    And I am taken to the homepage

That’s all, we hope, you understand the implementation

Gherkin features usually are written by QA engineers, but anybody from the team can do it as well.

Tips to get started BDD
and write documentation on Gherkin

• Do not make the “Three Amigos” meeting a formality. We would like to emphasize, the session must be efficient. Don`t waste your time!
• Don’t artificially limit the meetings to three and only three people. Depending on the feature, you might find that other teammates have valuable input like expertise.
• Three Amigos sessions are more productive if all participants of “Three Amigo sessions” have made home tasks beforehand. Read some materials, think about details for stories etc.
• A good practice is to review features that were implemented in the product before.
• Should make decomposition. If you’re moving into the realm of several AND statements after a THEN statement it’s a “red button” that you were flesh out several scenarios into one. Would be a good thing to break down the user story into further scenarios.
• Add and amend new elements in the feature file as needed. You won’t always think of every scenario upfront. That’s okay. Just remember to keep the team in the loop!
• Without blind fanaticism! It makes no sense to implement BDD because this is a trend. The same large number of details in the Feature file or duplicated test scenarios are too much.

Meet a perfect tool to implement the “Three Amigos” principle:

• Gherkin scenarios could be imported into the Test Management System.
• You can run both manual scenarios, automated scenarios and receive informative reporting.
• You can check failed, passed tests, test coverage, metrics based on this report in real-time, filter, tags, compare tests and many more…
• Test results will be visible to teammates. 
• Test management solution testomat.io provides comprehensive test case management to make decisions for all stakeholders.

Watch the DEMO conducted by our CEO Mykhailo Poliarush

The post What are Three amigos in Agile? appeared first on testomat.io.