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.
| TDD | BDD | ATDD | |
| Who | Developer | Developer, QA, Product Owner |
Developer, QA, Product Owner |
| Purpose | Unit Test | Understanding Requirements |
Automated Acceptance test |
| Notation | Code (software language) |
Structured plain English (Gherkin) |
Structured plain English (Gherkin) |
| Definition | TDD is a development technique that focuses more on the implementation of a feature |
BDD is a development technique that focuses on the system’s behavior |
ATDD is a technique like BDD with emphasis on capturing the requirements |
| Process framework | Agile | Agile | Agile |
Let’s dive deeper into the respective methods.
Test-Driven Development
Test-Driven Development has 3 distinct phases:
- Develop test (Test should fail)
- Develop code (Test should pass)
- 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 implementation |
|
| It helps to understand the code by providing examples |
|
| Defines “Done” |
Behavior Driven Development
There are 4 work-flow phases defined in BDD:
- Discovery of use-case (defining the test)
- Develop test (Test should fail)
- Develop code (Test should pass)
- 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
There are 5 work-flow phases defined in ATDD:
- Discovery of use-case (defining the test)
- Develop Acceptance test (Test should fail)
- Develop test (Test should fail)
- Develop code (Test should pass)
- 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.
Conclusion
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.
