Thorough testing is the only way to ensure that apps work as intended. We cover 4 software testing levels your app should go through from planning to release.
TDD vs BDD vs ATTD: key differences and benefits
There are 3 development methods that integrate quality into software development.
Acceptance test-driven development.
And behavior-driven development.
Software projects fail left and right in the unforgiving market due to running out of budget.
That can happen because they didn’t test often, and they didn’t test early.
The software development methods we’ll talk about here will remedy that by making sure quality assurance starts when development starts.
Although all 3 of them are similar, there are many key differences.
Here we’ll talk about their importance, how to do them and what separates them.
Let’s dive in!
What is shift left testing?
We can’t speak about TDD, ATTD, or BDD without mentioning shift left testing.
It’s a movement in agile software development that advocates introducing testing from the very beginning.
As you can see from the image, traditional testing starts late in development.
Shift left testing, however, starts right at the beginning, even before early design starts.
That means quality assurance is integrated into the project from day 1.
Not only that but it also means you’re constantly catching bugs and problems early. Leading to:
- Higher quality
- Money saving
That last point can be best illustrated by the below graph.
Let’s unpack that.
Most defects in software development are introduced when coding starts.
Those defects start being discovered around the time unit testing starts.
Now here’s the most important part.
The cost to repair defects rises exponentially as development draws to a close.
When unit tests start it already costs 4 times more than it would if the problem was caught during coding.
By functional testing it’s 10 times.
By system testing it’s 40 times.
By release, it’s 640 times. That’s not 64. It’s 640.
Let’s say you have a problem that would initially cost you $100 to fix.
By release, it’s $64,000. That kind of money runs you out of business.
That’s why shift left testing is so important and that’s why development methods that adhere to it are valuable.
Now let’s take a look at them.
What is Acceptance test-driven development (ATTD)?
The first method I’ll discuss is ATDD or acceptance test-driven development.
Acceptance tests are written from the perspective of an external user, such as a client.
These tests are business facing and they support programming.
Acceptance testing comes right after system testing before making the product available for use.
They are a great tool when written before the code and the user’s executable specifications.
But acceptance tests need acceptance criteria in order to be done right.
Acceptance criteria are basically a list of priorities for development.
For example: Documentation can be put as one of the acceptance criteria which means acceptance tests will take that into consideration before they can be passed.
All that being said let’s take a look at how ATTD looks in practice.
I call them the 4 D’s:
Let’s get into each of those steps.
Source: Quinta group
Discuss – During this phase, you discuss the user story. That means you discuss what the customer needs from the product at the end of development.
Distill – Here we agree on the acceptance test and automation criteria. We also consider different scenarios and how the system will behave during those scenarios.
Develop – Now, actual development happens. You develop a feature following the Test First Development approach until it’s passable.
Demo – Here, you demonstrate the prototype model to the business stakeholders and start iterating.
Pros and cons of ATTD
Let’s look at what the benefits and flaws of acceptance test-driven development are.
- Clarifies requirements
- Faster problem resolution
- Improves collaboration across teams
- Focused on customer needs
- Guideline for the entire development process
- Easy to manage
- Developers get to know the QA aspect and vice versa
- Process heavy
- Less flexible than TDD or BDD
- Automated testing is a must
- Not easy to work this way
With ATTD out of the way, time to turn to TDD.
What is Test-driven development (TDD)?
During test-driven development, we test every single change.
Tests are built to check for errors before we start development. We use those tests to guide code creation.
If a test spots a problem, we stop development and start working on a fix. This sort of development makes the whole process extremely efficient.
It’s a process in which test cases are made first and code is used to validate them. It depends on the repetition of a very short development cycle.
Test-driven development is a technique in which automated Unit tests are used to drive the design and free decoupling of dependencies.
We generally follow the below steps.
It’s a simple process but not an easy one.
Let’s dive into those steps.
- Add a test
- Run all test cases
- Write the code
- Run the test case
- Refactor code
Add a test – Write a test case that describes a specific function. In order to make the test cases the developer must understand the features and requirements using user stories and use cases.
Run all test cases – When you run all test cases you want to make sure they all fail.
Write the code – Here you write the code that passes the test case.
Run the test case – Now the test case should pass.
Refactor code – We do this in order to remove code duplication or redundancies.
Repeat – The steps are repeated again and again.
With steps out of the way let’s look at the pros and cons of this development approach.
Pros and cons of TDD
Test-driven development is great, but it does have some pitfalls.
- You only write needed code
- More modular design
- Easier to maintain
- Easier to refactor code
- High test coverage
- Less debugging
- Different bug introduction technique
- Test Maintenance
- Slow change process
- All or nothing approach (either every team member uses it, or no one uses it)
Having finished with TDD we move on to the final approach.
What is Behavior-driven development (BDD)?
It’s an approach that supports joint efforts among designers, developers, QA, marketing, and other non-tech members (PM/PO).
Behavior-Driven Development is an Agile software development process heavily influenced by TDD and DDD (Domain-driven development).
It permits the QA to develop test cases in simple, readable language.
Conversations and examples explained in understandable language are at the core of this development method, bringing a better understanding of the system’s behavior.
Automated testing especially thrives during BDD because it’s more focused on system behavior, rather than code implementation.
Basically, it makes sure every new feature is in accordance with desired system behavior.
Behavior-driven development can be broken into 3 phases:
- Discovery phase
- Formulation phase
- Automation phase
Discovery phase – Here we hold conversations and product discovery workshops to research and determine acceptance criteria.
They’re chosen by considering a few factors:
- Core features
- Target persona
- Product type
The product manager is heavily involved during this phase, along with the project manager, QA engineer, and developers.
Formulation phase – After finishing the discovery phase it’s time for implementation. This phase ensures that acceptance criteria are applied before development begins. That’s done using acceptance tests.
Automation phase – Here we automate acceptance tests. The goal of this phase is to have acceptance tests run constantly to make sure criteria are met and that new behaviors fit the system.
Pros and cons of BDD
As with the previous 2, let’s take a look at good and bad aspects of this development method.
- Requirements are defined in standard approach using simple language
- Focuses on how the system should behave from the customer’s and developers’ perspective
- Reduces effort needed to verify any post-deploy defects
- Communication between users/client and PM/PO is key
- Dedicated development team should be involved in the definition of new features
- Maintenance requires effort and time
- Doesn’t work well in short projects
Now that we’ve described all three development methods let’s take a look at how they compare.
ATTD vs TDD vs BDD: key differences
To better understand each development method and to see which suits you, here’s a table comparing them.
ATTD focuses on requirements
TDD focuses on feature implementation
BDD focuses on system behavior
Developers, customers and QAs
Developers, customers, QAs, and product manager
Plain English, and Gherkin
Programming languages like Python or Java
Plain English, and Gherkin
Writing Acceptance tests
Writing Unit tests
Understanding Acceptance criteria
Not as easy as TDD
Easier to track down bugs
Not as easy as TDD
Projects involving the end user and with high UX prioritization
Projects that don’t involve the end user
Projects involving the end user
Cucumber, JDave, JBehave, FitNesse, Spec Flow, BeanSpec, Gherkin Concordian
Gherkin, JBehave, Dave, Cucumber, Spec Flow, Concordian, BeanSpec
EasyB, Spectacular, Concordian, TestNG, FitNesse, Thucydides
TDD vs ATTD vs BDD: the verdict
Have you decided yet on which development method best suits you?
Well, that’s because each of these methods has its merits.
TDD is extremely focused, allowing no unnecessary code to be written. If you’re on a tight budget that’s the way to go.
ATTD builds on TDD, adding business stakeholders into the equation. If you’re more customer oriented, you should use this method.
BDD is all about making features comply with the desired system behavior and it does so through straightforward language. So if you want the best collaboration between developers, testers, and your product team, choose BDD.
Alternatively, we’re here to worry about all that. Our software development experts will choose the right development method for your project and execute it to perfection.
Feel free to contact us.