Selecting the target platforms or the compatible applications is really a program management or a marketing task. Someone who's very familiar with the customer base will decide whether your software is to be designed for a specific operating system, web browser, or some other platform. They'll also identify the version or versions that the software needs to be compatible with. For example, you've probably seen notices such as these on software packages or startup screens:
This information is part of the specification and tells the development and test teams what they're aiming for. Each platform has its own development criteria and it's important, from a project management standpoint, to make this platform list as small as possible but still fill the customer's needs. Backward and Forward CompatibilityTwo terms you'll hear regarding compatibility testing are backward compatible and forward compatible. If something is backward compatible, it will work with previous versions of the software. If something is forward compatible, it will work with future versions of the software. The simplest demonstration of backward and forward compatibility is with a .txt or text file. As shown in Figure 9.2, a text file created using Notepad 98 running under Windows 98 is backward compatible all the way back to MS-DOS 1.0. It's also forward compatible to Windows XP service pack 2 and likely will be beyond that. Figure 9.2. Backward and forward compatibility define what versions will work with your software or data files.NOTE It's not a requirement that all software or files be backward or forward compatible. That's a product feature decision your software designers need to make. You should, though, provide input on how much testing will be required to check forward and backward compatibility for the software. The Impact of Testing Multiple VersionsTesting that multiple versions of platforms and software applications work properly with each other can be a huge task. Consider the situation of having to compatibility test a new version of a popular operating system. The programmers have made numerous bug fixes and performance improvements and have added many new features to the code. There could be tens or hundreds of thousands of existing programs for the current versions of the OS. The project's goal is to be 100 percent compatible with them. See Figure 9.3. Figure 9.3. If you compatibility test a new platform, you must check that existing software applications work correctly with it.This is a big job, but it's just another example of how equivalence partitioning can be applied to reduce the amount of work. NOTE To begin the task of compatibility testing, you need to equivalence partition all the possible software combinations into the smallest, effective set that verifies that your software interacts properly with other software. In short, you can't test all the thousands of software programs on your operating system, so you need to decide which ones are the most important to test. The key word is important. The criteria that might go into deciding what programs to choose could be
Just as in hardware configuration testing, there is no right "textbook" answer. You and your team will need to decide what matters most and then use that criteria to create equivalence partitions of the software you need to test with. The previous example dealt with compatibility testing a new operating system platform. The same issues apply to testing a new application (see Figure 9.4). You need to decide what platform versions you should test your software on and what other software applications you should test your software with. Figure 9.4. Compatibility testing a new application may require you to test it on multiple platforms and with multiple applications. |