The testing of localized material has its own processes that are similar to those of software testing.
The important issues here are those of bug-tracking and communication.
It is critical that a good bug-tracking mechanism is used. A simple one could be a MS Excel spreadsheet where each row provides the following information on each bug: Unique ID, Title, Details, Severity, Assigned..., Current Status, and Attachment(s). Clear procedures need to accompany the entries in each field, for example: software cannot be released with bugs of Severity level s High or Critical; no-one can touch the bug unless that bug is Assiged to that person, and so on. Fields like Severity, Assigned to and Current Status would be drop-down selections from a list.
Many large companies have their own bug tracking software, sometimes web-based. Good vendors are quite at home working with the bug-tracking software of their customers.
Whatever method you use for bug-tracking, the important thing is to ensure that all concerned parties know who is dealing with what bugs when. There are many cases in software UI bug fixing where only one party can fix a resource file at any one time. You must establish firm control over the process so that everyone knows exactly who is dealing with which resources.
Testing is usually conducted as follows:
Depending upon the nature of the material, the preferences of the testers and the style of the customer, the customer may want to engineer, or get the vendor to engineer, output for testing. For example, for context-sensitive help, the testers will not necessarily want to be reading the source files in FrameMaker or Word. They will want to see the actual .chm or .hlp files, maybe working with the software. Similarly, some rounds of software testing can be conducted in Passolo, where the dialog boxes are visible, but for one or two rounds at least, the customer is going to want to test on the built software. You must decide these things with your engineers and your vendor.
