Standards and Guidelines

So far in this chapter you've learned about selecting the software that you'll compatibility test with your program. Now, it's time to look at how you'll approach the actual testing. Your first stop should be researching the existing standards and guidelines that might apply to your software or the platform.

There are really two levels of these requirements: high-level and low-level. It may be a misnomer to refer to them as high and low, but in a sense, that's really what they are. High-level standards are the ones that guide your product's general operation, its look and feel, its supported features, and so on. Low-level standards are the nitty-gritty details, such as the file formats and the network communications protocols. Both are important and both need to be tested to assure compatibility.

High-Level Standards and Guidelines

Will your software run under Windows, Mac, or Linux operating systems? Is it a web application? If so, what browsers will it run on? Each of these is considered a platform and most have their own set of standards and guidelines that must be followed if an application is to claim that it's compatible with the platform.

An example of this is the Certified for Microsoft Windows logo (see Figure 9.5). To be awarded this logo, your software must undergo and pass compatibility testing by an independent testing laboratory. The goal is to assure that the software runs stably and reliably on the operating system.

Figure 9.5. The Certified for Microsoft Windows logo signifies that the software meets all the criteria defined by the guidelines.

A few examples of the logo requirements are that the software

• Supports mice with more than three buttons

• Supports installation on disk drives other than C: and D:

• Supports filenames longer than the DOS 8.3 format

• Doesn't read, write, or otherwise use the old system files win.ini, system.ini, autoexec.bat, or config.sys

These may sound like simple, matter-of-fact requirements, but they're only four items out of a 100+ page document. It's a great deal of work to assure that your software complies with all the logo requirements, but it makes for much more compatible software.

NOTE

The details of the Windows logo can be obtained at msdn.microsoft.com/certification. Details for using the Apple Mac logo are at developer.apple.com/testing.

Low-Level Standards and Guidelines

Low-level standards are, in a sense, more important than the high-level standards. You could create a program that would run on Windows that didn't have the look and feel of other Windows software. It wouldn't be granted the Certified for Microsoft Windows logo. Users might not be thrilled with the differences from other applications, but they could use the product.

If, however, your software is a graphics program that saves its files to disk as .pict files (a standard Macintosh file format for graphics) but the program doesn't follow the standard for .pict files, your users won't be able to view the files in any other program. Your software wouldn't be compatible with the standard and would likely be a short-lived product.

Similarly, communications protocols, programming language syntax, and any means that programs use to share information must adhere to published standards and guidelines.

These low-level standards are often taken for granted, but from a tester's perspective must be tested. You should treat low-level compatibility standards as an extension of the software's specification. If the software spec states, "The software will save and load its graphics files as .bmp, .jpg, and .gif formats," you need to find the standards for these formats and design tests to confirm that the software does indeed adhere to them.

NOTE

Don't necessarily trust your team's interpretation of the standards or guidelines. Look them up yourself and develop your tests directly from the source. Remember the difference between precision and accuracy? You don't want your product's compatibility code to be perfectly precise, but totally inaccurate.