Here's how I look at test scenarios and test cases.
- Test Case - small, self-contained, tests precisely one thing (the thing can be a system action such as "log on with correct credentials" and may or may not have a number of implicit requirements, prerequisites, or steps)
- Test Scenario - sequence of related test cases performing an end-to-end test of a system function. An example using the log on test case above could be:
- Log on with correct credentials (user has sysadmin rights)
- Go to user management module (implicit requirement: this test case will fail if the sysadmin rights are not applied to the user)
- Add new user X with predefined user profile Y (implicit requirements: the profile for the new user has been defined as part of system setup)
- Log off.
- Log on as user X.
- Verify the list of available modules matches the expect list of available modules.
- Log off.
My heuristics for generating test scenarios are pretty basic: I look at user patterns, common end-to-end tasks, and so forth. From that and the possible configuration options, I can generate an endless list of potential test scenarios.
Some examples of the heuristics I use:
- Common tasks for each available privilege level
- Common tasks for each common configuration set
- Reported bug clusters
- Implicit requirements/prerequisites (i.e. in order to do X, I need to have done Y)
- User patterns (e.g. power users work almost entirely through keyboard shortcuts, so generate scenarios where all the navigation and functionality is triggered by keyboard shortcuts)
I don't need anything more complex than this because these kinds of heuristics will generate complex scenarios once I start using different combinations of possible options.