|
-
-
|
-
Introduction
-
Most industry sources expect testing to account for approximately 50% of the total
effort in a Year 2000 compliance project. Few people debate the need for testing, but
there are many opinions and much confusion about what needs to be tested and how it
should be done.
|
|
|
-
Year 2000 testing issues
-
Building the most effective testing strategy for your organization
begins with a sound understanding of the issues involved:
- Testing will be predominantly functional.
- A complete set of baseline tests will be required, to ensure
that your Year 2000 changes have not introduced errors into
other program functions.
- In many cases, system documentation will be either non
existent or out of date.
- Applications may be being used in ways not intended (or
even known) by the designer or other IT personnel, e.g. by
keying dates or other data into descriptive or "spare" fields, to
satisfy some (originally unplanned) requirement.
- Because all systems will not be ready for testing at the same
time, system level tests will need to be re-run many times, as
each new application is ready for integration, system and
acceptance tests.
- Date related tests will need to be re-run across multiple processing time horizons
to ensure that all date changes work correctly around the turn of the century, Feb 29th
etc.
|
|
|
-
Building the tests
-
Building the baseline tests (which in many situations will
represent the bulk of the work) will need active involvement from
those staff who best understand the application function - the
Business Users. This is not a part time task, and should not be
viewed as such.
Selected Business Users should be seconded to the Year 2000
project team early in the project, and become full time project
team members until their particular applications have been
changed and fully tested. Their role should include helping assess
business priorities for the conversion schedule, and designing and
creating the functional baseline tests that will be required. In
addition, their application skills and knowledge can be used to
assist in designing a complete range of tests to thoroughly test all
date related changes.
|
|
|
-
Training
-
Do provide some training for your test teams. A short (2 or 3 day)
course that addresses the practical issues related to major test
projects can save a great deal of time in the long run, and make
your test cases and testing more effective and complete.
Several organizations are now providing training courses in
software testing, but make sure that the course you choose is
suitable. It is important that the course focus is strongly practical,
and does not confuse the students by introducing many new (and
unnecessary) technical terms.
Remember that most of the testing will be functional, and so a
course that devotes a large amount of time to structural testing
will not be much use to you.
If in doubt, send one person to evaluate the course before
committing to send your entire test team.
|
|
|
-
Test plan preparation
-
Once training has been completed, take the time to prepare proper
test plans that document everything that you will need to do.
Once prepared, don't file the plans in the bottom drawer, use them
to review progress and keep them fully up to date as the need for
new tests becomes apparent.
The work that you do now will not only help to ease the Year
2000 testing problems, but will provide a sound test environment
for your converted systems for maintenance changes beyond
2000.
|
|
|
-
Test environment
-
Because you will be re-running tests many times it is vitally
important that you have a properly planned and structured test
environment that allows you to quickly and easily "roll back" your
test database/files to a common starting point in preparation for
running your tests.
Roll back time will be critical, so don't attempt to "save time" by
using a copy of your production database.
Select your test database data carefully so that you have enough
data to fully test everything, while at the same time keeping the
size of the database as small as possible to allow for fast roll
back.
|
|
|
-
Test Automation for legacy applications
-
Because many tests will be run many times, test automation can
help significantly in reducing testing time and costs. Automation
will also remove the human error associated with manual testing,
and provide a better documented and more reliable test result.
Be careful when choosing test automation tools. Testing in a
character based host environment requires special features to
allow your test cases to automatically adjust to variations in host
response times, and to handle submission and checking of batch
tasks. A client/server test tool may not have these facilities and so
may require considerable effort and time to create a stable test
suite for your legacy applications.
Because of the huge number of tests that will need to be created, it will also be
essential to select a tool that allows tests to be created very easily, and in a minimum
of time.
|
|
|
-
Start Test Planning now
-
Finally, begin your test planning now, don't wait until your
changes have been done.
Get your team together, get them trained, and use their skills in
helping assign conversion priorities. Begin creating your baseline
tests now, using existing production software which you know is
working correctly.
Decide how you are going to fully test all date related changes,
and begin designing these tests too.
With the right test tools, even these tests can be created before
you have completed your Year 2000 changes.
By beginning test planning and creation now, in parallel with
conversion changes, you will have fully tested and operational test
suites ready to be used as soon as your changes are ready for
testing.
This will speed up the testing process significantly, and have the
effect of extending the time you have to complete all your
conversion work.
|
|
|
 Tester's Corner
Test Management Paper
|
|
