RequirementsAsStoriesAndTests

For the past five years I have coached many teams on adopting Agile Software Development. As I have worked with the development teams coaching on techniques such as TDD/BDD, pair programming, simple & evolutionary design, etc. I have seen the number of defects making it to QA/testing drop dramatically.

One type of defect that I haven't always seen drop as dramatically is "missed requirements.” Often the developer believes they have completed the story only to have it pushed back from the tester due to missing requirements. I have seen teams add a queue or stage on their story board for a business analyst to review the card prior to testing. This back and fort is a waste of time and that can be prevented.

When the customer or business analyst sits with the team and communicates the requirements to the developer and tester as they are developing their respective portion of the deliverable the likelyhood of missing requirements dimineshes. The problem with this approach is that the customer may forget to communicate a feature of the developer may not as questions that lead to discussion on a specific feature.

A solution to this problem is the inclusion of acceptance tests with the stories. I would like to discuss how to go about implementing this practice. I will cover:

• What is an acceptance test? What should it include?
• Challenges in introducing this practice to a team.
• The advantages of automating acceptance tests.
• Tools that can be used to automate acceptance tests in ruby and java.