User Stories for Both Requirements and Testing

User stories are a technique taken from the agile development playbook that can easily be applied in traditional systems development and maintenance. User stories help you document needs in a structured way, from the users’ perspective. They are a good basis for test cases, so as to support integrated requirements management and testing. In this article, you’ll find concrete advice based on our own experiences developing the requirements and testing tool ReQtest for how you can make user stories the basis for requirements management and testing.

Author: Ulf Eriksson, ReQtest

User stories: a better basis for writing requirements

User Stories is a requirements documentation technique that is centered on user needs as expressed by the users themselves. They are written in a form that often looks like this:

As a <role>, I need to <goal> so that <purpose>.

A major advantage of user stories is that this template forces the writer to tell for whom the task or requirement is needed and why it needs to be done – basic facts that requirements documentation often lacks in traditional development. The developer needs these basic facts to fully understand the requirement. At the other extreme, when use case authors go overboard in capturing needs, important information can get lost among unimportant details; a simple user story emphasizes what’s needed most and why.

Examples of the components of a user story:

• Role: Administrator
• Goal: Edit the address of a customer who has moved.
• Purpose: Avoiding the workaround of deleting the customer record and creating a new one from scratch.

Formulated as a user story, this need would read: As an administrator, I want to be able to edit the address of a customer who has recently moved, so that I won’t have to delete the customer record and create a new one.

User stories are excellent at describing requirements at a high level of information. That helps you focus on what’s needed, instead of how to solve the problem. By focusing on needs and not solutions, you don’t get bogged down in technical details too early. When you write user stories, you write the test cases at the same time, which means that you automatically review the user story.

Some people think user stories can become annoyingly repetitive, since each one follows the same structure and they all start to sound alike. Keep in mind that you’re not trying to write a narrative; your goal is to write requirements that everyone can interpret in the same way. If you write the requirements in another way, each different reader will interpret your subjective wording differently.

One potential drawback facing user stories is that they can be too short. There’s no room for complex business rules or process descriptions in a user story. We recommend that you view user stories as a starting point for the body of requirements, and supplement them with further details and documentation as needed, but only then. The biggest problem with requirements is not that you write too few of them, but that you write too many, and that they’re too complex.

Rounding out the tale: complementing user stories with additional detail

Each user story should be very concise. Shorter stories usually take less time to write, and they keep your readers from drowning in unnecessary details. User stories are more than sufficient in many cases, especially if you supplement them with mock-ups and prototypes illustrating the user interface. On the flip side, your user stories might contain too little detail and precision for system developers to know exactly what it is you’re asking for. It’s a good idea to complement the user story with a record of the dialogue that takes place between the developer and the person writing the requirement. Additionally, you should complement each user story with the test cases needed to confirm that the requirement has been met. A user story, combined with test cases and the dialogue, constitutes a solid foundation for developers to build upon.

The difference between user stories and use cases is that use cases contain a main flow and a number of alternative flows. Too often, use cases are overly comprehensive, when use cases are meant to describe basic functions. You don’t have to give basic functions in this detailed way. Often the user story format works extremely well. If you feel limited by the lack of detail in a user story, you can supplement the high-level user story with more detailed use cases. You can also use traditional requirements, or decision tables as complements to the user stories. A decision table is useful when the requirement is based on complex business rules. In a decision table, you can put each of the business rules into a separate column, and make each column into a test case.

As an alternative approach, you can provide more specificity with your user stories by directly translating them into tasks to be assigned to someone on the team. Examples of tasks are “design the database”, “design the user interface”, or “write documentation.” Each user story can be further detailed in task form.

Begin with the end in mind: Write test cases in parallel with the requirements

A common problem in traditional development is writing test cases too late in the process, even when the system is fully or partially completed. As a result, the team discovers errors or omissions in the requirements definition late — sometimes so late that it’s impossible to solve the problems due to the cost and/or complexity of the fix. When you write requirements in the form of user stories, you can see the test cases as part of each system requirement. That means the test cases are ready for you to use as soon as the requirements are complete. The test cases also serve as the next level of detail below the requirements themselves.

Sometimes, you don’t discover gaps in the software requirements until you start writing test cases. Since the user stories method forces you to write test cases at the same time as you write requirements, you automatically review the requirements at an early stage. That way, requirements review becomes an ongoing, integral part of your work in a way that’s more natural and less cumbersome than in traditional development.

Summary

• Write requirements in the form of user stories.
• Provide additional information as needed.
• Write test cases at the same time as you write requirements. This helps you review the requirements iteratively.

About the author

Ulf Eriksson is one of the founders of ReQtest, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf’s decades of work in development and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy, which he has abided to for a number of years in his professional life as well as in private.