Article ID: 244632 - View products that this article applies to.
This article was previously published under Q244632
One of the primary tasks in preparing for testing is to write a test plan. In the test plan, you specify the scope and objectives for the testing and describe the methodology you are going to use.
When you develop a test plan for testing application compatibility with Windows, include the following:
Establishing the Testing ScopeIf 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.
Defining the Testing MethodologyWhen you plan the methodology, consider the following:
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.
Identifying Resource RequirementsAs 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.
Defining Pass-Fail CriteriaDefine 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:
Testing ApplicationsMany 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:
Testing StrategiesThe goal of your application testing is to verify that everything that works on your current platform also works on your current version of Windows. If an application was written for an earlier version of Windows, it does not necessarily use new Windows features, but its functionality should work in Windows 2000 as it does on your current platform.
Commercial ApplicationsFor commercial applications, the first step is to run Setup in check-upgrade-only mode to check for potential incompatibilities. When you run Setup in this mode, Windows checks the installed software against a list of applications known to be incompatible and logs any that it finds. The command line format for check-upgrade-only mode is:
winnt32 /checkupgradeonlyAlthough this tool can alert you to potential compatibility problems, it addresses only a small percentage of your applications and only the applications installed on the computer you are checking.
The next step is to check the directory of Windows applications to determine the compatibility of the applications you use.
Even if you find that some of your applications have already been tested by others, you should test them in your environment. In this case, focus your testing on the way your organization uses the applications. For example, test the following:
Custom ApplicationsIf you use custom third-party products or develop applications internally, you need to develop a more extensive testing strategy than for pre-tested commercial applications.
Even if you are testing an application which you did not develop, the Windows 2000 Application Specification can provide insight into testing. The MSDN Web site at http://msdn.microsoft.com
(http://msdn.microsoft.com)includes a downloadable version of the specification. The MSDN Web site also contains other important information about testing, such as white papers about exploratory testing and the method that independent testing organizations use to test the functionality of applications vendors submit for certification.
NOTE: The testing suggestions in this section are not comprehensive and do not apply to all situations. They are provided to help you start thinking about how to test.
Test Deployment ScenariosTest installing and running your applications using the scenarios you plan to use during deployment. For example, you might plan to deploy by installing on clean computers or by upgrading from Windows 95 or Windows 98 or an earlier version of Windows NT. If you plan to upgrade, you might keep the applications on the computer during the upgrade, or you might uninstall them and reinstall them after the upgrade.
Because of differences between Windows 95 or Windows 98 and Windows 2000, some application installations work differently depending on which operating system you use for the installation. For example, if you install an application on a computer running Windows 95 or Windows 98, and then you upgrade the computer to Windows 2000, the application might not work the same way as it would have if you had installed it in Windows 2000. In this case, you might need to uninstall the application and reinstall it after you upgrade or obtain a migration dynamic link library (DLL).
A migration DLL allows an application that was originally installed on Windows 95 or Windows 98 to function correctly after the computer is upgraded to Windows 2000. Migration DLLs can resolve application problems by performing the following actions:
Upgrade ScenarioIf you are planning to upgrade your computers:
Clean Installation ScenarioIf you are planning to install on reformatted computers:
Test Installing and UninstallingTest application installation in a variety of ways, such as the following:
Access DataTry to access data in a variety of ways, such as the following:
Test PrintingPrint a variety of document types with a variety of printers, such as the following:
Common Compatibility IssuesApplications developed for previous versions of Windows might not take full advantage of new features, such as Active Directory or IntelliMirror. This section does not address these new features.
Resolving Application IncompatibilitiesWhen you encounter application compatibility problems, you need to prioritize them and then assign someone to resolve them. You should have a plan for how to assign problems.
Assigning the appropriate personnel to research and resolve problems is critical to the success of your application testing. Problem resolution might encompass a wide variety of activities, such as the following:
Article ID: 244632 - Last Review: March 1, 2007 - Revision: 4.2
Contact us for more help