This document outlines the general procedures on a typical localization project. It should provide the lead test engineer with the correct guidelines for developing a specific QA plan.
1. Prepare Testing Environment
Technical analysis based on client materials such as:
2. QA Team Priorities
Prepare Project Specific test plan which includes:
Determine testing approaches and methods such as unit, integration and functional necessary for carrying out project specific QA process
Project manager assigns testing team making sure all members understand all client's specifications and project requirements.
Ensure the correct preparation of hardware and software environments
Ensure all team members, including translators are fully trained in all areas of product to be localised
Ensure all team members are fully trained in use of bug tracking system and in correct methods of bug reporting
3. Initiate Testing
3.1 Minimal Acceptance Tests
3.2 Functional Testing
Functional testing of all areas of the product ensures it will perform as closely to the English version as possible. This entails a series of tests which perform a feature by feature validation of behaviour, using a wide range of standard and erroneous input data. Depending on the project specification, it can range from simple smoke testing of the product to thorough script based testing of the product's user interface, APIs, database management, security, installation, networking, etc. The QA team at Oxford Conversis can perform functional testing on an automated or manual basis using black box and white box methodologies. Typical testing criteria for a localization project would include:
3.3 User Interface Testing
User Interface Testing will be performed on the running application or web site. Our Visual QA procedures provide comprehensive testing on all possible cosmetic issues of localised product. All testing will involve valuable input from our language experts. Throughout the testing cycle exploratory testing is also performed by expert QA engineers to find defects that may not be found by formal testing methods. Typical criteria for such testing would include:
3.4 Linguistic Testing
In the linguistic testing phase our testing specialists add another level of quality assurance by thoroughly testing the final build conclusively ensuring the product is both linguistically and technically sound. I.e. the translations are accurate, grammatically correct, and culturally appropriate.
4. Bug reporting and Tracking
Using the testing methodology listed above our QA engineers, translators and language specialists log issues, or bugs, on our Online Bug Tracking System. Localization issues which can be fixed by our engineers will be fixed accordingly. Internationalization and source code issues will also be logged and reported to the Client with suggestions on how to fix them. Bug Tracking process is as follows:
New Bugs are submitted in the Bug tracking system account by the QA.
When a bug is logged our QA engineers include all relevant information to that bug such as:
The QA also analyses the error and describes, in a minimum number of steps how to reproduce the problem for the benefit of the engineer. At this stage the bug is labelled "Open". Each issue must pass through at least four states:
In order to manage the testing process efficiently it is important to include several other bug status levels such as: Not a Bug, Use as Is, Deferred, Regressed, and Cannot Reproduce
Depending on quality of translations, engineering and on the number of bugs logged the QA team decides on a number of test cycles for project. Usually this would be no more than two or three full passes before Final Bug Regression and release to Linguistic Testing.