BDD 101: A Comprehensive Guide to

Behavior-Driven Development
BDD 101: A Comprehensive Guide to Behavior-Driven Development | 1
Content

3 | What is BDD?

6 | Why Use Behavior-Driven Development?

9 | Deliberate Discovery

11 | Example Mapping

14 | Building Executable Tests

17 | Continuous Integration

19 | Living Documentation

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 2

What is BDD? Behavior-driven development, or BDD, helps business
and technical teams better communicate to avoid
business analysts, domain experts, users, developers,
UX designers, testers, ops engineers, and others
waste. Using examples written in a domain-specific meet to come up with concrete examples of user
language, or DSL, BDD enables non-technical stories and acceptance criteria. These examples
users to express software behavior and expected ultimately become the automated tests and living
outcomes. Technical users convert these examples documentation showing how the software behaves.
into executable specifications that help ensure that
Testing Phase
their code meets business objectives outlined in user
stories and acceptance criteria. The testing phase is where concrete examples
become software. Using a BDD framework and
Let’s take a look at how the BDD process works from
DSL, the natural language used to describe the
a high level to better understand the terminology
concrete examples in the deliberate discovery
and concepts before diving deeper into the benefits
phase is converted into an executable specification.
and implementation.
Developers write code to make these tests

The Two-Part Process pass, which eliminates rework caused by vague

requirements, slow feedback cycles, and other
Behavior-driven development is a two-part process
problems that commonly arise in non-BDD scenarios.
consisting of a deliberate discovery phase and a
testing phase. While most developers are familiar These BDD tests, focused on business-facing features,
with testing, from test-driven development, deliberate work in conjunction with TDD tests, which focus on
discovery is often a new and profound experience. lower level implementation details.

Deliberate Discovery Where It Fits in Development

The deliberate discovery phase brings together In the Agile development cycle, BDD processes
key stakeholders to have conversations and come usually take place when you’d normally come up with
up with concrete examples. Product owners, acceptance criteria. The process involves converting

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 3

 these acceptance criteria into concrete examples
and automated tests before putting them into the
development pipeline. Developers can then use the
automated tests to drive their development process
rather than trying to write code based on potentially
vague acceptance criteria.

BDD Frameworks & DSLs

There are many different behavior-driven
development automation frameworks and
domain- specific languages — and more are
appearing every day. While all BDD automation
frameworks follow the same principles, different
frameworks target different languages and
platforms. It’s important to consider both the
maturity of the BDD framework and its suitability
for your application when choosing between
frameworks for your organization.

BDD Automation Frameworks

| Cucumber: Cucumber is the original BDD

automation framework that began with Ruby
(a pioneer of TDD and BDD) and expanded into
other languages.

| SpecFlow: SpecFlow is “Cucumber for

.NET” and has become the most popular BDD

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 4

 automation framework for Microsoft’s .NET writing a single line of code. Automated tests are
framework. more of a byproduct of BDD than the purpose of

| Jasmine: Jasmine is the most popular BDD using the strategy. This means that you should
never be writing tests after writing code since the
automation framework for JavaScript applications,
tests aren’t driving the implementation in that case.
which are becoming increasingly popular in
startups. “ BDD introduces unnecessary complexity.”
| Easyb: Easyb is a BDD automation framework
Many developers already use test-driven
designed for Java, which is widely used across
development, which includes unit and integration
enterprise applications.
tests. These processes may already test user
| Behave: Behave is a BDD automation framework
interfaces with automation frameworks, like
designed for Python, which is commonly used
Selenium and Capybara. Some developers see
for data-driven and scientific applications.
business readable language as an unnecessary
| Behat: Behat is a BDD automation framework step that slows down the test suite. But the two are
designed for PHP 5.3+, which is used across completely different: BDD is about collaboration,
many legacy web applications. not testing automation.

Domain-Specific Languages (DSLs) “ BDD will take longer and delay projects.”
| Gherkin: Gherkin is by far the most popular
BDD introduces some extra meetings to ensure
DSL used by BDD automation frameworks.
that business and technical users are on the same
page, but these meetings don’t have to be very
Common Misconceptions
long and they can help your team be much more
“ BDD is just a testing framework.” productive over the long-term. These meetings

Behavior-driven development is not a testing also ensure that developers aren’t wasting their

technique, it’s a development strategy. It’s the time writing the wrong code. We will see in the next

process of thinking about the user experience and section how BDD can help deliver real benefits with
application programming interface, or API, before a minimal time commitment.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 5

Why Use How many times have you written acceptance
criteria that were not properly implemented by a
gies aren’t enough, and the case for using BDD
in your organization.

Behavior-Driven developer? How many times have you had a conver-

sion with a developer only to find that you both had Software Development is Hard
Development? different ideas after parting ways? Behavior-driven
development attempts to resolve these common
Less than one-third (30%) of software projects are
completed on time and on budget, according to the
challenges that arise during software development
Standish Group, and another one-fifth of projects
to make it a much smoother process for everyone
are canceled before completion. In other words,
involved in the organization.
only about half of software projects could actually
Let’s take a look at why software development is be considered “successful” in being both on time
so challenging, why traditional Agile methodolo- and on budget. There are many reasons that a

Software Project Outcomes – Source: Standish Group

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 6

project may go over the original time and budget, Where Agile Falls Short
but most problems boil down to communication.
The problem is that many software development
Software Project Outcomes – projects still come in late and over-budget — there’s

Source: Standish Group room for improvement in Agile development prac-

tices. Behavior-driven development isn’t designed to
The good news is that these outcomes have im- replace Agile development, but rather, improve upon
proved over time. In fact, the number of software
it by adding more tools. These tools are designed
projects delivered on time and on budget roughly
to eliminate waste in order to help reduce software
doubled between 1992 and 2017, while the number
development costs and expedite delivery timelines.
of projects that were canceled nearly halved. The
number of late projects that went over-budget, There are several areas where traditional Agile
however, remained roughly even over the period. development falls short:
These trends suggest that at least some new soft-
| Transient User Stories: User stories are focused
ware development techniques are working.
on user personas rather than business goals,
Agile development is perhaps the most influential and there’s little ownership in keeping them
software development methodology to surface up-to-date as the project evolves.
over the past decade. While “Agile” is a very broad
topic, the underlying goals are to bring business and | Ad-hoc Acceptance Criteria: Acceptance

technical teams closer together, release software in criteria — or rules that let managers know
more frequent cycles, and adapt to evolving custom- when a user story is functionally complete
er needs rather than sticking to a plan. The result — varies in quality. Often times, there’s not
is better software projects that more closely match enough information to create reliable tests for
expectations — resulting in fewer canceled projects. use in test-driven development.

©2007 Scott Adams, Inc.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 7

| Limited Discovery: There’s no common lan- Why You Should Use BDD
guage used between business and technical
teams. Without communicating well early on, Behavior-driven development takes vague user

it’s easy for developers to go down a different stories and acceptance criteria and transforms

path than business analysts imagined. them into a formal set of features and examples
that can be used to generate documentation,
| No Overarching Test: Test-driven development automate tests, and a living specification. In other
can ensure that the technical components of words, it gets everyone on the same page and
an application function as expected, but there’s ensures that there’s no miscommunication about
nothing that ties all of these components to- how the software behaves or what value it provides
gether to ensure that the software delivers real to the business.
business value.
At the very least, BDD is worth a try for almost any
BDD places a heavy emphasis on concrete ex- software project that requires input from stake-
amples to reduce ambiguity in user stories and holders and business people. It’s a great way to
acceptance criteria. In addition to getting on the dramatically cut down on the waste that’s typically
same page, these examples help uncover gaps that seen in software projects while ensuring that
nobody had considered before the functionality they’re delivered on time and on budget rather
is implemented. The feature files generated in the than becoming a statistic. The tests that you write
BDD process also serve as living documentation will also be a lot more understandable and mean-
for the application, showing how it’s supposed to ingful to everyone on the team.
function in a human-readable fashion.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 8

Deliberate Imagine a long-term software project that your
team recently completed. How long did it take from
Deliberate discovery involves having conversations
about these user stories and acceptance criteria

Discovery inception to delivery? Now, imagine that you could using concrete examples — and assuming igno-

do the same project over with everything kept the rance. For example, a user might ask: Will my reply

same — except your team would know everything appear in my Twitter feed for anyone to see? The
original user story and acceptance criteria may not
they learned during the original project. How long
have specified the answer to that question, but it
would the second project take to complete? The dif-
would clearly have a big impact on the architecture
ference between these two scenarios tells you that
of the overall application.
learning is the constraint in software development.
Rather than building software and putting it in front
Deliberate discovery is the first step in
of users to get feedback, the goal of deliberate
behavior-driven development: Learning as quickly
discovery is to try and learn as much as possible
as possible to remove the constraints on a project before writing any code to minimize waste and
to deliver on time and on budget. maximize productivity.

1. 2.
What is Deliberate Discovery? Who Should Be Involved?
Most software development teams are familiar with Deliberate discovery processes should involve as
user stories and acceptance criteria. For example, many different team members as you need to provide
a user story for Twitter may state that a user can insights into their specific areas of expertise. De-
reply to another user’s tweet. Acceptance criteria velopers may think of features on a very technical
help define the specifics of how that functionality level, whereas domain experts may have insights
will be implemented, such as the presence of a re- into what actual customers are looking for in terms
ply button on the first user’s profile. The problem is of functionality. All of these insights are critical

that these two tools — user stories and acceptance for reducing the uncertainty around features and

criteria — don’t explore any unknowns. ultimately meeting the software’s business goals.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 9

Some examples of team members to include are: | Commitment Column: What decisions were are the cornerstone of the deliberate discovery
made that solidified the problem? For example, process. The meetings should include any relevant
| Product owners
| Business analysts decisions about deadlines or writing the non-technical stakeholders, developers, and

| Domain experts wrong code. testers. The goal of these meetings is to generate

| Users real-world examples of how the software should

| Deliberate Discovery: Could you have discov-
| Developers work if it existed, which can be high-level examples
ered information earlier that would have led
| UX designers or actual executable specifications.
to a different decision? For example, talking to
| Testers
customers or releasing early. Discovery workshops should be kept short and
| Ops engineers
frequent — usually about 25 minutes per user
| Real Options Column: How could you have
story — and no longer than one hour in total. When
3. kept your options open longer? For example,
just starting out, it’s a good idea to start with quick
making a commitment later when more infor-
ad-hoc discovery workshops focused on the riskiest
Getting in the Right Mindset mation was available.
user stories, rather than trying to define concrete
Team exercises are a great way to get everyone After finishing the exercise, the team should discuss examples for all of the user stories at the onset.
in the right mindset for future deliberate discovery how adding the discovery process could help them Once the team has a feel for it, the process can be
meetings. Liz Keogh suggests one popular exercise identify and avoid the problems. The takeaway expanded to include all user stories.
that works best in small groups of three or four peo- should be that making the discovery early often pre-
ple in a dedicated meeting room with a whiteboard. vents the problem from happening in the first place.

The exercise starts by drawing four columns on a

4.
whiteboard:
Running a Discovery Workshop
| Story Column: Each person should tell a story
about a problem they have encountered and a Discovery Workshops — also known as Three
discovery they made to resolve the problem. Amigos Meetings or Specification Workshops —

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 10

Example Mapping The deliberate discovery process makes sense on
paper — bringing together domain experts and de-
1. User Story: These are the user stories that
were developed earlier in the deliberate dis-
velopers to discuss the best path forward — but we covery process and serve as the starting point
haven’t covered how to actually run these meetings. for discussion.

At the core, the most important outcomes of these 2. Rules: The acceptance criteria for the user
meetings are concrete examples that can be turned story that contain agreed-upon constraints
into executable specifications, and ultimately, about the scope of the story, and summarize
automated tests and living documentation for the the underlying examples.
software application.
3. Examples: These are the concrete examples

Example mapping is one of the most popular strate- covering each rule. There can be more than

gies to come up with these concrete examples one example per rule to cover different
potential use cases.
during deliberate discovery meetings. In addition to
coming up with examples, the process helps uncov- 4. Questions: These are unknowns that arise
er any unknowns or uncertain assumptions. when exploring the rules and examples or
assumptions that were made in the interest
How Example Mapping Works of moving forward.

Example mapping was developed by Matt Wynne Matt suggests using a pack of four-color index cards

after he noticed that many deliberate discovery and some pens to capture these different types

meetings were long, boring, and unstructured. His of insights as the conversation unfolds, and then

goal was to introduce a simple, low-tech method arranging these index cards in a map.

that could make these meetings short and produc- The low-tech approach is designed to eliminate any
tive. The example mapping process includes four distractions and keep the team focused on having a
components: meaningful conversation.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 11

Running a Session 2. Write each acceptance criteria, or rule, on a If there are too many blue cards on the table, the
blue card and put them across the table under story may be too complex and could benefit from
Example mapping sessions are most effective when
the yellow card. being sliced into multiple user stories. If there are
they’re timeboxed at about 25 minutes per user
3. Come up with one or more concrete examples, too many red cards, the user story may be too com-
story. That way, the team has enough time to have a
write them on green cards, and place them plex and the product manager may have to refine
conversation and make an informed decision with-
under the appropriate rule. the story.
out spending all afternoon on theoretical concerns.
The actual example mapping session involves four 4. If any questions come up, capture those on red It’s important to keep in mind that a little uncertain-
simple steps: cards and move on with the conversation. ty is normal in software development, so the team
1. Write the story under discussion on a yellow After the time runs out, take a quick vote to see if the should try not to hold up the development process
card and place it on the table. user story is ready to be pulled into development. over minor disagreements or issues.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 12

Recording the Results
Many development teams assume that the example
mapping session should culminate in executable
specifications (such as Cucumber scenarios). While
this can be valuable, it can distract from the true
purpose of the conversation. The idea is to reach
a shared understanding of what it takes to get the
story done rather than sitting in an IDE writing test
in Gherkin. Fortunately, there’s a middle ground
that ensures everyone is on the same page.

CucumberStudio improves the example mapping

process by introducing a common interface for
business and technical teams. Using the intuitive
user interface, the team can create an executable
specification without code, which can be automat-
ically converted into a feature file. The process
ensures that everyone is on the same page during
the meeting and eliminates the work associated
with manually writing the feature file in code.

In addition to entering these scenarios, Cucumber-

Studio helps you define and save common action
words that can be used in many scenarios. This can
further cut down on the time it takes to write a sce-
nario during the example mapping session and get
well thought out stories into production sooner. CucumberStudio Sce-

narios

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 13

Building The behavior-driven development process dis-
cussed thus far culminates in feature files that
1. Scenario: Searching projects

2. Given I am on the search page

Executable Tests contain human-readable specifications. The next
3. When I search for “Acme Project”
step is converting each of these specifications into
executable tests using browser automation tools 4. Then the page title should start

that simulate how users would actually be using with “Acme Project”

the software product. These tests can then be

The Gherkin file above becomes the following
added to the application’s overall test coverage
executable specification:
and any continuous integration strategies.
1. Given(/^I am on the search
Let’s take a look at how to convert feature files into page$/) dodriver = Selenium::Web-
executable specifications that actually verify that Driver.for :chromedriver.get

code meets the business requirements. “http://localhost:3000/search”end

2. When(/^I search for “([^”]*)”$/)

Writing Step Definitions
doelement = driver.find_element

Most behavior-driven development frameworks (name: “q”)element.send_keys

“Acme Project”element.submitend
automatically convert feature files into a step
definition template. After this process runs, de-
3. Then(/^the page title should
velopers or test engineers must fill in the blanks
start with “([^”]*)”$/) dowait
to describe how the actual application should = Selenium::WebDriver::Wait.new
respond to the user actions. (timeout: 10)wait.until { driver.
title.downcase.start_with? “acme”
For example, let’s take a look at a simple Cucumber }puts “Page title is #{driver.
feature step definition using the Selenium WebDriver: title}”browser.closeend

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 14

There are many different browser automation tools CucumberStudio Publisher Step Definition use of variables means that test engineers may
that can be used in the process, and the right deci- Export need to provide some input before the test can
sion depends on your specific project. For example, automatically execute
Selenium remains the most popular overall frame- The CucumberStudio Publisher tool transforms sce-
CucumberStudio integrations can be either loose
work, but many Ruby on Rails projects use Capyba- narios into executable tests in your chosen language
or tight:
ra as the preferred browser automation tool for use and browser automation framework with the largest

with Cucumber. selection of automation frameworks and tools of any | Loose integration avoids integrating auto-
BDD platform. By defining individual steps describing mation-related content inside of scenarios
Automating the Process the actions that are performed, you can avoid the and action words. The specific implemen-
need to go in and write any test code — or at least re- tation is left up to the automation team to
There are many tools that automate the process of
duce the amount of test code that you need to write. complete for the test code to run.
building step definitions. These tools can speed up
the development process by automating work for For example, you could define “Click on Profile” by | Tight integration defines specific class
test engineers, while ensuring that all step defini- setting a specific target, such as “a[text=”Profile]”, that names and other details to make the tests
tions are consistent in their design and usage. will look for any link with the text “Profile” on the page. run out-of-the-box. That way, the testing can

These steps can also include variables, although the be completely automated.

CucumberStudio Publisher Step Definition

Export

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 15

Most automated testing uses a combination of manual
and automated processes. For example, it might not
make sense to break down a very long set of instructions
that will never be repeated into action words — it’s
easier to just write the test code by hand.

Important Considerations
It’s important to watch out for blind spots when con-
verting higher level feature files into lower level execut-
able step definitions.

For example, suppose that you want to test a user’s

ability to update their profile. There may be several
different ways that the user can save their profile in-
formation. Just because one button on the page works
doesn’t mean that the other methods won’t be success-
ful. Full test coverage may involve testing each method
separately to ensure that there are no unexpected
errors that occur.

You may also need to test scenarios in multiple brows-

ers. For example, many businesses still have users on
Internet Explorer. The latest version of Chrome won’t
necessarily function the same as an older version of
Internet Explorer. Many browser automation frame-
works enable you to switch between browsers to
easily run tests covering multiple platforms.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 16

Continuous Behavior-driven development (BDD) helps business
and technical teams better communicate to create
There are several benefits to continuous integration:

| Reduced Risk: Defects can be immediately iden-

Integration the right set of features, but the overarching goal
of Agile software development is to deliver quali-
tified and fixed, which reduces the likelihood of a
defect reaching a production environment.
ty as fast and cheap as possible. The best way to
accomplish that goal is through continuous integra- | More Confidence: The reduced risk means

tion, deployment, and delivery, which automatically that stakeholders can be confident in deploying

ensures that any new code passes the appropriate new features without worrying about costly

tests before reaching production. regressions.

Let’s take a closer look at continuous integration, | Greater Visibility: Everyone can see the proj-

how it fits into development workflows, and how to ect state in the shared code repository, which

better integrate BDD into the process. enables a better feedback cycle.

Behavior-driven development improves continuous

What Is Continuous Integration? integration by ensuring that effective tests can be
run by the continuous integration service. Without
Continuous integration is the practice of team
effective tests, the CI server might let errors and
members integrating their work frequently into a
omissions slip past into the production environment.
shared repository — often multiple times per day.
Each integration is verified by an automated build
How CI Fits into Your Workflow
to detect conflicts as quickly as possible before
they reach a production environment. For exam- Continuous integration is the final step of most Agile
ple, a developer may commit new code to a git development workflows. After writing tests and
branch that’s automatically checked by a continu- code, developers integrate their new additions into a
ous integration server against the master branch shared repository and receive instant feedback about
before it can merge. any conflicts or issues that need to be resolved.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 17

A typical CI workflow looks something like this: both hosted or on-premise solutions. When choos- many popular continuous integration servers to
ing between these options, it’s important to consid- make BDD processes more visible across the board.
| Code and tests are committed to
er the cost and features. Open source on-premise
the repository. There are a few easy steps in the process:
solutions are free, but could require a lot of effort
| The software is built using a to configure and run, while hosted solutions can be | Create a test run dedicated to the CI that
continuous integration service. more expensive, they are more convenient when it includes only tests that have been fully
| The service runs all of the automated comes to customizations. automated.
tests on the build.
Some of the most popular CI solutions include: | Install the CucumberStudio Publisher tool on
| If the build fails, notifications are sent
the CI tool and configure it to run using the
out to the team. | CircleCI: A leading CI platform that includes
step-by-step guide.
| If the build succeeds, the software is hosted and on-premise options with support for

automatically deployed. mobile platforms, including iOS and Android. | Publish the results back to CucumberStudio
using the step-by-step guide to ensure that
The workflow can be customized depending on | Jenkins: The leading open source automation
everyone is on the same page.
the needs of the organization. For example, some server with hundreds of different plugins to

teams prefer to deploy automated builds to a stag- support building, deploying, and automating

ing server rather than a production server, where any project.

final quality assurance can be done by hand. Other

| CodeShip: A leading hosted CI platform that
teams have CI servers that test new git branches
works well with a wide range of source code
against the master branch before it can be merged,
repositories and hosting environments.
and then automatically deploy any changes to the
master branch. | TravisCI: A popular solution that’s commonly
used with GitHub and open source repositories.
Automating the Process
CucumberStudio provides business and technical
There are many different continuous integration teams with greater visibility into the continuous in-
servers that can automate the process, including tegration process by automatically integrating with

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 18

Living Behavior-driven development does more than
improve communication and reduce errors in
Some key benefits of documentation include:

| Faster Updates: Developers may write docu-

Documentation production — it provides an up-to-date record of an
application’s features. In other words, it produces
mentation for other developers making it easier
for them to make updates. For example, system
living documentation that’s readable by both busi-
documentation makes it easy to find classes,
ness and technical teams. This living documentation
methods, and variables in a large code base.
can be invaluable for many parts of the organization
since it shows exactly what the application is sup- | Improved Support: Technical writers may

posed to do and proves that it can do it. create documentation for users that makes it
easier for them to use the application, or help
Let’s take a look at how to leverage the scenarios
troubleshoot common problems. For exam-
and executable specifications created during the
ple, Stripe’s legendary API documentation was
BDD processes discussed earlier to create a living
critical to its success.
documentation.
| Better Workflow: Operational documentation
Why Documentation Matters helps stakeholders communicate their vision to
development teams. For example, user stories,
Documentation is instrumental in keeping stake-
acceptance criteria, design documentation, and
holders, developers, and users on the same page.
other resources provide context to the code.
While documentation may seem to counter Agile
development principles by creating more work The amount of documentation required for a
upfront, the process actually reduces the total work project is where there’s always some confusion.
by ensuring that everyone is working together more Agile development focuses on writing as little
effectively. There’s no time wasted from miscommu- documentation as possible early on, while
nications and it’s much easier for everyone to get traditional waterfall development writes all of the
up to speed. documentation at the onset.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 19

Where BDD Fits into the Picture accessed within CucumberStudio by both business
and technical teams without the need to open fea-
The behavior-driven development processes dis-
ture files and sort through a code repository.
cussed in this article produce both human-readable
scenarios expressed in Gherkin and executable If a feature fails or is removed, the living documen-
specifications expressed in step definitions. When tation is automatically updated to remove the fea-
combined, these BDD tests communicate how ture without any effort by the business or technical
features should function and ensure that the code teams. This helps ensure that everyone is always
properly executes those functions. Testing auto- on the same page when it comes to an application’s
mation and continuous integration ensure that the features and the status of each feature in the devel-
features remain up-to-date over time. opment process.

Human-readable scenarios can be repurposed Where to Go from Here

into system documentation since they effectively
Behavior-driven development is a game-changer for
describe user stories and acceptance criteria. If a
business analyst needs to know if a feature exists, many Agile development teams. By dramatically im-

they should be able to look at scenarios and see proving communication, these processes minimize

whether the step definitions have passed. If a mistakes, reduce errors, and ensure a higher quality
developer wants to know the status of a feature, product reaches users.
they should be able to run a test and see whether
CucumberStudio makes it easy to implement and
it has passed.
automate BDD processes with minimal coding,
Building Living Documentation making it accessible to both business and technical

CucumberStudio automatically generates up- teams. With its easy-to-use interface, it’s the per-

to-date documentation when integrated with a fect solution for teams just starting out with BDD

continuous integration platform. Every time a BDD processes. The many features and integrations
scenario is added and successfully run, the scenario also make it perfect for established teams looking
is automatically added to the human-readable living for a more streamlined approach to implementing
documentation. This documentation can be easily BDD across their organization.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 20

Build quality, don’t just test for it.
Bridge the gap between business and development using BDD
Accelerate development with test automation
Get real-time insights with living documentation
Seamless integration with Git

Try CucumberStudio for free

30-day trial, no credit card required.

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 21

BDD 101: A Comprehensive Guide to Behavior-Driven Development | 22