Behavior-driven development in DevOps

When we talk about DevOps, we often reference unicorns like Amazon, Google or GitHub, and how they practice it. We, as developers, think about source-code management, continuous integration, building server, delivery-pipelines, and implementing continuous deployment on every active environment (e.g. development, test, staging, and productive). We seldom think about how to tackle organizational challenges, which often comes across as the hardest thing to achieve.

DevOps should not only focus on delivery pipelines, fancy technologies and cutting-edge tools, but consider communication and culture as well. This should be considered not just in a development team but in an organization as a whole. With Behavior-Driven Development (BDD), useful methods can help us establish a standardized communication between a Project Owner (PO), development teams 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 life cycle. It can help to formulate better user stories, better acceptance criteria by example, better living documentation and finally better test automation where the unit tests, integration tests, and UI tests are performed against acceptance criteria.

BDD in a nutshell

Before I introduce you to BDD, let's take a step back in time and delve a little in Test-Driven Development (TDD). Majority of developers are privy to TDD, a so-called "test-first" approach first introduced by Kent Beck in the late 1990s as a part of extreme programming (XP). First: TDD gives you a framework where the developer must first write a failing unit test, Second: The developer can implement only so much code that the test passes. Third: Refactoring the code so it’s clean. The two biggest advantages here are:

• Methodical analysis of what is needed.
• Only the code that 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 entirely focused on the units.

Figure 1: TDD Lifecycle
Source

Dan North introduced BDD in 2003 as an enhancement of TDD. BDD doesn’t only focus on units but on the whole software life cycle. It can be seen as a framework and it fits perfectly in agile project environments, since BDD 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 life cycle looks like the TDD life cycle, but on a larger scale.

Figure 2: BDD Lifecycle 
Source: BDD in Action by John Ferguson Smart

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

So much for theory, now what does BDD look like and how it helps cultivate DevOps in an organization?

BDD in action

Let's take another concrete example of the stakeholder's platform that has a login. Login is possible with a username/password combination. In the past there was no awareness of security issues, but since the topic hits the media regularly the stakeholder wants to make sure that passwords are secure. Now the PO formulates a story, which could look something like this:

Story

The user selects a password, during registration, which is secure.

As a system administrator
I want the users to register with a secure password
so that the user accounts are not easily hackable.

The acceptance criteria to this story could look like that:

• The password must have a length of eight or more characters.
• The password must have at least one number.
• The password must have at least one special character.
• 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. 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 categorize 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 a better understanding of the problem to solve as well as we created awareness of what it means to provide a secure password nowadays. In the meantime, the acceptance criteria of the story had been adapted:

1. Passwords should be categorized into three types: Weak, Medium and Strong.
2. Only passwords >= medium should be accepted as valid passwords.
3. The user should receive an error-message if the password is categorized as weak.

During the meeting, the QA began to formulate a data table:

as well as the feature-file that contains the scenarios:

The biggest advantage of using an example or behavior-based approach is to analyze the 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. Simultaneously, using BDD from the beginning acts 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 Continuous Integration/Continuous Delivery(CI/CD) process—continuous testing. A big part of Continuous Testing should be compact and meaningful reports, which facilitates necessary transparency. Since we use BDD as a tool to living documentation and executable specifications, powerful yet easy-to-read reporting is not far off.

Conclusion

BDD is no silver bullet to undo all wrongs, but it can help get the communication going in an organization. I’m convinced that with awareness the culture will establish by itself. Obviously, this only works if the whole organization is on board and the management is well-trained in agile methods, understands agile methods and has a fully agile mindset.