Using Modern Automated Testing Tools to Verify Mainframe and Midrange Batch Functions

Automated software quality (the process of having software test other software in an unattended fashion) has become a key player in the continued rollout of agile development processes whose target is “better software, faster.” Technical articles, open-source utilities, and licensed software solutions abound for desktop and server operating systems. But, what about classic System i and System z implementations which are still in use by the thousands?

By using Terminal Emulator (TE)-enabled automated testing software, we can automate the testing of most, if not all, green-screen-based applications running on our mainframe and midrange backbones. TE-enabled testing software allows for direct interaction with a formatted (3270, 5150) or unformatted (VT1xx, VT2xx, etc.) application interface (TE) running on a standard desktop platform such as Windows. These tools allow for simple record/playback scripting, as well as creating customized functions to perform specific operations. Verification points can consist of field formatting properties (e.g., protected, highlighted, numeric-only, visible, etc.), as well as field contents.

Let’s look at the steps to run a simple batch program on a mainframe and how a manual tester would verify the process via a 3270 interface:

1. Sign in.
2. Launch ISPF/PDF, locate the dataset, and edit the JCL for the job, changing date cards and/or other input parameters.
3. Submit the job to the Read Queue. Note the job number returned at the bottom of the screen.
4. Switch to viewing the Read Queue (optional) and wait for the job to execute.
5. Switch to viewing the Output Queue and find the output from the job.
6. Open the output and locate the values that signify a correct or incorrect run and pass or fail the test.
7. Optionally delete the Output Queue entry.

When viewing these steps from an automated testing POV, we can see what our test will need to do:

1. Launch the desktop TE, connect to the proper machine, and sign in. Wait for sign-in-successful screen.
2. Launch ISPF/PDF and navigate to the JCL file.
   1. Set up a “find text on screen” function that will locate a key word or phrase and return its location to the script. If not found on the current screen, the function will automatically page forward and continue to search for the text until it is found or the end of the list is reached.
   2. Use “find text on screen” to locate the dataset you’re looking for. Use the testing tool to select the correct line on the screen
   3. Use “find text on screen” to locate the date card or other JCL to be changed. Use the testing tool to update the JCL and save it.
3. Submit the job to the Read Queue. Use the testing tool to pick up and remember the job number from the resulting message.
4. Navigate to the Read Queue and put the test script into a loop, checking every few minutes for the job to change status.
5. When the job has run, switch to the Output Queue.
   1. Use the “find text on page” function to locate your job’s output by job number.
   2. Once found, open the Output Queue entry and parse through it, validating the results.
   3. Report on the validation process in the testing tool’s output report.
6. Optionally delete the Output Queue entry.
7. Optionally log out and close the TE session.

As you can see, automating the testing is just making the testing tool do what a human manual tester would do, including building in wait times for execution and visual verification of the output from the run. More sophisticated forms of validation, such as database queries, can also be included in the automated testing process.

Using TE-based, automated testing tools can speed up the process of validating interactive (e.g., CICS, ISPF/PDF), as well as batch operations on mainframe and midrange green-screen-based applications, resulting in better software—faster.