Author: Neftaly Malatjie

Many commercial applications have already been tested to determine how well they support Windows 2000 and later. Microsoft provides a directory of applications for Windows 2000 where you can look up the status of the applications you use. The directory uses the following designations: 

• Certified – Indicating that the application was tested by VeriTest and that it takes advantage of new Windows features.
• Ready – Indicating that, according to the vendor, the application was tested for compatibility with and is supported on Windows 2000. The application does not necessarily take advantage of new Windows features.
• Planned – Indicating that the intent is for the application to meet either the Certified or the Ready criteria when it is fully tested.

Define a procedure for testers to know when and where they are to log application problems and issues that you want to resolve.

To define the criteria for pass and fail, consider issues such as the following: 

• How significant is the problem? Does it affect a critical function or a peripheral one?
• How likely is someone to encounter the problem?
• Is there a way to circumvent the problem?

Your testing schedule depends on many conditions, including: 

• How many testers participate?
• Whether the testers are on this project full-time or need to be scheduled.
• The testers’ experience levels.
• The number and complexity of the applications.

As you plan for application compatibility testing, keep in mind the future state of your computing environment. Are you planning to upgrade some of your software to versions that fully use new Windows features? Are you planning to implement new standard desktop configurations or use Terminal Services? 

Issues such as these determine the resources that you require and the applications that you are going to test as a suite. 

If you plan to deploy new applications with Windows during the rollout, test these applications with the current applications.

You can facilitate testing by setting up a lab where testers can conduct their tests. In such a lab, you can have the necessary tools and equipment available at all times.

In the lab, set up the test computers for dual or triple boot so that testers can quickly access the mode they need to install and test their applications. For example, you might need Windows NT 4.0 and Windows 2000 to test the applications through the upgrade path. To make it easy for testers to restore the computers to their prior state, make disk images of the drives with the base operating systems.

When you plan the methodology, consider the following: 

• Where will the testing take place?
• Who will perform the tests?
• How will you communicate with and involve participants?
• How will you schedule the testing?
• How will you manage application problems?

If your organization has a group of application testers, we recommend that you use them. If you do not have such a group, look for ways to use a variety of resources to achieve the best results in a reasonable amount of time. 

For example, you can use a few experienced testers to develop a battery of test cases, which they can train others to run. Alternatively, you might have the experienced testers perform a core set of tests and then coordinate with business units to have their experts come to the lab to perform the functions they use in their work.

Devise a process for scheduling test days and communicating with the testers. For example, you might set up a Web site on your intranet where anyone can view test dates, status reports, contact names, and other relevant documents.

If your organization uses many applications, you may not have time to test all of them as thoroughly as you would like. Test the highest priority and the most frequently or widely used applications first. 

Test both server-based and client-based applications. Client-based applications are usually the most difficult and time-consuming to test because of the amount of applications.