Quite often when I’m asked to review a UML “Use Case” that someone else has written, I ask “Have you tested your Use Case with real data?” Sadly, the answer is usually “no.”
I don’t know why people don’t do this, but they don’t, and it seems like a very logical thing — essentially a unit test for Use Cases.
Use Case best practice: Walk through your use cases with real data
One time I was working with an insurance agency, and I was confidently told that a particular Use Case (and accompanying prototype) were “complete.” So I suggested that we walk through this one case with some actual data. I used my own car as an example, and as we walked through the Use Case with just the basic car data (2003, Chrysler, PT Cruiser, etc.), we quickly found a few missing items. When put in detailed context with just one specific example, the customer could clearly see that they were missing specific details in their use cases. But when they spoke in general terms, they didn’t see the problem.
Again, I’m not sure why people are reluctant to use actual data like this in their use cases, but I’ve seen that people like to speak in general terms so often there should be a name for this phenomenon. Technically, Use Cases at this point are referred to as “conceptual,” or “high level.” It seems like people are happy with their Use Cases when they are at this conceptual level, but for some reason they don’t want to take that next step to the detailed level that is actually required to validate their general ideas.
UML Use Case testing and Richard Feynman
I was reminded of this while reading a book named “Surely You're Joking, Mr. Feynman” this morning. In a chapter titled “Would You Solve the Dirac Equation,” he spoke of his approach when someone tried to explain a new concept to him. He said he would always ask a wonderful question:
“Is there a particular example of this general problem?”
When I read that line, I thought to myself, “See! I’m not crazy for wanting to test use cases with real data!”
When I read this story by Mr. Feynman I realized that someone else essentially used this “real data” testing technique in a totally different field, and he was obviously a tremendous scientist. In this same chapter he goes on to explain that people always used to think he was a slow starter because he asked questions like this initially, but later on he would find flaws in people’s approaches just because of this process.
I think it is very important to do this with UML Use Cases: Walk through your use cases with real data. Think of this approach as testing your use cases — “Unit testing for use cases,” if you prefer.
books by alvin
 |
 |
 |
 |
