How to Implement BDD Efficiently

BDD (behavior-driven development) - is a set of software engineering practices designed to help teams build and deliver more valuable, higher quality software faster . It draws on Agile and lean practices including, in particular, Test-Driven Development (TDD) and Domain-Driven Design (DDD). BDD is not software development methodology in its own right. It’s not a replacement for Scrum, XP, Kanban, RUP, or whatever methodology you’re currently using.

BDD Process

1. The business owner and the business analyst have a conversation about what the business needs

2. The business analyst, the developer, and the tester elaborate the requirements together. They define requirements as structured, English-language format "scenarios"

3. The scenarios guide the developer and act as automated tests

4. The tester uses these scenarios as the basis for the tests

5. The automated tests provide feedback on progress and help document the application

• Given describes the preconditions for the scenario and prepares the test environment

• When describes the action under test

• Then describes the expected outcomes

• The And and But keywords can be used to join several Given, When, or Then steps together in a more readable way

The main feature of all BDD frameworks is mapping text steps into method of program language by using regular expressions.

Example of GUI Scenario

Scenario: Running a Full Text Quick Search.

Given I perform Quick Search by "IPhone 4S"

When I click on link 'Search History' on panel 'Quick Search'

Then the term query "IPhone 4S" should be the first in the Search History grid

Note: Text description of scenarios uses Gherkin language

Pros

1. The acceptance criteria are nice thought

2. Test logic is in total independent layer of implementation

3. We get executable specification

4. All test cases and automated tests are up to date

5. Application development time reduced

6. Manual qa engineer can use automated test scenarios for manual testing

7. BA could accept user-story base on test execution report

8. Manual or Junior qa automation engineers help qa team develop automated tests

Cons

1. It is not possible to do testing in the middle of the test. Checks are made only in the THEN section

2. It's hard to maintain reusable steps in the scenarios. Very often it leads to duplication of code in the test system

3. It is difficult to refactor tests

4. It is necessary to create and maintain the Domain Dictionary for writing tests

5. The complexity of writing test scenarios without Helper-s ( typos, say the phrase can be different )

Define workflow of scenarios creation with team.

1. BA writes draft of scenarios or requirements in classical style and puts them into Jira story

2. QA reviews scenarios, rewrites them, asks BA additional questions and puts final version of scenarios into Jira story

3. BA approves the final version of scenarios and put comment about it

4. User story is ready for development

Create the initial version of the Domain vocabulary/Templates of BDD steps.

The most important step of BDD tests creation is to define abstract layer (strong technical or non-technical) of BDD steps. It should be understandable for Business (PO, DM, BA and etc.) and for technical engineers (developers, QA engineers, DevOps and etc.).

Limitations

1. Most difficult things in BDD are create good test system architecture and define «Rules of the game»

2. BDD is a very good approach. But this is not a silver bullet

3. To use or not to use BDD depends on situation and project

4. Tests Stability and BDD usability depends on you