Testing software upgrades
Environment
Companies are now integrating their geographic information systems (GIS) for use
throughout the company. Thus, upgrades to the GIS application affect not only the core
GIS product and its users, but users of dependent products such as work and outage
management. In order to test these complicated systems fully, a test environment or lab
is crucial.
Analyzing the number of and the extent of the GIS upgrades can help determine the best
testing approach. For example, if the application is a basic GIS application with no
interfaces, it would already contain core product changes and relatively few upgrades
would be expected. In this case, testing in the corporate lab might be the best approach.
Since the core product testing is the vendor’s responsibility and the upgrades are
minimal, scheduling time should not be an issue and extended testing should not be a
priority. On the other hand, if a fully integrated GIS already exists or is being planned,
an independent test lab is strongly recommended.
Funding a test lab can be a challenge in itself. An executive sponsor could be
instrumental in securing corporate funding and ongoing support. This person should
know what the lab will contain, what will be tested and delivered, and what the added
value to the corporation will be; and he or she must be able to market the entire package
to executive decision makers.
Coordination within the training department is also beneficial. Training generally has
hardware, software, and space allocated for these purposes. Piggybacking on this may be
a good interim step. (Cox 2002)
Not having a testing lab usually results in scrambling for equipment and/or space for
testing upgrades each time they are received. An even more difficult situation may
develop when the upgraded software is “tested” on a developer’s computer, then new and
perhaps significant problems arise after the upgrade has been rolled out—users stop
working, production is crippled, and acceptance of the software is hindered. Leveraging
the associated costs of these scenarios can help to justify a testing lab.
The following factors are important when building a testing lab:
- The room should be an adequate size. Consider available equipment and resource
needs now and in the future.
- Consider space-saving ideas such as equipment racks and master switches for
monitors, mouse, and keyboards to control several machines.
- Build in more network drops, modem lines, and power plugs than the lab is
expected to contain. Wire the lab so that the hardware can be easily broken down
and set up for different configurations.
- Provide storage space for documentation, software packages, and miscellaneous
supplies.
- Consider security and safety. Install security devices such as badge readers and
locks and safety features such as fire and smoke alarms.
- Remember the human factor. People may be spending long hours in the lab, and
the environment should be suitable. Good lighting and a soothing environment
ease tension.
- The appropriate hardware and software must be present in the lab. Database, web
and file servers, mobile and client machines, and any other hardware specific to
the company should be configured and networked as in the production
environment. Core application software and interfaces should be configured and
communicating.
- Installed software should mimic the user’s desktop. All applications installed on
the user’s machine should also be installed in the testing lab. This includes the
operating system, office applications, and virus-control software.
- Having the testing lab ready when the test cycle begins requires proper planning.
Among other things, additional hardware and software many need to be ordered
and installed, and the configuration may need to be adjusted. A testing
coordinator or lead should be identified to organize and support the testing lab.
This person should be granted sufficient time and the authority to set up and
maintain the lab.
The testing lab described above is ideal for all testing situations. For upgrade testing,
emphasis should be placed on the software configuration. Underlying code changes
(changes that the user does not actually see), interfaced legacy software, and custom
configuration may produce compatibility problems. Along with the above considerations
within the testing environment, the types of tests performed are another important factor.
