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.

A Better Way to Write a Use Case: Plain English

I was talking to a colleague recently about use cases and it got me thinking about my evolution as a use-case-writer. I used to do formal use cases exclusively – where they very clearly denoted system and user steps (whether in one list or 2 columns), preconditions, triggers, Postconditions, etc. etc. etc.

After years of writing and teaching about formal use cases, I have to confess, I rarely write them now. Sometimes I still teach about them, I think it’s important to know how to write good ones. But the reality is that as we move towards shorter-iterations on our projects, the less formal we need them to be in the use case itself. What I’m finding works really well are these use cases written more like user stories. They may still have a linear set of steps, but the big difference is they are written in a more readable language of plain English with slightly less structure.

I’m oversimplifying but to make my point, instead of:

1. System displays shipping fields

2. User enters shipping info

3. System displays payment options

4. User enters payment options

I could simply say:

User enters shipping and then enters payment information.

I’ve conveyed the same information without stating the literally obvious points. You have to be careful here though, don’t assume the obvious incorrectly! Now, before you agile non-documenters jump up and down and say “I told you so!”, I want to be clear – you still need to write something down. This is the part that many projects neglect to tackle is the next level of detail. You still need to capture specific functional requirements for this use case/user story – there are our typical RML™ – with people, systems, data models to be created that describe those requirements, So I use the user stories, just like I used a formal use case – stepping through each “step” and determining what details need to be specified for building the software. Oh and one more thing, I do still use preconditions, triggers, and actors in the header – just makes it cleaner to call those out up top.

Live from REFSQ: Deriving Information Requirements from Responsibility Models

Tim Storer from St. Andrews University in Scotland presented this paper. His underlying assumption is that in large scale socio-technical enterprise systems, you are constrained by the design of the platform you select, integration to other systems, and systems of systems factors. He contends that the functional requirements in these projects are more useful in the procurement process where you select the system to implement, and specifically less useful in the actual implementation. The reason for this is that the system is already constrained by behavior based on what you select. While I don’t entirely agree with the de-emphasis of functional requirements he implied, his overall point is absolutely valid in that you often are in a situation where you must configure the system and adapt business processes around the system.

This paper discusses how beyond the functional requirements, you also need what he calls “information requirements” which help you to configure the purchased system for the given context. These requirements tell you:

• What information is needed


• Who needs the information


• Who produces information for the system


• Flexibility for access to that information


• Consequences of incorrect information flow

And these requirements influence platform configuration, organizational changes, and system integration.

To identify these information requirements, they use “responsibilities” as a starting point. They have defined “responsibility” as “a duty, held by some agent, to achieve, maintain or avoid some given state, subject to conformance with organizational, social, and cultural norms.” They are not goals, but rather more abstract and less formal. They are not concerned with specific types of agents. Then for each responsibility, they determine the resource needs, ultimately leading to information requirements.

In his example, a self service check-in terminal has responsibility of “provide boarding pass”. Then they can look at the resources needs– blank tickets, ticket database which is fed by ticket server, etc.

For the information resources, you then have to look at what happens if it the resource is unavailable, inaccurate, incomplete, late, and even early. And ultimately you get to the details mentioned above to form the information requirements.

What I found useful in this paper is helped validate some of our own thinking we are applying on projects in that we look at something very closely related with data requirements. We’ve written before about our People, Systems, Data (PSD) approach to discovering all requirements using visual models from RML™. In this case, if we break down the Data component of PSD in combination with the People component of PSD, we have something very similar to what Tim spoke to. Very briefly, we use the People models (e.g. Org Charts) to identify the people using the system and then look at what stories they need to execute in the system (e.g. User Stories). Now we can also look at the top-level data model (e.g. BDD – a Business Data diagram), and for each data entity in the diagram, we look at how it is:

• Created


• Viewed


• Changed


• Removed


• Copied


• Moved

(And yes, I deliberately did not call out the CRUD because I’m not a big fan of the acronym!). In doing this, we can actually complete the list of user stories and identify system integration points. Similar to above we would also use the user stories to cross-verify the BDD was complete. Our data actions closely map to the list in Tim’s presentation:

• What information is needed -> the BDD entities


• Who needs the information -> Who views it, changes it, copies it, moves it


• Who produces information for the system -> How is the data entity created


• Flexibility for access to that information -> Who views it


• Consequences of incorrect information flow -> exceptions in the stories that come out of the list

Now in a recent example, we were working with a system that we did not know well. There were six main data objects and a list of about 10 user stories for the system. I wanted to validate whether the list of User Stories was complete, so I proceeded to walk through each of the 6 actions above against each of the six data objects. Not every data object could have those actions performed in the system, but it was useful to deliberately check each. In the end we identified about five new User Stories.

Why Do We Model Software Requirements?

The other day, I was flying to California to visit my customer. On the plane, I was seated next to a gentleman who worked for a small engineering firm in the Silicon Valley.

We quickly struck up a conversation about work and when I began to explain what I do), he got this perplexed look on his face. Seeing the confused look, I decided to try and explain in greater detail what I do as a product manager.

The gentleman quickly explained that he understood the idea of requirements but did not see how there would be enough demand for someone to do this for a living. Then he said "So, tell me what your company does that is so different from what I might do."

I briefly began telling him about requirement work and when I got to modeling he just laughed. "How and why do you model a requirement?” he chuckled. “A requirement is just a statement that says what functions you want the software to do.

I compared Use cases to an assembly instruction for one of his mechanical devices, and an ERD to an exploded view of one of the fully assembled parts that he might design. We discussed benefits of modeling in opposition to just creating a lot of "System Shall" statements.

I summarized things this way:

Requirements Models Allow Us to Organize Our Data in Multiple Ways.

There are only so many ways to say that someone needs a log in screen. But who needs it? And why?

By placing information into models, such as context diagrams or organizational charts, we can see information from angles that we wouldn’t normally have. We can use the images to gain perspective that we wouldn’t normally have.

Models Help Us to See Things That Might Be Missing.

When you’re sitting down with someone, it’s pretty easy for them to take a first stab at telling you everything they want.

But how many times have you had someone say, “Yep, that’s it,” when you asked them if you’ve covered everything only to find out that that there were, in fact, a few pieces missing.

Putting things down on paper helps us arrange information visually so that we can see the gaps that we normally wouldn’t see in a long list of requirements.

Models Create a Visual Representation of What’s Expected.

Ever tried to describe a web page without building a wireframe?

You’ve probably discovered by now that even if you scratch out a design on piece of paper and hand it to someone it’s more effective than writing 1000 words.

Plus when you put a wireframe in front of your customer, you can get them to say, “Yep, that’s what I was looking for,” or “Nope. That’s not it.” In either case, you’re able to get their feedback on something solid before you give it to development.

As we continued talking, I saw the light go on.

Models aren’t just fancy drawings that product managers use to eat up time and paper. They are an effective and powerful tool that helps us communicate with our users and developers. Don’t get me wrong, you need to be able to write up functional specifications clearly and concisely.

But do yourself a favor. Add a few models to your toolkit.

How to Prepare for Requirements Sessions with Your Users - Tip 3

We have now discussed the need to organize your time and prepare models in advance of the sessions.

Today we suggest you Prepare Your Elicitation Questions in Advance

One of the key steps to take prior to a stakeholder meeting is to prepare a list of questions to be asked during the meeting. These questions might be created based upon past experiences or recent meetings with the user. If the analysts know the users, the organization, or the types of issues they face, that knowledge should lead to obvious questions. If the analyst has met with the user already, new questions should be created based upon those original meetings, lessons learned and new issues identified. Also, if drafted models exist, those most certainly should prompt questions.

There are some stock questions that you can use as a guide to requirements gathering sessions. Keep in mind, though, each project will need its own unique questions, and some of these questions are likely not appropriate.

How to Identify Actors for Software Requirements

Here are some suggested questions to ask to identify the actors of the system. These questions are in a guide that we've design to keep on your desk. Download it here.

• Who uses the system?
• Who installs the system?
• Who trains people to use the system?
• Who fixes the system?
• Who starts up the system, who shuts it down?
• Who maintains the system?
• Who creates, updates, deletes information in the system?
• What other systems interface with the system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a predetermined time?

How to Identify Use Cases

The following suggested questions can be used to identify the list of use cases or system functionality.

• What functions will the actor want from the system?
• Does the system store information?
• Do the actors need to create, update, or delete information?
• Does the system need to notify an actor about changes in an internal state?
• Are there any external events the system must know about?
• What is the actor’s overall job?
• What problems has the actor had in the past?
• What steps are manual today?

How to Identify Alternative Courses

In order to identify alternative courses or exception paths, these questions should be asked at every step of a use case main course.

• Is there some other action that can be chosen?
• If X does not happen, then what should happen?
• What if the actor cancels an operation (e.g., closes a window)?
• What if the actor provides incomplete information?
• What might go wrong at this step?
• What if part of the system goes down or is unavailable?
• Are there any events (or interrupts) that might occur at any time during the use case?

Are you ready for the last part in our series? It's an oldie, but a goodie!