Use Cases - when done properly - are the same as scenarios / personas.
The problem comes when people do overly general use cases and think they
are done. If I had a dime for everytime someone had handed me a 'general'
use case that didn't flesh out the details I would be a rich woman. Truth
be told, scenarios tend to be much more general than a well-defined use
case.
Here is the a successful methodology:
1. Scenarios/General Use Cases (synonymous) are written to get the
customer base thinking about the process that needs to be implemented.
These use cases define general processes.
2. Screens are mocked-up from the 'approved' Scenarios / General Use
Cases and run by the appropriate personnel - or test subjects.
3. Use Cases become more detailed and the screens are changed from the
feedback received in step 2. (These 2 steps can be repeated many times.)
4. You come to a point where everyone agrees this is the best that can be
expected. By this time, your Use Cases should be so well-formed that they
can be the basis for the test cases you would hand-off to QA.
5. Development creates functional versions of what has been discussed and
mocked-up and you test that against your expectations (use cases) and
against real test subjects. (There may be changes here again, change your
test cases.)
6. Repeat step 5 as many times as necessary / possible.
7. Test.
8. Release and improve.
Truth is, the vocabulary changes for the same thing depending on what
point you are in the process. Use Cases are to be written for BOTH the
ACTORS and the SYSTEMS and how they interact. They start off as general
scenarios until they morph into test cases. If you are doing anything
else, you aren't using the tool correctly in my opinion.
Regards,
Melissa L. Owsley 248 724 0667 (H)
[log in to unmask] 248 312 5353 (W)
________________________________________________________________________
"During times of universal deceit, telling the truth becomes a
revolutionary act." - George Orwell