Data Compatibility

FIGURE 10.7 The Arabic, French, and Russian keyboards support characters specific to those languages. (www.fingertipsoft.com)

FIGURE 10.8 Data compatibility testing of localized software can get fairly complex.

During this round and round of data transfers, with all the conversions and

handling of measurement units and extended characters, there are numerous places for bugs. Some of these bugs might be due to design decisions. For example, what should happen to data moved from one application to another if it needs to change formats? Should it be automatically converted, or should the user be prompted for a decision? Should it show an error or should the data just move and the units change?

These important questions need to be answered before you can start testing the compatibility of your localized software. As soon as you have those specifications, your compatibility testing should proceed as it normally would—just with more test cases in your equivalence partitions.

How Much Should You Test?

The big uncertainty that looms over localization testing is in determining how much of the software you should test. If you spent six months testing the American English version, should you spend six months testing a version localized into French? Should you spend even more because of additional configuration and compatibility issues?

This complex issue comes down to two questions:

• Was the project intended to be localized from the very beginning?

• Was programming code changed to make the localized version?

German Application

#1

French Application

#2

English Application

#3 Import

Import Export

Export

Load Save

Cut, Copy, Paste

Metric Units, Extended Characters

English Units, Non-Extended Characters

If the software was designed from the very beginning to account for all the things discussed in this chapter, the risk is much smaller that a localized version will be very buggy and require lots of testing. If, on the other hand, the software was written specifically for the U.S. English market and then it was decided to localize it into another language, it would probably be wise to treat the software as a

completely new release requiring full testing.

NOTE

The amount of localization testing required is a risk-based decision, just as all testing is. As you gain experience in testing, you’ll learn what variables go into the decision-making process.

The other question deals with what needs to change in the overall software product.

If the localization effort involves changing only content such as graphics and text—

not code—the test effort can sometimes be just a validation of the changes. If, however, because of poor design or other problems, the underlying code must change, the testing needs take that into account and check functionality as well as content.

IS IT LOCALIZABLE?

One method used by teams who know they are going to localize their product is to test for localizability. That is, they test the first version of the product, assuming that it will eventually be localized. The white-box testers examine the code for text strings, proper handling of units of measure, extended characters, and other code-level issues. They may even create their own

“fake” localized version. The black-box testers carefully review the spec and the product itself for localizing problems such as text in graphics and configuration issues. They can use the

“fake” version to test for compatibility.

Eventually, when the product is localized, many of the problems that would have shown up later have already been found and fixed, making the localization effort much less painful and costly.

Summary

Ha Ön egy rátermett és képzett softver ismer?, és folyékonyan beszél egy nyelvet az Angolon kívül, Ön egy nagyon piacképes szakképzett személy.

That’s the same first sentence of this chapter—only written in Hungarian this time.

Don’t worry if you can’t read it. You’ve learned in this chapter that knowing the language is only part of the overall testing required for a localized product. Much work can be done by checking the product for localizability and for testing language- independent areas.

If you are fluent in a language other than English, keep reading this book, and learn all you can about software testing. With the global economy and the worldwide adoption of technology and computers you will, as the Hungarian phrase roughly says, “have a very marketable skill set.”

For more information on localization programming and testing for Windows, visit www.microsoft.com/globaldev. For the Mac, consult the Apple website,

developer.apple.com/intl/localization/tools.html. Linux programmers and testers can find localization information at www.linux.com/howtos/HOWTO-INDEX/other- lang.shtml.

Quiz

These quiz questions are provided for your further understanding. See Appendix A,

“Answers to Quiz Questions,” for the answers—but don’t peek!

1. What’s the difference between translation and localization?

2. Do you need to know the language to be able to test a localized product?

3. What is text expansion and what common bugs can occur because of it?

4. Identify several areas where extended characters can cause problems.

5. Why is it important to keep text strings out of the code?

6. Name a few types of data formats that could vary from one localized program to another.

•User Interface Testing

•What Makes a Good UI?

•Testing for the Disabled:

Accessibility Testing

Usability Testing

S

oftware is written to be used. That sounds pretty

obvious, but it’s sometimes forgotten in the rush to design, develop, and test a complex product. So much time and effort is spent on the technology aspects of writing the code that the development team ignores the most impor- tant aspect of software—that someone will eventually use the stuff. It really doesn’t matter whether the software is embedded in a microwave oven, a telephone switching station, or an Internet stock trading website. Eventually the bits and bytes bubble up to where a live person will interact with it. Usabilityis how appropriate, functional, and effective that interaction is.

You may have heard the term ergonomics, the science of designing everyday things so that they’re easy and func- tional to use. An ergonomist’s main concern is in achiev- ing usability.

Now, you’re not going to get the knowledge of a four-year ergonomics degree in the 15 or so pages of this chapter, nor do you need to. Remember from Chapter 1, “Software Testing Background,” the fifth rule of what constitutes a bug: The software is difficult to understand, hard to use, slow, or—in the software tester’s eyes—will be viewed by the end user as just plain not right. That’s your blank check for usability testing.

You’re likely the first person, other than the programmers, to use the software. You’ve become familiar with the speci- fication and investigated who the customers will be. If you have problems using the software while you’re testing it, odds are the customers will, too.

Because there are so many different types of software, it’s impossible to go into detail about usability issues for all of them. Usability of a nuclear reactor shutdown sequence is

pretty different from usability of a voicemail menu system. What you’ll learn in this chapter are the basics of what to look for—with a bias toward software that you use on your PC every day. You can then take those ideas and apply them to whatever software you have to test.

Highlights of this chapter include

• What usability testing involves

• What to look for when testing a user interface

• What special usability features are needed by the disabled

User Interface Testing

The means that you use to interact with a software program is called its user interface or UI. All software has some sort of UI. Purists might argue that this isn’t true, that software such as what’s in your car to control the fuel/air ratio in the engine doesn’t have a user interface. In truth, it doesn’t have a conventional UI, but the extra pres- sure you need to apply to the gas pedal and the audible sputtering you hear from the tailpipe is indeed a user interface.

The computer UI we’re all familiar with has changed over time. The original comput- ers had toggle switches and light bulbs. Paper tape, punch cards, and teletypes were popular user interfaces in the ‘60s and ‘70s. Video monitors and simple line editors such as MS-DOS came next. Now we’re using personal computers with sophisticated graphical user interfaces (GUIs). Soon we’ll be speaking and listening to our PCs, carrying on verbal conversations as we do with people!

Although these UIs were very different, technically they all provided the same inter- action with the computer—the means to give it input and receive output.

What Makes a Good UI?

Many software companies spend large amounts of time and money researching the best way to design the user interfaces for their software. They use special usability labs run by ergonomic specialists. The labs are equipped with one-way mirrors and video cameras to record exactly how people use their software. Everything the users (subjects) do from what keys they press, how they use the mouse, what mistakes they make, and what confuses them is analyzed to make improvements to the UI.

You may be wondering what a software tester could possibly contribute with such a detailed and scientific process. By the time the software is specified and written, it should have the perfect UI. But, if that’s the case, why are there so many VCRs blink- ing 12:00?

First, not every software development team designs their interface so scientifically.

Many UIs are just thrown together by the programmers—who may be good at writing code, but aren’t necessarily ergonomics experts. Other reasons might be that technological limitations or time constraints caused the UI to be sacrificed. As you learned in Chapter 10, “Foreign-Language Testing,” the reason might be that the software wasn’t properly localized. In the end, the software tester needs to assume the responsibility of testing the product’s usability, and that includes its user interface.

You might not feel that you’re properly trained to test a UI, but you are. Remember, you don’t have to design it. You just have to pretend you’re the user and find prob- lems with it.

Here’s a list of seven important traits common to a good UI. It doesn’t matter if the UI is on a digital watch or is the Mac OS X interface, they all still apply.