We are repeatedly asked how the use of BDD should be evaluated. At first glance, there are many reasons for Behavior Driven Development:

• Readable test cases are created.
• This is accompanied by a high level of traceability and transparency of the test cases.
• There is a “single source of truth” for the requirements to be implemented.

So why shouldn’t we use BDD everywhere? Or to put it another way: does BDD fit into every day-to-day project?

The basic idea of BDD

BDD is a development process that can be broken down into four steps:

1. Before a new feature is integrated into software, the requirements are clarified. A formalized syntax is used for this, e.g. Gherkin (Given-When-Then format) or Markdown.
2. As soon as the implementation starts, the (formalized) requirements are transferred to the test automation. The tests will be FAILED at the beginning because they describe a behavior that is not yet implemented in the software.
3. The functionality is then implemented and the test automation is implemented in parallel. The test cases are executed continuously during this phase.
4. At the end of this cycle, the requirements will have been successfully tested.

In essence, this is a test-driven approach that places formalized requirements at the beginning of the development process.

In practice, lifecycle management systems can be used in which the scenarios can be executed for both manual and automated test cases. For example, with opentext ALM Octane or in Jira using XRAY, the scenarios can be recorded as test cases directly in Gherkin syntax.

Requirements as a connecting element

These (formalized) requirements form a unifying unit – from business, development and QA teams to infrastructure teams. Each team contributes its own perspective and thus develops a common database.

BDD therefore requires high-quality requirement engineering and a cross-functional team.

In practice, however, there are always other constellations:

• DEV and QA teams are organizationally separate and are also involved downstream in the project.
• Requirements are formulated by separate business analysts, often in free text and in tools that are not accessible to QA or infrastructure teams.

Here it is difficult to make a general statement about the sensible use of BDD.

Anyone who wants to live BDD should therefore consciously ask themselves the following questions:

1. Is there a cross-departmental development team?
2. Is it justified to compile formalized requirements again exclusively for test automation?

BDD and test automation

If you look at common tutorials on the subject of BDD, you can quickly get the impression that Gherkin is an easy-to-use language.

It is – if you follow a few rules:

1. every requirement, every scenario, is test automation source code.

• The well-known CleanCode principles should apply, e.g. “Don’t Repeat Yourself” or “Keep it simple stupid”.
• Each request should typically comprise 5-7 lines – no more!
• Scenarios should be reviewed and refactored at regular intervals.

2. each requirement, each scenario, describes expected behavior.

• UI designs or UX designs belong in separate documents, not in the scenarios.
• Instead, the workflow of all artifacts should be described:
  • What is the initial state?
  • What happens to them?
  • What do the artifacts look like at the end of each process step?

3. every requirement, every scenario, must be (continuously) testable.

• BDD does not solve structural problems in test automation.
• Test data or test clusters must be available and accessible via CI servers.
• Stable, recognizable objects must exist in the front end and APIs must have a corresponding consistency.

BDD does not replace a test automation framework, but adds another layer.

BDD and acceptance tests

BDD and acceptance testsComprehensive workflows are usually tested in the acceptance test. The test cases often comprise many individual steps, which in themselves are complex to automate. Even without BDD, this test level is the most complex process step in product development. Conversely, does this mean that BDD should be dispensed with at this level?

As is so often the case, it helps to take a look at the entire test process. If every single process step can be tested automatically, how great is the remaining risk in the overall process?

The focus on the process steps helps in several ways:

• Suitable test data can be provided for each step in order to test special constellations.
• In each step, exceptional situations (connection failures, program crashes, etc.) can be simulated much more easily.
• If individual process steps are changed, this only affects a subset of all tests. It is therefore not necessary to adapt all tests in case of doubt.

The “acceptance test” can therefore be highly focused. Exploratory tests or A/B tests with selected user groups are often more cost-effective here and cover the same risk as an attempt to implement complete test automation with BDD.

A general answer as to whether BDD makes sense for an acceptance test is ultimately only possible in the specific project context.

Summary

BDD connects all specialist areas on the basis of uniform, formalized requirements.

The use of BDD is not a sure-fire success and requires careful planning in the project. Just because the syntax appears modern and simple, it still requires continuous efforts to use this level in test automation in a meaningful way.

Podcast recommendation