Using BDD and Agile Methodologies in Automated Testing: A Breakdown

Over the course of this blog post, we are going to take a look at Behaviour Driven Development (BDD). We will also look at the continuous integration & testing pipeline and the role that automated testing takes as a part of it. We will start with an overview of BDD and Agile. For a more demo focused blog post click here to read about creating BDD tests using Cucumber and Appium. That features a full step-by-step guide on the creation of automation tests using Cucumber and Appium.

The most common way to carry out BDD and Agile is with the Cucumber framework and its built-in specification language known as Gherkin. For the purposes of this post when we discuss and demonstrate mobile automation testing with this Framework we use Appium.

The truth is that it is not 100% necessary to use Appium in your BDD approach to automated testing, but we have found that Cucumber and Appium complement each other and so the power of that combination is on full display.

Before we get to that, however, let’s take a look at the historical perspective of different software development methodologies like Waterfall, Iterative Waterfall & Agile.

The Waterfall Method of Development

Software development processes traditionally have modeled the top-down approach. This is when stakeholders and analysts pull information from end-users and interpret it. The result is that these groups, working in concert, produce sets of functional and non-functional software requirements. Developers then take the requirements to study them and then convert them into team specifications.

With their specifications in place development teams then complete building their applications. Next is the testing phase.

When we use the word testing we refer to the testing of the system itself in addition to quality control and quality assurance. Applications are verified against the specifications of its design and then the acceptance criteria are used to validate the application. At this stage, QA teams work with stakeholders and end-users to make sure that applications are verified against the criteria that were laid out in the initial phases of application development. QAs’ next task is to work with technical teams to ensure that the application follows the expected requirements & specifications. The next step for QA is to communicate with stakeholders to determine if the application’s needs and goals will be met.

The next phase includes the implementation of the application and a round of user-driven change requests. The implementation of requests follows the workflow below.

Some details to consider.

• Analysis and Design – This phase is defined from the beginning before any programming is done.
• User Involvement – It only takes place at the start and completion of the development lifecycle.
• Making Changes – Given the linear and non-iterative nature of the workflow going back to make changes is an unwieldy part of the process.
• Testing – Aside from the development team carrying out unit testing, an application only undergoes a full shakedown after completion.

The Waterfall Method suits certain types of projects better.

• Requirements remaining static over the life of the project.
• Business needs and problems are understood at the highest level making the requirements easily assessed and anticipated.

Additionally

• Due to the open-loop system of the Waterfall Method, there is no feedback between phases.
• Software projects are delivered in one monolithic application file.

The Waterfall Method does have significant limitations. The foremost of these limitations is that this is not the most suitable model for the development of larger more complex projects. We will see in the next section.

The Iterative Waterfall Method

This method encourages teams to break down software application delivery into smaller and more manageable builds. Each software project divides into logical partitions instead of a homogeneous build. That makes software delivery come in a per build scenario.

Iteration is built into each build process. The closed-loop like process allows you to end each phase with feedback.

Here are two scenarios as an example.

1. Post testing if you find bugs that need correcting you can return to the development phase and edit the code base accordingly.
2. If you have a release that works but does not meet business goals then the specifications need to be changed. In this case, you will again return to the design phase and make the necessary design changes.

For these reasons, the Iterative Waterfall Method allows for a more adaptive and flexible approach.

Agile Methodology & Behaviour Driven Development (BDD)

Before we delve into the concept of Behaviour Driven Development (BDD) and where it fits in Agile methodology we have to define Agile.

Agile development methodology developed as a need to evolve out of the waterfall-based methods. The concept was to create a development process that was leaner, more flexible, and nimble.

Once a software’s requirements are set, they will be communicated via epics and short user stories.

Sprints, which are periods of a week up to 15 days, are for assigning user stories then testing and reviewing them. When we say review we are talking about an active process that includes all teams and ensures that all business goals are met.

The process starts with multiple sprints that focus on completing the tasks in the product backlog, from Epics down to user stories.

One of the main benefits of Agile methodology is that developers establish each software development phase into a single sprint. The immediate result of this is to bring about quicker and more reliable outcomes. If some of the functionality does not meet the set goals then the end-users will have a chance to validate it in real-time which will allow developers to make any necessary changes earlier in the process.

The agile development process uses a shorter user story format. The structure is to outline the type of user, the action that they will execute, and the end goal that this action achieves.

Here are two examples:

1. Store Owners – should be able to update stock when items come in – so that the store’s stock is correctly tabulated.
2. Ordinary Users – should be able to upload a profile picture to a personal account – so that they have a profile picture.

These types of user stories are both simple to understand and just as easy to use when communicating with stakeholders, QA, engineers, testers, DevOps engineers, and end-users.

If we want to take the idea of user stories and scenarios to the next level this is where BDD and Agile by extension come in.

Here are a few examples:

1. Development teams turn user stories into testable acceptance criteria.
2. Similar to test-driven development (TDD) the focus moves to expected outcomes and behavior. This reduces the chances of errors since technical teams will no longer be making assumptions about expected outcomes.
3. Agile development depends upon inter-team communication. One of the most common ways of sharing business goals and functionality across a team is by executing tests that can also double as acceptance criteria.

Practical applications of BDD

The idea of BDD is to move away from a process in which business stakeholders and team members constantly reinterpret and rewrite their requirements. Rather the nature of BDD is to use an executable specification, and an expected outcome to create a repository that can be shared amongst any company member involved in the development process.

The practice of BDD and Agile focuses on collaboration and communication. The desired outcome of BDD is to bring together sometimes disparate groups such as customers, developers, and QA.

Here is a closer look at the diagram below.

Let’s break down the processes in greater detail.

Discover

Traditionally business analysts interacting with customers create high-level requirement documents using waterfall methods.

In BDD however developers, UX/UI designers, and QA team members, carry out initial interactions with clients end-users and stakeholders. Their focus is on getting information from users, whether by asking questions or making suggestions. They then lay out development requirements by using examples and calculating different scenarios.

The interactions between these groups will produce requirements. These take the form of business rules, acceptance criteria, and use cases. We recommend that when writing acceptance criteria you do it using the Given, When, Then Agile format. More on that in a bit.

Formulate

One of the most important parts of the BDD process, formulation ties the Discovery stage into the rest of the SDLC.

During the Discovery stage is when we create the repository using the Given, When, Then format. With this repository, anyone who is involved in the software development process can share information. The benefit of such a repository is that instead of trying to define business requirements on an individual or team specific level you now have what is known as a single source of truth.

Defining BDD Terms

It is important to clarify the terms of behavioral driven development which we will do below.

• Features – The highest-level description of desired product functionality. For example, withdrawing cash from an ATM.
• Scenarios – Behavioral specifications using formal steps and examples. An example of this would be what happens if a person enters their ATM Pincode incorrectly a certain number of times. It is still part of the cash withdrawal feature.
• Executable Specifications – These are scenarios that use the Given, When, Then agile syntax. Using our cash withdrawal example an executable specification would look something like this.
  • Given: A valid card was entered into the ATM.
  • When: Three attempts to enter the ATM PIN failed.
  • Then: The card will be blocked.

Below is a table showing the breakdown from Feature to executable specification.

Feature Files

Another BDD concept that is important to explain, feature files are, simply put, files that contain a single feature. Feature files include all of the information in the table above, the feature itself and all of the scenarios and Given, Then, When syntaxes. Feature files also include the implementation information for each feature scenario.

Automated Acceptance tests and Cucumber

Once you create your feature files you need to convert them into acceptance tests. Each test will start as a stub that develops will write code into until the desired feature, and scenario functions as desired.

The open-source behavioral driven testing and collaboration tool Cucumber is the perfect tool for converting features into acceptance tests. For a step-by-step guide as to how this process works click here. BDD and Agile are complementary methodologies that combine to help you create an automation testing project that is both robust, efficient and simple to communicate.

 

Jonny Steiner – Content Manager