Test cases are mostly written in programming languages such as Java, Ruby, etc. and can be written using test automation tools such as Selenium, Watir, Windmill, etc. Since test scripts are written in programming languages, it is hard for a business analyst or test owner to verify the test scripts.
Behavior Driven Development (BDD)
BDD is a software development technique that defines the user behavior prior to writing test automation scripts or the functional pieces of code. Used in an agile sprint, this method ensures that a shippable product is generated at the end of a sprint. This involves:
- Behavior of the user is defined by a product owner/business analyst/QA in simple English.
- These are then converted to automated scripts to run against functional code.
- The development team then starts writing the functional code to ensure the automated test script gives them a green light.
- The development team can then refactor and organize the code to produce a tested deliverable at the end of the sprint.
BDD can be driven by multiple tools such as Cucumber, FitNesse, PowerTools, Docker, etc. The test scripts are written in plain English in Gherkin, Wiki frameworks, etc. Since the behavior is defined in English, it gives a common ground for ALL stakeholders involved in the project. This reduces the risk of developing code that wouldn’t stand up to the accepted behavior of the user.
TDD vs. BDD
- BDD is in a more readable format by every stake holder since it is in English, unlike TDD test cases written in programming languages such as Ruby, Java etc.
- BDD explains the behavior of an application for the end user while TDD focuses on how functionality is implemented. Changes on functionality can be accommodated with less impact in BDD as opposed to TDD.
- BDD enables all the stakeholders to be on the same page with requirements which makes acceptance easy, as opposed to TDD.
The behavior of the application is the central idea in BDD; it focuses on the customer and pushes developers and testers to walk in the customer’s shoes. If actions do not affect the end-user, BDD might not represent such a scenario very well, in which case TDD better serves the purpose.
Like many other software development practices, it might not be feasible to identify what works universally for all projects. For systems that are driven by actions of the end user such as an ecommerce website or a HR system, BDD acts as a good medium to capture all the user actions. For systems that have third party API calls, cron jobs, data exports/imports, etc., TDD might be a better solution.
A Trusted Software Development Partner
At GlowTouch, we’re skilled and adept in a wide range of development approaches, from test-driven to behavior-driven development. Learn more about our custom software development services here.