DevOps means more than continuous integration, delivery and deployment. Quality assurance should also be integrated as a continuous component, as it’s done with software development. Therefore, different kinds of tests should be used more often throughout the entire software lifecycle.
When we talk about DevOps, we often reference unicorns like Amazon, Google or GitHub, and how the practice it. We, the developers, think about source-code management, continuous integration, build-server, delivery-pipelines and how to implement continuous deployment on every environment that is in use (e.g. development, test, staging and productive). We seldom think about how to tackle the organisational challenge, which in my opinion is the hardest thing to achieve.
DevOps should not only focus on delivery pipelines, fancy technologies and awesome tools, but should consider communication and culture as well. Not only in a development team but in the whole organisation. With the support of behaviour-driven development (BDD) it is possible to use methods that help us establish a standardized communication between project owner (PO), development including quality assurance (Dev) and operations (Ops). When BDD is implemented properly, it can prevent social friction and misunderstandings.
BDD, as a method, can be introduced early in the software lifecycle. It can help to formulate better user stories, acceptance criteria by example, living documentation and finally test automation where unit test, integrations test and UI test are tested against acceptance criteria.

BDD in a nutshell

Before I introduce you to BDD, I need to step back in time and tell you a little bit about test-driven development (TDD).
I guess, TDD is a term most developers know. TDD is a so-called ‘test first’ approach and was first introduced by Kent Beck in the late 1990 as part of extreme programming (XP). In general, TDD gives you a framework where the developer must first write a failing unit test, secondly implement only so much code that the test passes and third refactored the code so it’s clean. In my opinion the two biggest advantages are

  • Methodical analysis of what is needed.
  • Only code which is necessary is implemented

One disadvantage, which is the reason why BDD was introduced in the first place, is that developers tend to lose sight of the big picture, since they are focused entirely on the units.

Dan North introduced BDD in 2003 as an enhancement of TDD. BDD doesn’t focus only on units but on the whole software lifecycle. It can be seen as a framework and fits perfectly in agile project environments since it is based on lean and agile methods.
With the use of simple and natural language syntax, BDD provides the possibility to break down complex requirements and formulate them in a way that all involved roles have an equal understanding of the requirements. The BDD Lifecycle looks like the TDD Lifecycle, but on a grander scale.

  1. User stories are analysed and examples for the stories are defined.
  2. A small group within the team has a conversation about the example. Members of the group should include the project owner, development including QA and operations.
  3. During the conversation the example is formulated as a scenario, which is used for automated tests and later as living documentation.
  4. Since the team is working with a test first approach, the scenario fails at the beginning of the software lifecycle. Same as TDD.
  5. The scenario is implemented. BDD is an enhancement of TDD – not a replacement. Therefore, TDD is still used to implement the scenario.
  6. The scenario is implemented and completed when the automated scenario passes.
  7. The next scenario is implemented.
  8. The story is done after all scenarios are implemented.

So much for the theory, but what does BDD look like and why does it help to cultivate DevOps in an organisation?

BDD in action

Since we talked about examples, I would like to stick with that and give you a concrete example. Let say the stakeholders platform has a Login.
Login is possible with a username/password combination. In the past there was no awareness for security issues, but since the topic hits the media regularly the stakeholder wants to have a way to make sure  that password are secure. Now the PO formulates a story, which could look something like this:


The User should select a password, during registration, which is secure.
As a system administrator
I want the users to registered with a secure password
So that user accounts are not easily hackable
The acceptance criteria to this story could look like that:

  1. The password must have a length of eight or more characters
  2. The password must have at least one number
  3. The password must have at least one special character
  4. The user should receive an error message if the above criteria are not met.

With this formulated story the PO calls for a ‘three amigo’ meeting to have a conversation about it.
After the PO introduces the story, the following conversation could take place:

Dev: A password with less than eight characters should be denied, for example “Secret”.
PO: Correct, my understanding is that an algorithm exists, which can crack short passwords in no time.
Dev: Would the password ”Password1!“ work?
OPs: In my opinion, it would be correctly implemented, but it is a weak password. Dictionary words with one number and one special character are covered in the most basic brute force attack algorithms.
Dev: Ok, if “Password1!” is a weak password because it is a dictionary word, what about “GuineapigMonkey”.
OPs: I would categorise it as a medium strength password.
PO: The suggested password contains no special characters or numbers and is considered a medium secure password, what would a strong password look like?
OPs: A password like “Gu1neapig$Monk3y!” would be a strong one in my opinion.

What happened in that conversation? We used examples to provide better understanding of the problem-to-solve as well as created awareness of what it means, nowadays, to provide a secure password. In the meantime, the acceptance criteria of the story had been adapted:

  1. Passwords should be categorised in the following categories
  2. Weak
  3. Medium
  4. Strong
  5. Only passwords >= medium should be accepted as valid passwords.
  6. The user should receive an error-message if the password is categorised as weak.

During the meeting QA began to formulate a data table:




as well as the feature-file, which contains the scenarios:

The biggest advantage of using an example or behaviour-based approach to analyse requirements is that we minimize the loss of details during the “translation” from one business language into another, or even misinterpret requirements completely and implementing them erroneously. At the same time, using BDD from the beginning aids as a base to create a transparent automated test suite, where we can speak of executable specification and living documentation.

What’s next

After establishing communication and culture, the next logical step from a quality assurance point of view is the integration of a decoupled test automation into the CI/CD process – continuous testing. A big part of Continuous Testing should be compact and meaningful reports, which create the necessary transparency. Since we use BDD as a tool to create living documentation and executable specifications, powerful, yet easy-to-read, reporting is not far off.


BDD is no silver bullet for making righting all wrongs, but it can help to get the communication in an organisation going. I’m convinced that with this communication the culture will be established “by itself”. Obviously, this only works if the whole organisation is on board and the management is well trained in agile methods, understands agile methods and in best case has a fully agile mindset.
About the author:

Thomas Goldberger, Test Automation Expert, Nagarro GmbH

Thomas Goldberger works since 2011 in Software Quality Management and is specialized in Test Automation. As Test Automation Engineer it is important to him, to work as a link between the test team, the development team as well as the business department. Since he works not only with technicians but also very close with project owners’ he finds the use of methods, which supports an easy way to implement a common communication between these roles, to define better and more understandable requirements, very useful.