Admin Alert: The Rule of Fours for i5 Test Environments

After my recent article about duplicating data to a test environment, I started receiving e-mails discussing some other issues surrounding test environments and how your test data can affect (and be affected by) production data concerns. To address these concerns, I am going to pull back from the technical issues I usually discuss in this column and focus instead on the practical issues of designing an i5/OS test environment.

From my experience, I have found that a good i5, iSeries, or AS/400 test environment functions best when it is designed around the following four concepts:

• It should be secure: Your test environment should be as secure as your live environment. In fact, it should be more secure because (by definition) the software you are testing in that environment will be less stable, and test systems may contain copies of sensitive live data that can easily be compromised.
• It should be distinguishable: It should be extremely difficult for your users to mistake your test environment for your live environment. Test system outputs should also be easily distinguishable from live outputs that trigger company actions.
• It should be replaceable: Because you are usually prototyping new software in a test environment, system and programming changes happen quickly and may need to be reversed when mistakes are made. Frequent backups should be taken because frequent restores may be needed.
• It should be reloadable: It should be fairly easy to reload your test data when it inevitably gets corrupted by programming mistakes. Data reloads may also be necessary to repeat specific testing scenarios.

Undoubtedly, a good test environment encompasses more than these four concepts, but for the purposes of this article, let’s focus on these ideas as a starting point. If other readers contact me with different concerns, I may revisit this subject at a later time.

Security Your Test Data As If It Were Production

For many companies, test environment security is treated as an afterthought. This is done for a number of reasons. First, test environments are frequently only used by small groups of testers rather than by entire departments, functions, or companies. Because of this, there is a tendency to let everyone be able to test everything regardless of whether they should be exposed to the test data or not.

In situations where larger groups of users are testing and training on new software (such as when you are migrating to a new package), some administrators find it easier to ease up on the security during testing rather than take the time to secure each individual object and file, with the thought being that stringent security should only be used in live environments. Again, in a situation where users are running copies of live data, this undermines your production file security as users can potentially get to data that they were previously denied.

The third situation is that security can get wiped out or replaced when objects are recompiled and recreated. This is probably the most difficult situation to avoid because you frequently don’t even realize that it’s happening.

In i5, iSeries, and AS/400 environments, here are some suggestions for better test environment security.

1. If possible, stage your test environment on a separate partition from your production data. Separation allows you to create an isolated security environment that will not be influenced by existing security settings that you put in place for your production users.
2. Create separate user profiles for your test users and only authorize test users to enter the test environment. If a live user has a choice between entering a live environment and entering a test environment, he may become confused and start treating his production data as if it were test data. A live user profile may also contain more security authorities than are appropriate for the test environment.
3. You may want to set up a gateway program that authorizes users to enter the environment and that also initializes the environment for them as they enter it. If you do that, it’s a simple matter to set object authorities for the gateway program to only allow your designated users to enter the test environment and to keep all other *PUBLIC users out.
4. If possible, change your database files to *EXCLUDE access for *PUBLIC users and then compile your programs to adopt the authority of the user who owns the data (for a good explanation of this process, read this article by Wayne O. Evans on the IT Jungle Web site). By doing this, the user is automatically authorized to all the files that the owner of the program is also authorized to. The big benefit is that, because users get all the file authority they need from the programs they are running, you can lock down your users from accessing potentially sensitive test data through other techniques such as JDBC, ODBC, and Query.

I have one other caution about sensitive data. City, state, federal, and international laws governing how to handle personal information (such as credit card numbers, driver’s license numbers, hospital records, social security numbers, etc) are constantly changing and evolving. Some jurisdictions, such as the state of California, are requiring breaches of unencrypted personal data to be reported to all customers in that jurisdiction who have their data stored on the system. This can have incredible repercussions for you if a breach occurs in a lower-security test environment, so security should be seriously evaluated whenever you are planning to copy live sensitive data to a test environment.

Distinguishing Your Test Environment from All Others

When creating a test environment, it’s important that you distinguish it from your real data environments so that users don’t mistakenly start treating production data as if it were test data. Staging your test environment in a separate partition as mentioned above is one way to distinguish your test environment. You may also want to give your users separate test environment PC5250 sessions that use the package’s color mapping feature to change the foreground color of screen text when they are running a test session. That particular foreground color should only be used for sessions running in the test environment. If you use universal headings on your screens or Web pages, you may also want to change some headings to include the words “Test Environment” or something similar on the screen. The important thing is to physically change something about your interfaces on the test environment so that the user immediately knows where he’s at.

You also need to be careful with system outputs in a test system. Testing doesn’t change the fact that most system outputs (such as reports, emails, and web pages) will be exact duplicates of the output generated by your production environment. Be very careful when you produce critical test system outputs such as invoices, credit memos, picking lists, etc, from your test system, particular if these outputs are sent to user areas. If test output forms are indistinguishable from live output, there is a very real danger that a user could pick up the form and send it off to a customer or supplier, never realizing that it was just a test.

There are two ways to solve this dilemma. First, you can try to make sure that test output forms are always sent to test printers that never come into contact with users; you could even dedicate a special printer that only prints out test spooled files. The second option is to alter all test documents so that they plainly contain a warning literal that says something like ‘Test–Do Not Distribute’ in big black letters that are impossible for a user to miss (you could even make this literal a watermark if you’re using a graphics capable printer). The point is that you have to be doubly careful with test system output because if falsely distributed, it could cost your company a great deal of time, product, money, or embarrassment.

Restoring Software When Needed

As opposed to the stabilized code that you generally use in a production environment, test environments are much more volatile and easier to break. They also change at breakneck pace, where a lot of new functionality can become active in a single day. Unfortunately, this means that it’s much easier for programmers and system administrators to totally mess up a test system, creating a need to reload software pretty much on demand. So even though you are working with a test environment, you should try to backup your application programs and data every day. If you don’t back up on a regular basis, you run the risk of losing a good amount of programming when you need to restore. If you have the hard drive capacity and you don’t want to back up to removable media, you can also back up your application libraries to disk on an i5, iSeries, or AS/400.

Lock and Reload

Restoring data on a nightly or on-demand basis can help your testing scenario. If your organization is diligent and it takes the time to create a series of modeled data to test a desired result, your shop can make programming changes, test those changes with the modeled data, and then restore the data at night in order to test new program changes over the same data set. In addition to performing specific test scenarios, you may also want to reload your data set from time to time just to get rid of the bad data that creeps into your environment from test programs.

A Surface in Need of Scratching

As you can see, there’s a lot to think about when setting up a test environment on an i5/OS or OS/400-based machine. It’s a topic that’s worth doing your research on and planning well ahead of implementation to make sure that your testing falls within appropriate laws, satisfies company needs, and doesn’t have any adverse on your customers, suppliers, employees, or existing computer systems.

RELATED STORIES

Backing up i5/OS Partitions to Disk

Controlling PC Access

The Pitfalls of Duplicating Data to a Test Library

Readers Check in on PC5250 Color Changes