All of the dozen project managers queried say they plan to spend 50 percent to 65 percent of year 2000 project time on testing. And most agree that no matter how much time you spend on testing, it isn't enough. But there are ways to make the most of the testing time you have. Proper planning, stringent control, practical use of resources and tools, creative approaches and keeping the enterprise focused on year 2000 can make all the difference.
The year 2000 testing task is so daunting that it's tempting to get moving immediately. But good, up-front planning can save weeks on the back end.
If your company is a latecomer to year 2000 and you haven't begun to fix date code, how you plan your conversion can make a big difference in testing time. One large insurance company reduced the amount of code it needed to test from 80 percent to just 10 percent. It did that by using the "added-logic" conversion method, according to the project manager, who spoke on condition that he not be named.
Rather than expand dates to four digits, the project team added logic to the source code to interpret two-digit dates. Any date less than 50 is interpreted as 20xx, so 12 would mean 2012. Any date greater than 50 is interpreted as 19xx, so 72 would mean 1972. The change works well except with birth dates, the project manager says, and the team developed special logic to handle those. By using the added-logic method, you don't need to change any data files, so you don't need to test the programs that use the data files as you normally would, the project manager says.
If you do change date code in your remediation, don't get carried away and fix other things or you'll have to do more testing.
But chances are you won't have time to test everything, so you'll need to prioritize testing just as you did for remediation. "You have to decide what you have to test and what you're willing to gamble on. But that decision should have been made before. You should be working only on mission-critical systems now," says Jack Sanders, year 2000 project manager at Fina Oil and Chemical Co. in Dallas.
If you still need to triage for testing, your disaster recovery plan is a good place to start, says David Register, information technology project manager for year 2000 at Pacific Corp., a Portland, Ore.-based power company. "The business units have already said these are the applications we absolutely have to have," he says.
Having good contingency plans in place for non-mission-critical systems can make you feel less uneasy about not having the time to test them as you'd like, says Steve Jost, project manager of the year 2000 conversion service at Deere & Co. in Moline, Illinois. "We are not going to compromise [our remediation process] because time is running out," he says. "For applications that may not get converted in time, we emphasize contingency plans as an alternative."
If you haven't let the remediation team fiddle with nondate code, don't waste time testing nondate logic, says Irene Dec, vice president of information systems at Prudential Insurance Company of America in Newark, New Jersey. "Review the tests and make sure that you're going for date logic only."
It's likely that you already have most of the tools you need for 2000 testing work. Use them; it will save the time it takes to learn new tools.
"We looked around, and tools that we already had were right for us," says Lon Rinehart, assistant vice president of business analysis at Ohio National Financial Services in Cincinnati. The tools included Compuware Corp.'s Xpeditor and FileAid, which Rinehart already had been using for non-year 2000 testing. An extension to FileAid called DataAger automates the aging of files for various date tests, and a configuration management tool called Change Man from Serena Software International in Burlingame, California, helps test how a change affects other applications.
But there also are special year 2000 tools that can save you time and effort. Del Duca uses a code analyzer called Visual 2000 from McCabe & Associates in Columbia, Maryland, that pinpoints all the dates in a program. "I may have a system with 100 modules but only 20 have [dates]," he says. "I only need to test those 20. You can really cut back on the amount of testing" if you know which modules have dates.
Dedicated year 2000 hardware also can save time and frustration, Dec says. She suggests setting up a limited partition (LPAR, which lets you run mainframe test files as if they were in a separate machine) in the mainframe environment and year 2000 test labs with dedicated servers for a distributed environment. That way, you won't risk crashing your normal test machines, nor will you have to share testing time with non-year 2000 projects, she says.
You also can arrange with your disaster recovery service to use its site for dedicated year 2000 testing.
That lets you do more sophisticated testing than you might be capable of back at the office, and it doubles your testing time by working simultaneously in both locations. "We don't have a separate LPAR, but at the disaster recovery site we can do that," says Mike Pratt, year 2000 manager at Appleton Papers, Inc. in Appleton, Wis. "We're planning to do full Y2K testing, including all the distributed applications and the interfaces to those."
Meanwhile, Pratt's team will be doing date simulation testing for online and batch programs at the office.
Another way to double testing time is the old-fashioned way: work extra shifts. "You definitely don't have enough time if you're only willing to work 40 hours a week," Sanders says. "This late in the game you need to add time on weekends, and we've actually gone to a night shift."
Finally, if year 2000 testing is competing with other priorities, you're wasting precious testing time, says Steve Hugley, senior vice president for information services at Comerica Inc. in Detroit.
"Every business unit executive has his own business plans he's trying to address at the same time as year 2000 and, unfortunately, they use the same resources," he says.
If other projects need to test, they have to wait. Year 2000 has to have first dibs on testing resources. "That's a biggie and a tough one to do," Hugley says, but "we've got to keep that Y2K focus."
(Melymuka is Computerworld's senior editor, management.)SIDEBAR: Time-Saving Testing TipsBy Kathleen Melymuka-- When choosing your date-fixing method, consider how long it will take to test repaired code.
-- Don't let your remediation team work on code that's not year 2000-related. If it does, you'll have to test that code as well.
-- Focus testing on mission-critical systems and functions; have contingency plans in place for critical and noncritical systems.
-- Use familiar testing tools as much as you can, but don't ignore time-saving year 2000 tools.
-- Use limited partitions on mainframes and dedicated year 2000 test servers in distributed systems to avoid fighting for resources and to prevent hardware crashes.
-- Use disaster recovery services for sophisticated testing.
-- Consider extra work shifts to squeeze more time out of the day.
-- Maintain year 2000 as a top company priority so you can have first claim on resources.
SIDEBAR: Going to Far
By Kathleen Melymuka
Don't let the auditors and lawyers spook you into trying to test every system. You don't have the time -- and it isn't necessary.
"Nobody will be able to test at 100 percent coverage, but I don't know why anyone would really want to do that," says Matt Hotle, a research director at Stamford, Connecticut-based Gartner Group Inc.
There comes a time when it makes good business sense to stop testing, says Boris Beizer, a senior consultant at Cutter Consortium in Arlington, Massachusetts.
"Every potential failure has a cost," he says. "We stop remediation and testing when the expected gain of further effort is less than the cost."
Even mission-critical systems don't need to be tested to death. Hotle suggests that you dig down into the applications, find the functions and transactions within those programs that are truly critical pieces and test only those.
For example, a mission-critical billing system might include functions that you can't live without, such as invoice generation. It also may include functions you can live without, such as report generation. So test the invoice function rigorously and lay off the reports function.
That's just what Randy Bauer is doing. "We're not testing the use of every piece of data and every system; that would be impossible," says the program manager for the year 2000 project at Toyota Motor Sales USA Inc. in Torrance, California. "We're beginning to focus selectively on mission-critical functions."
Your application experts -- the people who developed the system or know it best -- can help you separate critical functions from noncritical. Don't set yourself up for failure by attempting to do the impossible.
Hotle asks when Microsoft last delivered defect-free software. "But it's good enough for the marketplace, and that's what you should be aiming for," he says.
SIDEBAR: Three Levels of Year 2000 TestingBy Kathleen Melymuka-- Regression testing: checks software that has been fixed to ensure that no new errors have been introduced.
--Forward-date testing: checks whether software performs properly by using various future dates such as Jan. 1, 2000; Jan. 3, 2000; Feb. 29, 2000; and so on.
-- Integration testing: checks whether remediated systems work together properly throughout a department, division, company or among business partners.