======================================================
Software Testing, Second Edition
By: Ron Patton
======================================================
++++++++++
Part 3:
Chapter 9:
Standard and Guidelines
++++++++++
1. Standard and Guidelines
Two level requirement:
High-level: Standards are the ones that guide your product's general operation.
Low-level: Standards are the nitty-gritty details, such as the file format and the network communications protocols, both are important both need to be test compatibility.
2. High-level standard 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.
++++++++++
Part 3:
Chapter 9:
Data Sharing Compatibility
++++++++++
1. Data Sharing Compatibility
The most familiar means of transferring data from one program to another is saving and loading disk files. Here are a few examples:
Files save and files load are the data-sharing methods that everyone is aware of. The data format of the files needs to meet standards for it to be compatible on both computers.
File export and file import are the means that many program use to be compatible with older version of themselves and with other programs.
Cut, copy, and paste are the most familiar methods for sharing data among programs without transferring the data to a disk. In this case, the transfer happens in memory through an intermediate program called the Clipboard.
DDE(Dynamic Data Exchange), OLE(Object Linking and Embedding),COM(Component Object Model)
++++++++++
Part 3:
Chapter 9:
Summary
++++++++++
This chapter introduced you to the basics of compatibility testing. In entire book could be written on this subject. Each is a manageable task that you can easily handle if you approach your testing with these three things in mind:
l Equivalence partition all the possible choices of compatible software into a manageable set. Of course, your project manager should agree with your list and understand the risk involved in not testing everything.
l Research the high-level and low-level standards and guidelines that might apply to your software. Use these as extensions of your product’s specification.
l Test the different ways that data can flow between the software programs you’re testing. This data exchange is what makes one program compatible with another.
++++++++++
Part 3:
Chapter 10:
Foreign-language Testing
++++++++++
Highlights of this chapter include
Why just translating is not enough
How words and text are affected
Whey footballs and telephones are important
The configuration and compatibility issues
How large of a job testing another language is
The process of adapting software to a specific locale, taking into account its language, dialect, local conventions, and culture, is called localization or sometimes internationalization. Testing the software is called localization testing.
++++++++++
Part 3:
Chapter 10:
Translation Issues
++++++++++
Translation Issues
It’s important that you or someone on your test team be at least a little familiar with the language you’re testing.
Text Expansion
A good rule of thumb is to expect up to 100 percent increase in size for individual words-on button.
Another possibility is that this longer text can cause a major program failure or even a system crash.
ASCII, DBCS, and Unicode
Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language.(www.unicode.org)
Hot Keys and Shortcuts
In localized version of your software, you’ll need to test that all the hotkeys and shortcuts