Karen Nicole Johnson

Let me digress to make a comparison (in the process I may age myself but so be it) – I think back to the time when desktop publishing was first introduced. With desktop publishing draft copies gained a way of looking complete, finalized and picked up an air of authority based solely on the crisp appearance of the material.

I think of user stories in the same way.

I don’t like to review user stories and believe that they are always “right.” I don’t believe that the stories are always “complete.” And I don’t believe user stories can be the authoritative source for anything more than “what the author thought the application would do at the time they wrote the story.” I am a committed skeptic.

Like reading the answer key while taking a quiz, I don’t like to read user stories before I’ve gathered my own ideas. I worry that the user stories will stifle my testing thoughts.

So what do I really do with user stories? I put them aside at first and …

I think about what functionality is either being introduced or enhanced in the coming build and what test ideas I have collected in my notes already.

I think about existing functionality and what might need to be regression tested.

I review the data model. I expect myself to be able to envision how the application is being changed by reviewing the database changes. I usually can. I pick up more test ideas this way.

Then I pick up the user stories and …

I scan stories for their titles, if the title is written well, I get the point. I don’t continue to read for the details until after I’ve thought about the functionality being introduced or improved. So I’ll take the title of a user story and then think through ways to challenge the premise of the story.

I go back and read the user stories thoroughly. I ask questions. The questions I ask often result in early bug finds and more user stories being written. If I can find issues that early in the process, that’s great.

I write notes while I read the stories. My notes are often more test ideas.

In my experiences with user stories, the most helpful aspect is whenever I learn about a scenario that I didn’t think about – some nuance that I didn’t foresee. I bump these test ideas up early in the process because these are the stories that I feel I can learn from – the stuff I might not have expected.

Despite sounding somewhat negative or skeptical towards user stories, I actually do like them. I generally prefer user stories to more formally written requirements.

User stories are especially more helpful than the requirements that often get written around the medical software I’ve worked with that has so many requirements commanding: “the system shall X” but yet much of the nuance of “how” is not addressed.

I also like to think about and test for the “what if the system doesn’t.” Testing around error conditions and seeing how graceful a system handles certain states or conditions is important. I don’t see user stories written around these concepts though, instead the user stories I’ve worked with have been pretty happy path focused. And I am a rainy day person.

My largest frustration with user stories is if I follow the detailed path that has been drawn out and I find a bug just following the story – a large functional bug. I’m disappointed to realize that unit testing didn’t pick up on the issue. If I think of a variance or nuance from the story, I don’t necessarily expect those issues to have been found or thought about – but I do expect the happy path basic operations to be functional. Just because I expect this and wish for this to be true, doesn’t mean that is what I’ve experienced.

Overall, I think user stories are more digestible than requirements but I can appreciate that some features of an application aren’t described as well in the story format as well as other features. This is why I think having too prescriptive of a story format is a detriment that can be avoided. While, I would not vary the format of each user story because that might result in making the collection of stories hard to follow, I would not use the same format just to be consistent. Some features might be better told in longer prose and some features might be better explained with a grid or a table. I think any format used whether a user story or a requirement stands the chance for not being the best format for the requirement being described. I suppose user stories are like any tool or hammer we learn, there may be a temptation to overuse the format, seeing everything as a nail as the saying goes.

On a recent project where I was working with user stories, I would like to have more involvement earlier on with reviewing and participating in writing the stories. I’m surprised I didn’t/haven’t had that opportunity. I’d like that opportunity – any time I can gain experience from a different perspective (like gaining the experience of producing the stories versus being a consumer of the stories) I learn a great deal.

Not long ago, someone emailed me asking me to write about working with user stories. I have a few thoughts about working with user stories. I thought I would write about what I call the “missing parts problem” this time.

In my experiences working with user stories, one element often missing is how a new feature will work with existing features. Notice that I stated “in my experience” because this doesn’t need to be the case. I realize this statement might bring questions to mind – it raised questions in my mind as I tried to explain the missing part problem to a project stakeholder recently. These are the questions and thoughts that roll through my mind and are darn close to a conversation I had recently.

What’s missing in the stories?

The user stories are usually about the new features without hashing out how a new feature will work with existing features. So I end up with 10 user stories about a new feature but the feature is alone. The stories are missing how the new feature will play with other features.

How do I look for the missing parts?

What I do is I create a vision of the new or upgraded feature in my mind; I then walk through the rest of the application with that new feature in mind. Some features will have no – um, perhaps this word works – interplay, no interaction with the new feature. If there’s no interplay to consider, I move on. I do this with aspects of the application that might not be thought of as features – such as active, inactive users, user permissions, etc.

It takes some discipline to walk through that same course over and over but the upside is you get faster at this the more often you use this approach. I’m sweeping through the whole application. I’m not thinking about features in a staccato disconnected fashion.

If you can’t draw that vision in your head, map it out in your notebook. I probably look like I’m zoning out when I gaze out windows or close my eyes but I can see things in my mind pretty clearly. An alternate approach would be to draw a table with a list of the application features and continually run through the list. It’s kind of fun because it’s like holding a puzzle piece and your hand, looking at a jigsaw puzzle and asking yourself, does it (the new feature) fit here? How about here?

I do write a fair amount of grids/tables in my notebooks as I plot out combinations. And if it helps to know, I don’t get my grids right on first drawing – I frequently have to draw them out 2 or 3 times before it’s a grid that works for what I want.
And that thought process is massively helpful because now I’m part of the application, I’m learning. I could be handed the same grid of combinations or permutations of whatever I’ve thought of but I wouldn’t have consumed the knowledge as much as if I drew it out myself. This is the same reason that when I’m given a table I try to force myself to not see the table as complete but instead ask, is anything missing?

Why are there missing parts?

I don’t know. Deep sigh. On one project I worked remotely with a virtual team, the person writing the stories didn’t think I would have input despite my asking to be involved. On another project, the stories were in place when I joined the team. But here’s the more important perspective – I don’t want to whine about not being involved – yeah sure that happens sometimes but more importantly – I would never look to user stories or requirements to think that everything I needed to think about would be written down anyway.

I expect to be the person on the project who thinks of the combinations of things that result in unfortunate results. Or sometimes gets to discover a rock-solid application – whichever the case may be. The combinations of a new feature with an old feature, a new feature under stress, a new feature with challenging data, race conditions, and boundary conditions – the list continues.

If the user stories covered everything, and I all I needed to do was test the user stories, then I wouldn’t be an exploratory tester. I would be a test script executioner or a user story executioner. In either case, I would have disengaged thinking from my work. (Ok, I’ll stop the soapbox.)

How do I continue with testing in this situation?

Happily. I know this is one of the first areas I’m going to think through and see if I can find issues. When I do, I nearly always hear the same reaction from the developers, “Oh.”

But this is probably a good time to point out that I never want to be snotty about finding a defect. Building a good rapport with development is so important. And I make mistakes too – all the time – so it’s best to remember that.

If you have other questions on this subtopic, let me know.

I’ll post about what I do with the parts that are there – the next time.