Previous Info Memo

Next Info Memo

List of Info Memos

INFORMATIONAL MEMORANDUM

May 20, 1998



To: Chairman, Board of Directors
Chief Executive Officer
All Farm Credit System Institutions

From: Roland E. Smith, Chief Examiner Roland E. Smith
Office of Examination

Subject: Testing for Year 2000 Readiness


During the past 2 years, several Informational Memorandums have been issued that relate to the Year 2000 problem, including a March 17, 1998 Informational Memorandum titled “Expectations for Testing of Mission-Critical Systems.” The March 17, 1998 Informational Memorandum established key milestone dates for testing mission-critical systems. This Informational Memorandum compliments that earlier document and provides additional guidance on the testing phase.

Testing may be the most critical phase of the Year 2000 readiness process. The purpose of testing is quite simply to ensure that remediation efforts work effectively. Failure to conduct thorough testing may mask serious remediation problems. Not identifying or correcting those problems could threaten the safety and soundness of an institution. Ultimately, each institution is responsible for ensuring its readiness for the Year 2000.

TESTING FOR YEAR 2000 READINESS

In recent guidance issued by the Federal Financial Institutions Examination Council, testing mission-critical systems was estimated to consume 50 to 60 percent of the time, funding, and personnel needed to make a financial institution Year 2000 ready. Although the percentages may differ for institutions examined and regulated by the Farm Credit Administration (FCA), testing will still likely require a substantial commitment of resources. Institutions must effectively manage the Year 2000 testing process, regardless of how individual systems are developed and operated. In practice, the controls necessary to manage the testing process effectively will differ depending on the design of the institution's system, interfaces with third parties, and the type of testing used.

Farm Credit System (FCS or System) institutions should test mission-critical systems first, as the failure of mission-critical services and products will have a significant adverse impact on the institution's operations and financial condition. Each system and application should be evaluated and tested based on its importance to the institution's continuing operations and the costs and time required to implement alternative solutions. System institutions should also obtain sufficient information from their mission-critical service providers and software vendors to determine if they are able to test products and services for Year 2000 readiness. The failure of these service providers and software vendors to test their products and services in an adequate and timely manner could pose a risk to the safety and soundness of an FCS institution.

FCA supports the employment of user groups for testing as a means to control costs and to expedite the testing process. Therefore, FCS institutions with common needs and similar mission-critical systems may join forces to evaluate the performance and testing methodologies of service providers and software vendors. By working through user groups, institutions can gather and share information on testing methodologies and results of user group evaluations of service providers and software vendors tests.

The extent to which institutions rely on third parties to design, implement, and manage their systems will affect the extent of an FCS institution's involvement in testing. Institutions that outsource all of these functions will have less extensive involvement in testing than those System institutions that perform some or all of their own programming or processing in-house.

No single approach to testing for the Year 2000 problem is appropriate for all entities. Testing options range from testing within a System institution's own environment to "proxy" testing. The appropriate testing method to employ will depend on a variety of factors, including whether the testing is being conducted on software or services received from third parties, as well as the type of system or application to be tested.

Testing Methodologies

Each institution should determine the types of tests it will perform based on the complexity of its systems, the level of its Year 2000 risk exposure, and its reliance on third parties for computer-based products and services. Moreover, in addition to testing a particular product or service, institutions should conduct testing between systems and products that interface both internally and externally. The following are examples of testing processes that could be employed:

· Baseline tests are performed before any changes are made to a computer program or application. The baseline test helps an FCS institution compare performance of the system after changes are made to it.

· Unit tests are performed on one application to confirm whether remediation efforts yield accurate results for that application. They do not test how well the application will perform with other applications.

· Integrated tests are performed on multiple applications or systems simultaneously. Integrated tests confirm whether computer programs function properly as they interact with other programs.

· Regression tests verify a remediated system against the original system to ensure that errors were not introduced during the remediation process. Regression testing should be applied to both the remediated portion and the unchanged portion of the system.

· Future date tests simulate processing of renovated programs and applications for future critical dates to ensure that those dates will not cause program or system problems.

· User acceptance tests are performed with users and validate whether the remediations have been done correctly and applications still function as expected.

· Point-to-point tests verify the ability of an institution to transmit data directly to another entity or system.

· End-to-end tests verify the ability of an FCS institution originating a transaction to transmit test data to a receiving entity or system through an intermediary.

TESTING PLAN

As previously communicated by FCA, System institutions must have a testing plan completed by June 30, 1998. The testing plan should employ a testing strategy and set testing priorities based on the risks that the failure of a system may have on operations. The objective of the Year 2000 testing strategy should be to minimize business risk due to operational failures.

The testing plan should also provide for testing of both internal and external systems. Internal systems may include software, operating systems, mainframe computers, personal computers, reader/sorters, and proof machines. Internal systems also may include environmental systems, including heating and cooling systems, vaults, security systems, and elevators. External systems may include services from service providers and any interfaces with external entities.

Management and staff are expected to have the knowledge and skills necessary to understand and effectively manage their Year 2000 testing efforts. Management should identify special staffing and training needs for personnel involved in testing. They also should determine how they will allocate resources and, if necessary, hire and train employees to run and analyze tests. Examiners will evaluate testing efforts by reviewing a System institution's testing strategies and testing plans to ensure that it can meet key milestones addressed in the previous FCA Informational Memorandum --“Expectations for Testing of Mission-Critical Systems”--dated March 17, 1998.
Elements of a Testing Plan

FCA examiners' review of an FCS institution’s testing plan will focus on certain elements that should be addressed in the plan. Those elements apply to institutions that test internally developed systems, as well as institutions that test with service providers and software vendors.

· Testing Environment: Considerations for an appropriate test environment should include whether to partition current operating computers, by setting aside one or more sections to be used only for testing, or by using a separate computer facility to test. If the institution uses either a separate computer facility or the computer at its contingency site, it should consider how all interfaces, both internal and external, will be duplicated and adequately tested. Management should evaluate whether the test environment has sufficient computing capacity needed to complete the testing plan.

· Testing Methodology: The plan should address the types of tests for each application and system. See "Testing Methodologies" above for a description of various tests.

· Test Schedules: The plan should identify when software and hardware will be tested, including interfaces between systems. Test schedules also should be coordinated with the test schedules of third parties.

· Human and Financial Resources: The plan should include budget issues, as well as a description of the participants to be involved in testing (e.g., the information technology staff, end-user, and external parties).

· Critical Test Dates: There are certain critical dates that need to be tested for each mission-critical system. If an FCS institution's systems or applications fail to operate properly when tested for these critical dates, management must determine whether remediation and subsequent testing can be completed successfully, or whether contingency plans must be implemented. Critical dates may vary for a variety of reasons. Because additional dates may be critical for any given institution, each institution should test for any other dates it deems critical. At a minimum, FCS institutions should test for the following dates, including the "rollover" or progression before and after these dates, to ensure that applications and systems will operate properly:

Date Issue

September 9, 1999 Oftentimes, “9999” denotes the "end of input" in many computer programs.

December 31, 1999 Last day with 1999 year.

January 1, 2000 Beginning of the Year 2000.

January 3, 2000 First business day in the Year 2000.

January 10, 2000 First date to require a 7-digit date field (1/10/2000).

February 29, 2000 Leap year day.

March 1, 2000 Day after leap year day.

March 31, 2000 End of first quarter of 2000.

October 10, 2000 First date to require an 8 digit date field (10/10/2000).

December 31, 2000 End of Year 2000.

January 1, 2001 Beginning of the Year 2001.

December 31, 2001 Check that year has 365 days.