He Said – She Said …
If creating black-box test scripts is the most tedious job (which it is), then creating Use Cases is the most fun. As a matter of fact, if you pay attention and create a good Use Case you can often create your test scripts directly from these cases. Just don’t tell anyone, you might spoil the pleasure the project manager gets at watching you type away on those test scripts.
The attached example should say it all, but let me extrapolate a bit to ensure you get the most out of the document.
The first part of the Use Case template is an executive summary. It sets the stage for the performance that is detailed in the next part. It gets the developer’s head into the solution they are about to code and ensures those busy stakeholders that we understand their problems and business processes and are ready to create a solution.
The Use Case Number is mostly important for big development projects where the Use Cases are being managed by a data store. However, just out of habit and because I like to keep things organized, if there is no predefined convention applied, I usually assign the Use Cases an ID like UC_001, UC_002 and so on. That way when someone asks how many Use Cases are still in development or testing, you can quickly figure it out. This ID can save a lot of time.
The Use Case name I usually assign is the same or similar to the name of the process I defined in the Workflow. Here’s an example. You are developing a system to manage medical claims received via the internet that passes them to a repository which is accessible to claims specialists and claims managers. The application allows these users to manage, confirm and pass valid claims to the payment department. It also contains the ability to pass claims between the specialist and manager when a claim is initially found to be invalid. I would use names like these, “Receive New Claim”, “Processing by Claims Specialist”, “Processing by Claims Manager” and “Passing Clam to Payment Department”.
There is a quick tip here. Object Orientated Programming (OOP) places an emphasis on watching for verbs and nouns. With the first Use Case “Receive New Claim” the developer may notice they could create a class named “NewClaim” with a property named “claim”. The “getter” or mutator could be used to return the property value (the new claim) and the “setter” or accessor could be used to capture the contents of the new claim. If they adopt your Use Case names into their design, the application is much more understandable for further customization or new developers.
The Package Name applies to the name of the end product such as the application itself, the module or whatever will contain all the compiled code that is produced by these Use Cases.
The Description should be one or two short sentences that summarize the overall purpose of the Use Case. In the example of the “Processing by Claims Specialist”, I would say something like, “Allows Claims Specialist to processing new claims determining the validity of the claim, forwarding both valid and invalid claims to other actors”. In this same example I would derive the Actors from the Workflow. These would be the Physician, Claims Specialist, Claims Manager, Payment Department and the system.
Likewise the Pre-Conditions and Post-Conditions are derived from the Workflow and detailed here. In our example the Pre-Condition is “Claim received from physician over the web.” The Post-Condition summarizes the most favorable path through the system. This would be if the claim contains no issues and is passed to the Payment Department by the Claims Specialist. It would read something like this, “Claim is passed to Payment Department”.
The Main flow is likewise short and to the point. It would read something like this, “Physician submits claim to Claims Department. Claims Specialist processes claim and passes claim to Payment Department”.
Now you can work on your playwright skills. The first actor is the Physician who submits the claim via the claims-submission system. The system encrypts the claims information and passes the data to the data store. Be as specific as you can.
The next actor is the Claims Specialist who, after logging into the system, opens the claims repository and chooses the “Process New Claims” option from the drop-down menu.
When writing Use Cases, keep primarily the developer in mind. I’ve found the stakeholder doesn’t mind if the Actor / System interaction is a bit technical. This is actually what makes analysis work so fun. You have to be able to relate to both the non-technical business people and the technical people who have to actually build the solution.
When it comes to Alternate Flows and especially the Error Flow, create the system messages for the developer. After all, you know what speaks to the end user. If you leave system messages to the developer they may come-up with stuff that only God will partially understand.
Finally we’re down to the sign-off process. I find no-one likes to sign-off on stuff, but if you make the entire thing a rather light hearted event it should work. This presupposes the project manager, or whoever is in charge, wants documents to be signed-off.
I consider the sign-off important because it finalizes in everyone’s mind that what is written in the Use Case is what will be created, tested and deployed. The sign-off adds that little bit of pressure that helps stakeholders understand they can’t make a lot of changes, if for no other reason, that changes inconvenience a lot of people. It also preserves a higher level of accountability across the board, than if no signature finds its way onto the paper.
When you get sign-off on the final version of the Use Case, you can, with around 99% accuracy, begin work on those lovely black box testing scripts.
Articles Additional Resources
Check out these resources to gain a better idea of what a Use Case is and how to design them.
Wikipedia article on the Use Case
System Use Case by Scott Ambler
Use Case Fundamentals by Alistair Cockburn