A quick guide to implement ATDD in Agile Teams-A Case Study

Collaboration is one of the core values of Agile. While I was working on a large project I noticed lack of collaboration between developers, QA’s and business folks, lack of clarity in requirements, frequent scope creep into requirements, team having no visibility on the testing being done and finding defects late in the project lifecycle. Most importantly no one had any idea about our automation framework and all the automation tests were written after the features were deployed to QA.

Based on these findings I started doing research on how people tackle these kind of problems. As a result, I found ATDD (Acceptance Test Driven Development) as one of the approaches to mitigate some of these problems. It is often been used synonymously with BDD (Behavior Driven Development) and TDD (Test Driven Development). The main distinction of ATDD compared to other approaches is, its focus on making developer, testers, business, product owners and other stakeholders collaborate and come up with a clear understanding of what needs to be implemented. It also focuses on how automation can be leveraged early in the SDLC.

Come join me in this session, where I discuss the problems my team had before implementing ATDD and how I trained the entire team of 25 people on different practices to encourage collaboration, learning and re-instating the mindset of One Team, One Goal. I also discuss the process changes that happened due to ATDD, how my team could leverage test automation throughout this process and finally share the lessons learned from the implementation.

This session is based on my real life experiences of how one single tester can make a HUGE impact in the team if they care about the testing craft and recognize collaboration is the KEY to successful delivery of products.