The Power of Acceptance Test-Driven Development
Acceptance test–driven development enhances cross-department collaboration while maintaining a customer-driven focus. Learn how it works in our free guide.
Acceptance test–driven development (ATDD) is a programming technique in which test cases are determined before the application or program is written. It brings in a wide range of people with varying areas of expertise, including (but not limited to) software developers, software quality assurance engineers, business stakeholders, project managers, and product managers.
There are two goals with this approach. One aim is to prevent features from being implemented in a way that doesn’t meet customers’ needs. Another goal is to foster collaboration across departments, leading to a greater shared understanding of the application being produced.
This article will introduce ATDD, offering a summary of key concepts, an explanation of best practices to implement ATDD, and an explanation of what the process looks like to different team members.
Summary of key acceptance test–driven best practices
The following table is a collection of best practices by teams utilizing ATDD.
Is ATDD the same as TDD?
One methodology similar to acceptance test–driven development is test-driven development (TDD). The main difference between the two is that ATDD is higher level, placing less emphasis on technical functionality.
Another way of putting this is that ATDD focuses more on ensuring that the right features are being developed and less on building the features the right way. ATDD can be said to focus more on the users’ and stakeholders’ perspectives in determining what features are desirable. In contrast, TDD focuses more on the developer’s view of writing the feature technically correctly.
Benefits of adopting ATDD
There are some benefits of adopting ATDD as your team’s development process. As mentioned earlier, ATDD can create an environment where there’s greater collaboration between technical departments, such as software development and quality assurance, and between technological and non-technical sectors, such as business and management. There is greater visibility in the development process because more people are involved in the initial phase of determining the desired behavior of the application and the subsequent test cases that QA will develop to verify those behaviors.
Accordingly, an additional possible benefit is that this process can optimize the product so it is most in tune with customers’ needs. There is often a disconnect between the product’s vision and the developers’ interpretation of what’s expected. ATDD aims to ensure alignment and close the gap between the concept and the developers’ understanding of the product vision.
Finally, ATDD leads the development cycle to “shift left.” This means the product is subject to tighter and faster feedback loops even before any code is written.
Explanation of best practices
Document the feature being tested
In this initial phase, different members of the software development and quality assurance teams as well as business stakeholders meet to discuss the product’s vision. This includes discussing the technical requirements necessary to achieve that vision, the benefits the feature being developed will enable, and how all of this relates to the other tasks being worked on.
Document a user story
In this stage, the team attempts to best describe what needs of the end users will be met by the feature. They will discuss at length how the user will interact with the feature, and from here, the team can develop different logical flows of the product and testing scenarios.
Include customer-friendly constituent input
To ensure that the developed feature will be a welcome addition to the product, the team will include a constituent who’s customer-friendly and has a strong degree of empathy for the end-user’s perspective. It is even suggested to share documents detailing the proposed feature with this person before the meeting.
Some suggested people who can fill this role are those who serve in customer-facing, post-sales roles, such as professional services engineers, technical support staff, or customer service agents.
Plan for the three-amigos meeting
Before this meeting, documents should be prepared and shared with all participating members. The main goal of this meeting is to unite three different perspectives via representatives from business, software development, and quality assurance (source of the name “three amigos”).
The business representative’s goal is to present the problem that the feature will be trying to solve. The developer shares perspective on how to solve that problem. The quality assurance engineer questions the different aspects of that solution that could go wrong and what needs to be tested. The end product of this meeting is a list of scenarios that the three-amigos team can present to anyone in the organization, which will then serve as the foundation for technical specifications, manual test cases, and automated test cases.
Another idea is to ensure that there is a QA automation engineer present, in addition to the three amigos, who can speak about writing feature files that have correct syntax and good structure. This individual can also help with thinking through testing scenarios. The manual QA engineer can be creative in exploring scenarios and edge cases grounded on an intimate knowledge of the application.
It’s important to note that if the feature being discussed is already a part of the product, then the bugs that appeared during previous feature releases need to be discussed.
Document the test cases
Following the three-amigos meeting, test cases (including both unit and functional testing) can start being documented within test case management software. This test software can include the following, among other options: Jira X-Ray, Testrail, Microsoft Excel, and Confluence. Those test cases can be based on the feature file that documents the expected test scenarios discussed during the three-amigos meeting.
Create a preview environment for the feature branch
The team should create a separate feature branch to test all the code changes needed to complete this feature. Creating an isolated ephemeral environment for each feature branch avoids resource contention across development teams working on different product features and dramatically speeds up the overall testing process.
The team can use environment as a service (EaaS) tools such as Uffizzi to automate both deploying the test environments and removing them after the test is completed. Available in an open-source version and hosted service, Uffizzi’s documentation pages provide instructions on how to get started.
ATDD from different perspectives
ATDD is a process that requires buy-in from all members of the team, so it’s essential to understand how this will affect all the departments involved.
Business stakeholders
ATDD will help establish feature specifications that are shared between business analysts and software developers. The business department will have a better opportunity to convey the feature’s overall goal and their expectations for the product’s behavior following the implementation of the feature. This will lead to greater unity between the technical and non-technical sides of the team.
Manual QA
ATDD enables manual QA engineers to do their jobs better and even introduce more creativity into their workflows. Because the initial meetings will allow all departments to have a say in how the team will write the test cases and test plans, this alleviates manual QA and the burden of being the primary drivers of the overall testing strategy. This will give manual QA more bandwidth to conduct exploratory testing and discover more edge cases and difficult bugs before the feature is released to production.
Automation QA
With ATDD, engineers can write automation tests based on acceptance criteria and scenarios discussed with business stakeholders. Automation tests can better emulate how customers interact with the feature.
Software development
Since software engineers are introduced early in the conversation about implementing a feature, they can discuss technical limitations that business representatives and quality assurance may not be as inclined to notice. Furthermore, this will happen well before the sprint begins to develop the feature, which is the most efficient time to catch problems.
Software developers can also feel a greater sense of ownership over the feature instead of just being required to follow the expectations of the business stakeholders. As mentioned earlier, the expectations of the feature behavior are shared at an earlier stage between developers and business representatives, leading to communication between the two parties becoming more straightforward and less ambiguous.
Challenges to getting started
Given how remarkable some of the benefits may sound, it makes sense to look into implementing ATDD for your team. However, this can be challenging. One reason is that it requires cooperation from several departments within the organization, such as business, quality assurance, and software development.
A successful process implementation will also require all members to learn a new process, and new tools could be needed to make ATDD work more smoothly. This may make some reluctant to start because the first several tries will inevitably have rough patches and introduce inefficiencies that must be worked out.
Conclusion
Teams that can push past the initial potentially difficult phases of implementing ATDD may enjoy many benefits. Once ATDD is fully up and running, it can help everyone better understand what’s being developed, increasing everyone’s sense of ownership of the product. The development team will have a suite of automated tests they can use while creating the feature, ensuring that significant bugs are found sooner. This will also free up manual QA engineers to conduct more exploratory testing, further assisting in finding bugs sooner and allowing the engineers to exercise more creativity in their roles.
Like this article?
Subscribe to our LinkedIn Newsletter to receive more educational content.
