Article by Mike Kelly
Many testers on Agile projects struggle to keep up with the pace the development team sets in terms of story delivery. In time-sensitive environments, it’s critical for the tester to get a leg up on testing by having clarity in what needs to be tested.
In addition, most Agile teams have extensive unit and functional test automation that tell the developer when she’s done with development on a given story. Given both of these situations, you’d think we’d be a bit more rigorous with how we write our stories to make sure it’s clear to both developers and testers what needs to be tested. In this article, we look at some simple techniques for making your stories practically test themselves.
Templates help you remember what’s important
There are a number of methods for writing user stories, and a popular technique for teams getting started is to leverage a template. One such story template that I really like is Dan North and Chris Stevenson’s story framework for behavior driven-development:
As a <role>, I want <feature>, so that <benefit>.
Here are a couple of examples:
- As an unauthenticated user, I want to see the login link in the upper right hand corner of each page, so I don’t need to navigate back to the homepage or some account page to login.
- As a sales associate, I want to be able to pull up my current active leads, deals and tasks on my iPhone, so that I can still follow up with clients and update deals status while traveling.
Those look good right? You get an immediate feel for who cares about this story, what they want, and why they want it. However, when most teams write stories using this template, what typically happens over time is something like this:
- As an unauthenticated user, I want to see the login link in the upper right hand corner of each page.
- As a sales associate, I want to be able to pull up my current active leads, deals and tasks on my iPhone.
It’s exceedingly easy to leave off that last piece of the story. To the person writing the story, it’s obvious why the user would want that feature. However, to the developer and the tester, it’s not.
For example, with the first story, I might conclude that the login link in the upper-right hand corner of each page should take you to a login page. However, when I read the original story, it’s easy for me to see that the benefit is fewer clicks to login — the user doesn’t want to leave the current page to authenticate. With that knowledge, I can design an Ajaxy solution to keep them on the current page and still authenticate.
Don’t leave the benefit of the story off of the story. Even if you’re not using a template, make sure it’s clear why this feature is important. That gives powerful insight to the developer as they design the solution. It gives valuable insight to both the developer and tester when they assess risk for what should be tested.