Using UML For Requirements Based Testing (Part 2)
| 2011/11/27 | Posted by CCAdmin under Models, prodcutivity, Software Testing, Tools |
Part 2 – Activity & Sequence Diagrams
Use Cases
With use cases we saw that we could define high level behaviors and describe their potential scenarios. These scenarios are likely to cover a broad range of requirements.
Use cases can help to generate scenario based test cases, but what about more detailed items that requirements specify sometimes, like:
- Boundaries
- Interfaces
- Timing/Performance
- Control Flows
- Data Flows
Activity Diagrams
Activity diagrams are kind of like a flow chart, but with swim lanes (technically swim lanes are optional, but I find them very helpful). Activity diagrams are good for showing control and data flow along with their partitions between architectural elements (can you say “boundary crossing”?), but they do not show sequence (temporal) detail very well. The swim lanes (vertical partitions) show which architectural element “owns” each action shown. An Activity diagram can show a higher level picture which “covers” lower detail requirements than we saw with use cases.
Figure 1: Activity Diagram (Annotated)
Activity Diagrams to Test Cases
The Activity diagram is created by describing some particular behavior. The behavior may be analysis of a set of the requirements you are testing. Much like the use-cases, an activity diagram will normally have one success scenario (which is the nominal path) and the other paths will indicate the extension scenarios (robustness, alternates, failure paths, etc..)
Sequence Diagrams
Sequence diagrams take activity diagrams down yet another level of detail. Activity diagrams show control and data flow, but when things like loops occur, they don’t show sequence very well.
Sequence diagrams show sequence of flows. Certain behaviors are very well displayed as sequence diagrams. Message passing or handshaking protocols, for example, because there are a lot of sequential actions happening back and forth. Activity diagrams tend to show all sequence paths, but they do not show the order. Sequence diagrams show the order of a sequence much better, but the price paid is deep detail. That is the Sequence diagram is so detailed that you don’t get the “big picture” view as you do in Activity Diagrams (or even more so in Use Case diagrams). Typically, it would take many sequence diagrams to show behavior in one Activity diagram, but each sequence shows detail not possible in the Activity diagram.
When getting into deeper requirements (e.g. lower-level), there tends to be a lot of information about “how” things are done. Timing is often added to these types of requirements. In these cases Sequence diagrams may be much better suited to show those detailed bits of information. Sequence diagrams not only show the architectural elements and boundaries that Activity Diagrams show, but they also show the order of data passing, the timing of actions and data flows, etc…
.
Figure 2: Sequence Diagram
Sequence Diagrams to Test Cases
Sequence diagrams can be worked into test scenarios much like Activity diagrams can. However, there is only one path in a Sequence diagram (or else it would be called sequences diagram, right?). So essentially, each sequence diagram would break down into one test case. From that test case, we can still potentially generate many other test cases just like we did with Activity diagrams because of the possible extensions (which should end up as sequence diagrams of their own).
Wrap Up
So from the requirements we now have three successive methods of modeling. Each method gets more detailed than the previous. The higher levels of modeling are more likely to cover a greater number of requirements; however the lower levels of modeling are more likely to show more difficult requirements.
So which level does one use? How do you decide which diagram is needed to show the requirements? In the next (and final) part of this series, I’ll talk a little bit about the level of diagram to use. It might not be as straightforward as you think.
Recent Comments