Do we need Narratives and Acceptance Tests?
Some agile/XP projects that I have worked on or know off, use user stories as a planning tool. But then, they have Business Analysts [BAs] who take the stories and write detailed narratives. Based on these narratives the QA/BA would write acceptance tests.
According to me:
It‘s duplication of information. Both the narrative and acceptance tests communicate the same piece of information: “what the system is supposed to do?“ or from a developer‘s point of view “When do I know I‘m done?“.
Acceptance tests are any day better. They are automated and eliminate ambiguity.
They can be excellent tools to measure progress at any given point of time. [Can be good input data for the burn down charts]
Usually people who favor narratives give the following reason. “We have some requirements that cannot be expressed as an acceptance test; we need to write a description.” I would really question that requirement. Because we have requirements who‘s testing cannot be automated. This means the requirements are not testable. [Did I triggered a fear training in your mind?]
I really like Jim Shore‘s How I Use Fit post. That‘s exactly how I would like to use FIT or any acceptance testing framework.
