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!

Localization Testing

Pseudo loc testing is a proactive step taken on before product localization primarily to:

1.        Detect under or over localization issues

2.       Find UI issues related to truncated strings, improper display of characters

3.       Perform one round of functionality testing to ensure product works as expected in a non English build

The important point to note above is the 3^rd one. Why take on functionality testing post localization for every single locale if it has already been done in the pseudo localization phase? One must remember that though one goal of testing in the pseudo loc phase is to find as many issues as possible upfront, another important goal is to validate that the base English product has been designed well to support localization. This assures that the product can now be taken across multiple locales and not that the product will work fine on every locale. Think of this as prototype testing for a series of buildings to be constructed. The prototype testing is going to help you catch possible issues upfront and bring down the cost of fixing them later on. One could avoid prototype testing and actually decide to audit each individual building. If there are fundamental issues detected at that stage, it only amplifies the magnitude of the issue and fix so much more, impacting your core 3 project variables viz. cost, time, quality.

Ok, you may ask, yes, I get “why pseudo loc testing“, but now “why loc functional testing as well“?

Pseudo loc testing has only helped us identify and fix issues that existed in the product base that would have affected all locales. It has not helped us identify locale specific issues. For e.g.

1.       How does the product function when the target language is Double byte character set (DBCS) or Multi byte character set (MBCS) or bi-di?

2.       Are data inputs received and stored correctly, in the database, for the locale under consideration?

3.       Is data correctly retrieved on to the front end and being used for correct functional flow E2E?

4.       Are locale specific product customizations working fine?

Since every locale has its own character encoding complexities, doing one round of pseudo loc testing is not a replacement for loc functional testing. The place where I agree with my customer is that, one should closely look at an optimal coverage when it comes to loc functional testing.  Running all tests again is not going to give you additional bugs. It is only going to delay the loc sign off…Pick the right test cases centered around data inputs, data storage, any locale specific customizations, one E2E flow etc. to complete your pass. Discuss your test coverage with the larger product team (including program managers, developers) to ensure ROI from the loc functional testing effort. This will help them see the importance of this task and slowly start understanding the coverage and plan for these sanity checks even during the development phase. By doing this, you have right away educated the entire product team on localization engineering best practices and helped push quality up stream.

While pseudo loc and loc functional testing is normally done by the mainstream engineering team, it definitely helps to have linguistic experts for linguistic/translation testing. Translation tools will help you validate the translated text only at a high level. The contextual meaning and geopolitical issues if any, can be validated only by linguistic experts. In order to create a product with high end user acceptance and avoid any potential legal issues down the line, an upfront investment in linguistic testing by in country experts, is totally worth every $ you spend on it.

Hopefully, this has thrown light on the importance of all 3 test efforts (pseudo loc, loc functional and linguistic testing) with the right amount of optimization to ensure a smooth and successful global release of a product.

To ensure that your decision to outsource was the best that you ever took, you need to collaborate with a partner who knows what it takes to outsource, a partner who understands the softer as well as the mission-critical aspects that will ensure the success of your enterprise.

Time and again we have iterated the importance of Independent and Unbiased Testing along with outlining the benefits that organizations can achieve by internalizing such a model in their processes. However, one question that we get asked all the time is what are our differentiators as your outsourcing vendor. To answer that we have put together a nice little table that clearly articulates what positions us as one of the leaders in this market.

As intricate the process of localizing a product may sound, it only constitutes half of the story. The other half lies in testing this localized version of the product on every single locale/culture that it supports. This testing of a localized and internationalized product is termed as Localization Testing. This effort not only involves testing of proper translation but also relevant functional verifications. This would involve verifications ranging from simpler ones like checking for text truncation to much complex functionality like support for Unicode character sets, checks for sorting rules etc.

With so many tests to be conducted per locale, management of the whole process becomes much critical. Managing hardware and software to simulate native user environment, building a team of skilled testing engineers who appreciate and understand what would break in localized software, and above all getting to a release-ready product within the allocated time and budget can be a daunting task for any team not prepared for it.

Localization Testing, unlike traditional functional testing, calls for much vast set of hardware and technical skill set. Not only that but every aspect of test management from test case optimization to test metrics adorns a different meaning in the context of Localization Testing. For example, with a localized product the bug tracking tool now would need to have a way to track bugs on a per locale basis. Now, there are many ways to do this, a simple keyword based extension identifying all locales on which the bug exists is one option. Does this approach suffice? Does this extension in any way twist the project metrics?

Another example is in the process of test execution. Localization testing for most of the common functionalities calls for a defect, when found, to be checked on the language that the product was built on in the first place (in most cases English) and in some cases in all supported locales. However, this calls for an additional effort. Should this be always done? Can this be optimized?

In terms of resources, localization testing labs needs to be equipped with hardware and software to simulate any and every native user action and experience on a localized product. A product supported on 22 languages, two platforms (Win/MAC) would need at least 48 machines still with the constraint that a combination of the machine/locale can only be used by a single person at a time. This problem is solved by smart use of virtualization. Can every test case of the product be tested on a virtual machine?

We at QA InfoTech have developed insightful answers to all such questions as raised above based on our long experience of working on large product localization projects. We have developed large teams where in people exactly understand what Localization Testing calls for. Our QA Managers have long experience of juggling and optimizing resources without compromising on quality or project deadlines. Our labs and infrastructure provide the right support for our teams to be best productive.

Do not hesitate to write to us if you are a project manager having difficulties with your Localization Testing projects, we would love to hear from you.

Here is a snapshot of a quote by Mukesh from the article. Read the complete article here.

Huh! The list is long and never ending…Don’t worry; the intention was not to bombard you with the boring itinerary; it was only to demonstrate just how pervasive usability is in our daily routine. I was pleasantly surprised to know about ‘World Usability Day’ when I stumbled upon the website http://www.worldusabilityday.org/. From alarm clocks and heating controllers, to voice mail and vending machines, in modern times we’re struggling with technology virtually every hour of the day. Each of these things might not have a mouse attached, however in many other respects they are as much of a computer as the one you’re using right now.

“Don’t Make Me Think” is the title of usability consultant Steve Krug’s book. If a website is difficult to browse or use, people quit. If a homepage of a site fails to clearly state the purpose of the company and what users can do with the website, people leave. Quitting is the first line of defense adopted by users when they encounter a difficulty. Imagine - A user cannot find a product on an online shopping portal and a student is unable to locate a course that he intends enrolling for via an online varsity. Result is bad rapport with customers, no improvement in revenues; in a nutshell not much output. What’s the problem? Perhaps, you forgot to test for USABILITY!

Now the question arises - When and how does one work on usability? It plays a role in each stage of the design process. Before starting the new design, test the old design to identify the pros and cons. Conduct a field study to see how actual users treat the system. Make paper prototypes and test them. Invest as less time as you can on these initial design ideas because you’ll need to change them all based on the test results. Thereafter, keep refining the design ideas through multiple iterations. Once you hit the bull’s-eye and implement the final design, test it again. Remember, subtle usability problems always keep creeping in during implementation. So, don’t get bogged down. Just try to work around them as much as possible. The best answer of “How?” lies in user testing. Get hold of some representative users, and have them perform representative tasks with the design. Make note of their actions - where they succeed, and where they face difficulties. And use this data to your advantage because in here lies the key!

Like most of us, I love eating cookies…especially Britannia digestive biscuits, and sometimes the rarely found (in India) Oreo cookies. What’s common in their package designs? - open from side, slide tray out, slide tray in. It’s a new concept these days. But the tray design makes it difficult to slide back into package. Due to this usability flaw the package gets caught on grooves of the tray. The design is great from a packaging standpoint in that it keeps the cookies fresh while on the shelf. However, when you take it home, how do you keep the cookies fresh after packet is opened? Straight answer is - put it in a ziploc pouch. No re-seal ability and no way to shove the plastic tray back into its packaging is really annoying for me as a consumer. Now, how does this cookie packaging apply to a website’s usability and design? Sites are designed by engineers with business rules in mind, just like packaging is done by a packaging engineer with shelf-life dates to take care of. It must meet certain technical standards. However, technical standards do not take into consideration how consumers will actually interact with the product. So, test your site with your target audience and the average consumer who is not tech savvy - in mind. Doing so, will open your eyes to the way customers interact with your creation everyday.

As our first blog post rightly said - we at QA InfoTech empathize completely with our customers and consider all use cases and situations that the product will face once it goes out in the real world. This unique attribute of ours lets us have our way with ‘Usability’. Be it mobile testing, globalization testing, load testing, website testing or eLearning application testing - we honor the importance of usability in each of these areas that are important to our customers. Our drive to serve our clients better, state of the art labs, abundant knowledge base through user experience and valuable human resources have paved our way to success as a reliable Usability testing partner. So folks, Think Noble, Think Usable! And should you have any queries and issues we’re here to serve you…