Software QA FYI - SQAFYI

New Approaches to Creating and Testing

By: Harry J Robinson Sankar Chakrabarti

Creating high-quality software that runs in any language is a big challenge. By changing our development process to stress early defect detection and by using the World Wide Web as a collaboration tool, we have dramatically improved the quality of our internationalized software.

Most software companies want to sell their software in every country in the world. Since users prefer to use software in their native language, it makes good marketing sense to develop software that can run in those languages. After the initial investment has been made to write and test software in English, a software company can make significant profits by reselling the same software to other countries if the cost of conversion into other languages can be kept low.

Traditionally, software testing occurs at the end of the development cycle. This kind of testing works against creating high-quality software. When bugs are found late in the cycle, there is little time to fix them. This is especially true in internationalized software development where the developers, testers, and translators are spread all over the world. Our new approach allows a team

to test the software during the entire process and to release foreign language versions simultaneously with the English version. Developing Internationalized Software The I18N Approach One common method of creating internationalized software at a reasonable cost is called I18N.* The essence of the I18N approach is to separate the executable code from any character strings that the user will see. User messages are placed into files called message catalogs. Two numbers, the set number and the message number, index each string in the message catalog. The executable code uses these numbers to retrieve strings.

For example, every C language programmer knows the classic hello, world program:
hello.c:
main()
{
printf(”hello, world\n”);
}
In the I18N methodology,1 this program would be written as follows:
hello.c:
main()
{
my_cat=catopen(”hello.cat”, NL_LOCALE);
printf(catgets(my_cat, 1, 5,
”hello, world\n”) );
catclose(my_cat);
}
The program accesses the string “hello, world\n” by retrieving set 1, message 5 of the “hello.cat” message catalog file.
hello.cat:
$set 1
5 hello, world\n
The string “hello, world\n” that appears in the printf statement is a default string that is used if no message catalog file can be found.

Separating executable code from user-visible strings is very useful when working with translations. If we want to run our hello, world program in French, a translator merely changes the string in the message catalog to:

$set 1
5 bonjour, le monde\n
* I18N = I[nternationalizatio]N. 18 is the number of letters between the I and N.

Users running the hello.c program with the translated message catalog will see bonjour, le monde as their output. No changes are made to the executable code to support the French version. Only the user interface strings need to be translated. The executable code remains unchanged. Figure 1 shows an example of what a typical application Help menu looks like in both English and French. The same executable code was used to generate each menu, and only the message catalog was changed.

Process Flow The idea behind creating internationalized software is conceptually simple, especially when the number of languages is small and the application is as simple as hello.c. On the other hand, producing real-world applications in a dozen languages can pose several challenges to a development team.

The shaded area in the diagram in Figure 2 shows the traditional process flow for developing an internationalized application.

1. The programmers write an application with the appropriate I18N calls for fetching strings from the message catalog. They also produce the original message catalog in English.

2. The message catalog is sent to translators (called localizers) who translate each string into a target language, such as French.

3. The application (with the original message catalog) is delivered to the test team, who verify that everything works correctly.

Conclusion
Internationalized software has great advantages for the marketplace and is a worthwhile and growing trend, but high quality levels can only be achieved if internationalization is integrated with the rest of the software development process. Current development models do not encourage easy integration of coding, localizing, and testing. We have designed tools to promote early detection of defects and collaboration among the different groups involved in software creation.

Full article...


Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/

New Approaches to Creating and Testing