Practical Testing on the IBM i

 

Managers of business critical applications know the anxiety that comes with deploying changes. Few RPG shops have a complete library of test cases they can run to prove they are not delivering new defects into existing production code. How can this persistent problem be dealt with?

 

As a long time developer I have to confess that there is no aspect of software development I dislike more than testing. The curse is a blessing, however, in that I have worked hard to develop testing methods that achieve maximum benefit with minimal result. I manage projects by the following maxim:

 

 

Therefore, wherever possible, invest in testing tools and processes and go for large volumes of tests. This is what I refer to as extreme testing.

 

Categories of Testing – and being practical about priorities

Here's a way to categorize testing in a way that is familiar to iSeries developers, along with a general sequence I recommend for addressing each category. You can't do it all at once, so start with the biggest bang for the buck first:

 

Testing Type	Batch Programs	Interactive Programs	Service Programs1
Regression testing	1	4	2
New functionality testing	3	4	3

 

¹By service programs I mean such things as web services, stored procedures, etc – externally callable programs or middleware

 

This article is too short to review all categories, but you can learn more by reading A Visual Guide to Cost Effective Testing on the iSeries.

 

The Quickest and Most Valuable Extreme Testing: Regression-Batch

The technique and goal for regression-batch testing is what I call high volume parallel testing, which is tremendously facilitated by good tools.

 

Before I go into detail, a caution: you might be tempted to first tackle regression testing of interactive programs. I think this is a tactical mistake:

 

Key Components of a Testing Infrastructure

So let's focus on batch regression testing where we get the quickest improvements and lay the foundation for future improvements.

 

All of the capabilities and techniques I discuss below are available and readily deployable in Databorough's X-Data Test Suite.

 

There are three principle steps involved with regression testing batch programs:

Preparing A Database

There are two primary steps involved in test database preparation:

 

The purpose of intelligent data subsetting is to create relationally coherent records and tables that are smaller than the full production database.

 

For example, you might want a test database comprised of canceled orders. You would extract orders based on a canceled flag and then populate all related tables accordingly, customers, items, code tables, etc. This is a non-trivial task and is only viable with a sophisticated tool that knows the complete data model.

 

The next step is data masking, which alters confidential data to protect sensitive consumer or corporate information. Again, this is non-trivial as the data must maintain a legible appearance to users and relational integrity to associated tables.

 

Automated High Volume Parallel Testing – The Regression Payoff

Once a subsetted database is constructed for a project then it can be duplicated, with one copy for testing with the current version of the software and another copy for the new version of the software.

After parallel batch runs, file update results and report output can be compared. Manually comparing thousands of records, fields, and printed lines for high volume tests is not only laborious, but also error prone due to the limits of human attention.

 

Automated results comparison enables a much greater volume of testing at less cost with near perfect accuracy.

 

Achieving Extreme Testing

The only way I have survived my career as a developer is that I am mindful of this maxim and employ tools that facilitate testing. This is much more than a personal preference. As shown by studies of thousands of projects, the largest chunk of time in software development is devoted to detecting and correcting defects. (See Estimating Software Costs, Bringing Realism To Estimating, Capers Jones)

 

A good set of tools will help you lower both the costs and risks associated with testing your programming efforts.