A Quick Guide to Implementing ATDD

This article provides a quick guide to anyone interested in implementing ATDD in their teams and projects. It outlines the benefits of following this Agile approach based on my firsthand experience on a corporate software development team.

Collaboration is one of the core values of the Agile methodology. Once, as I was working on a large project, I noticed a lack of collaboration between developers, testers, and business-minded individuals; a lack of clarity in requirements; frequent requirements scope-creep; a lack of visibility in regards to the testing completed; and defects being identified late in the project lifecycle. Most importantly to me, though, was that no one had any idea about our automation framework, so all of the automation tests were written after the features were developed and ready for testing. Because of these observations, I began researching how people tackle these kinds of problems. As a result, I found Acceptance Test Driven Development (ATDD) as one of the approaches used to mitigate many of these issues. It is often used synonymously with Behavior Driven Development (BDD), Story Test Driven Development (SDD) and Specification By Example (SBE). The main distinction of ATDD, as opposed to other agile approaches, is its focus on making developers, testers, business people, product owners and other stakeholders collaborate as one unit and create a clear understanding of what needs to be implemented.

Based on my own experience, I am going to share my ideas on how teams can implement ATDD in their own projects.

The Context

I worked at a large company that had a startup mindset, so any innovative ideas and feedback were encouraged by the team. We quickly built prototypes to see if an idea would make our product better or would help in the overarching company goals. I was the lead tester in a 25-member team, which consisted of one scrum master, one technical lead, and multiple business analysts, designers, developers and testers. As a result of the culture of innovation, there was often chaos within the team, including frequent changes in feature requirements, individuals working in siloed environments, and team morale being at an all time low. This was concerning to me, so I volunteered to assist in finding a resolution to these pain points, which led me to ATDD.

All my learnings and experienced with ATDD can be categorized into below 3 steps.

The ATDD implementation cycle

Created by Raj Subramanian

Step 1 - Training and Experimentation

There are many ways of approaching tasks, especially when considering individuals experiences working in different agile teams inside and outside their current organizations. In order to bring a shared and common understanding of the team and organization’s goals, it is important to provide the proper training. In regards to ATDD specifically, it should include goals, objectives, expectations and the information about the results that will come from using this approach. After training, it is important to start with a small-scale implementation in order to try different things and receive iterative feedback.

For example, after researching ATDD, I explained to the different stakeholders why we needed to explore this approach and what benefits we would receive from it. I highlighted a few of the possible positives such as increased team collaboration, better clarification of requirements, earlier identification of defects within the software development life cycle (SDLC), increased visibility and earlier use of automation in the SDLC, as well as involvement by the whole team in coming up with clear acceptance criteria.

During my discussion with the stakeholders, I emphasized that this would require some experimentation, but without trying it, we could never know its benefits. After a few lengthy discussions, we decided to split the original team of 25 people into 2 smaller teams: Team A  consisted of 12 people, and it would implement ATDD. Team B had the remaining 13 people, and it would continue doing what it was already doing.

I planned a 2-day training workshop for Team A by learning about ATDD, determining which concepts made sense in the context of our project, and how we could leverage automation throughout this process. I included a mixture of theoretical and hands-on exercises in the training. Some of the exercises are below:

• How to write Gherkin statements - Given/When/Then (GWT)
• What are the key attributes of a good user story?
• A demonstration of our automation framework, including both how it worked and how was it structured. There were also exercises on how to write simple automation test code as a team. Before the workshop, a team member and I modified our automation framework to be in sync with the ATDD approach. We used the Cucumber plugin with Java and Appium for our automation framework.

Source

Step 2 -  Increasing Visibility

When a project lives through multiple sprints, it is easy to lose track of the different processes which need to be followed. So the key is to make the goals, objectives and expectations visible to the whole team.

When we began using ATDD, I started by simply writing down each of the daily processes that would need to be followed on a whiteboard, which I placed where our team had its daily stand-up meetings. Onto each user story I added a checklist of items which needed to be done before the story would be considered complete. This way, there was no ambiguity on what ATDD processes need to be followed. One such checklist item was a kick-off meeting, during which the developer, tester, and business people discussed the requirements as a team, identified which requirements could be automated, and outlined the acceptance criteria of the story in GWT format. Another checklist item was the QA-Dev Handoff, where the Developer would show the tester, via a quick demo or discussion, how the requirements had been completed and what unit tests were written as part of the story. Through this handoff, the tester learned which areas were not covered by unit tests and developed a better understanding of the implemented feature, therefore leading to better test coverage. Checklist items were sometimes obvious, but good to have clearly stated. We included one to ensure all the defects associated with the story were closed; another was final approval by a business person upon viewing a demo, ensuring the feature was built according to the previously set requirements and expectations.

We also started having a "Process Hawk". This was an individual team member; it could be a scrum master, project manager or anyone who would ensure the team would follow the process. In my case, it was another senior tester within the team; he and I regularly reminded everyone to follow the ATDD process in all meetings, including standup, planning, retrospective and other team meetings.

Step 3- Iterative learning and feedback

Having a constant feedback loop is crucial in the implementation of any agile approach, including ATDD. Having weekly or bi-weekly retrospective meetings with the whole team is an important way to know which parts of the process are actually benefiting the team, and which ones may need to be modified. As we already know, something that does not help the team leads to wasting time and effort.  As Brian Tracy, author of  Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time states, "One of the very worst uses of time is to do something very well that need not to be done at all."

In the current era of information technology, organizations cannot afford to waste time and energy on ineffective approaches; rather, we need lean and effective processes in place. This ties in with the lean startup principle of Validated Learning: the Build, Measure, Learn cycle.

With this in mind, I started having 30 minute meetings every Thursday with Team A to check in on how the team is doing with the new process. This was a good way to gauge what changes needed to be made based on reactions from the team. This meeting occurred separately from the retrospective meeting which was at the end of the 2-week sprints. This approach brought continuous feedback from the team, allowing us to make immediate and effective changes. Feedback was not solely from the weekly process check-ins; the daily stand-up meetings also proved to be a valuable source of information. The individual team member updates and discussions uncovered red flags related to the process, and we were able to immediately address them before they affected the rest of the team.

Summary

As a result of following the ATDD implementation cycle, Team A started to see considerable differences in team morale, collaboration and requirements.

Team Morale

Everyone started working as a team and felt empowered. Each person owned a story right from start to finish. He/she ensured the story had all the necessary information to start development and testing work. The team member also ensured all follow ups related to the story were done. Finally, the person was in charge of demonstrating the story to all the stakeholders at the end of the sprint. This feeling of ownership significantly boosted the team morale.

Collaboration

The kick-off meetings brought the business person, developer and tester together, in order to develop a common understanding of the user story. The QA-Dev Handoff, which happened before pushing the build to the QA servers, helped both the developer and tester know what testing would be completed as part of the story, and brought a better understanding of the implemented feature. There was increased visibility in automation, since the whole team took ownership, instead of just the testers. Finally, in the planning meetings, the entire team discussed the story together, therefore generating more ideas, questions and discussions. Increased collaboration also led to increased learning - the team decided to have peer-to-peer coaching sessions to learn from each other, testers started doing paired exploratory testing and lunch-n-learn sessions were hosted by different team members to discuss various topics regarding technology. All these things led to improving overall team collaboration.

Requirements

One of the main issues with our previous processes was frequent changes in requirements and scope creep. With the ATDD approach, it was imperative that once the developer started working on a story, the requirements became locked. Any changes must be prioritized alongside the other upcoming stories and added to the upcoming sprints. This reduced the workload of both developers and testers, and prevented the stakeholders from having unrealistic expectations of completed features.

After seeing all the above improvements Team B began implementing ATDD as well. As a result, the entire original team used this approach after regular experimentation and feedback.

Conclusion

I recommend the approach of ATDD, and it aligns with the "Shift Left Paradigm" which states development and testing should start as early as possible in the SDLC. It brought more visibility into automation as we began writing automated tests at the beginning of the SDLC, which in turn increased collaboration within the team.

Source

Remember, ATDD is not a "one size fits all" solution. It was the agile approach that made the most sense in the context of my project, but there are various other ways to improve processes in teams. I used this approach because of the focus on better acceptance tests, but more importantly because of its emphasis on collaboration. The collaboration piece is an integral part of this approach, and I believe to be the most valuable.

About the Author

Raj Subrameyer is a tech career strategist focusing on helping people to land their dream job and become successful leaders. He is passionate about guiding professionals to maximize their opportunities and discover their zone of genius. He uses his experience in the tech industry to research, speak and write about how we can embrace technology and become full-on digital citizens. He is a sought-after speaker at various conferences and has been featured in numerous podcasts and publications, including CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success and The Good Men Project. He is also the author of the new book - "Skyrocket Your Career". His areas of expertise include career advancement, leadership, motivation, productivity and entrepreneurship. In his spare time, he loves traveling and enjoying craft beer. You can find more info about how he serves people through his website.