The old way of doing software development was to write tests after you wrote the code.
Although this method is better than nothing, it comes with its own set of drawbacks. One major drawback is that it takes longer to get results than writing the tests first because you have to wait for code changes before you can run and see any new test failures.
To combat this issue, a new technique has emerged called Acceptance Test Driven Development (ATDD). ATDD involves writing a set of acceptance criteria for your features to help determine when an application is done.
Acceptance test driven development is a methodology that has been gaining traction in the software industry for the past several years.
But what is acceptance test-driven development? Acceptance test-driven development (ATDD) is an agile methodology of developing a product by breaking its development into a series of tests and building the product incrementally until it meets all the specified criteria for testing. The main benefit of this process is that it enables teams to develop their products or services iteratively, providing visual customer feedback at every stage of the development cycle.
This article will go through the acceptance test driven development, how it works, and some best practices to get started with it.
The problem with the traditional software development
Before learning more about acceptance test-driven development, let’s first go through the traditional software development life cycle or waterfall type of software development.
In the traditional software development life cycle (SDLC), the product development team gathers requirements from the business. In this part, business analysts and system analysts sit together and understand what features the customers need. Then, based on the requirements, they create a picture of the final system.
After that, the project manager creates the user stories, epics, and development tickets. Then, once the business side completes the requirements, the development team sits to code the entire application.
They communicate the deadlines to the stakeholders. Also, based on the business needs, the QA team creates the appropriate test cases. Finally, developers code the application day and night to meet the deadlines.
Finally, the application is ready. Yaay, developers are tired but happy that they completed the work. Next, the developers present it to the testers. Once the QA checks and approves the final delivery, the application is presented to the end-users for acceptance testing.
Business users, end-users, stakeholders look at the application, run their business test cases. Then, they test the application as comprehensively as possible. Finally, the application passes through all the user criteria and is given a sign-off for production.
Straightforward, isn’t it?
Clean flow, no hassles, no bottlenecks, application coded, tested and deployed.
But this is rarely the case!
And this is where acceptance test-driven development comes in. By nature, the only constant in software development is the change. Frequent modification of requirements is a nightmare for the Project Manager and Product owners. But the changes are inevitable.
In some other engineering industries, change is not possible. For example, you can’t set out to build the house but then decide on an entirely different room arrangement in the middle of the project execution.
However, in software development, application development almost needs to support the changes. So here, acceptance test-driven development comes to save your project.
What is acceptance test-driven development, and how does it work?
In the acceptance test-driven development, the developers, testers, and end-users work collaboratively to understand how the application should look. They work together instead of just business analysts bridging the gap between developers and end-users.
The stakeholders become part of the process of the development. Before any software coding begins, the acceptance criteria and the acceptance tests are created to create less room for surprises later on. Acceptance test-driven development is an agile process that aims to bring the end-users and the product team both on one page, maximizing close collaboration so that back and forth communication or understandings gaps are removed as much as possible.
How ATDD combats the waterfall approach deficiencies
If you look at the traditional waterfall approach, several things usually go wrong. There can be multiple stakeholders, and different stakeholders require different features.
Furthermore, while requirements are discussed, stakeholders and the product team never discussed the final application in the first place. As a result, when presented to the final users, it is not rare that the final application is different from what the users had envisioned in the beginning. Hence while the requirements might be meeting, and the application is performing as it was discussed in the beginning, business and end-users might request further changes in the application before the company can roll out the application to the production.
At the heart of ATDD lie acceptance tests. They define the agreement on how the application should work.
Acceptance Tests
The word “acceptance” in the term “acceptance test” means that these tests verify that a system satisfies a set of requirements. A product’s stakeholders typically specify acceptance tests. They are created to exercise the user interface and validate business logic, among other things.
Acceptance tests are written by the customer or product owner, not by developers. That fact makes them different from other types of tests. Usually, developers and testers write the tests to validate software functionality during development before releasing it to production.
In acceptance test-driven development (ATDD), acceptance tests drive your development process. In other words, developers write the code to ensure it passes acceptance tests. By having acceptance tests as a guideline, the development team produces only features that tests have specified. They don’t build features that no one asked for, and no one will be using.
This means there are fewer surprises when you deploy your changes to production.
Acceptance tests do not aim at solving every aspect like how big the text box should be. Instead, they solve the system complexity reflecting the behavior of the final system. In a nutshell they:
- Mention the inputs and output for any particular flow or behavior of the application
- Show the behavior of the system for different stage changes
- Provide the final view of the system according to the stakeholders
Until the tests are agreed upon, no coding takes place. The acceptance tests ensure that code work is minimized to satisfy only the business needs, and rework on code is reduced from the beginning.
Why Consider Acceptance Test-Driven Development
As discussed above, ATTD aims to bring the stakeholders on one page. The main advantages you get when adopting the ATTD approach of development are:
- There is less misunderstanding between the teams.
- There is less useless back and forth communication.
- From the beginning, every stakeholder understands what the end product will achieve.
- User stories are concise and precise, and they reflect the final system.
- Stakeholders know what the final system will look like and what not to expect.
Implementing ATTD
Because ATTD focuses on a framework that requires building tests that stakeholders can accept, it is necessary to have an adequate team structure that satisfies this need.
The team structure is made based on the flow of tests:
- Create and write the test cases – This is the responsibility of both the stakeholders (customers or clients) and the business analysts. Business analysts from the product development team create test cases based on the analysis of the requirements and feedback from the stakeholders. Stakeholders review, write or modify the test cases based on their needs. They also need to keep in mind the final state of the system. Every test case is a step toward a completed system.
- Implement the code according to tests – This is the responsibility of the developers. Developers write the production code that satisfies the failing test. Here, the target is to write the minimal code that is required for the final acceptable product. After the test passes, they can safely refactor the code to make it better.
- Execute the tests for the final needs – Testers are responsible. First, the developer performs the unit testing. But there might be other forms of automated testing, such as integration tests and UI test suite. After that, the tester performs functional testing. He makes sure that the application is running successfully against all acceptance test criteria and the outputs are exactly as desired. If there is time, they can also perform exploratory testing. Finally, end-users go through the acceptance test cases to be satisfied with the system’s validity. Testing can be both manual and automated. By automating the acceptance testing phase, you can perform much faster regression testing in the future.
Make sure every person in your product team is aware of their role. The above is not the final version. Of course, based on the needs of the project and team members and the size of the project, more people can be onboarded to facilitate the process. However, in the absence of any good team and assigned responsibilities, the whole project can fail.
Disadvantages of Acceptance Test-Driven Development
ADTT is a very comprehensive framework for designing systems. It removes the communication gaps and brings all the stakeholders together as well. But every good thing comes with a cost:
- ADTT is a magnificent process, but not all companies feel it is necessary. They might consider the comprehensive requirement gathering sessions as useless or a waste of time. Secondly, writing tests and reviewing them might be annoying to some team members.
- Communication between technical staff to non-technical people requires great patience. Bringing business on one page with the development team can be challenging for the Product Manager.
- Further, comprehensive test cases take a lot of time. Collaborating with all the stakeholders and bringing everyone on one page can become a tiresome job. Because of this, project deadlines might suffer.
Acceptance test-driven development vs. Behavior driven development
A lot of developers rely on code to guide their design. However, code doesn’t always give the best UX. One way to fix this is to use behavior-driven development (BDD). BDD is a testing technique that focuses on defining software functionality through the perspective of the user. It utilizes specific, concrete examples of how the end-user should interact with your software to produce specific responses. BDD uses techniques like Gherkin to help teams focus more on testing their software with end-users in mind.
Behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD). The difference between BDD from TDD is that the BDD employs the natural language to specify what a piece of software should do in a “Given,” “When,” and “Then” format. BDD tests have the following format:
Given <some user>,
When <user performs the action>,
Then <some output happens>
When it comes to comparing ATDD vs. BDD, there are a lot of similarities. For example, they both try to use simple language to describe the application. However, the key difference is that BDD focuses on explaining the behavior of the feature, while ATDD focuses on gathering the system-wide requirements.
In conclusion, they are pretty much the same. The only difference is that ATDD might cover a wider area of the system in one test.
Acceptance test-driven development vs. Test-driven development
Acceptance test-driven development (ATDD) and test-driven development (TDD) both use tests to verify the functionality of a software program. The main difference between the two is that ATDD uses acceptance criteria to help control the design and implementation of the system. These acceptance criteria are written by the end-user and not by the developer.
ATDDs involve the customer in creating the unit tests, and they help develop an understanding of how the system should work. The tests and the design evolve together. The customer and developer work as a team to ensure that the system is working as it should.
TDD involves unit testing in the development process as a fundamental step. The developers use a unit test to get feedback on whether the units work when isolated.
Conclusion
You can control the quality of software development by changing your development process. By using ATDD, you can have better communication between developers, testers, and end-users. As a result, all parties involved will know what to expect from the software, which leads to better-designed software that users love!
So take advantage of this process the next time you think about how to improve your development efforts.