I’ve been teaching Acceptance Test-Driven Development (ATDD) for many years. At the start of every course, I ask the attendees for issues they have with their development processes. After they have experienced the ATDD process, including creation of acceptance tests, I review their issues to see whether they feel that ATDD will help, hurt, or be neutral in respect to those issues.
Here’s a sampling of the issues in the attendees words. According to them, ATDD will help in solving:
- Unclear requirements
- Missed requirements
- No detailed requirements
- Development without requirements
- Unclear business rules
- Poorly defined acceptance criteria
- Huge user stories
- Smaller stories leave gaps
- Not enough detail in stories
- Not enough testers
- Missing test cases
- Not enough time for testing
- Stories not verifiable until end of the sprint
- Test data not available
- Issues with integration tests
- Coding starts before tests are written
- Development team not understanding business process
- Acceptance tests written for coding, not testing perspective
- Communication challenges – IT is technical, business is not technical
If you have any of these issues, there’s a great chance that adopting ATDD will help in solving it.
In my book, Lean-Agile Acceptance Test-Driven Development, I have reports from many people on how ATDD has benefited them. Here’s a summary of those benefits:
- Rework Down from 60% to 20%
- Little Room for Miscommunication
- Workflows Working First Time
- Getting Business Rules Right
- Crisp Visible Story Completion Criteria
- Tighter Cross-Functional Team Integration
- Game Changing
- Saving Time
- Automation Yields Reduced Testing Time
As you can see, ATDD can benefit your process in many ways.