Three Agile Testing Methods – TDD, ATDD and BDD
As a Product Owner or Developer
I want I want to understand the different Agile testing methods
So that I can decide which to use
In the word of Agile, there are currently three methods that can be used to improve our testing practices and to assist with enabling automated testing.
- Test Driven Development (TDD)
- Acceptance Test Driven Development (ATDD)
- Behavior Driven Development (BDD)
TDD, ATDD and BDD are software development techniques that can be used in any methodology although aspects of all three are often part of a team’s agile approach.
Test Driven Development (TDD)
TDD ensures that the product, system or process is being built correctly. It tests independent small units or objects to make sure each works as intended.
TDD is a software development approach where a developer writes a test before writing any code. The test is then used to build the code needed to pass it. Once the new code passes the test, it can be refactored to an acceptable standard (i.e. code layout, notation, performance)
TDD focus is “does the code do what it is required to do?”
Acceptance Test Driven Development (ATDD)
Acceptance Test Driven Development is also referred to as Story Test Driven Development (STDD)
ATDD ensures the product, system or process being built meets the expectation of the Product Owner. It’s a mechanism to facilitate the conversation between developers and product owners about the requirements and validate the expected business value is met.
It is a collaborative practice where users, testers, and developers define acceptance criteria. ATDD helps to ensure that all project members understand precisely what needs to be done and implemented. In Scrum these are referred to as the Acceptance Criteria for each User Story.
ATDD focus is on does the solution do what it is required to do?
Behavior Driven Development (BDD)
BDD is often referred to as Specification by Example
BDD ensures the correct product, system or process is being built by writing specifications or examples that describe the behavior expected.
BDD tests are written in an english-like language. Subject matter experts use their native language in combination with the language of Domain Driven Design to describe the purpose and benefit of their code.
A team using BDD should be able to provide a significant portion of “functional documentation” in the form of executable scenarios or examples. BDD is usually done in very English-like language helps the Domain experts to understand the implementation rather than exposing the code level tests. It’s usually defined in the format of: GIVEN WHEN AND THEN.
I recommend the use of a combination of ATDD and BDD.
Definition of Acceptance Criteria for each user story
Definition of ???
Defining BDD ???
Other Blogs from this category
When talking about testing in a data project we have to first identify that the testing we need to do is similar but different to the testing we do in application development project. One of the useful way to identify these differences is to understand a number of the...
When do BI projects that require new data we know anecdotally that once we have acquired the required data from the System of Records the majority of our time and risk is applying code that transforms and/or augments data. In my terminology I call this "doing bad...
As a BI Manager I want to understand the impact of pipelining the Agile teams workflow So that I know if it is an approach I wish to use Managing to complete an AgileBI build in three elapsed weeks is very very difficult. And by a build I mean from...
As a Stakeholder or Product Owner
I want to understand where the traditional planning documents fit in the AgilebI process
So that I know when I need to have them created
As a Product Owner or Developer I want I want to understand how to deal with a lack of clear acceptance criteria So that I don't delay delivery Acceptance criteria for a user story is crucial. Without it the development team and product owner...
As a BI Practitioner
I want to understand what AgileBI processes are
So that I know what processes to implement (and what processes not to)