Why not testing for date and time issues could cost you a bundle.
You don’t have a crystal ball. Seeing the future is impossible, yet your job requires you to plan for the future and to know how things will pan out today, tomorrow, and a year from now. A major challenge of operating a mainframe for large organizations is knowing how the system will behave over time, how it will deal with old data, and how changes in date and time of files will affect operations. Understanding what files and systems with date-based parameters will do in production is important, and proper testing is the only way you’ll really know.
Companies as big as Apple have had struggles dealing with changes like daylight savings time, leap years, and other time-based events. Owners of iPhones have overslept when their alarms went off an hour late. Conversely, Windows applications told their users it was an hour earlier than it was. Though companies are no longer scrambling to deal with Y2K or other impending date-based drama, there exist still plenty of situations where it is important to test and simulate how systems and applications will behave over time.
Testing and planning systems around date and time changes such as leap years or daylight savings time can save your company from data-loss, lost productivity, and angry customers. By simulating the passage of time, you can test how time-based functions will work when triggered. Seeing how files and data will behave within your system over time is a critical part of testing. Since you don’t have a time-machine to rocket into the future to see what happens, it is important to have a method of securely moving forward within a safe simulated environment.
For example, if you had an application in place to auto-archive certain types of files that have not been viewed or modified in 180 days, you wouldn’t want to set up test data and then wait six months to see if your program worked. It would be far more practical to simulate the files getting older so you can see how they will act when they reach the 180 day mark. This can help reduce the risks of applications failing to function properly when they reach certain time triggers. Testing that sort of behavior in advance will prevent any unpleasant surprises with your production data.
This type of testing is especially important when setting up applications to run across multiple time zones. Transactional data from across multiple time zones can get snarly. For example, a mainframe processing credit card transactions should process each transaction in the time zone in which it occurred, rather than the time zone where the mainframe is housed. When setting up and testing the system, rather than flying staff across the county to perform test transactions, the time zone of the transactions could be simulated to make sure the system understands how to process them.
Solving the problems of files and systems working correctly as time passes requires extensive testing and sophisticated tools. These tools must be able to simulate changes in date and time to test date-sensitive code, dynamically age files to create test databases and files, and to be able to test time-based programs outside of the regular production environment. You wouldn’t want to perform these kinds of date/time tests on production data. It will always be much better to clone the data you want to test and perform your simulations in a safe environment.
Get your free trial of WizDom by ASPG to see how this type of testing can save your company time, headaches, and the expense of potentially large amounts of costly date/time errors. You’ll be glad you did.
