The Agile approach for development has gained vast popularity as it supports timely, faster and high quality working software delivery that meets customer needs. Some of the published agile processes are Test driven development (TDD), Extreme programming (XP), Scrum, Adaptive software development and the likes.
There are unique factors that help choosing one framework over another. However, the standard parameters remain the same – Easy to learn, use and implement; Supporting tools and the value generated for the customer.
With Acceptance Test Driven Development (ATDD), business customer, the tester and the developer collaborate to produce testable requirements. They help the customer to clarify their needs, the developer to have an objective to code forward and the tester to plan for more than just functional testing.
Acceptance Test driven development (ATDD) offers a collaborative and simple approach where the product owners, developers and testers discuss the requirements by addressing the questions – “What is needed?” and then “How we will know we have done that?”
Understanding the requirements or stories is the most critical part of the Sprint. There is always a possibility of misunderstandings. Questions are usually asked by developers and testers on things that they are aware they do not know. This is called “known unknown”. But it is the “unknown unknown” that causes problems. And one of the simplest ways to address this is clear conversation, alignment to what the end result should look like and most importantly – an agreement on the criteria that will define the completion of the work.
The objective is to have specific answers, with examples if possible. ATDD focuses on having the acceptance tests specified up-front, before any coding takes place. This little extra bit of work helps avoid misunderstandings before writing any code, by getting all teams together.
Let us further see on the significance of ATDD.
- A. You have been doing some ATDD already – In your agile scrum approach, you may be already brainstorming User stories with specific examples to validate the ‘Done’ or acceptance criteria. “Meeting the requirements” may be too generic in the sense that – developers will write code keeping in mind the quality (for easy maintainability) and testability of functionalities & testers will ensure the piece of software meets customer needs. The Sprint delivery can be optimized by designing executable test cases for the user stories, thereby defining the ‘Done’ criteria.
- B. The ATDD solution helps –
- Developers write code with ‘Testing’ in mind
- Receive quick feedback on code quality
- Outlines the specific feature
- Clear details to let the developers /testers know when they are ‘Done’
- Fosters communication between the engineering and business customers
Test the code (Test driven development – TDD)
Test the product (Acceptance Test driven development – ATDD)
C. Automation and ATDD-Working with ATDD with your testing automated certainly is an icing on the cake. But you actually do not need to automate testing using sophisticated tools to see value from ATDD.
While working with a healthcare company with an objective to automate the test cycles, we were, for about 6-8 months deprived of approvals due to an Organization change happening at their end. We did not let go waste this time just waiting. Instead, our team gathered to brainstorm the user stories and distil them into executable test cases. The only tools used for this exercise were white board, markers and excel sheets. The developers were equipped as well with more clear objectives to write code matching the expected output of each user stories.
D. There are no special skill or tools required to perform ATDD –
- Understand and Write User stories
- Extract Acceptance criteria from User stories
- Convert Acceptance criteria into executable Acceptance test cases
- Write code to match the Acceptance test cases
Probably, communication is the key to perform ATDD. To implement and reap the benefits of ATDD, here is all that you need –