Down the Audit Trail.
Documenting efforts for testing solutions to the Year 2000 computer problem can help protect your company not only from computer failures but from potential litigation.
The type of audit trail that can only be provided by automated testing is a necessity for protection from Year 2000 (Y2K) date-related failures and accompanying litigation. Industry experts predict that total damages from Y2K litigation in the United States could run as high as $100 billion. Simply upgrading to applications that are certified as Y2K compliant won't protect you from integration problems or from liabilities if the program isn't really fixed.
A continuous testing regimen is the only way to determine whether all the many components and layers of your information systems will continue to operate uninterrupted over the coming months and years.
Regardless of how much money and time you have spent on Y2K readiness, chances are that you still may be on the hook for a huge potential Y2K liability. Dates are so all-encompassing that when you start changing the way that software handles them, every aspect of the program and all the interrelationships between different programs need to be tested.
Even if all your developers, application package, and information systems infrastructure suppliers are prepared to reassure you that their products are "Year 2000 ready," can you be sure that they'll all work properly together in your environment? Vendors can't test the millions of possible combinations of application and database settings. In addition, each company has a unique configuration and network.
Other vendors fall short of offering an unequivocal guarantee by stating that if you can demonstrate a Year 2000 defect, their only responsibility is to do their best to fix the problem. So, in a worst case scenario, if your systems fail, your suppliers will each argue that it's someone else's fault and, even if a single supplier does acknowledge fault for the problem, the company only has to do its best to come up with a fix.
Here's an example of how easily an integration issue can cause a Y2K problem. One customer recently reported a failure in using one of our products with 21st century dates.
When we attempted to recreate the fault on one of our support systems, all our tests passed without exception. We sent a support consultant on site and precisely established the customer's run-time environment. The consultant discovered that they were running our product in conjunction with an outdated version of a standard Microsoft DLL. The date test failed. This was in spite of the fact that the DLL in question apparently has absolutely nothing do with date manipulation.
Eight-digit dates are only a starting point to Year 2000 readiness. Just because a program stores dates as eight digits doesn't mean that all date comparisons and date arithmetic will operate correctly nor does it guarantee that Feb. 29, 2000, will be recognized.
Also, many products use date windowing to achieve Year 2000 readiness. But the algorithms used can compromise the product's ability to correctly process existing data. And, because the pivot date for inferring the century can vary between applications, tools, and infrastructure products, very unpredictable results can occur. This is a particular problem for any organization or system that often processes entities or transactions that are more than 30 years in length, such as mortgages, life insurance, medical records, taxation, and social services.
It's important to note that just because your testing determined that your systems were Year 2000 compliant a month ago, it doesn't mean that they still are today. This is often called the pollution problem. Programmers are continually adding new functionality or making additional fixes that can introduce noncompliant routines. In addition, new internal systems are continually coming on line and external systems are being interfaced with.
Year 2000 testing is an iterative process that must be repeated many times to determine whether it meets the completion criteria set by users. Throughout the analysis, assessment and conversion steps of the compliance effort, essential information about applications, relationships and data is fed into repositories that feed the testing process.
Nearly every company that has estimated the magnitude of the effort required to comprehensively and continuously test their systems for Year 2000 compliance has ruled out manual testing on the basis of manpower considerations alone. These companies discover that the testing process will not only occupy the lion's share of their efforts but will require more manpower than allocated to the total project.
That's why automated testing is a necessity for Year 2000 readiness. Today's most advanced automated testing solutions operate on a "black box" principle. This means they simulate everything that goes into or comes out of your information systems. You do not need access to a source code. You simply record a business process using contemporary dates and then automatically it replays at a series of future dates spanning the transition from 20th to 21st century.
When you replay, the script automatically synchronizes all input data to the simulated test date and calculates expected results, taking into account correct date arithmetic. Outputs generated by the test are then automatically compared with the expected results and any differences indicate a Year 2000 problem.
Automated testing typically fits into the Y2K readiness effort as follows. Typically, the analyst determines which aspects of the application are date sensitive, what fields have to be keyed in to challenge the date functionality of the application, and which aspects of the output are critical.
Then the users go through a series of operations that thoroughly test the application while the testing program records the keystrokes and generates a script that can be easily edited at a later date if required. The conversion process begins with locking up the source code for a particular application. The code is installed on a production system and the script is used to run a baseline test.
The testing tool organizes the results of all the tests. It provides screen-matching facilities that can quickly and easily detect unexpected discrepancies between screen snapshots taken before and after code remediation. When the test results are completed, an analyst compares the results of each run with the baseline run to determine whether the application is working as intended.
If a problem is identified, then the analyst sends the code back to the remediation specialists. If not, then the analyst documents testing results and prints hard copy reports required for due diligence efforts. The Year 2000 compliant code is then migrated into production using the code management system. The testing program also produces trend analyses that can be used to track the quality of the remediation effort.
Automated testing dramatically reduces the time required to test Year 2000 compliance. Rather than tying up operators and analysts in a repetitive manual process, the software tests all aspects of Year 2000 compliance on an automated basis Testing time is typically cut by 60 percent to 90 percent compared with the amount of time required for manual testing.
Thanks to this improvement in productivity, the compliance effort can come in ahead of schedule and right on budget. The new methodology has proven so successful that management in companies that try it typically make the decision to use it as part of the normal testing whenever an application is developed or upgraded.
All automated tests are recorded for due diligence in Year 2000 testing. The entire process, including all real-time keystrokes and screen displays processed by the tests, can then be archived with the test results.
If all goes well and your system proves 100 percent Year 2000 ready, automated testing provides a complete audit trail to prove you've exercised due care. Automated testing can significantly reduce the staff time now dedicated to system validation testing while at the same time improving the quality of mission-critical applications. In fact, automated testing makes it economical to address everyday user concerns with the same exhaustive level of due diligence that you are now being forced to devote to Y2K readiness.
|Printer friendly Cite/link Email Feedback|
|Publication:||Risk & Insurance|
|Date:||Jul 1, 1999|
|Previous Article:||Uncertain Fortunes of FINANCIAL REFORM.|
|Next Article:||How Hazardous To Health Is Y2K?|
|ETIo Accelerator for SQL/Teradata.|
|Introducing the Chargemaster.|
|Authentify Enables Safer Online Transactions. (New Products).|
|Extending the role of audit trails: a modular approach.|