By David Doyle

Every consultant that provides software or services to clients should have a good plan for testing their systems before deploying them at clients’ sites. Unforeseen problems can arise after a client starts to use the systems, which can be embarrassing not only to your organization, but it can end up costing your firm thousands of dollars, not to mention the potential loss of future clients. This article outlines a general plan that can be followed for several situations regardless of the platform or operating system being used.

How does lab testing benefit me, and why is it necessary?
Even if you are certain that the software is a good product and that there haven’t been too many bugs, you can never take too many precautions. Testing can expose problems such as:

  • Flaws in the design.
  • Inefficient processes.
  • Poor performance.
  • Incompatibility issues with hardware and/or software.

Testing is also a good way to practice installing and configuring the product before it is presented to the client, and it allows you to learn about the software more thoroughly. It can show how the product will perform in various situations, particularly if the testing is done in an environment that duplicates the one that will be used by the client after the product is deployed.

But most importantly, testing will help you to be prepared in case something goes wrong with the system (hardware or network failures, data corruption, etc.).

Getting started
There are two very important requirements for all testing projects: documentation and budgeting. You can never have too much documentation.

Even if it’s not a very large project, you should be keeping a record of all your actions from the very beginning. It might seem that you don’t need the notes right now, but if you get stuck on a problem later, the documentation can help you trace the problem back to a previous step.

Start with your ideas of what should be accomplished by testing the software, any problems that you foresee, and a list of other people who might need to participate in the testing.

Next, plan a budget for the project. Even in the early stages, you should have enough resources allocated so that you can add more testing components later, if necessary. Remember that you should avoid taking any equipment that is already in the production environment, such as computers or other components currently in use, even occasionally, by office workers or other personnel.

Ideally, you want the testing lab to simulate the production environment, so identical equipment should be purchased for the lab if feasible. It’s also best to avoid using the lab testing equipment in the production environment later. That same equipment can be used again in testing sometime in the future.

Although it can be expensive to acquire the equipment and set up the test lab, it is quite possible that the costs can be justified in several ways. Consider the return on investment (ROI):

  • If you can use this equipment for other projects, you can save substantial amounts of money in the future.
  • Most likely, you will also be able to streamline the testing process over time by discovering more efficient ways to accomplish various tasks.
  • The lab can serve as an environment where you can have training for the demonstration of functionality, deployment processes, or resolving problems in a project.

The equipment that will be necessary for the project should include:

  • Servers that are identical (or as similar as possible) to the ones in the production environment.
  • Client computers corresponding to the ones end users have (including operating systems, other necessary equipment, and software).
  • Peripherals like the ones currently in use (printers, etc.). This will allow you to gain familiarity with the hardware to be used in the deployment and do performance tests.

If necessary, costs can be kept down by purchasing less-expensive equipment, as long as the major components are present. If you are lacking the resources for certain components, you’ll still be able to perform specific implementation scenarios on the less-capable equipment. In that case, the servers and client computers must be able to run the same software.

Building the test network
Keep the lab separate from the production network. This will ensure that the testing activities do not affect the production LAN. You should mirror the network that is used in production as closely as possible:

  • If you use both Ethernet and Token Ring there, then the lab should include both.
  • Use the same models of hubs, routers, switches, and bridges.
  • Use the same types of cables, if possible.

After everything is in place, test all the connections before actually installing the servers. If it all checks out, then go ahead and install and configure the servers.

Performing the testing
Now you’re ready to start the actual testing. Make sure you have plenty of backups. This will be very important when you test the impact of version upgrades, service packs, patches, and third-party software or add-ons.

Early in the testing stages, it may not be possible to test absolutely everything, but you can start with the most vital elements:

  • Test the busiest server on the network.
  • Test the slowest client computer.
  • Test the least-reliable network link.
  • Check who has control over specific administrative rights and thoroughly plan and test the rights as you would with other security features.
  • Test all the known components until you have ensured that it can run with good stability.

If it was necessary to make any changes to the design, as specifically directed by the architects of the project and/or the developers, then continue testing until you have reached stability. Once the systems are stable, verify that the components and applications function properly. This step may require several iterations.

Completing the testing project documentation
Now that you have verified that the system works properly, it’s time to work on the most important documentation in this project, which covers the following critical areas:

  • What were the exact objectives and results of the project?
  • What were the techniques and the tools that were used to perform the tests and evaluate the results?
  • What were the resources required for the entire project?
  • What hardware and software were used and at what stages? List the types and models of all of the hardware, including networking devices. List all the software, versions, updates, and service packs that were used.
  • List the names of all the personnel who participated, the departments they came from, the things they did at various times, and when they did these things.
  • Write out a full description of the results.
  • Explain the resolution of each of the problems.

After you’ve completed all of your testing and documentation, you can use the lab for training purposes or for further research and simulation of any other problems that may have occurred after the system was implemented.

David Doyle is an IT consultant based in Louisville, KY. He’s completed technology projects in the medical and transportation logistics industries.

Win a TechRepublic coffee mug!

If you’re a consultant, tell us about a time when you failed to conduct proper testing on software prior to deployment at the client site. What steps did you take to avoid mistakes the next time? Send us your stories! Names will be kept confidential. The purpose of publishing stories of such failures is so that other IT pros can learn from past mistakes. If we publish your story, we’ll send you a TechRepublic coffee mug.