Agile Performance Testing - Testing Experience

More documents

Recommendations

Info

4. Include the delimiters as leading and trailing square parenthesis “[“, “]”- [öüß Pseüdö Tränsläte meßüö] Usually the activity of Externalizing the strings from the source code is completed, before the pseudo-translation process is performed. Externalizing is an important activity that helps to separate the translatable elements from the source code into separate files called resource files. After the strings have been externalized into resource files, the resource files are sent to language experts for translation into the native language. These resource files also undergo pseudo translation using internal tools (to perform the above steps) or proprietary tools like Alchemy Catalyst etc. What does a pseudo-translated screen look like ? Below is an example - Image source: http://www.globalvis.com/news/pseudo_after_noresizing.jpg The essence of pseudo translation: Before delving into the real benefits of pseudo translation, let me first explain what happens when the text is actually translated and shown on the UI. Whenever a text is translated into a non- English language, invariably the amount of space it occupies on the UI increases (as e.g. a German or Japanese character occupies more space than the English character), and the entire text expands horizontally and vertically. Based on past experience and facts, it is an accepted fact that incorporating 30% text expansion will help to solve most of the issues related to text expansion. Also, when the product gets localized, the majority of bugs are related to UI sizing, text truncation, hard-coded strings, character corruption, and few to over- translation, string concatenation etc. Most of these bugs are found “only” after the product is “actually” translated, which invariably happens towards the close-down in the product life cycle, i.e. in the L10n testing phase. This is where pseudo translation can add immense value, because it helps simulate the conditions related to all these bugs in earlier in the I18n testing phase. So by the time we reach L10n testing phase, most of the bugs have been found and flushed out#corrected?. How does a test engineer test pseudo-translated builds? • By its very nature, pseudo translation simulates translation. So when a tester inspects the pseudo translated screen, he/ she can still read the actual English text. Looking at our previous example, the original text was “Pseudo Translate me”. After pseudo translation, it looked like this - [öüß Pseüdö Tränsläte meßüö] So, by looking at the UI a test engineer can easily recognize the text highlighted in yellow, as it still resembles the original text. • Think of a condition that either the leading or trailing delimiter is missing with some padded text, as in the string below - [öüß Pseüdö Tränsläte m Here, the trailing padding as well as some of the original text is missing. It is an indication that the appropriate space has not been designed in the UI for possible string expansion, and this is probably a text truncation. • Another situation would be that after the string has been pseudo-translated, it appears in the UI as follows - [??? Pse??d?? Tränsl??te me???] Such a string is an example of character corrpution and is indicative that the rendering of strings has not happened as expected. • Suppose that after pseudo translation has taken place, the resultant text still shows up as the original string, i.e. Pseudo Translate me. This is an indication of a hard-coded string, i.e. the string was not externalized to resource files and is still embedded in the source code. • Another instance would for example be a product name (product names are usually not translated). If it is shown as a pseudo-translated string, it is indicative of over-translation and hence should be taken out of the resource files. The beauty which is shown in the above examples is that pseudo translation helps uncover most of the common bugs related to globalization, and it does so even before a single penny is spent on the actual translation of the UI. This results in huge cost savings for the organization. Limitations of pseudo translation: Pseudo translation, as you may appreciate by now, is quite a valuable approach for helping to find globalization-specific bugs early in the life cycle. However, the real utility of this approach is generally for the products that are being translated for the first time, or are generally undergoing extensive UI changes which require a lot of translation. Suppose that you used Pseudo translation for version 4.0 of your products and reaped a lot of benefits and that you are now planning version 4.5 testing, you may realize that the UI is going to be largely the same and that there may also not be extensive I18n code changes. In such a situation, pseudo translation may add very little or no value. So in some cases pseudo translation would not be considered, as most of the translation is already in place and won’t change across different versions. Epilog: Moving quality upstream for software products has been a buzzword for quite a while. The pseudo translation technique, when applied correctly, certainly goes a long way in improving quality. There are some very strong benefits in helping to unveil bugs, such as text truncation, character corruption, hard coding etc., which traditionally have been found only after the base product was translated. Finding these bugs after the products has been translated is a costly affair, mainly because translation is usually an outsourced activity and the cost of outsourcing increases with each additional change request. With pseudo translation in place, most of these bugs are simulated and found early on. Apart from cost savings, one of the other tangible benefits for the organization is to achieve “simship”. 8 The Magazine for Professional Testers www.testingexperience.com
Biography Anuj Magazine is a software testing practitioner currently working at Citrix R&D India Pvt. Ltd. He has been a regular speaker at conferences, such as QAI, STEPin forum and has spoken on several software testing topics. He has written articles in www.stickyminds. com (TheSmartTechie Magazine) and writes frequently in his blog- http:// anujmagazine.blogspot.com . He is an MS in Quality Management and holds CSTE and CSQA certifications. www.testingexperience.com ready for smart iT implementation? Implementing ICT solutions can prove to be difficult, often consuming more budget and time than expected. To provide you with firm grip on IT, Valori has developed CHANGESmart ® : a tailor-made training programme that involves people, process and technology where we believe people are crucial for success. CHANGESmart ® has been specially developed for users of TMAP ® , ISTQB ® , TestGoal ® and SmarTEST CHANGESmart ® leads to great timely results! For more information, please visit www.valori.nl or contact Service Innovator Martin Kooij, e martinkooij@valori.nl, t +31 (0)30 711 11 11. valori | P.O Box 595 3430 AN Nieuwegein The Netherlands The Magazine for Professional Testers 9
Page 1 and 2: 10 ISSN 1866-5705 www.testingexperi
Page 3 and 4: © Hans Schaefer www.testingexperie
Page 5 and 6: Five Lessons in Performance, Load,
Page 7: Bug type Bug description String con
Page 11 and 12: folder). Thus, every time an applic
Page 13 and 14: Feierabend! Seine Last- und Perform
Page 15 and 16: vices/resolutions. 3. Repeat the te
Page 17 and 18: Figure 2: DBAP Test Data Usage Cube
Page 19 and 20: Database Constraints restrict which
Page 21 and 22: XLT Xceptance LoadTest Functional &
Page 23 and 24: Biography Ronny Vogel is technical
Page 26 and 27: In this article we describe how Hud
Page 28 and 29: Foto: © swoodie - Fotolia.com Why
Page 30 and 31: init_server The init server job hel
Page 32 and 33: Load and Performance Testing for So
Page 34 and 35: © iStockphoto.com/cogal limited pl
Page 36 and 37: Altogether the criteria are grouped
Page 38: Testing is carried out primarily fo
Page 41 and 42: Berlin, Germany IT Law Contract Law
Page 43 and 44: © iStockphoto.com/naphtalina Agile
Page 45 and 46: October 6 Conference Day 2 Track 1
Page 47 and 48: availability of empirical data to n
Page 49 and 50: ous causal analysis in each case. T
Page 51 and 52: www.testingexperience.com An approa
Page 53 and 54: Figure 3 - Script line analysis 2.1
Page 55 and 56: Testing & Finance 2010 - The Confer
Page 57 and 58: tially desired test script shown in
Page 59 and 60:
Daddy’s performance test Saturday
Page 61 and 62:
i.e.people that know the product. H
Page 63 and 64:
© iStockphoto.com/Petrovich9 Knowl
Page 65 and 66:
ting is good. Tests often don’t u
Page 67 and 68:
and software engineering is not yet
Page 69 and 70:
Subscribe for the printed issue! Pl
Page 71 and 72:
© iStockphoto.com/arlindo71 © iSt
Page 73 and 74:
As you can see, we had good matches
Page 75 and 76:
Lesson 5: Start Early and Stay on C
Page 77 and 78:
© Pitopia / Klaus-Peter Adler, 200
Page 79 and 80:
This is even when the transaction r
Page 81 and 82:
the experience of educational speci
Page 83 and 84:
Time to change a winning team? Duri
Page 85 and 86:
lity Center, TestManager and VSTS E
Page 87 and 88:
Masthead EDITOR Díaz & Hilterschei
show all

Agile Performance Testing - Testing Experience

Create successful ePaper yourself

Delete template?

Save as template?