WTF is this fuzz about User Stories, Use Cases and Test Cases
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. User stories make up the backlog and details of a user story can be captured in a use case. A use case is a collection of scenarios that together help achieve a goal for the involved actors.
User Stories work perfectly for Agile planning and estimating. Next to that, a very important aspect is that user stories force the team members to communicate with each other, be it with 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?
It could be that the organization needs formal requirements documents to please some institution, law or worse manager or even better a reason I heard today, ‘we need test cases to verify everything else still works’. There is nothing wrong with writing documentation, just do not let it dominate your communication.
Well there is good news, with the user stories there comes acceptance criteria and from these acceptance criteria you can derive test cases to further detail the user stories. So user stories get detailed with test cases and these can be documented in any form you want and preferably automated using tool like e.g. Fitnesse, Selenium, Cucumber or QTP . You can group a set of related user stories into an use case if you wish (if the user stories are related and small enough) and use an use case as a container for related user stories. If you use Gherkin specifications for your test cases then these can be used as scenarios in your Use Cases. 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.