Standards for Testing › Types of Testing › Test Techniques › Manipulating Test Data

Manipulating Test Data

• You should have tools for examining and altering test data.
• You should have a means of looking at any database file that you are likely to change. The CA 2E Toolkit Work with Files (YWRKF) command can be useful in this respect.
• The OS/400 interactive debug facility can be used to check calculation values during program execution.
• You should have a means of listing the data from the main database files before and after each test is run.

The Test Cycle—When testing, you will be going through an iterative cycle of testing and error correction.

For each iteration, there will be an overhead involved in recompiling objects from corrected source and in resetting the test data to the initial conditions. It is, therefore, important to adopt a working method that corrects as many errors as possible during a given iteration. In other words, you should not necessarily stop at the first error you detect and attempt to correct and reiterate it, but rather, continue in order to detect and correct as many other errors as possible.

There are several techniques you can use to resume a test run, despite the occurrence of errors:

• Use the OS/400 interactive debug facilities to correct any program variables that are preventing the completion of a test.
• Use the CA 2E Toolkit Work with Files (YWRKF) command to correct any database fields that are preventing the completion of a test.
• Use the CA 2E Toolkit edit data area commands (YEDTDTAARA, YEDTLDA, YEDTGDA, and YCHGDTAARA) to correct any data areas that are preventing the completion of a test.

Error Reporting—In a live system, locating the cause of a bug is often more difficult than actually fixing the bug. This is partly because the sort of bugs that elude system testing tend to be obscure, and may only occur under certain combinations of conditions, but also because they are often reported by the end user, who quite naturally may not be adept at providing the information that helps to characterize a bug. It is important, therefore, to have an error reporting procedure that helps to capture as much information about bugs as possible. The user should be trained in basic recording techniques. Automatic techniques may also be used.

For any reasonably sized system, it is desirable to have a computer-based error reporting and problem determination system:

• To record the occurrence of an error in a standard format
• To monitor the progress of fixes for the error
• To allow the cross-referencing of related errors
• As a database for a system support personnel (a ‘Helpline’ or ‘Hotline’ function)

iSeries has a number of facilities that can be used to assist with problem resolution. For example, the Question and Answer database may be used as a basis for a computerized problem reporting system.

Problem Reporting Data—Careful consideration should be given to the standard information recorded for each problem, and the classifications under which they are filed.

Some items that are generally important are:

• Application or product name
• Product version number and fix level
• Operating system version number and PTF level
• Program or object name
• Command or menu option name
• User name, date, and time

Include circumstantial information, such as what the user was doing at the time.

Problem Reporting Procedure—Standard practice should include the following:

• Take a program dump if an escape message appears.
• Preserve the job log until the problem is resolved. A print of the log may be obtained either by pressing the PRINT key while displaying the second level messages, or by taking the OS/400 Sign Off command (SIGNOFF) with LOGOFF(*LIST).
• Print any associated displays using the PRINT key.

If you are operating on more than one machine, the Operating System version levels, including Program Temporary Fix (PTF) levels, should be recorded. The OS/400 Display Program Temporary Fix (DSPPTF) command can be used to examine the applied fixes.

Trapping Error Information Automatically—Apart from its normal job of logging facilities, OS/400 has three particular features that may be used to trap error information automatically:

• System reply lists. A default reply to exception messages can be specified for a job using the INQMSGRPY parameter on the OS/400 Submit job (SBMJOB) or Change job (CHGJOB) commands.
• Break message programs. An exception-handling program can be specified for particular messages using the DFTPGM parameter on the OS/400 Add Message Description (ADDMSGD) and Change Message Description (CHGMSGD) commands. Apart from dumping, the default program could carry out additional processing, such as notifying an operator. This facility can be used in conjunction with a system reply list so that the message-handling program is only invoked for certain jobs.
• RPG III *PSSR Subroutines. Exception handling subroutines can be coded in RPG III source to achieve a similar effect to break message programs.