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

2. Vision Statement World-Ready process builds World-Ready applications

3. 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

4. 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

5. 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

6. Shipping Global Products

7. 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

8. 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

9. 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

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

11. Development Timeline Globalization

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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)

18. 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

19. 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

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

21. Demo Example of a globalized test

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

23. Development Timeline Localizability

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

25. 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

26. Demo Verify the localizability of the tested application

27. 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

28. Development Timeline Localization

29. 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

30. 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

31. 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

32. Resources GlobalDev, portal to internationalization http://www.microsoft.com/globaldev Developing International Software Chapter on MUI and MUI aware applications E-mail us: Dr. International (mailto:drintl@microsoft.com)mailto:drintl@microsoft.com