This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Agile Requirements Gathering is Not Just About Stories
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
In it, he talks about the use and misuse of Story Cards to capture requirements. To sum up, Story Cards are not 3x5 requirements documents. They are placeholders for a more detailed discussion about the business requirements.
But how and where are these requirements ultimately captured? According to XP literature, this is the role of the Acceptance Test. A Story has one or more Acceptance Tests, created by the stakeholders, that define the correct behavior from their viewpoint. Ideally, these can be automated.
I've seen a lot of discussion on Unit Testing, Test-driven Development (TDD), and other developer-oriented testing, but there is a much smaller body of work for what is arguably a much more important activity - Acceptance testing. This is the Agile equivalent of a functional specification, regression test suite, requirements document and safety net all rolled into one.
Why are acceptance tests so important? There isn't any other artifact in an Agile process that captures the details of a Story in an unambiguous way. It's a way of recording customer intentions and decisions for posterity. Unit tests are great for module level verification of code, but they don't address business functionality. How do I know if I'm breaking an important feature if I don't know how the end-users are using it?
Part of the discussion in the James Shore article is around FIT (Framework for Integrated Test) as a tool for facilitating the creation of these tests. FIT supports documents in HTML (that can be written using Word, for example) with a mix of prose and test tables. The idea is that you can wind up with an human-readable specification, created by customers, along with an executable set of test examples in table form. Programmers then write test fixtures to make the tables run and pass or fail.
This stuff isn't exactly new, but in many of the organizations I've worked with, very little of this is going on in practice. In organizations with QA teams, some acceptance testing occurs naturally, but is still not entirely from the customer viewpoint, it's from a tester's perspective. Stakeholders often don't see creating acceptance tests as part of their job - "What are we paying you developers for?"
The idea of FIT is to remove some of those objections by making test creation easier, instead of making customers work harder. As more tools like FIT become available, they can only help improve the outcomes of Agile projects.
And as practitioners, we need to remember the fundamentals: Discover, Design, Implement, Verify, Repeat. The "verify" part isn't just at the code level, it has to be at the business level too.
Previous Topic
