(*) indicate iteration. The message is sent multiple times. The expression within the brackets describes the iteration rule.
Deletion. An X is used to indicate the termination (deletion) of an object.
Let's begin with the simplest kind of testing-syntax testing. When performing syntax testing, we are verifying that the sequence diagram contains correct and proper information. We ask three kinds of questions: Is it complete? Is it correct? Is it consistent?
Do you remember our secret from the last article? You do not need to know the answers to any of these questions before asking them. It is the process of asking and answering that is most important. Listen to the answers you are given. Are people confident about their answers? Can they explain them rationally? Or do they hem and haw and fidget in their chairs or look out the window or become defensive when you ask? Now for the questions:
- Does each object required for the interaction appear on the diagram?
- Have all objects not required in the interaction been removed from the diagram?
- Does each object's lifeline begin and end at the proper time?
- Is each object's activation described properly?
- If the object's lifetime terminates, is it indicated with an X?
- Is each message well named with a strong verb?
- Are proper parameters included for each message?
- Are conditional branches drawn properly?
- Do conditionals cover all of the cases?
- Have any overlaps of conditionals been removed?
Domain Expert Testing
After checking the syntax of the sequence diagrams, we proceed to the second type of testing-domain expert testing. Again, we have two options: find a domain expert or attempt to become one. (The second approach is always more difficult than the first, and the first can be very hard.) Continuing, we ask two kinds of questions: Is it complete? Is it correct?
- Are all the ways that things could go right identified and handled properly?
- Are all the ways that things could go wrong identified and handled properly?
- Does the main success scenario run from the trigger to the delivery of the success end condition?
- Does the sequence diagram show each step that must be executed to implement the function?
- Can each step actually be implemented?
Finally, after having our domain expert scour the sequence diagrams, we proceed to the third type of testing-traceability testing. We want to make certain that we can trace from the use cases to the sequence diagrams and from the sequence diagrams back to the use cases. Again, we turn to one question: Is it consistent?
- Is each use case represented by at least one sequence diagram?
- Does each actor appear on at least one sequence diagram?
This set of questions, based on syntax, domain expert, and traceability testing; and focused on completeness, correctness, and consistency; is designed to get you started testing in an area with which you may not be familiar. Future articles will apply the same principles to testing class diagrams and state-transition diagrams.
Have fun testing.
Other articles in this series:
Testing UML Models, Part 1
Testing UML Models, Part 3
State-Transition Diagrams: Testing UML Models, Part 4