Platform and Application Versions


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:

Works best with AOL 9.0

Requires Windows XP or greater

For use with Linux 2.6.10

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 Compatibility

Two 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 Versions

Testing 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

  • Popularity. Use sales data to select the top 100 or 1,000 most popular programs.

  • Age. You might want to select programs and versions that are less than three years old.

  • Type. Break the software world into types such as painting, writing, accounting, databases, communications, and so on. Select software from each category for testing.

  • Manufacturer. Another criteria would be to pick software based on the company that created it.

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.




    Software Testing
    Lessons Learned in Software Testing
    ISBN: 0471081124
    EAN: 2147483647
    Year: 2005
    Pages: 233

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