Over the last few years I’ve had lots of discussions with teams on how to cope with this thing we call Agile Testing. The same topics arise over and over again, with the same kind of discussions. The main question is ‘How do we handle all these Use Cases, User Stories, Test Cases and Requirement Documents in this Agile Journey’
‘First we had software requirement specification documents, from these documents we derived our test cases…..’. We worked with the RUP, used CMMI or even worse the freighting DOD or MIL standards! Now you try to ‘help’ us in using user stories, but what about the use cases and the test cases? how do they relate? what about my Master Test Plan, Feature List, Test Specification and the like? Are they not needed anymore?

First of all, an approach that worked for me several times is to start with what is already used and only propose to remove or change things when it becomes clear that things are not needed anymore. So if e.g. people are using an Master Test Plan, let them use it until it becomes clear that the way they’ve been using it does not add the value it should add because of the iterative way of working. The same holds for using user stories. If they are used to using use cases let them use it next to the user stories. If you can help the team make a successful transition they will figure out how to cope with the use cases.

User Stories work perfectly for Agile planning and estimating. Next to that, an very important aspect is that user stories force the teams to communicate with the requirements people, be it the product owner, customer or domain specialist. In the case of use cases, what you see is that people incorrectly assume that they can write everything in the use case and that face-to-face communication is not that important because the requirements are written down so ‘carefully’ and ‘precise’…..
So, if you have a mixed team with testers, requirements people and developers, why do you still need to write this pile of documentation? Why not…… just talk more to each other?
It could be that the organization needs formal requirements documents to please some institution or manager, or even better a very ‘good’ reason I heard today, ‘I want to give the test document to someone else to do the testing for me’ or ‘when we fix a bug, we need to use the test case to verify everything else still works’.

Well there is good news, with the user stories there comes acceptance criteria and from these acceptance criteria you should derive test cases to further detail the user stories. So user stories get detailed with test cases, preferably automated ones, and these can be documented in any form you want. You can even group a set of related user stories into an use case if you wish and use an use case as a container for user stories. The test cases fill up the test documents as the sprints progress and at the end of a release there you have your required test documentation….. ….. or is it not required anymore?