Y2K fixes: Standing the test of time

Testing IT systems can account for half the time spent on co-ordinating year 2000 projects, and many experts recommend that companies will need all of next year for this purpose.

'That leaves a little more than one year for implementation, assessment and fixing those dates which need changing,' warns Mercury Interactive's vice president of product marketing, Zohar Gilad.

He adds: 'Time is running out for corporate IT. There are simply not enough hours to leave testing to the end of the date conversion process. Customers need to identify, correct and test applications all at the same time to achieve their goal of converting their most business-critical applications by the end of the century.'

But the cost of testing is enough to make your hair curl. Gartner Group estimates testing will account for 45% of the cost and effort of year 2000 conversion. Sema Group's year 2000 programme director, David Broughton, has different arithmetic again - he reckons the figure is nearer 70%. 'Testing consumes even more time and resources than were ever imagined, and certainly more than would be expected under normal circumstances,' he says.

Unusually, extensive testing is often required during the early stages of a year 2000 project. 'It's important to test business critical systems to establish whether or not they are year 2000-compliant,' adds Broughton. This, of course, bumps up the cost, but it's unavoidable. 'You could go direct to code scanning, searching for dates, but to be certain you need to test,' he says.

It is generally recommended that you establish a testing environment and isolate it totally from your production systems to ensure testing doesn't interfere with day-to-day business activity (your 'live' IT environment and the data that lives within it). This may mean you have to buy in extra hardware and software - another cost.

If you're an organised company you'll have spare capacity in the production data centre to meet peaks and troughs in demand - weekly, monthly and year-end.

'Larger organisations have testing facilities and disaster recovery data centres,' points out Keith Hodgson, director of systems integrator SX Consultancy. 'If they have the luxury of their own disaster facility then this is the obvious choice for hardware.'

And, of course, watch out for time. Your normal suppliers may not be able to meet your equipment needs or timescales without sufficient notice. 'Critical systems must be extensively tested with data created to simulate genuine scenarios across the millennium boundary,' says Broughton. 'Again, this can be time consuming and expensive.'

All conversion software, either developed internally or bought in, should also be rigorously tested. If any suppliers have developed software for your business, you should check your licensing agreement with them before testing.

However, year 2000 testing is more than the testing of applications. It can, and often does, involve testing of the underlying operating system, database software, communications software and language compilers - all of which may need replacing or upgrading to achieve compliance. Newly purchased de-vices with embedded chips also need to be tested, possibly per sample, and preferably with the supplier present at the test.

That said, what about tools? BR Business Systems uses both date intercept software and a separate environment on the mainframe that allows the behaviour of systems to be tested on dates close to and after the millennium. However, Paul Seward, BRBS' international projects business manager, says: 'Testing tools - other than those for date interception - should not be purchased just for year 2000 but chosen because they will improve the quality and productivity of the organisation for all future work. Remember that economic and monetary union (EMU) is the next challenge.'

New testing tools are hitting the market almost every week. Before you commit, get the tool on trial and find out of what it's really capable of. 'Ensure that you know how it will be of use to you and whether your staff will have to change their processes to use it effectively,' advises Seward. 'If changes are required, check to see if your organisation can make them successfully in the time available.'

This raises the spectre of co-ordination. Who should be in charge of the testing process and which areas of the company are involved? Many companies have created year 2000 development manager posts to monitor the overall process, but there's no getting away from the fact that testing involves IT and business users alike.

'Building the baseline tests - which typically represent the bulk of the work - will need active involvement from the business users,' says Softlab's marketing manager, Karin Rutter. 'Involving the end user in the process enables more people to be deployed against the problem, and ensures a better quality of end result.'

According to Broughton, senior users must take a strong role in defining the scope and extent of year 2000 testing. 'This involves much more than IT technical issues. Systems do not live independent lives - they interact with people and processes,' he says.

Seward agrees: 'Users and IT departments have to work together to determine the right priorities and achieve a balance. Testing costs needs to be assessed against the cost to the business of not testing.'

'Astute senior managers in both business and IT are now realising that the year 2000 testing issue is about tough business decisions, not simply computer code,' says Lockyer. 'Their most valuable support tool to help in this process is a proven risk assessment method, which sifts out the essential changes from those which are less important.'

To do this properly, you've got to refer back to your compliance plan. ICL's approach is to use the business process as a means of identifying and prioritising the systems it wants to make year 2000 compliant, instead of trying to fix everything. 'Our app- roach is to ack- nowledge that not every system is critical. Some systems can be allowed to fail without endangering the business,' says man- aging consultant Andrew Rollerson. 'The resour-ces available to a year 2000 project are limited - so the "fix everything" approach might not be feasible or cost-effective anyway.'

Page 60

Dos and don'ts: Year 2000 testing

In a nutshell, the process for year 2000 testing is: analyse, modify, re-test and repeat.

• DO plan testing early, especially the test environment and the resources you need to conduct the testing.
• DO plan testing thoroughly, including the tests of any changes.
• DO involve users as early as possible. 'End users tend to know the useful business functionality of the systems - what's gone wrong with new releases, system blackspots, and so on,' says Dave Parmenter, marketing manager for Unisys' team 2000 group.
• DON'T use your live IT environment for testing.
• DON'T overlook the systems' interfaces to third-party products and external companies. ICL's Andrew Rollerson believes you should critically examine the classes of external organisations with which your company interacts. 'For example, a supplier of an essential raw material to a production process is clearly more critical to the business than a supplier of gardening services, although both may be classed as suppliers,' he says. Draft a list of all the interactions and prioritise them by carrying out an impact assessment for each one. 'This involves identifying the perceived risk of failure of a given interaction and the impact it would have if a failure would occur,' adds Rollerson.

Words of wisdom: 'Test, then test again'

'If there is any doubt at all, and even if there isn't, then testing changed code must still be performed. Someone who suggests that changed code need not be tested is an idiot' - Peter de Jager (Biting the Silver Bullet) 'It could be all too simple to find yourself on 1 January 2000 saying, "We did what we could, we used every bit of budget and resources, and changed every bit of code", while knowing that this was done at the expense of appropriately testing any of it' - Sysdeco Solutions' marketing manager, Stuart Lockyer 'IT departments cannot simply modify their mission-critical systems and put them back in operation. They need to test them. In fact, the scale of testing shouldn't be underestimated, and you should get on with it. Test everything and keep testing it' - Gerard Long, Midland Bank's year 2000 planning manager

NCC and CSSA: Testing code of practice

The National Computing Centre (NCC) and the Computing Software and Services Association (CSSA) have issued a code of practice for testing year 2000 systems and software. The code of practice was put together following advice from professional testers, users and vendors. The document outlines the minimum activities and checks that should be applied when testing for year 2000 conformance, and is freely available from both the NCC and CSSA Web sites at: http://www.ncc.co.uk/y2k.html and http://www.cssa.co.uk/cssa. The CSSA is asking for feedback on the document from its members, and hopes that the code will be adopted by all software vendors as a voluntary scheme for providing year 2000 reassurance to their customers. The CSSA Web site holds a register of the products which have already been tested to this standard.