Methodical software development processes can unlock hidden value in your digital transformation projects. A well-implemented Agile framework that incorporates adaptive, evidence-based planning, iterative delivery, and automation can reduce risk, shorten release cycles, and diminish workforce disruption. Effective test automation, including strategies such as Test-Driven Development, Behavior-Driven Development, and Acceptance Test-Driven Development, can increase predictability but also add their own unique challenges.

Software tests must be repeated frequently during development cycles; each time source code is modified, software tests should be repeated. For each release, the software should be tested on all supported operating systems and hardware configurations. Manually repeating these tests can be costly and time-consuming. Automated tests, in contrast, can be executed repeatedly at no additional cost, thus creating efficiency and reducing testing time. Automated testing can reduce the time required to run repetitive tests from days to hours, translating the effort directly into cost savings.

In this article, I’ll address some of the common obstacles encountered in Test-Driven Development (TDD), Behavior-Driven Development (BDD), and Acceptance Test-Driven Development (ATDD) transformations.

First, let’s define each approach.

Who Developer Developer, QA,
Product Owner
Developer, QA,
Product Owner
Purpose Unit Test Understanding
Acceptance test
Notation Code (software
Structured plain
English (Gherkin)
Structured plain
English (Gherkin)
Definition TDD is a
technique that
focuses more on the implementation of
a feature
BDD is a
technique that
focuses on the
system’s behavior
ATDD is a technique
like BDD with
emphasis on
capturing the
Process framework Agile Agile Agile

Let’s dive deeper into the respective methods.

Test-Driven Development  

This image has an empty alt attribute; its file name is Screen-Shot-2020-04-01-at-1.10.30-PM.png

Test-Driven Development has 3 distinct phases:

  1. Develop test (Test should fail)
  2. Develop code (Test should pass)
  3. Refactor code (Test should pass)

The introduction of TDD requires a change in philosophy and synchronized cooperation between development and test teams. Developers should write the test, code, and refractor while the test team reviews the test-cases for completeness and coverage.

Although TDD is primarily a programmer’s job, testers can collaborate by sharing the test scenarios consisting of:

  • Boundary value cases
  • Equivalence class test cases
  • Critical business cases
  • Cases of the error-prone functionalities
  • Securing level cases

Testers should also participate in defining unit test scenarios and provide their feedback on the test results. TDD offers benefits but has several drawbacks as well:

The Good The Bad
Promotes testable software Hard to apply on legacy code
Refactor promotes better written
software solutions
Requires maintenance
Increases code coverage It takes time and effort to learn
Build confidence Restrict to unit testing only
Forces developers to think before
It helps to understand the code by
providing examples
Defines “Done”

Behavior Driven Development 

This image has an empty alt attribute; its file name is Screen-Shot-2020-04-01-at-1.10.47-PM.png

There are 4 work-flow phases defined in BDD:

  1. Discovery of use-case (defining the test)
  2. Develop test (Test should fail)
  3. Develop code (Test should pass)
  4. Refactor code (Test should pass)

As you can see, BDD is TDD with an extra step: discovery of the use-case. First, you need to define a user story. The story should follow a common agile pattern:

  • 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.

Next, the business analysts, developers, and testers must determine different use-cases and the acceptance criteria for each of the scenarios.

Each scenario acceptance criteria follows this structure. They are called “steps”:

  • 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 clause;
  • And: the expected outcome, in another clause (Optional).
  • But: the exception in the clause (not always supported by the framework).

BDD encourages conversations across technical disciplines and stakeholders. Critically, this approach helps ensure that teams share a clear understanding of the requirements, which is necessary to work towards a common goal seamlessly. These conversations provide concrete, real-life examples of product behavior; these examples can more explicitly define what needs to be delivered.

Writing quality scenarios requires some practice; it will take time. Start simple, then expand the scenarios with more details. My advice is to keep scenarios simple, with a maximum of 10-15 steps.

The Good The Bad
Promotes collaboration It takes time and effort to master
Removes ambiguousness Time-consuming when applying to
legacy code
Defines “Done”

Acceptance Test-Driven Development  

This image has an empty alt attribute; its file name is Screen-Shot-2020-04-01-at-1.11.13-PM.png

There are 5 work-flow phases defined in ATDD:

  1. Discovery of use-case (defining the test)
  2. Develop Acceptance test (Test should fail)
  3. Develop test (Test should fail)
  4. Develop code (Test should pass)
  5. Refactor code (Test should pass)

Teams often find that the act of defining acceptance tests during requirement discussions improves their understanding of the requirements themselves. ATDD tests force an agreement on a software’s exact behavior and result in a more testable software overall. Further, automated regression tests can rapidly provide valuable feedback regarding business-facing expectations.


TDD (Test Driven Development), BDD (Behavioral Driven Development), and ATDD (Acceptance Test Driven Development) are increasingly popular strategies within agile teams. It’s important to understand the differences between these three test methodologies before starting your transformation so that you can select the most appropriate method based on your objectives.