Testing your systems

If you have been following along with the earlier installments of this series, you are getting ready to handle your (and your clients') Y2K issues. You've set aside time to do it all now, you've lined up the tools you need to make a list of your hardware and software that may cause problems, and you're ready to go full-blast into testing your systems to make sure you'll get through the year-end without a problem. So now what? Simple: test, test, and retest.

Why bother doing this now, instead of, oh, let's say, December? A few simple reasons. First, you get only one good shot at solving this problem. If your accounting package dies next January, you'll be down for quite a while as you upgrade the software, potentially causing much more problems next year. Secondly, the amount of software and hardware that could potentially cause problems is underestimated by everyone. You will almost always forget about something. Or one package interacts with another and causes an issue. Third, if there is custom software involved that needs patching or updating, getting the manpower and debugging time later this year will be next to impossible. And fourth: the year-end ain't gonna be delayed if you're not ready. You can't call someone up and beg a few more weeks until you deal with the issue. Do it now!

How much time is necessary for testing your systems and those of your clients? A rule of thumb I've used for years is that for any project, forty percent should be allocated to testing and debugging, and another ten to fifteen percent for roll-out and final testing. That's half your project time involved in testing of one form or another. That may seem high but the experiences of many developers will prove this to be the case. Actually developing the solutions to the problems is a small percentage of the overall problem: maybe fifteen to twenty percent. The rest of the time is used up evaluating the needs, developing a plan of action, and managing the overall process. 

Sure, testing is an inelegant part of the project, but in many ways it is the most crucial. If I had a nickel for every time I was sure the code I wrote was bug-free but something unexpected cropped up, well, I wouldn't be writing this column. Testing is a long and involved process to do properly and there's a whole subgenre of software developed specifically for the purpose. Fortunately, you will likely not need any of it. All you need is people and time: sit in front of the system and pound away. Fix the bugs as they crop up, and by year-end you'll be happy.

What's involved in testing? It depends on what you're doing, of course. If you're upgrading software to a Y2K-compliant format straight from a major vendor, all you need do is make sure the package launches properly, read existing files, and interfaces with all the necessary applications and devices. If you've custom written code, you need to give it a thorough test out under all conditions. If you've upgraded hardware, test it for the year-end roll-over. And so on. Getting ready for the testing cycle requires some planning. You need to decide what kind of tests are required, plan who will do them and when. Decide what kind of results you'll get if all is well, and what you'll do if problems occur. You need to keep track of the tests and also verify the results. If you're doing the testing for a client, you need to keep them updated and present them with verification of the tests, too.

So how do you test most of the software patches you're likely to run into? Start by doing what I mentioned in the previous paragraph. Use the application on existing and new data. Make sure it interfaces with everything else it need to work with. And then take the risky step: move the dates forward. Some sites it is better to try a date-forward exercise on just a subnet of a larger network, primarily because the data must be kept in synch with calendar dates. On other systems you can roll the entire company forward without any effect other than calendars looking odd.

Moving the dates forward is not as simple and trivial as it sounds. Don't just set a few system clocks to Dec 31 1999 and make sure the computers are still in one place the next day. Instead, move the dates ahead of the roll-over by a week or more, preferably a month, and then keep using the system until the roll-over happens. If the dates roll-over in, say, May, you have two alternatives. If everything works fine through May and June, you can backdate the systems and trust all will be well at real year-end. (You should change file and directory dates, to keep everything consistent, too.) If problems occur, you will know what needs to be fixed and can backdate the computers. They should then be working properly again (although you'll have to patch dates and maybe fix any affected data because of the faulty roll-over), and you now have time to come up with a solution to the problem and do the whole process again. However you do the date testing by advancing roll-over dates, this is one test that must be done. Don't just assume that things will work right first time. They won't.