The BDD

3 proven ways enterprise

IT Maturity Model
leaders can speed up
SAP innovation
A Leveled Approach to Scale
Behavior Driven Development

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 1

 CONTENTS

LEVEL ONE: BDD Collaboration begins.............................................................................3

LEVEL TWO: BDD Frameworks and Tools Are Chosen and Implemented......................5

LEVEL THREE: Systems Connect for Development and Automation ..............................6

LEVEL FOUR: CI and Systemic Collaboration Become Standard.....................................7

LEVEL FIVE: Measuring BDD Success With Reporting......................................................7

INTRODUCTION
According to Digital.ai’s 2020 State of Agile The following model is designed to help you
Report, nearly a third of companies are using assess where your team is on the journey to BDD
test-driven development (TDD), with only 19 maturity. This guide will give you a framework for
percent performing the more advanced behav- understanding your team’s progress as they gain
ior-driven development (BDD). That’s because it’s experience and better define new processes.
much more difficult to successfully perform BDD The model includes five maturity levels, which are
— but BDD can offer significant advantages for based on the adoption patterns we’ve seen as
software quality. organizations mature and progress through the
BDD learning curve.
While TDD calls for writing test cases before code
is written, it does not specify things like where By assessing your team’s current maturity and
development should begin, what should be outlining a plan to progress to the next level, this
tested, or how those tests should be structured guide will help you determine the incremental
and named — all of which BDD prescribes — and steps for your team to take to continue making
all of which is much more difficult to achieve. But progress towards BDD maturity. Implementing
rapid adoption of TDD shows that the founda- BDD involves significant process changes, both
tions are in place for a significant uptick in BDD within and outside the QA team, but is well worth
adoption. Open source tools like Cucumber and the effort. Teams with mature BDD practices
SpecFlow are growing in popularity as teams also tend to be further along in their DevOps
adopt specification languages to improve collab- journey — DevOps calls for quality at speed, and
oration between business testers, expert testers by shifting testing left with BDD, these teams are
and developers, all in the name of creating better delivering faster without sacrificing quality.
software — that meets the needs of its users and
the business developing it — faster.

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 2

 LEVEL ONE : BDD COLLABORATION BEGINS
“We collaborate, we record that collaboration in some form of specification
and then we automate that specification to drive out the implementation.”

— Cucumber.io

At level one, your team has started to dip their mastered this skill, they have paved the way for
toes into BDD as a viable development and true alignment between business requirements
testing methodology. The team’s initial focus and the features being developed and tested.
should reside in making collaboration work
across all team members. This means that Your team should be familiar with the concept
they have some level of consistency around of living documentation, but it’s likely that there
the roles of the product owner, developer, and hasn’t been any formal training for writing in the
tester in an agile environment. At this stage, the Gherkin syntax and team members are not yet
three roles work together to design acceptance familiar with advanced concepts of data tables
criteria by exploring and discovering the needs and test tags. Even though team is documenting
of the business. in the Gherkin style for features and test scenari-
os, there is no standardization of tools, and that’s
At this level, the team should be able to use their o.k. They may be writing acceptance criteria and
understanding of business goals to question the test scenarios on note cards or a whiteboard.
form (and at times, the validity) of the features And manual execution of the scenarios is likely
the business is asking for. Once the team has performed outside of any test automation.

Scenario Steps
Given When Then

Setup Initial State Perform Action(s) Check end state

Phase One Achievements Next Steps

Ȍ Collaboration and alignment is improved with Ȍ You’re writing Gherkin-style scenarios. Now it’s time
early sessions between the product owner, to put the proper tools in place
developer, and tester
Ȍ User stories are clearly related to business out-
Ȍ Example mapping sessions demonstrate visible comes. Now it’s time to implement them with code
progress and help gain executive level buy-in and write automated tests.

Ȍ The team is highly focused on making sure the Ȍ Proper use of Gherkin syntax is sporadic. Now that
building blocks of the BDD process are in place the team has had a chance to practice, it’s time to
introduce additional Gherkin concepts, like feature,
background, and datatables, to increase test case
writing efficiency.

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 3

 LEVEL TWO : BDD FRAMEWORKS & TOOLS ARE CHOSEN & IMPLEMENTED
“We collaborate, we record that collaboration in some form of specification
and then we automate that specification to drive out the implementation.”

— Cucumber.io

At level two, your team should evaluate tools and To minimize re-work, teams will adopt a domain
select one that can tie the BDD process togeth- specific language required by their particular
er. Prior to this, team’s might have written their BDD methodology. For example, if your team has
acceptance criteria and scenarios in notepad chosen to work with Cucumber, the team will
or physically on note cards. Tools like SpecFlow, also learn and become familiar with the Gherkin
Cucumber, JBehave, and Gauge are all valid can- syntax structure during level two. This lays the
didates your team should discuss when deter- groundwork for test driven development and test
mining which tool is best for them. For simplicity’s automation.
sake, in this maturity model, we are going to
assume that Cucumber has been chosen as the
collaboration tool for BDD transformation.

Phase Two Achievements Next Steps

Ȍ Proper tools are in place and connected Ȍ Features need to be versioned with source code for
version control and test automation
Ȍ You’ve laid the groundwork for automating test
scenarios Ȍ Reuse of test scenarios should increase.

Ȍ The proper syntax is now familiar with all team Ȍ Features should be connected with enterprise agile
members planning tools (i.e. Jira Software, Version-One)

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 4

 LEVEL THREE : SYSTEMS CONNECT FOR DEVELOPMENT & AUTOMATION

Up to this point, all features and scenarios have test scenarios that validate the defined behavior
yet to be connected with source code (i.e. Git) and drive automated deployments.
and typical project management tools (i.e. Jira
Software). Integration with source code enables At this stage, your team also needs to link fea-
developers to implement features and testers to tures with project management tools in order
add automated step definitions. provide traceability for sprint progress. For
example, you may have epics and user stories
Once source code is connected, development to that are being tracked in typical scrum envi-
uses the test scenarios to drive the implementa- ronments on To Do,” “In Progress,” and “Done”
tion of the feature. Testers can then execute the status’. Communicating your BDD processes
back to these key artifacts enables you to justify

Your Project

Features

Scenarios Technology
Facing
Steps

Step Definition
Business
Facing Support Code

Automation Library

Your System

Phase Three Achievements Next Steps

Ȍ Features are stored with source code for Ȍ A proper mix of manual vs. automated test
source of truth scenarios has not been established

Ȍ Results and status rolled up to overall project Ȍ Automated test scenarios are not yet tied into
plan for acceptance criterias continuous integration (Jenkins).

Ȍ Features status help progress issues into Ȍ ChatOps notifications have not been enabled
production members for systemic communication.

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 5

 LEVEL FOUR : CI & SYSTEMATIC COLLABORATION BECOME STANDARD

One of the main reasons teams give up on BDD good partner here. However, lots of teams suc-
is a lack of automated test scenarios. Teams wil cessfully implement BDD and ATDD without ever
stop short of adding automated step definitions moving all the way to TDD. If that’s the case, after
and simply run their scenarios manually after code commits and stay focused on functional
development has implemented the feature. automation related to the test scenarios.
However, to achieve true BDD maturity, automat-
ed test scenarios are a must. Teams taking on test-driven development should
be generating automated code stubs once a
At level 4, teams need to start thinking about feature has been created. This practice sends
marrying their development team’s test-driven failing step definitions into a Git repository, which
development (TDD) process, if applicable, with mandates attention to the feature. Since the code
BDD processes in testing. Not all teams take on repository is connected to the CI pipeline, the
TDD, but if the development team is practicing team cannot progress until they add test automa-
TDD, it’s typically happening at the time appli- tion and ensure the automated tests pass.
cation code is being written, and BDD can be a
Lastly, teams must also include Exploratory and
usability testing after their test scenarios have
been automated. As mentioned earlier, BDD
usually breaks down when the test
scenarios are not automated and
simply ran through like traditional
manual test steps. However, this
does not mean that we throw out
any test planning that included ex-
ploratory and usability testing.

Phase Four Achievements Next Steps

Ȍ You’ve mastered test driven development (TDD as part of your BDD Ȍ Team-level reporting
process
Ȍ Executive-level reporting for BDD
Ȍ Feature file results are reported back through the CI pipeline for full progress
continuous integration

Ȍ ChatOps workflows instantly alert team members when results fail

Ȍ A proper mix of exploratory testing has been added to your test cycle

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 6

 LEVEL FIVE : MEASURING BDD SUCCESS WITH REPORTING

It seems that every maturity model ends with a So what does that mean for your reporting pro-
focus on reporting, and for good reason. Re- cesses? The DevOps manager will need traceabil-
porting is the best way to establish a consistent ity reports to understand which features (code)
method for measuring your progress against are ready to be pushed to production. Executives
your goals. When reporting on BDD, too many will appreciate a high-level overview of progress
teams stop short at reporting which scenarios for each project and team. The executive-level
passed and which scenarios failed. While that’s report should include measurements like risk
an important metric that allows teams to rapidly profile, time spend and average number of test
respond to broken builds, it’s also important to scenarios per feature, as well as scenario auto-
report on some higher-level metrics that will help mation progress.. Not only will this help you keep
you measure and communicate business value. your executive team in the loop, it will help get
After all, that’s what BDD is all about — aligning you and your team into the mindset of delivering
the business with the engineering team, and and communicating business value with each
delivering business value with each release. release.

Phase Five Achievements Next Steps

Ȍ Pipeline analysis is given in live dashboard as a key Ȍ Present business case to management for
indication around current state of business value extending BDD adoption
delivery
Ȍ Remove silos and extend BDD process
Ȍ Phase analysis is given through drill down detail into across teams
certain handoffs/areas in the pipeline to analyze
why they are speeding up/slowing downs

Ȍ Retrospective views summarize data for review after

the completion of a sprint or major release

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 7

GETTING STARTED
Now that we have discussed some steps to maturity, how should you get started down the path to BDD?
Here are some practical steps to jump-start BDD at your organization.

CREATE A SMALL GROUP

Find team members that want to do something different. That’s a simple statement, but the journey to
BDD requires a huge mindshift with lots of experimentation. Teams that were the first to move from
waterfall to agile might be a good place to start. Strengthen your chances that the group will succeed by
including business stakeholders as well as developers and testers.

FOCUS ON THE PROCESS

Before you start “doing BDD,” it is critical to understand the additional level of trust that the process
requires. If your team is not bought into the process, they will instantly become frustrated. That’s because
BDD requires a more tightly integrated scrum team than you have ever had in the past. In typical scrum
teams, you have mixtures of the scrum master, testers and developers. However, most of the time, team
members can quickly create the mini siloes where requirements, code and test are not connected.

PERFORM EXAMPLE MAPPING

Example mapping will quickly identify potential communication breakdowns. Set up a whiteboard, stick
post-it notes on a wall, or use an agile planning tool like Jira Software to create concrete examples
through continuous conversation. Each example mapping session includes four types of information
objects, which build on each other: stories, rules, examples and questions. As your team talks through
how the examples will behave in the system, they will naturally form the basis for acceptance tests.

Example mapping will also help you accurately define the project’s scope. If a single story ends up
having 50 rules, for example, it could be broken into multiple smaller stories. Or if the team has more
questions than examples, you may need to reconsider that feature.
Read more about Example Mapping here.

LEARN CORRECT GHERKIN

Before you start “doing BDD,” it is critical to understand the additional level of trust that the process
requires. If your team is not bought into the process, they will instantly become frustrated. That’s because
BDD requires a more tightly integrated scrum team than you have ever had in the past. In typical scrum
teams, you have mixtures of the scrum master, testers and developers. However, most of the time, team
members can quickly create the mini siloes where requirements, code and test are not connected.

ADOPT CUCUMBER AND START GETTING TECHNICAL

Now is the time to start figuring out the technical aspects of your BDD process: choosing your BDD collab-
oration framework, performing source code integration, setting up continuous integration and tying it all
together with reporting. Having the non-technical, foundational elements in place first will ensure you can
continue your progress toward BDD maturity — and save your team a lot of frustration.

tricentis.com © 2021 Tricentis GmbH. All Rights Reserved | 8

 ABOUT TRICENTIS

Tricentis is
Tricentis isthe
theglobal
globalleader
leaderininenterprise
enterprise continuous
continuous testing,
testing, widely
widely credited
credited for for reinventing
reinventing
software testing
software testingforand delivery
DevOps, forand
cloud, DevOps and applications.
enterprise agile environments. The
The Tricentis Tricentis AI-based,
AI-powered, con-
continuous
tinuous testing
testing platform
platform provides
provides automated
a new testing and
and fundamentally real-time
different way business risk software
to perform insight across your
testing.
DevOps
It pipeline.
addresses This development
both agile enables enterprises to accelerate
and complex their
enterprise digital
apps, transformation
enabling enterprises by dramatically
to accelerate
increasing
their digitalsoftware releasebyspeed,
transformation reducing
dramatically costs, and
increasing improving
software releasesoftware
speed,quality.
reducingTricentis has been
costs, and
widely recognized
improving softwareas the leader
quality. by has
Tricentis all major industry
been widely analysts,asincluding
recognized being
the leader by allnamed the leader in
major industry
Gartner’sincluding
analysts, Magic Quadrant five years
being named in a row.
the leader TricentisMagic
in Gartner’s has more than five
Quadrant 1,800 customers,
years in a row. including
Tricentis the
largest
has morebrands
than in the customers,
1,800 world, suchincluding
as Accenture, Coca-Cola,
the largest Nationwide
brands Insurance,
in the world, such as Allianz, Telstra, Dolby,
McKesson,
RBS, and Zappos.
Accenture, Nationwide Insurance, Allianz, Telstra, Moet-Hennessy-Louis Vuitton, and Vodafone.

To
To learn
learn more,
more, visit
visit https://www.tricentis.com
www.tricentis.com or follow us on LinkedIn, Twitter, and Facebook.

AMERICAS EMEA APAC

2570 W El Camino Real, Leonard-Bernstein-Straße 10 2-12 Foveaux Street
Suite 540 1220 Vienna Surry Hills NSW 2010,
Mountain View, CA 94040 Austria Australia
Unites States of America [email protected] [email protected]
[email protected] +43 1 263 24 09 – 0 +61 2 8458 0766
+1-650-383-8329

tricentis.com
tricentis.com © 2021 Tricentis
© 2021 USA GmbH.
Tricentis Corp. All
Allrights Reserved|| 24
Rightsreserved 9
v. 0521