Testing for Compatibility

   

Once the software inventory has been created and verified , you can formulate a test plan. A valid software test plan for the deployment of a new operating system must include basic details, such as whether an application will run on the new operating system, as well as more complex testing that includes combinations of the applications found in the organization.

This section describes the strategies for testing applications during a Windows deployment. It also provides information regarding the tools in the Application Compatibility Toolkit and how they can help during this phase of your deployment.

The applications to be tested for a Windows deployment should include every program being used within your organization, both desktop and server. Organizations that have standardized on a set of approved applications might find this task somewhat easier than those who have no standardization at all. Once you have gathered the information in your software inventory and analyzed the business priority of each application, the test plan should be formulated.

In a perfect world, you would test every application present in the organization for compatibility with the new Windows operating systems being deployed. Very few IT departments have this luxury both in time and in budget. By assigning a priority to each application in the organization, you can make intelligent choices about where to spend your testing time. Priorities for applications should be assigned according to their relevance to daily business functions. A desktop application that is used occasionally would have a much lower priority than a client-server application that manages the main product of your organization. A suggested priority scale is as follows :

  1. Business-critical.

    Applications in this category are absolutely required for business to be performed. Business-critical programs cannot endure downtime without a significant loss in revenue.

  2. Business-function.

    This category includes applications that are used by a majority of users within the organization for their daily work. An example of a business-function application would be Microsoft Word 2002 if most people in the organization use it for daily business. Some downtime or problems can be tolerated, but the core functionality of the application must be ensured.

  3. Specialty.

    An application in this category would be important to a very small segment of the user population within an organization and not tied directly to the continued success of the organization. An example would be an art program used to process photographs for marketing materials, important to a small segment of users but not impossible to live without if there were a serious compatibility issue.

  4. Other.

    Applications in this last category include nonstandard programs that users have installed on their own. Typically, these programs have little or no bearing on the daily business of the organization, and application compatibility issues here will have no impact on the business.

Microsoft provides the "Designed for Windows XP" Application Test Framework document to describe a suggested set of test cases and procedures, including test lab setup, for evaluating whether an application meets the requirements for the Designed for Windows XP logo. While you might not be concerned about logo requirements of an application during a Windows deployment, this document does provide excellent insight into testing procedures that have been designed to test for Windows application compatibility.

The Test Framework assumes that the tester has the skills to create an effective test plan, run the tests, and evaluate the results. These skills include the following:

  • Software testing experience and familiarity with creating test plans

  • Experience testing Windows-based desktop applications

  • Experience installing and configuring computer hardware

  • Familiarity with Windows operating systems

  • Ability to install and configure Windows XP and Windows Server 2003 options

  • Experience monitoring test applications using kernel-mode debuggers

The depth of testing described in the Test Framework is beyond most IT professionals; still, the benefit of this document is in the description of testing environment and techniques.

Gathering Information About Applications

As mentioned earlier in this chapter, the Analyzer can be used to collect a list of the applications in use within your organization. However, it can't tell you the business purpose of each program. To obtain this information, you must conduct interviews with users that represent a wide variety of environments within your organization. As a general rule of thumb, try to involve the following groups when collecting information about the applications in use in your organization:

  • Management.

    Top-level management might have specific input regarding the applications in use. Also, collect data from the management of individual departments in the organization.

  • Information technology.

    The IT department in the organization is in a unique position to understand which applications are actually used on a day-to-day basis within the organization.

  • Users.

    This group is often overlooked or underutilized during the interview phase. Try to gather information from representative groups of users from various parts of the organization to assemble a cross-section view of what is actually useful to them on a daily basis.

It's entirely possible that applications on the list of installed software are not even in current use. These, then, can be safely listed as low priority for compatibility with the new operating system. This is actually the reason for gathering application usage data. It enables you to set priorities for testing and helps to reduce or eliminate concerns about applications that have compatibility issues with the new operating system, if in fact they are not used very much. A suggested priority scale would be the following:

  1. Business-critical.

    Applications that are vital to daily business and cannot tolerate any downtime without adversely affecting the organization. An example would be the electronic commerce application for an online merchant. Without the ability to process new orders, the business is down.

  2. Daily-use.

    This category describes the applications that are used on a daily basis by a majority of users in the organization but can tolerate some downtime. A failure of an application in this category would be irritating , but business would still be conducted with only minimal interruption.

  3. Minimal-use.

    The final category describes applications that are in use but not essential to business. You might find it necessary to divide this category into subcategories to deal with applications that are infrequently used but still quite important to the organization, and those applications that are simply nice to have on your computer.

By carefully reviewing the usage patterns of the users within your organization, you can adjust the time allocation for application testing to focus primarily on those programs that are most important to the organization. You can also reduce or eliminate the time spent testing applications that are not important to the organization.

Using Compatibility Administrator

Compatibility Administrator can be a useful tool during the latter portions of your testing schedule. This tool will not help you to automate your software testing, nor will it find compatibility issues in your programs. What Compatibility Administrator can do is help to identify possible solutions to the compatibility issues raised by your software testing.

As the testing process identifies areas of concern with the current or planned applications in your organization, Compatibility Administrator can be used to identify possible solutions for those issues. Consider the following example:

  • Application.

    MyApp16, a 16-bit Windows-based application used for entering customer service call data and for tracking incidents.

  • Business impact.

    Daily-use application, used by the customer service department and used to handle all of its incoming customer call data. Can tolerate some downtime but is important to the daily workflow.

  • Compatibility Issue.

    MyApp16 was designed to run on Windows 3.1. It performed adequately when the organization upgraded to Windows 95 but does not run at all on Windows XP Professional or Windows Server 2003.

With an example application like MyApp16, you might be tempted to recommend upgrading to a newer , 32-bit, application that would accomplish the same tasks . Imagine that the budget constraints for the planned deployment of Windows XP Professional to all of the desktops in the organization preclude the simultaneous upgrade of the customer service application. The task then becomes finding a solution that will enable the application to function on Windows XP. Compatibility Administrator can be used to test possible solutions for the problems this application encounters on Windows XP.


   
Top


Introducing Microsoft Windows Server 2003
Introducing Microsoft Windows Server(TM) 2003
ISBN: 0735615705
EAN: 2147483647
Year: 2005
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net