Tools that generate test cases from software requirements

In this expert response, requirements expert Robin Goldsmith gives examples of a variety of tools, including tools based on use cases, state analysis tools, and all pairs tools, which generate test cases from software requirements. He also explains some of the differences of the various tools, but warns that none is foolproof.

Are there tools that can take requirements as input and generate test cases as outputs?

I'm aware of several types of tools that generate test cases from some form of requirements. Tools based on use cases, such as Ravenflow, seem to be the most widely-known type. A use case describes how an actor interacts with the system. An actor usually is the user but can be a piece of hardware or other software.

These tools typically capture the step-by-step user actions and system responses in a somewhat structured format. The tools usually edit to confirm the use case follows certain logical and formatting rules, such as ensuring that IF statements include both main and alternative (ELSE) outcomes.

The tools then identify each path through the use case. Widely-held conventional wisdom says that a use case can be fully tested by executing one test case for each use case path (scenario). Unfortunately, this conventional wisdom is misleading because use cases and their path mapping frequently overlook far more paths than they identify; and one test case per path doesn't get to all the different ways that may cause the path's decisions to be taken.

More rigorous tools, such as Bender RBT, develop much more thorough detailed cause-and-effect graph logic flows from a very structured method of documenting functional specification business rules and then identify the minimum set of tests which will execute all the included functional variations. Bender co

uples the tool with ambiguity analysis to improve the accuracy of the functional specifications.

State analysis tools, such as Rational Rhapsody, draw a state diagram from structured descriptions of the various states of a unit, which can be a device or a program. The state determines the behaviors the unit should and should not exhibit, including what triggers transition to a specified other state. Test cases then are defined to exercise each path of states, demonstrating the behaviors it should exhibit and assuring those it shouldn't exhibit don't occur.

All pairs tools identify a way to reduce the effort of testing combinations of multiple variables that each have several possible values. All pairs most frequently is applied to testing configurations, such as multiple browsers/versions, operating systems, and hardware component options. Experience suggests that testing three- and more-way interactions is not productive, since two-way interactions account for the bulk of combination problems. While all pairs and the related orthogonal array techniques do cut the number of combinations to test, their advocates frequently forget to point out that all the many test cases still need to be executed for each combination.

While each of these methods offers certain advantages, it is important to note that none is likely to catch issues related to wrong or overlooked business requirements, quality factors, alternative ways to invoke a decision path, or product functional specification design decisions.

Dig Deeper on Topics Archive