I have encountered Use Cases on several occasions, sometimes they seem like a simple tool that can be used to better understand how a system behaves from a users perspective, while at other times people describe them as terrifying monsters that have murdered people and led to the destruction of entire projects. So I am going to recommend only using the good kind.
But what is a use case? It is simply an example of how a system (or business service) could be used by someone.
Where do Use Cases come from?
Use cases were invented by a Swedish guy named Ivar Jacobson, who is really famous in geek circles. I imagine he has his own groupies and he certainly has a big fan base, because he apparently invented sequence diagrams, he was one of the founding creators of UML and, if people had listened to him, he would have made the whole IT industry pretty simple and straightforward. If you google him you will find out that he is still trying to get the IT industry to admit how simple things could be, while the rest of us are still trying make it all sound complicated so we can continue getting lots of cash for doing obvious things.
According to James King history (I haven’t checked my facts too carefully) people were building systems by asking the users what the system should do. But when they built the systems they didn’t work too well because nobody had thought about how a user would actually use them.
So Ivar said to his friends “why don’t we actually ask users how they would use a system”.
But his friends were confused, “how would we do that?”, they asked.
“Let’s just ask them for some examples of how they would use it and then we can get the IT geeks to work out how to build something that does that for them”, explained Ivar, “We will call it ‘Using Examples to Build Stuff’”’.
Unfortunately for people not living in Sweden, Ivar speaks Swedish and apparently they have a word that means “a case (example) of how something would be applied or used”. The unfortunate bit is that when Ivar’s simple idea was translated into English, the translator decided that Use Case was the closest thing we have in our language to “a case of how something would be applied or used”. So instead of having “examples” or “ways you could use this” we have are stuck with the slightly less obvious “use case”.
Of course if you just ask for a couple of examples of how people might use stuff, then you will have a lot of holes in your requirements. But Ivar had thought of this.
Use cases for really simple systems
For simple things, he suggested listing the users (who he called actors) and listing the examples of stuff they might use the system for (the use cases). He then invented two ways of communicating this.
An obvious approach (called an Actor-goal list) is to simply create a table listing the actors and what they want to achieve:
|Jenny||Add members to the coffee club system|
|Member||Look up coffee details|
For a simple system, this might be all the documentation you do to create a list of test scenarios. But Ivar and his groupies also came up with a diagram to show the same thing. They drew a box representing the system they were building or testing put all the use cases inside the box. Then they drew some stick figures to show the users (actors) and then drew lines to connect the actors to the use cases they might use.
This provides a map of the use cases, or more technically a “Use Case Diagram”:
Use cases for more complicated things
Ivar and his groupies, together with other gurus came up with some advice for how to better describe use cases when you want to know more about them. Unfortunately there are now several different international “standard approaches” for doing this, but fortunately they are all pretty similar.
So here is the internationally agreed James King version of a use case when you are using them for scenario testing.
Firstly, we will break the use case into four components
- The metadata (information we want to know about the use case)
- Sample data to use (this is not generally done for use cases, but it might be useful to us)
- Instructions – The happy days scenario (a series of steps to follow when things go well)
- More instructions – Other scenarios (examples of where things go wrong or where people use them differently)
You can add whatever you want here, but these are my suggestions:
|Title||The name of the use case and possibly a reference number||
Add new member
|Preconditions||What should happen before you start||The actor has logged into the system and is on the “membership” page
The actor has a completed form or the potential member is standing there
|Trigger||What causes the use case to happen||The actor decides to enter a new member in the system|
|Success||What should happen if all goes well||The member will be active in the system
The system will send the member an email
|Minimum guarantee||What should happen if the use case fails||No data will be stored unless the use case completes
No membership fee will be charged unless the use case completes
You could also add things like “expected time for the scenario to complete”, a picture of the screen the user should see or reference documents that the tester can read for more information. It is really up to you.
If you run the same tests a lot then you might want to record the information you will frequently enter. For example you might record:
|Member name||John Smith|
|Member card||Amex card 2233 444 expires 12.12.14|
Of course if you are really sophisticated you will have a lot of personas (sample users and members). In that case you would simply list the personas to use,
This is where you actually write down the steps to follow when running the use case. You could go into a lot of detail if you want others to be able to use the instructions, or you could keep it really simple if you were the only one using the scenarios for testing.
When talking to use case groupies you would say that a use case consists of several scenarios. Each scenario is a different possible outcome for the use case. For example the “happy days” scenario is the one where everything works properly and the actor makes the simplest possible choices.
So if you only document one scenario in the use case (ie one example of how the use case might go) then it should be the happy days scenario:
|1||Press the “add new guy” button||You should see the member creation form|
|2||Enter the name and press tab||The name should populate and you go to the address field|
|3||Enter the email address||The email address should populate and you go to the notes field|
|4||Press the confirm button||The member flag on the top changes to active
An email is sent to the member
The step number allows you to record where things went wrong. The instructions let the tester know what to do and the expected result allows the tester to see if the right thing happened.
In a formal use case you would actually add a step for what the actor does and then a separate step for when the system responds. This makes it easier to identify specific errors or different outcomes. I don’t care about this for my test scenario but if I were working on a system that could kill people (say an autopilot for a plane) then I would definitely use a format more like the following one:
- The user presses the “add new guy” button
- The system displays the member creation form
- The user enters the name and presses tab
- The system validates that the member does not already exist and takes the user to the email field
Again, I should point out that the amount of detail you add will depend on who will be running the scenario. You might just say “add the member” or you might do really detailed instructions so anyone on the team can follow them.
Of course when I run this scenario I won’t always follow the instructions correctly. In fact I might turn off my machine at step 3 (or at least close the browser). Then I will log in again and try to enter the member again to see what happens. This is where the tester can use the international standards for being scared and being stupid.
But the first time I run the scenario I will probably try to follow the instructions and make it work.
In addition to the happy days scenario, you might enter some alternative flows or other outcomes.
For example, I might create an alternative to test what happens if Mr Smith already exists in the system. In this case I might start deviate at step 2:
|Existing member outcome|
|2a||The system displays a warning that the member may be a duplicate||The display should pop up before you can enter more data|
|2b||Press the “so what – I want to enter this new member anyway” button||return to step 3|
The number 2a tells me where I came from so I don’t need to write the whole thing out and then the final line should either tell me the use case is ended or that I return to step x and continue.
Use cases were designed to help build a system and not just to test it. But for regression testing you might decide to create a scenario (or test case) that includes bits from several use cases. For example, I might create a scenario that allows me to
- Attempt to login but get the password wrong
- Try again and get in
- Add two new members
- Run the daily membership report
- Book one member into our special coffee connoisseur course
- Change the booking for the course
- Confirm the member got an email on joining the club, one one joining the class and one on the class change. Confirm the other member only got an email on joining
So that’s about it – the idea of use cases is that you create some examples of how a user might use the system. The use case diagram could be a good map to help you understand which users are involved in which use cases and by documenting the use cases in more detail you are creating a set of instructions for other testers to use.
You might also use this approach to build automated testing or to pass information onto trainers and technical writers.