Modular test case design consolidates tests |
 |
By Jennette Mullaney, Assistant Editor
19 Oct 2007 | SearchSoftwareQuality.com |
|
|
The number of manual test cases in a software project can be overwhelming. But David Dang, director of automation practices at Questcon and his colleague, Shaun Bradshaw, director of quality solutions, believe they have found a way to streamline this process.
In their session "Modular Test Case Design," the lively duo explained how modularization can consolidate procedural test cases into modular test cases, which can then lead to test automation. To illustrate how, Bradshaw and Dang told attendees about a major lending institution that was spending too much money maintaining manual test cases. The institution adopted a modular approach, and its 830 manual procedural tests cases were converted to 53 test modules. It was then able to automate 670 of these test cases.
|
| Testers embrace a user-oriented approach |
Modular test case design forces testers to imagine the big pictures when designing modules. "You need to be aware of the interactions between different requirements. It's a holistic approach," said Shaun Bradshaw, director of quality solutions at Questcon. "Modular testing forces testers to align their thinking with business and get into the head of a user or customer," he continued.
Yet many testers are glad to have this opportunity. David Dang, Questcon's director of automation practices, has worked with many different clients and finds that testers relish the opportunity to better know their projects. "I've never heard a tester say 'I just want to wait until the end to be brought in,'" said Dang. Bradshaw has also noticed testers warming to the holistic approach modular testing fosters. "The tester gains context," said Bradshaw. And testers love context. |
|
|
|
|
Bradshaw and Dang define modular test case design as "a function-based method of test design, which allows testers to categorize functionality to be tests into reusable "modules.'" Modularization substantially reduces redundancy, said Dang, using Google's main page as an example.
Imagine Google's main page. At the top there will always be a search function. Instead of creating 1,000 manual tests that include the search feature, turn the search feature into a module. Other functions, such as news, maps and login appear on nearly every page. Those may be broken down into multiple modules based on functionality, Dang and Bradshaw explained.
In the Google example, breaking down the application based on functionality makes sense and, according to Dang, is one of the most common ways to break down an application. However, there are other approaches, and testers will have to spend time studying the application and analyzing requirements before creating modules. Dividing an application along business processes or requirements may be more appropriate.
Some testers may not like this time-consuming aspect of modular test case design, and project managers may not appreciate the longer lead time. Bradshaw and Dang admit that modularization is not for everyone. However, many software testers appreciate the holistic approach of modular test case design and find the benefits outweigh the negatives. (See sidebar for more on the tester's attitude and role in modular design.)
Once a tester breaks down the application into modules, he uses a skeleton script to call those modules. Instead of cutting and pasting the same information over and over again, a tester can reuse the modules, greatly reducing redundancy. One member of the audience challenged that process, asking Dang and Bradshaw whether adding a domain field to the login function would require all of the skeleton scripts to be uploaded with the new information. All 1,000 tests do not need to be updated, said Bradshaw, and a large percentage of the regression tests can be automated.
Bradshaw explained: "For nearly all of the tests we would use a 'default' domain, and as a result we would add a conditional statement in the login module stating something like:
Step x -- If no Domain variable passed, set Domain to "Default."
Input -- Domain
Expected Result -- Domain value is set"
"In this example we still use a variable, but it is set to a "hard-coded" value of "Default" in the module anytime we have not specified the Domain in the skeleton script."
Dang emphasized that some test cases cannot or should not be automated. The ROI may simply be too low, for example.
"You don't want to automate 100% of your tests," he said. "If you can automate 70-75% of your regression tests, you're way ahead of the curve."
Modularization can make the transition to automation easier. In fact, most of the modularization analysis used to create the manual tests will apply to the automated tests, according to Bradshaw and Dang. And because the entire testing team participates in modularization, it doesn't need to be put off on a separate automation team.
Modular test case design may not be for every testing team. Those with a very small regression baseline, for example, may not see much benefit in adopting modularization. Bradshaw and Dang, however, attest that for many teams, modularization may greatly cut down on maintenance and keep testers focused on the "big picture" of their projects.
|
|
|
|
