Distributed Agile: Acceptance Test Driven Development (ATDD) in Practice

In one of my posts (Agile Testing – Incremental Functional Test Approach) I discussed about the impedance mismatch between developers and tester in Agile team. The basic issue is – testers receive the user-stories at the end of sprint when you definitely won’t have sufficient time to test it. To resolve that problem, we came up with an idea of splitting the user-story in functional tasks so that at the end of each functional task, tester could test it. That way tester can test in incremental way rather than waiting endlessly for a Ready for Test user-story.

Moving a step further, how about getting away from breaking user-story into functional sub-tasks and just write acceptance tests at the beginning of sprint itself? Developers then have to make sure that they develop the code to satisfy those functional test cases. Here acceptance test cases are not written in English prose but in a DSL structured in English (understandable to anybody).

However currently the way we practice acceptance criteria (from PO) implementation is mostly adhoc in Scrum based projects. In practice, I am not sure how many Sprints are actually tested thoroughly by Product Owner and how many POs still define any acceptance criteria in the user-story. Again, the translation of written acceptance criteria in English (or native language) to technical tests also is not sure to get verified from PO side depending on the technicality of test cases.

Another problem from distributed Agile perspective is – tester may be sitting with the offshore team and may have less oppurtunity to talk to PO which happens in practice in many projects where PO is involved in many other things other than project. Ideally PO should be fully dedicated to one project but in practice, I have seen PO to be involved in multiple things. Getting his time for explanation sometimes becomes precious to the team especially at distributed end where core working hours between both onsite and offshore team are even less because of timezone difference.

So we have a problem statement as follows:

• PO may not have sufficient time for the distributed team as and when needed by the tester sitting with distributed team
• Acceptance criteria (in English) are either not written or sometimes lose their validity in technical translation.
• Customer is not sure right translation of English prose based acceptance criteria into technical acceptance test. Also criteria sanctity may get lost in regression tests later.

Because of all these issues, though Sprint Demo become successful but that may or may not ensure into production ready application.

Let’s take a different approach.

How about PO or QA person sitting at customer location starts writing acceptance tests in English based DSL. However now that English based DSL becomes acceptance criteria in technical language for developers too. Woohoo…That’s a win-win situation. Isn’t it?

Here is a functional test-case written in easyb (BDD based framework)

[groovy]
scenario "User submits invalid credentials and gets to the login page again",{
given "Open the login page",{
}

when "User enters invalid password", {
}

then "User should be with login page again", {
}
}
[/groovy]

That’s all a PO or a QA person has to write to create a functional test for “invalid-credentials check” on login screen. How this test case gets implemented is more of a developer’s headache :).

In above snippet, the “scenario” itself explains what’s functional test all about, “given” is the pre-condition, “when” is the actual work done for executing the function and “then” is the post-condition or the result of the test case.

As you can see the test case is written in English but it serves as the technical specs for the developers and they need to make sure that they pass this acceptance test as part of definition of DONE (DoD) for the user-story.

Conclusion

This is an example of Acceptance Test Driven Development in practice for distributed teams.
Here PO/Business analyst/Tester is involved in writing the test case they want to get implemented with local or distributed development team in their own technical DSL.