Use cases are a great way to organize and document a software system's functionality from the user's perspective. However, they have limited uses for testers. They are great vehicles to accomplish some tasks, and not-so-great for others. Understand what you're trying to accomplish by testing before deciding if use cases can help - and be cognizant of the challenges they present. They are useful to testers, but not for every situation.
What are Use Cases?
Use cases are a relatively new method of documenting a software program’s actions. It’s a style of functional requirement document – an organized list of scenarios that a user or system might perform while navigating through an application. According to the Rational Unified Process , "A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor."
What’s so good about Use Cases?
Use Cases have gained popularity over the last few years as a method of organizing and documenting a software system’s functions from the user perspective. They support an iterative development lifecycle, and are part of the Rational Unified Process. (For more information about use cases, please see www.rational.com/rup)
What are some of their problems?
There are problems inherent in any documentation method (including traditional functional requirements documents), and use cases are no different. Some general problems to be aware of include:
- They might be incomplete
- Each case not describing enough detail of use
- Not enough of them, missing entire areas of functionality
- They might be inaccurate
- They might not have been reviewed
- They might not updated when requirements changed
- They might be ambiguous
What are some problems with using use cases to test software?
In addition to the generic problems listed above, there are specific challenges when testers use use-cases to test.
They are only useful for certain types of testing:
- User Acceptance Testing
- Positive “business as usual” Functional testing
- Manual black-box (some)
- Scripted automation -Automated testing—Use cases would be able to help you automate test scripts. It seems as though use cases are well suited to generate (even record) a suite of positive regression scripts. The use case helps you decide which are the common scenarios to record automated scripts for regression testing.
They could also help types of testing that overlap (or are co-defined) with positive functional testing:
- Smoke testing
- Sanity testing
- Regression testing
- Ad-hoc testing
What kind of bugs would not be discovered?
There are many types of bugs that you would NEVER find by “testing” a program by following its use cases. Some of them include:
System testing—Could you find a memory leak bug (not by accident) by following a use? case?
Integration testing—A use case for a financial trading system states that a buy order for a security can be good for one hour, one day, or until canceled. A tester (actor=buyer) following this use case might enter buy orders, then advance the system time/date to see if the order is removed from the system. But what the tester might not do (since it might not be explicitly explained in the use case) is check if the order appears and goes away on the seller’s workstation, or in the admin screen that summarizes all open orders in the system.
Performance testing—Would you be able to discover a defect for an advanced search that would take too long to return due to an inefficient database schema?
Load testing—Would you be able to test the load boundaries by following use cases?
Software Compatibility testing—Browser/OS: Drop-down lists or scrollbars are improperly formatted on Netscape 4.72. Did the use case directly help you find this bug?
Hardware Compatibility testing—drivers, printers, processors… Your app doesn’t print with older printers; use cases won’t help you find this bug.
Exploratory testing—Exploratory testing practices state that you learn as you test, and that your next test depends on what your last test was. It is a heuristic search for bugs not to be constrained by use
|The Dangers of Use Cases Employed as Test Cases||69.26 KB|