A Use Case is not a substitute for a Test Case. I start with this point because there is a growing trend of organizations using Use Cases as Test Cases. Writing Use Cases takes a lot less time, requires fewer resources and less expertise.
Use Cases are user scenarios—typical sequences of tasks performed on the software by a typical user. A Use Case is useful for one purpose, in User Acceptance Test (UAT), to verify the software works correctly in typical workflows. Use Cases will include normal flow and alternate flow sequences, but they are still confined to fairly normal end-user workflows.
Test Cases cover the software more thoroughly and in more detail than Use Cases. Test Cases include every function that the software is capable of (or is supposed to be capable of); handling every type of data input/output, every expected behavior, every design item, and every class of defect. There are a lot of Requirements that are not covered in Use Cases. But all Requirements must be covered in Test Cases.
To satisfy a Test Case, there may be one, two, or more testscripts. Ideally, testscripts have step-by-step, click-by-click instructions that any person off the street could see and instantly perform with no training. (But because of reality constraints, testscripts often assume knowledge common to the designated testers.) When the testscripts pass, the Test Case passes. When the Test Cases pass, the Requirements pass.
Every part of a Test Case must be traceable to specific items in the Requirements document, which is not complete until you have captured implied requirements, and converted them into documented Requirements.
For example, if I’m testing to verify that closing “print preview” takes the user back to the “print dialog box,” then the Requirements document better state that closing “print preview” must take the user back to the “print dialog box.” If I am testing the boundary of max characters allowed in a field, the Requirements document better state the max characters allowed in that field. Then you can trace the test back to the requirement.
To trace between Test Cases and Requirements, you might see something like this:
- Requirements excerpt: “… (0052) the notes text field must allow copy/paste functionality, (0053) the notes text field maximum characters allowed must be 250. (0054) The date field …”
- Test Case item: 0053: verify the notes text field maximum characters allowed is 250.
- Testscript section: 0053: 1. enter 250 characters, click save (no error); 2. enter 251 characters, click save (returns error warning that the max characters allowed is 250).
Use Cases do not have this traceability; the 100 percent phrase-to-phrase, 1:1, reciprocal mapping to and from requirements.
As a sidenote, this Test Case traceability is also a good way to analyze Requirements. Every phrase in a Requirements document has a number before it, and every phrase is testable. If there’s a non-testable phrase in the Requirements, take it out.
So there is a big difference in the character and the coverage of the two ways of testing. Test Cases are for searching and exposing every type of error in the software (should be written by a seasoned SQA professional). Use Cases are for comfort-factor UAT to ensure that no embarrassing errors will happen in the common workflow areas (could be written by collaboration of customer service, technical sales, QA team, probably final review by the product manager). That’s my take.
Philosophy note: In everyday life, liberty, and the pursuit of happiness, don’t be a Use Caser (stuck in routine workflows), be a Test Caser (investigate everything, see how everything works, find new paths, explore boundaries).