Behavior Driven Development (BDD)

[anitsh]

Behavior-Driven Tevelopment (BDD)

BDD is an agile software development process that encourages collaboration among developers, QA, and non-technical or business participants in a software project to enable Agile methodologies such as Scrum, Kanban, XP, etc..

It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.

It emerged from test-driven development (TDD) and can be seen as an extension of TDD, or adds some structure to TDD. Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design(DDD) and object-oriented analysis and design (OOAD) to provide software development and management teams with shared tools and a shared process to collaborate on software development.

Behaviour-Driven Development (BDD) helps in optimizing the value of work done by Scrum team.

BDD focuses on:

• Where to start in the process
• What to test and what not to test
• How much to test in one go
• What to call the tests
• How to understand why a test fails

BDD uses a simple domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes that forms a structure of the User Story. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.

Therefore BDD specifies that business analysts and developers should collaborate to create User Stories which are mapped to the test. Each User Story should, in some way, follow the following structure:

Title: An explicit title.

Narrative: A short introductory section with the following structure:

• As a: the person or role who will benefit from the feature;
• I want: the feature;
• so that: the benefit or value of the feature.

Acceptance criteria: A description of each specific scenario of the narrative with the following structure:

• Given: the initial context at the beginning of the scenario, in one or more clauses;
• When: the event that triggers the scenario;
• Then: the expected outcome, in one or more clauses.

Specific tool are needed to implement BDD like Cucumber.

User Story Specification

The Three Amigos, also referred to as a "Specification Workshop", is a meeting where the Product Owner discusses the requirement in the form of Specification by Example with different stakeholders like the QA and development team. The key goal for this discussion is to trigger conversation and identify any missing specifications. The discussion also gives a platform for QA, development team and Product owner to converge and hear out each other's perspective to enrich the requirement and also make sure if they are building the right product.

The three Amigos are:

• Business - Role of the Business user is to define the problem only (and not venture into suggesting any solution)
• Development - Role of the Developers involve to suggest ways to fix the problem
• Testing - Role of testers is to question the solution, bring up as many as different possibilities for brain storming through What-If scenarios and help make the solution more precise to fix the problem.

Stories

Stories are short descriptions of a small piece of desired functionality, written in the user’s language. Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed in a single Iteration. Stories are the primary artifact used to define system behavior in Agile. They are short, simple descriptions of functionality usually told from the user’s perspective and written in their language. Each one is intended to enable the implementation of a small, vertical slice of system behavior that supports incremental development. Stories provide just enough information for both business and technical people to understand the intent. Details are deferred until the story is ready to be implemented. Through acceptance criteria and acceptance tests, stories get more specific, helping to ensure system quality. User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.

Enablers bring visibility to all the work necessary to support efficient development and delivery of future business requirements.

User stories are the primary means of expressing needed functionality. They largely replace the traditional requirements specification. (In some cases, however, they serve to explain and develop system behavior that’s later recorded to support compliance, traceability, or other needs.)

Teams may need to develop the architecture or infrastructure to implement some user stories or support components of the system. In this case, the story may not directly touch any end user. These are enabler stories and they support exploration, architecture, or infrastructure. Enabler stories can be expressed in technical rather than user-centric language,

Resource

• [ ] https://automationpanda.com/BDD
• [ ] https://trello.com/c/26yykLNZ/83-test-code-test-driven-design
• [ ] https://techbeacon.com/app-dev-testing/better-behavior-driven-development-4-rules-writing-good-gherkin
• [ ] https://gojko.net/2020/03/17/sbe-10-years.html
• [ ] https://www.scaledagileframework.com/story
• [ ] https://github.com/cucumber
• [ ] https://www.scrum.org/resources/blog/behaviour-driven-development-bdd-helps-optimizing-value-work-done-scrum-team
• [ ] http://coding-is-like-cooking.info

[anitsh]

Agile is a set of principles, not a process. Agile determines or controls the processes used. BDD is a part of the development process that takes the Agile principles into account. In fact, an Agile approach must be used in order for BDD to be effective.

First, requirements and user stories will be tied together. Design documentation will be created, even if, as is likely, after the fact. Test cases and test results will also be tied to the user stories and requirements. Test cases can be directly related to the user stories. They will be easily verified. And assuming the developers began coding with a clear idea of what the results will be, the testers will have an easier job of testing. They will have objective indicators of what a failure looks like.

An Agile process does not mean the negation of documentation, as tempting as that may be. Rather, an Agile philosophy and BDD processes should result in the creation of complete and effective documentation.

https://www.agilest.org/devops/behavior-driven-development