Using UML For Requirements Based Testing (Part 1)
| 2011/11/27 | Posted by CCAdmin under Models, prodcutivity, Software Testing, Tools |
Part 1 – Use Cases
UML, while although relatively new itself, is fairly well known in software design circles, but how many have seen its usefulness on the software testing side of things? There are many diagrams defined by the UML that give great information with regard to testing, especially requirements based testing.
Let’s take a fictitious system and draw a cloud diagram showing the boundaries, commonly referred to as a boundary diagram (explained here).
Boundary diagram to show boundaries/interfaces to SUT
Figure 1: Boundary Diagram
The diagram above shows the system under test and its interfaces to each external system that it interfaces with. This is a good starting point to understand the big picture of what you are trying to verify and can (for most systems) be drawn in only a few minutes. From this we already have the start of some scenarios we will need to exercise, namely each interface with an external system. This helps lead you in to the UML models you may create later.
Now, remember I’m writing this in the context of having a set of functional requirements, so I’m making the assumption that a functional requirements document is the starting point. From the functional requirements, you can determine the major behaviors in your System Under Test (SUT). This will also partition your requirements into manageable pieces.
Use-Case Diagram to show a behavior
Figure 2: Use-Case Diagram
Well, that is a pretty diagram, but what does it tell us? How can it help us develop test cases? The answer is that just a use case diagram really can’t give us that much information. Just the diagram without anything “behind” the use cases isn’t very helpful. We need to add some information to those use case pictures.
A use case needs “stuff” behind it to describe it. A use case diagram is a behavior diagram, so each use case needs its behavior described. Referencing Alistair Cockburn’s book, Writing Effective Use Cases, I’ll use the following format for use case capture.
Use Case Title– active-verb goal phrase that describes the primary use case goal
Primary Actor – Who has the goal?
Actor(s) – Any other actors involved
Scope – Identifies the system under discussion
Level – High-level, Low-level or some other level?
Stakeholder Goals – Someone or something with a vested interest in this behavior and their expectations
Preconditions – Must be true before the use case runs
Guarantee – Must be true after the use case runs
Main Success Scenario – Nominal case in which nothing goes wrong
Extensions – What different paths can be taken during the scenario?
For testing purposes, the success scenarios are very important. A success scenario is often an eagle’s eye view of a nominal (successful) test case. The extensions are variations on the success scenario, each of which can be broken into at least one more test case. So what we have is an outline of test cases that come straight from the use case scenarios.
Let’s continue with an example use case description. Here’s an example use case for purchasing a product over the web.
Use Case Title – Purchase Item
Primary Actor – Purchaser
Actor(s) – Web browser, Web site
Scope – Product Web site
Level – User Goal
Stakeholder Goals:
Purchaser – Want to purchase item
Web site – Want to sell item, take purchaser’s payment information, update inventory, notify user with transaction summary
Preconditions – Purchaser already has web browser open and pointed to the web page with the item they wish to purchase.
Guarantee – User is notified if transaction was completed or not, transaction logs are updated
Main Success Scenario:
- Purchaser selects “purchase” for an item from the web page.
- The shopping cart page is displayed and the purchaser updates the quantity.
- Purchaser selects “checkout”.
- The payment information page is displayed and the purchaser adds payment information.
- The purchaser selects “purchase now”.
- The web site displays a “processing” message and begins to process payment information
- When payment processing is complete, website displays a “transaction completed” message.
- The website sends an email to the purchaser containing a summary of the transaction.
- The website updates inventory, and sends email to the shipping department with order information.
Extensions – I will leave extensions off to make this example easier.
We have a use case now. So what? What can we do with it? How can it help us to test?
Remember that I mentioned in the beginning that I was writing this in the context of functional requirements and that the use case diagram partitioned your systems into manageable pieces. Well, if we are requirements-based, then we could easily allocate a portion of requirements to this use case. If we test this use case, then we’ll be testing those requirements. The job is even easier if the requirements are divided up by system behaviors rather than functionally.
Well, look at the format of that use case. It states things in the form of “do these steps” and “obtain this goal”. If we just flip that around, we have the goals and test by determining if those goals were met when we “execute these steps”. It doesn’t hurt to verify the details described along the way too (even if there are not requirements to cover them).
Taking our example to the testing step, we can first re-list the goals.
Stakeholder Goals:
Purchaser – Want to purchase item
Web site – Want to sell item, take purchaser’s payment information, update inventory, notify user with transaction summary
Guarantee – User is notified if transaction was completed or not, transaction logs are updated
So as we complete the success scenario execution, were these goals met? Did the purchaser purchase an item? Did the web site sell the item, take purchaser’s payment information, update the inventory and notify the user with a transaction summary? Was user notified when transaction was not complete yet, and did that status change when transaction was complete? Was transaction information recorded in system logs?
So this success scenario was pretty simple. It is standard practice to keep use cases fairly simple for this purpose. The success scenarios can get very convoluted if you try to describe too complex a behavior. Complex behaviors can often be broken down into multiple simpler behaviors (e.g. use cases).
Though this use case was simple, there are still a lot of variations that can change things. I left off extensions, but extensions are all the other variations that can happen in the success scenario. Each can be a test case of its own (possibly more than one). I won’t go into detail as it is pretty straight forward, but an extension is effectively just another use case and goal. In the name of clarity, however, let’s list a few possible extensions.
- What if the user updated the quantity to 0 when in the shopping cart page?
- What if the user selected cancel during the payment information screen?
- What if the user navigated off the page from the cart screen?
- What if the last item was just purchased before user completed transaction so that inventory was now 0?
So it is easy to see that there can be many ways to navigate through the use case. There is a main success scenario, but there can be many possible paths as well. Each of these possible paths is another possible scenario. It is very common for some of these extension scenarios to be tied to requirements allocated to that use case as well.
When testing a set of functional requirements, use cases are a good (and fast) way to get to test cases for many of those requirements. It does not guarantee that all requirements will be covered, but it is a good starting point and will often cover a large amount of requirements with minimal work (compared to work to get to the harder requirements that were not covered). Use cases can also help uncover requirement problems. They talk about interactions between actors in the system, and often a requirement may not cover that interaction.
So what about those requirements that are not covered? What other kinds of requirements are there that would not be covered here? Stay tuned for part 2 of this article where I go into more detailed behavior models, activity diagrams and sequence diagrams.
Recent Comments