Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Automated Test Plan Creation - a New Approach

IP.com Disclosure Number: IPCOM000035651D
Original Publication Date: 1989-Jul-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 4 page(s) / 19K

Publishing Venue

IBM

Related People

Lucy, EE: AUTHOR

Abstract

The following article describes a method for creating an automated modular test plan consisting of both the stated intentions of the plan and the implementation and verification of that plan. It was tried and verified during the component test phase of the past release of the XEDIT component of the VM/SP operating system. The method is based upon experience gained during the component test phase of release 6 of VM/SP operating system development.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

Page 1 of 4

Automated Test Plan Creation - a New Approach

The following article describes a method for creating an automated modular test plan consisting of both the stated intentions of the plan and the implementation and verification of that plan. It was tried and verified during the component test phase of the past release of the XEDIT component of the VM/SP operating system. The method is based upon experience gained during the component test phase of release 6 of VM/SP operating system development.

The component test phase of the development cycle is the phase whereby the external characteristics of the VM/SP operating system are verified as to its correctness. The component test plan is created from studying the new external enhancements added by the development phase of the product. This plan takes into account new code and how it relates to the existing VM/SP operating system.

The test plan or what we commonly call the IT1 calls for a clear concise method as to how an external command is verified as being correct. A separate plan, called the IT2, is created to do the actual implementation and verification of the first plan.

The first phase of this process is identification of all the states that are possible for the command(s) that are being tested. For example, you have the command FILE with parameters NAME, TYPE, LOCATION. Then three states would be identified, one for NAME, one for TYPE, and one for LOCATION. The values that these states could take would need to be identified. This comes from the formal specification that the tester was provided by the development organization. This identification process continues for each command that is being tested. So, for example, if there are three commands, then this process would be repeated three times, once for each command.

Environment must also be considered. For example, if testing FILE, then another condition to test for would be if the file physically existed or not. This would be considered another additional series of states to be added to the first set that was defined.

After identification has been done for each command, the next step of this phase is to identify how these commands and states can be integrated. All dependencies must be identified along with any ability for separate processing. The process requires that all dependent variables be identified. So, for example, if command two must execute before command one, then this is a dependency. If command three has no dependencies on one or two, then it is a free variable. This also applies to all the states that were identified. Free variables are those com mands and/or states that can be executed without any dependencies upon any other commands or states.

The next major step of the first phase is to arrange the commands in a logical sequence so that execution will make sense. This is accomplished by looking at the dependent variables and the free variables. Free variables can be executed in any order because of their nature...