Globalization Of The Testing Process Rostislav Shabalin Microsoft Corporation World-Ready software from the QA’s Perspective

Vision Statement World-Ready process builds World-Ready applications

Goal And Objective Product seen as local in every market Best functionality for any language or country Ship worldwide Minimal allocation of resources On schedule QA that guarantees world-readiness

Today’s Situation Single-binary product Globalized services of the OS World-ready applications of the OS Simultaneous release of localized versions No-compile localization MUI language skins LIP

What Brought Us Here? Not the programmers! Programmers too, of course QA made world-ready Organizational effort Technical approach to the problem Changing human minds World-ready QA works only with world- ready development

Shipping Global Products

Organizational Effort No single-country functional requirements No language-specific Development Testing Country-specific planning is a part of global process Results in global specifications

Changing People’s Minds Things that people value Source of income: pay check’s foreign part Appreciation: managers remember Internationalization is hard Professional challenge It helps when the problem is technical – that is, in the field known to your team

Formalizing The Task Being culture-authentic does not sound technical How does a guy from Washington know what people want in Beijing? Globalized functionality is achieved through technical tasks Verification of globalization is a technical, not a linguistic, task

New Test Breakdown Globalized Test of core features Verification of Localizability Test of Localization

Development Timeline Globalization

Globalization Of The Test - Goals Globalization - property of the functionality, not an application’s feature Functions must be tested for globalization Globalized test covers Multilingual text handling Processing of multiple scripts Proper handling of encodings Locale awareness Following the locale or user’s settings

Place Of The NLS Functionality NLS (language/locale) support becomes a core feature First to be tested NLS support - prerequisite for testing any application The only area where language or locale- specific functionality exists

Globalization Of The Test Step By Step Prepare test – globalize functional test cases Prioritize Select the platform Create the environment Run Select test data Classify problems Track defects properly

Prioritization Applications from the High-risk group Running on multiple platforms Interacting with legacy code Converting encoding of text Natural QA choice List Known Globalization offenders Anything that handles locale-related data Text parsers and processors, database applications, etc

Platform Of Choice Convenient choice: English Windows XP System, User, Input locales – change as needed Localized OS – use to interact with Localized names of built-in elements OS Environment of your market MUI version of Windows If the code has to adjust to the UI settings of the operating system

Test Environment – Bumpy Road East Asian System locale Non-Unicode data path assumes single-byte text European System locales OEM vs. Windows “ANSI” User Locales with “tricky” rules Special sorting rules: Spanish locales, placement of “ch” “Hand made numbers” under “exotic” locales: –if(CSng(sAppV1&“.”&“sAppV1)>= 5.5)

Globalize The Test Data Match the environment “Hard to process” data “DBCS” data in search for DBCS failures “Risky” SBCS (Windows vs. OEM) 3-byte UTF-8 in search for buffer overruns Match the task Application-specific “risky” characters “Dotless I” for case conversion and sorting

Running Tests Classification of problems Easy to categorize well-defined symptoms Loss of functionality Data loss Display problems –Fonts –Encodings Hard-coded locale Single defect database

Some Types Of Test To Globalize Specification-based Risk-based Model-based Code coverage Performance Hardware and Application Compatibility Usability Functionality-based

Demo Example of a globalized test

Post-ship Strategy Global Product Support Service Works with global defect database Single-Binary Service Pack World-Wide feedback collection

Development Timeline Localizability

Localizability Testing Tools Code review Pseudo-localized build Pilot localization Place After the code is complete; before translation

Pseudo-localized Build Pseudo-localization - stress the build Covers it all – whatever localizers can do Stresses the testers Breaks the test tools Pilot localization It’s a real thing Takes time to start Does not cover all aspects of translation May cover your best market though

Demo Verify the localizability of the tested application

Test Tools In The World-Ready Test Globalization of tools Pros Globalization benefits from formalization: automation is highly formalized Easy to repeat; eases the task of understanding Helps vendors to test localization Cons No universal tool so far Makes test tools more complex then the tested application If it’s too hard, it’s not needed

Development Timeline Localization

QA And Localization Less advanced then once Functionality is tested already Localizability is unlikely a problem Need not to be done on campus New QA task: manage the risks of outsourcing

Available Options Option 1: development team per language Seems to be “natural” The goal of World-readiness is not intuitive Known to be bad “Us vs. Them” mentality Release deltas Split and wicked codebase Mess with technical support and maintenance Option 2: single-country market

Recommendation Make sure the world-readiness is the goal of development process Make the globalization a technical problem Break the language/country tie in development

Resources GlobalDev, portal to internationalization Developing International Software Chapter on MUI and MUI aware applications us: Dr. International