Using UML For Requirements Based Testing (Part 3)
| 2011/11/28 | Posted by CCAdmin under Models, prodcutivity, Software Testing, Tools |
Part 3 – Getting the Right Level
Introduction
This last installment of discussing the idea of using UML for requirement based system testing shouldn’t be very long, but it is an important point. Part of the reason it is so important is because it is so difficult (yet looks so easy). Context, context, context! This is one of the reason why modeling with UML won’t “always” be the right solution.
The idea of using UML to help generate user/system scenarios has been presented. There are three primary models I’ve discussed to generate these scenarios: Use Case diagrams, Activity diagrams and Sequence diagrams. All three have times when they are good and appropriate to use. Sometimes you may use all three diagrams. Other times some (or all) may not be appropriate to use.
It’s a Decomposition Exercise
I see the “big picture” here as a decomposition exercise. You start with use cases and generate user/systems scenarios. Use Case diagrams are very broad and cover a large range of requirements (potentially), but only very high-level broad type requirements. They often do not have the detail sufficient to cover a requirement that has much detail contained within it. The next level of requirements down, with more detail, may be covered better by Activity diagrams. These requirements get more involved with elements like some of the architectural components of the system, for example. The next level of requirements down has much detail in them. They often cover performance and timing issues, sequencing or messaging protocols, etc… These are the type of requirements that Sequence diagrams often handle better.
Remember, all of these models are behavior models It is important to note that they are modeling behavior more than function. Viewing things from a behavioral point of view tend to lead to more overlap in test cases such that more requirements can often be covered from the fewer test cases. If you think of a behavior model as showing the “map” to gain a desired outcome or objective, then one can make a nice analogy with real life maps.
Map Analogy
Let’s say you are in Miami, FL and your objective is to drive to the Space Needle in Seattle, WA. Then the first level of detail is looking at “the big picture” and seeing broadly where your path lies to get you there. This is very similar to a Use Case diagram.
- Simple Route = Use Case Diagram
Next, you might take one significant leg of that trip to look a little closer, like what highway you would be on, and what direction you would travel it, what midpoint destinations you might go through that would be a good place to stop for the night, etc… This would be the mid-level detail. This would be similar to the level of the Activity diagram.
- Medium Detail Route = Activity Diagram
Then, you may take a particularly complex behavior and need to get much more detail to understand the requirements. In our analogy, a good example would be the final leg of the journey. Once you get to Seattle, you would need street by street directions to get to the Space Needle. Perhaps how long the drive or mileage on each street would also be helpful, to ensure you didn’t miss your turn. This would be the equivalent to the Sequence diagram in our analogy.
- Detailed Route = Sequence Diagram
Bump in the Road — Getting the Right Level
OK..up to this point, it seems pretty straight-forward, right? Well, the concept is straight-forward, but the execution may not be. This is the difficult part of the exercise. There is virtually no way to get this correct, other than experience (and even then you can do it incorrectly). The problem lies in the fact that even though each of these diagrams are somewhat of a decomposition of the one before, each diagram, itself, can be done at varying levels of detail.
A rookie mistake, for example, is to draw an Activity diagram to such detail that it is practically diagrammatic pseudo-code of the software or system. One could draw an Activity diagram with four action boxes or with eight action boxes depending on how detailed you created your model. The truth of the matter is that you only need to go the level of detail required to verify the requirements you are modeling. As I said, though, finding that correct level of detail typically only comes with experience. Especially, as that level may be different from program to program as it is truly dependent on those requirements.
I want to make a slight side note here. When I started modeling with UML, and I did some reading from various sources, I found it odd that Activity diagrams were not in high favor. To me, they seemed the perfect compromise of not too high level and not too low level. However, lately, I think I’ve been realizing why they are not as favored. This problem of finding the “right level” seems much more prominent on Activity diagrams than on Use Case diagrams and Sequence diagrams. High-Level and low-level (Use Case diagrams and Sequence diagrams) are not as difficult to find the right level because they are, by definition, the highest or lowest levels of detail. Activity diagrams are “in the middle” and can fall anywhere in between. I personally find getting the right level with Activity Diagrams by far the most difficult.
I’m beginning to be of the mindset (though I have no data to back this up yet) that doing multiple Sequence diagrams may be a better route to take than doing Activity diagrams. An Activity diagram can be “covered” (the same requirements covered) by multiple Sequence diagrams. As it is easier to get the right detail on Sequence diagrams, it may be better to just do those diagrams in the first place. Remember though that a Sequence diagram should only have one sequence shown per diagram.
Conclusion
UML modeling has become quite prevalent in software development. When working from requirements, it is entirely possible that development teams may have already created these diagrams. If so, they should be “there for the taking” to help with the software testing task. If they are not, learning some basic UML modeling techniques is a great tool for a tester to add to their tool belt.
Like any tool, nothing is perfect and nothing is a “one size fits all solution”. There is no such thing as a “one size fits all solution” as testing context always has the potential to change the game. However, when a scenario driven testing solution is a good route to take, then often this UML technique can be a helpful direction to go when looking for those user/system scenarios.
Keep decomposition in mind as this technique lends itself to decomposition well. Try to get the most scenarios from the higher levels because doing so covers more requirements in your developed test cases. Another reason UML behavior models are a good technique is that it looks at the requirements grouped as behaviors (rather than functions) and you tend to get more overlap from that point of view than from a traditional functional point of view. This facilitates getting more requirements per test case most of the time.
I hope this three part article has been helpful to you and gives you a new perspective when trying to develop user and system scenarios (which lead directly to test cases) when you are testing to a requirement specification. Good luck!
Chris,
This was an interesting series!
The use of such modelling isn’t limited to requirements based testing though. I’ve often reverse engineered such models during ET as a map of my explorations. I find this useful for keeping track, spotting gaps in my testing, and for generating further test ideas.
I’ll be revisiting this in 2012, perhaps I’ll write an update then.
–Iain
Good post, provided very good information Using UML For Requirements Based Testing.Thank you very much