Using Use Cases To Create Test Cases

As part of my "Live from BAWorld: Boston" series, I attended a talk Monday by Matthew Leach of Doreen Evan Associates called "Leveraging Multi-Level Use Cases for Testing and Other Ways to Obtain Greater ROI on your Business Analysis Investment".

His talk went into great depth about how you could use use cases on your project in multiple ways, looking at different levels of detail in use cases. He quoted a study from VokeStream that indicated 76% of people surveyed manually build test cases still.

This is the one point I also wanted to emphasize the importance of: re-use your use cases to generate test cases, particularly user acceptance test scripts (UAT scripts). At some level this seems obvious to me, but I don't think it is all that obvious after all based on the above study, Matthew's experiences, and my personal ones as well! On a recent project I worked on, the business came to us to talk about how awful the integration and unit test cases were - that they just would not work for UAT. My immediate thought was "well of course not, those aren't meant for UAT". Apparently QA had told them to write their UAT scripts from these test cases. That's almost as challenging as writing them from code! So we walked them through how we could take the use cases we had written (which the existing test cases were generated from) and easily translate those into UAT scripts.

If you think of your use case having a happy path and alternative paths, you would want to blow out each of those paths into at least 1 test case each, by adding concrete data to the use case. So for example, if there is a step for the user to input "shipping information", then in the UAT script, you would want to supply actual shipping information including a specific name and address that would be in the test data set. It's important during UAT to also test the alternate and exception paths - to ensure the not-so-happy path and errors are handled to the business' satisfaction. That said, it's also unrealistic to think your users have time to test all possible paths. To mitigate this, I have two suggestions.

1. Pick the most important UAT scripts to test. You have to decide what "important" is, but it would be wise to look at the use cases that add the most business value and/or are most frequently used.
2. Use your BAs during UAT - particularly for the less important test cases that the users can't it.

INCOSE 2008 – Systems Engineering Railroads - So Many Requirements Stakeholders

The opening talk on Monday at INCOSE 2008, “Crossing Borders by Applying Systems Engineering”, was by Bert Klerk, the CEO of ProRail, who runs the railway system of the Netherlands. Behind Japan and Switzerland, this country is 3rd in the list of most densely used railroad networks. They have 6500 km of track and because they are a land of much water, 4500 bridges to cross. This is clearly a large system which has had great success from applying systems engineering principles.

This is not the first time I’ve heard a talk about a project for Europe’s rail systems. I find it to be a very interesting topic, and though I have never worked on a railway project, I can see the challenges so clearly. This talk highlighted an example of a track to be laid that in particular had to cross a small river. They put out bids to contractors to see who could most cleverly navigate this river while staying under budget; and the winner’s solution was implemented. But the point here is systems engineering on this scale involves hundreds of stakeholders. When dealing with these large scale systems – you cannot just think about the users at all, the scope spans way beyond that. It’s not just those people using the tracks, those operating and maintaining them, but also those who are impacted by the train system deployed – the town people who enjoy the river. And while they are not direct users, you cannot ignore them – they might actually put up big roadblocks to deploying the system.

Anyway, if you can imagine how hard it is to get 200 users aligned – now imagine you have 30 types of stakeholders with a couple hundred of each and most of them will never actually use the thing you are building. Try to keep that group satisfied!