Grid Test Case Management
Original Publication Date: 2004-Mar-25
Included in the Prior Art Database: 2004-Mar-25
The Grid Test Case Management methodology helps test case creators and test managers generate test cases and assess coverage much quicker than traditional test case management methods. Software testing requires that all functionality be executed and the path variations through these functions be exercised. These paths are documented in the form of test cases. Because not all releases require all paths be executed, some paths are at risk for repeatedly being exercised while other paths may be totally ignored. In addition, test cases are also usually stored in a manner that lists each test case as a number or brief description. The Grid Test Case Management methodology allows a test professional to easily create complete test case coverage, quickly select subsets of test cases, and ascertain whether or not adequate coverage has been given to variations of functionality.
Grid Test Case Management
From creation to data collection, software testing can be managed from a central point by implementing Grid Test Case Management. This process is used to ensure 100% coverage of all variations of test case scenarios, quickly produce test cases, test suites and test metrics for specific releases.
Grid Test Case Management begins with test case creation. Starting with a two-dimentional grid form, isolate all the available commands, or starting points and end points. After all of the commands are isolated, find all the available parameters for this command. For each parameter, list the possible values. Placed within a grid format, test cases are the automatic result of filling in command rows and parameter columns.
Grid Test Case Management Steps
1. Obtain a list of commands
2. Find parameters for each of the commands
3. List all possible values for each each parameter.
4. Place all obtained values into a two dimensional grid
Using these steps on a command line interface results in a completed grid:
command/parm File name Protocol Format
Send On local SMPT XML Send On local SMPT X12 845 Send On local SMPT ASCI Send On local HTTPS XML Send On local HTTPS X12 845 Send On local HTTPS ASCI Send On local FTPS XML Send On local FTPS X12 845 Send On local FTPS ASCI
Menu driven user interfaces can be implemented just like the command line. Each menu pick is treated the same as a command. All available options associated with the menu pick are treated as parameters.
For object oriented GUI's use functional end points that would generate a use test case. For instance, if the test product was on-line ordering, users could create, edit and delete orders. These actions would have the command and data entry fields as the parameters. Because GUIs are often not linear, it can be more time consuming to delineate the commands and parameters.
This process can be used to create test cases for the entire application. Once the grids are completed, testers can quickly assess how many tests they have for every functionality. For instance, if the functionality were limited to the example above, you can quickly ascertain that there are 9 total test cases. Local files were tested 9 times. There are 3 XML test cases, 3 SMTP test cases and so forth.
Using the same, very small example above, if all rows were executed you would have 100% coverage. However, if this is a regr...