Behavior Driven Development Vs. Traditional Development


Is there a way to shave years off of the trial and error implementing Agile?
Find Out Now.


In this episode of Whiteboard Friday, we address Behavior Driven Development, aka BDD. We’ll talk about what BDD is and compare it to a traditional development process.

Watch the full Whiteboard Friday series:

A traditional development process begins with a stakeholder determining what the business needs are for the product and dictate that to the product owner. The product owner then writes the requirements on his or her own, leaving out the developer and tester. Because they were absent during the requirement writing, the developer and tester must translate the requirement into what actually needs to happen; the developer translates requirements to code, the tester must translate requirements to test cases and technical writer translates into technical documentation.

A BDD process begins with the product owner, tester and developer collaborating around the requirements, asking questions and providing examples of the business need. Agreed upon requirements are defined as English-formatted scenarios. In BDD, the developers can then use the scenarios for automated tests and testers also use scenarios as the basis for their tests.

The byproduct behavior driven development means moving away from silos to a more collaborative process, resulting in a more complete final product that what a traditional process can deliver.

#BDD in a tweet: “Using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters.” -Dan North @tastapod