You are currently on IBM Systems Media’s archival website. Click here to view our new website.

AIX > Tips & Techniques > Application Development

Are You Up to the Test?

Exploring best practices of testing

Exploring best practices of testing

Testing Process

A critical part of the testing process is the data with which we test. We need verifiable, accurate data for proper test results. In other words, if we don’t know the data to be accessed and manipulated, how will we know if our program is operating correctly? Establishing the test data is the foundation on which our testing is conducted. The technique of extract, transform and load (ETL) is how we establish the test data. We often use production data for testing, but we probably don’t need the entire production data set – just the appropriate data for our testing. This brings up an important point regarding test data – if you use an extract of production data for your testing, you need to use the same safeguards and security for that test data as you do for your production data. Confidential customer information must be protected even if it’s being used for testing.

The ETL process consists of extracting data from our production system, transforming the data to meet our testing needs (perhaps changing an identifier such as company number), and then loading the data into our test system. The test system may be a different LPAR, a physically separate system or a system composed of different libraries. Of course, the important consideration is to keep our production system and our test system separated. Nothing quite like the feeling you get when you realize you just set the status of all the open orders on a system to cancelled.

Conducting the test gets to the actual heart of the matter. Two types of tests are usually needed – unit tests and system tests. Unit tests are where we test the individual unit of code that we’ve changed. That unit of code could be a program or a procedure. I find that testing the smallest unit of code possible will yield the best results. It’s much more difficult to test a 25,000-line program for the change I made than it is to test a 50-line procedure. But while that has more to do with your program design philosophy, I think it points to the value of modular code. The system test is usually more involved, and may not be needed for all changes (though I think it should at least be considered for most testing). The system test is used to ensure correct operation and to identify any potential problems with other (usually downstream) processes. For instance, if I make a change to the order-entry program, I should also test the programs that print the list of open orders.

We want (and need) our testing to be repeatable. If we have a test script, and we have the same data, then every time we run the script against that data we should have the same results. This seems trivial, but it’s important. Results that aren’t repeatable show some type of inaccuracy; the data isn’t the same, the testing isn’t the same or the program hasn’t been changed correctly. You can easily determine if the testing is repeatable by simply running the same tests and getting the same results.

Regression testing is a type of unit and system testing. The idea behind regression testing is that fixing a problem, adding new functionality or making an enhancement to a program can introduce new problems. Sometimes a problem that was previously fixed will reoccur because the source code used to make the change was out-of-date. Sometimes fixing one problem can introduce other problems that weren’t even considered. Keeping test scripts around can be very helpful in regression testing. Re-running tests scripts can point out new problems or errors.

Michael Ryan is a technical editor with IBM Systems Magazine. Michael can be reached at



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters