Software compatibility checklist

Always be sure that a problem does not occur on your current platform before researching it as a Windows compatibility issue. Some of the available resources for researching Windows compatibility issues are:. Appendix E provides the specific location where can you obtain the specification.

This guide include valuable information about diagnosing compatibility problems. Directory of Windows applications, which includes support information and links to vendor Web sites. Summary One of the primary tasks in preparing for testing is to write a test plan. More Information When you develop a test plan for testing application compatibility with Windows, include the following: Scope: What priority levels you address during testing?

Methodology: Who does the testing involve? Criteria for pass-fail: What determines if an application passes or fails? Schedule: How do you plan to complete the testing by the scheduled date? Establishing the Testing Scope If your organization uses many applications, you may not have time to test all of them as thoroughly as you would like. Defining the Testing Methodology 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? Identifying Resource Requirements As you plan for application compatibility testing, keep in mind the future state of your computing environment.

Defining Pass-Fail Criteria 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. Testing Applications Many commercial applications have already been tested to determine how well they support Windows and later. The directory uses the following designations: Certified - Indicating that the application was tested by VeriTest and that it takes advantage of new Windows features.

Testing Strategies The goal of your application testing is to verify that everything that works on your current platform also works on your current version of Windows. Commercial Applications For commercial applications, the first step is to run Setup in check-upgrade-only mode to check for potential incompatibilities.

For example, test the following: Configurations your organization uses. Features most frequently used. Combinations of applications you use together.

Custom Applications If 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. Test Deployment Scenarios Test installing and running your applications using the scenarios you plan to use during deployment.

Migration DLLs can resolve application problems by performing the following actions: Replacing or upgrading Windows specific or Windows specific files with Windows compatible files. Install the application you want to test. Upgrade the computer to Windows Test the application. Clean Installation Scenario If you are planning to install on reformatted computers: Install Windows Install the application.

Test Installing and Uninstalling Test application installation in a variety of ways, such as the following: Terminate the installation before it is complete. Try all the installation options used in your environment. Try to uninstall the applications. Access Data Try to access data in a variety of ways, such as the following: Access data on a server running the current version of Windows, as well as on a server running Windows Test concurrent use of a database, including simultaneous access and update of a record.

Perform complex queries. Test Printing Print a variety of document types with a variety of printers, such as the following: Print documents with embedded files from several source applications. Print to printers with long file names. Common Compatibility Issues Applications developed for previous versions of Windows might not take full advantage of new features, such as Active Directory or IntelliMirror.

Resolving Application Incompatibilities When you encounter application compatibility problems, you need to prioritize them and then assign someone to resolve them. Problem resolution might encompass a wide variety of activities, such as the following: Researching Web sites for known problems and solutions.

Contacting vendors for patches, Setup programs, or migration DLLs. Contacting Microsoft support. Debugging internally-developed applications. For example, you might choose to: Fix the problem if you developed the application. The person may use high speed connectivity like 4G or a slower connection like dialup. When preparing for network compatibility testing, it is vital to work with the client to identify in what ways the end users will access the system and how the system should function accordingly.

The following is a list comprising of several general checkpoints to be considered when doing operating system compatibility testing. Operating System Compatibility Testing Checklist. The system or application icon needs to be clearly displayed and available for the user. The application may be accessed via different methods depending on the OS. This could be via shortcut, from taskbar, program list or through the long file path directly. When system uses different file types in the system, these files need to be supported by the local applications as well.

The application or system may support additional hardware. Some OS allow plug and play while others require explicit mounting of peripheral devices before use. Therefore, this dependency needs to be tested for compatibility. It is not enough to test the compatibility of the viable operating systems. For compatibility, it is important to test whether the system blocks the installation to unsupported operating systems while displaying an informative notification to the user stating that the application only supports a particular list of operating systems.

Each operating system deciphers certain keyboard signals differently. Therefore, if the system allows keyboard shortcuts within its operations, this needs to be tested across the approved list of OS to verify each keyboard shortcut is decoded the same way. Operating systems are built on different architectural platforms.

While the system works fast in a certain OS, it may not mean that it works just as fast in every other OS. Therefore, the system performance needs to be tested on all operating systems. This notification depends on the operating system. The trigger point, consent, UI and ultimately the functionality needs to be verified for all selected operating systems. Lot of client applications use the system date in its operations. Therefore, this needs to be checked for compatibility.

Installation on rooted devices is an important consideration. It is highly recommended that applications such as banking, insurance and stock markets should not be allowed to be installed on rooted devices. If the client decides that the application should not be allowed on rooted devices, a helpful notification to be displayed to the user at the attempt to install the application blocking the activity.

The application should also be unusable, when the device is jail-broken while the application is installed. The following checklists comprises of the items to be tested when conducting a browser compatibility test.

Browser Compatibility Testing Checklist. It tells the browser what rules will be used by the system. Since conditional CSS scripting can be done, rendering on each browser may differ accordingly. Another commonly used scripting language in web development is JavaScript.

For this, the following tool can be used:. When JavaScript is heavily used in web sites, it is important to test how the system behaves without JavaScript enabled. When JavaScript is disabled for the browser, the system needs to be just as operational for the user. The font size specified may differ when represented in different browsers. This is most applicable for mobile devices. When websites are accessed via smaller screens. Therefore, it should be developed in a manner that it would still be responsive and usable for the user despite the screen size.

Just as the font size validation, the page layout also needs to be tested in different resolutions and browsers. Images and alignments are two more common UI features that needs to be validated in every selected browser version. Page headers and footers need to be consistent across the selected browser versions, therefore it needs to be verified accordingly.

When viewing the same content on different browsers, the standard browser features may differ if not specified explicitly. For example, numbers and decimals are generally right aligned and the main page content should be in the center, not left aligned. The font styles, bullets and other styles used in the system should render the same way across selected browser versions. When the data format of the system conflicts with the default date format defined in the platform, the behavior needs to be verified.

This is especially important when it comes to mobile browsers. HTML Entities can be placed in source code like any other alphanumeric characters to produce special characters and symbols that cannot be generated in HTML with normal keyboard commands.

These special characters may render differently in each browser and platform. Therefore, these special characters need to be removed from the HTML.

The system needs to be checked in each browser for general zoom in and zoom out functionalities inside the browser. If advertisements are allowed in the system, they should be tested for its usability in different browsers including mobile browsers. Device Compatibility Testing Checklist. Each device has its special way of navigating to a particular application.

This needs to be tested for each of the devices. The default buttons available on the device should work without any obstruction from the application. If any of the default button functionalities were overridden, these functionalities need to be specially tested. The application font should be readable for the user despite the screen size. This includes the content, buttons and labels, and also ads if relevant.

The view on a desktop and the view on a mobile device should be proportionately different and user friendly for the end user.

This checkpoint is related to bullet points, templates and any special styles used in the UI of the application. The specified UI aspects should be similar in all devices which have been selected for the test. Therefore, to make the product in development completely meet all the above-mentioned requirements, a quality assurance team should perform testing on the basis of a complete checklist that looks in a next way.

After testing the mapping of all elements of a website, you can move to testing the correctness of the message send and receive forms functioning. If a future product is targeted at several geographical regions, you should devote time to globalization and localization testing. Technical and logical compatibility is tested to understand that the website that is being tested is compatible with the systems, in which it will be directly used either in terms of hardware or operating systems and extensions.

While testing a web product, you should ensure that all settings and functions of a website, its design is independent of the current technical state of the system environment. In other words, a tester should always remember about such groups of tests:.

As we can see, website testing is a huge work of searching for technical defects and bugs that should be fixed before the product will have been released. The process of testing should be always supported by a special document checklist that should contain all possible tests from complete testing of the layout to functional testing of mail servers and database.