Testing Use Cases
After the requirements are tested they evolve in a functional model (for instance Use Cases) of the required application. To Test the Use Cases you can use the checklist I derived from the article: "Use Cases and Testing (Lee Copeland)"
1)Syntax Testing
More: [ALM] & Business Continuity
After the requirements are tested they evolve in a functional model (for instance Use Cases) of the required application. To Test the Use Cases you can use the checklist I derived from the article: "Use Cases and Testing (Lee Copeland)"
1)Syntax Testing
- Complete:
- Are all use case definition fields filled in? Do we really know what the words mean?
- Are all of the steps required to implement the use case included?
- Are all of the ways that things could go right identified and handled properly? Have all combinations been considered?
- Are all of the ways that things could go wrong identified and handled properly? Have all combinations been considered?
- Correct:
- Is the use case name the primary actor's goal expressed as an active verb phrase?
- Is the use case described at the appropriate black box/white box level?
- Are the preconditions mandatory? Can they be guaranteed by the system?
- Does the failed end condition protect the interests of all the stakeholders?
- Does the success end condition satisfy the interests of all the stakeholders?
- Does the main success scenario run from the trigger to the delivery of the success end condition?
- Is the sequence of action steps correct?
- Is each step stated in the present tense with an active verb as a goal that moves the process forward?
- Is it clear where and why alternate scenarios depart from the main scenario?
- Are design decisions (GUI, Database, …) omitted from the use case?
- Are the use case "generalization," "include," and "extend" relationships used to their fullest extent but used correctly?
- Consistent:
- Can the system actually deliver the specified goals?
- Complete:
- Are all actors identified? Can you identify a specific person who will play the role of each actor?
- Is this everything that needs to be developed?
- Are all external system trigger conditions handled?
- Have all the words that suggest incompleteness ("some," "etc."…) been removed?
- Correct:
- Is this what you really want? Is this all you really want? Is this more than you really want?
- Consistent:
- When we build this system according to these use cases, will you be able to determine that we have succeeded?
- Can the system described actually be built?
- Complete:
- Do the use cases form a story that unfolds from highest to lowest levels?
- Is there a context-setting, highest-level use case at the outermost design scope for each primary actor?
- Correct:
- Are all the system's functional requirements reflected in the use cases?
- Are all the information sources listed?
- Consistent:
- Do the use cases define all the functionality within the scope of the system and nothing outside the scope?
- Can we trace each use case back to its requirement(s)?
- Can we trace each use case forward to its class, sequence, and/or state-transition diagrams?
More: [ALM] & Business Continuity