Localization testing has gained a lot of momentum and market share in the recent years, thanks to ISVs who have been focusing on global launch of their products. Amongst the competitive forces that significantly determine the product launch, “time to market” is a very important criterion. Very often ISVs are time crunched in their testing phase for even the English version of the product, leave alone the localized versions. In such situations, how can the ISV or a testing service provider add value to the localization testing phase, not compromising on quality? Here is where one needs to focus on what best practices to adopt in the localization testing phase, which will help ship the product on time, yet provide the required coverage. While testing best practices in general would apply to localization testing as well, here are a few core best practices especially applicable to localization testing:
Build Reusability – Reusability bears a lot of importance especially in localization testing because there is a lot in common between pseudo localization testing and localization functional testing. Test cases written for pseudo localization testing can be largely reused in localization functional testing, with changes made to the test data. Test data in pseudo localization phase would either be gibberish or typically a representative language such as German, whereas in the localization testing phase, you would be testing with data for every single locale. However reusing previously written test cases is going to save you a lot of time and effort at the same time give you good test coverage. Obviously there are quite a few differences between pseudo loc and loc testing phases ( for more details on this refer to my previous blog titled “Why take on localization functional testing when you’ve already done pseudo localization testing?” ).
I have so far covered just one aspect of reusability, which is reusing tests written in the pseudo localization phase during localization functional testing, in the same project. The other aspect to consider is reusability across projects. We should look at building generic test cases for pseudo localization and localization functional testing by classifying products – such as localization testing for ecommerce applications, for social networking applications etc. This will expedite boot strapping localization testing for such projects as we’ve built reusability in test case design upfront. These are value add tasks you can have your testers take on after project completion, during down times etc.
Exercise due diligence in filing localization bugs – A Localization bug differs from the core product bugs in the English language in that, it may be specific to the language under test, it may be specific to a group of languages – e.g. a bug reproducible in all DBCS character set languages. Tester should apply due diligence in isolating the bug based on scenarios under which it is reproducible, by which he/she helps the developer comprehend the issue quickly. This is also similar to bugs specific to OS Browser testing. Based on the nature of the bug, the tester should decide whether to report all issues seen in the same bug or file separate bugs for each issue. Other factors to take into consideration when combining issues in the same bug are ease of fix and ease of regression without any chances of missing any one issue. Also, providing details such as platform on which the issue was observed, any screenshots, video files showing the bug’s reproduction steps are going to be very helpful in resolving the bug quickly. This is all the more important in localization bugs, since the developer who is fixing the issue may not know the target language in which the bug is reported.
Build a comprehensive yet optimized matrix to test – Similar to building the right coverage matrix to test in OS Browser testing, building a matrix in localization testing is very important since the variables to test are large. In fact, building a matrix here is more complicated than in OSB testing since localization testing touches upon both OSBs and locales under test. To make this a more manageable task, see if you can talk to the product management team that typically plans for product launches. Understand launch priorities of various markets including market share, targeted number of end users in each market, launch timelines etc. which you can take into account in building your test matrix. Also take into account the OSB usage specific to the target locale. For e.g. a given browser that has a large global market share, may not have a significant share in the target locale. Such inputs will help you prioritize the OSBs to test on for various locales. Web sites such as: http://marketshare.hitslink.com/, will help keep track of OS Browser usage statistics. Using virtualization to set up multiple test configurations is also a best practice to adopt here.
Automate the right set of test cases – As talked earlier, there is a lot of reusability possible between the pseudo localization and the localization testing phases. It is a good practice to set aside some time for automation in the pseudo localization testing phase, as they can then be re-used in the localization testing phase. Test data alone would need to be prepared, locale wise, that the automation suites would feed into. This would also provide the tester a lot of time to focus on exploratory testing in the localization testing phase. Do not spend a lot of time automating UI tests, as that is best done manually especially in localization testing. Picking functional test cases to automate would provide maximum reusability not just during the localization testing phase, but also during the product maintenance phase.
Use of productivity tools – Since the tester will need to emulate test data in various locales, preparation of test data is especially more time consuming in localization testing. To make this test process simpler, more accurate and faster, a number of open source & freeware productivity tools are available. It is a good practice for the tester to use such tools to help expedite the test process. Also, it would be helpful to download such tools or provide a set of such links in a wiki share or any other internal knowledge base system, so it becomes readily available for subsequent use. Some examples of such tools are: keyboard simulators (Microsoft keyboard layout creator, Java virtual keyboard), string file compare tools to compare content in English vs. the target locale.
Adopting the above defined best practices will not only help you meet the defined and sometimes time crunched deadlines but also create a robust localization testing methodology to practice and improvise across projects. This is in no way intended to be a comprehensive list of best practices, but rather a good set to start adopting right away. Happy Localization Testing!