Software Process and Measurement

Today we have a guest post from Jeremy Berriault.  Jeremy is a columnist on the Software Process and Measurement Cast and the author of the QA Corner blog. He is a professional tester and is currently a QA manager.  During a recent recording session, Jeremy and I talked about using story maps in testing.  That discussion resulted in this guest post.

Guest Post: Story Maps for Testing

The use of story maps has been picking up speed and the use of them have proven to be a good tool to start linking items up so that there are no surprises down the road.

From a testing perspective, I feel, this is something that should be looked at as not only helping see what the bigger picture is, yet also identifying areas to simulate early so that the teams can prepare.

Barry Overeem’s article https://www.barryovereem.com/the-user-story-mapping-game/, has a nice description of how it all works, along with a nice picture of what one would look like. Yes, the intent is to ensure that features are not done sooner than any other dependent tickets, which is a good thing. When I talk about setting up simulations, it is more about not waiting of those features if the scheduling of the development in the release is not fully aligned. From a quality standpoint, it is making sure things are smooth.

Now imagine using string (well virtual string if your map is online) to connect the tickets along with the deliverables. It could end up like a conspiracy theory wall. Which in the end it is ok since you will now have a good path of where and when you can focus attention and see where help might be required early.

For me I see this as another tool in the toolbox to get things straightened out. I remember the days of 80-page requirement and doing something like this to identify where I need to plan things out and when. A nice graphical view allows for easier consumption and not missing something. Which helps with early detection and making the appropriate changes.

The way I see it there shouldn’t be one ticket that is not linked to another in some way. Something always builds onto another one. Same as how I talk about test case building. To keep it modular and easy to use, a test case should have the output of a different case to feed into another. If you think about it you will have only one test case where that would not happen, the initial main case to get the system going, unless you get granular (which is a bad idea for testing functionality and should be focused on Unit testing).

From a test planning view, you would have a second “map” of just test cases that should overlap over the product story map. With the exception that there will be a lot more connections on the test case map. Now all that is left to do is plan out the simulations (Data, SOA, Files etc…) and get to work.

Both maps together would then help reduce the risk of having an “oh crap” moment late in the release cycle when something new is discovered or not thought of. Work smarter not harder, correct?