Saturday, September 26, 2009

All Globalization Testing myths uncovered so far....many more to come

Its been a while that i have been writing about uncovering various myths associated with Globalization testing. While there is a lot of relevant information on Globalization testing already listed in this blog, i am inclined to think about and work towards consolidating this information and much more in the form of an ebook in the time to come. Though i dont have definitive timelines in mind at the moment, this is something i have started working towards already. For the benefits of the readers, while i work to uncover more myths around Globalization testing, i have consolidated all the previous posts on this topic below.
[Just to remind that all these myths are the real time myths that i have experienced while working on Globalization testing]

Uncovering Myths about Globalization testing -1
Myth 1: G11n testing is not technical enough
Myth 2: G11n testing is majorly about testing the UI
Myth 3: G11n Testing can start only after the base product is translated

Uncovering Myths about Globalization testing -2
Myth 4: A person who doesn't know French cannot test the French version of the Software
Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
Myth 6: There is no scope of exploratory testing while testing internationalized applications
Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.

Uncovering Myths about Globalization testing -3
Myth 8: If a test case works fine in French language, it will work fine in German language as well
Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.
Myth 10: Globalization testing doesn't require the same test setup as is required to do the Base language testing. Globalization testing can be done with a minimum test setup.

Uncovering Myths about Globalization testing -4
Myth 11: Localization - means Localized product on a localized Operating System, Internationalization- means Localized product on English Operating System

Uncovering Myths about Globalization testing- Demystifying MUI Packs
Myth 12: Testing International applications using "Microsoft's MUI Pack" or "Localized OS installation" means one and the same thing

Uncovering Myths about Globalization testing- Input validation testing
Uncovering Myths about Globalization testing- Input validation testing 2
Myth 13- A tester can perform tests specific to text inputs for Localized applications using the similar approaches as the English language testing

Uncovering Myths...."Security Testing is from Mars and Globalization Testing is from Venus"
Myth 14- Security Testing is from Mars and Globalization testing is from Venus

Uncovering Myths about Globalization testing- English version on Localized setup
Myth 15: There is no use testing the English version of a product on Localized Operating systems

Uncovering Myths about Globalization testing- MUI Packs in Win XP and Win Vista
Myth 16: There is no difference between MUI technology being used in Win XP and Win Vista

Uncovering myths about Globalization Testing- Reusing Test Automation
Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing

Hope you enjoyed going over these again. Would appreciate your comments, suggestions!

Thursday, September 17, 2009

Key professional lessons from a Long distance run

The title of this blog may sound intriguing for a blog focused primarily on Software testing. I hope that by the time i reach the end of this post, i would have justified the inclusion of it here. For close to around 2 years now, i have quite actively taken up running. The prime reason that attracted me towards running was experiencing the feeling of reaching the finish line after persevering a long distance run. Before i started running, i used to think of it as quite a magical feeling but after crossing the finish line close to a dozen times now, it only substantiate my original perception of crossing a finish line. Its not just magical, its simply unbelievable.
I participated in Kaveri Trail Marathon last weekend. It was a 10 Km run on a day of sweltering heat and very rough, uneven terrain. While the run was pretty challenging and as i crossed various milestones, there were quite a few valuable life lessons that i learnt. Please read ahead to know more (the points below are not necessarily in order of importance)-

When your body says "Give up"- Just don’t give up. When a random thought in your mind says "You can’t do it", Just laugh it off.
The start of every run is always full of energy and optimism. The initial moments of a long distance run pass on with ease as legs and mind are fresh and usually (if it starts early in morning) the weather is favorable. It’s only after one has travelled a few kilometers especially near the half way point, the mind start playing games. It is often surrounded with casual thoughts that tend to discourage the runner from competing further. It is at this time, the body starts getting tired as well and tends to listen more to easy thoughts that prevent you from completing the run. The key here lies in being mentally strong and laugh off the negative energies and persevere till you reach the end. Infact, in my experience, one cannot reach the finish line carrying negative, confused thoughts.
Quite similarly, in the professional world, there are often the difficult projects/situations that bring an individual out of his/her comfort zone. There is always such time in these projects/situations when one starts doubting their abilities. The key here like in a marathon is to believe in yourself and shun all the negative thoughts and keep moving forward. Just remember- "When your body says "Give up"- Just don’t give up. When a random thought in your mind says "You cant do it", Just laugh it off."

Every small step towards the goal counts
The key principle in running a long distance run is that Each and every single step adds up in you completing the run successfully. Long distance runs cannot be completed in one step. Likewise in professional life, each project decomposes in to various steps that need to done right to attain the success. One cannot achieve the end goal without performing the smaller goals to perfection. Irrespective of conditions, Always put your best foot forward.

Key to success lies in staying in present
Our mind's ways are never static and even the well trained Long distance runners often face this dilemma i.e. while on the run, the mind tend to always think ahead i.e. picture of the runner reaching the Finish line starts framing up and all this makes the runner believe that he/she has already achieved the goal whereas the runner would not have even reached the half way mark. Or it may even happen that mind takes you back to thinking about ease and freshness at the start of a run. These are the biggest distractions for a runner and has a potential to distract the runner from reaching the summit. What is important in given context is to think only about the next step and not worry about the Finish line because if the next step is taken in the right direction in a right way, you are going to reach the finish line sooner or later. So, the key lies training your mind to stay in present and be there only. In the professional life, there is a great deal of importance in Staying in present. I have tried to capture the essence of it in my post- Software Testing and art of Staying in present .

If you fall down, thats not the end of the race- there is always a better option to get up and run
It happened in the most recent long distance run i took part in. It can happen in any long distance run that gets organized. People stop either because of minor accidents or because they suffer from cramps or they get tired or any other reason. Whatever may be the reason, Falling down is the part of the game. Its not an ideal world that we live in, things usually do not always go as we plan or as intended and Failures are a part of life. The idea here is to treat failures as a minor speed bumps that slow you down but not knock you off completely. Failures should be treated as learning opportunities and not the reasons to drift away from your goals. Any one who faces failure, ideally has 2 choices- either quit or continue. The ones who have strong conviction in their goals never quit. Failing faster holds the key. Remember- If you fall down, that’s not the end of the race- there is always a better option to get up and run.

Cheering your peers gives you momentum
Long distance running usually constitute of people from different backgrounds, age groups, gender etc. There can be a 70 year old participating as against a 14 year old boy or 25 year old female or anyone running alongside you. The diversity of participation makes the run even more wonderful. It happened in my recent run also. The fun lies in treating the running participants as your peers and continually cheering and encouraging them. In the entire run, there will be many phases where you face difficult time and the thought of giving up starts to play around. If in this situation, your fellow runner comes, pats your back and says "Good job", it just helps one defeat the negative emotions and just helps you regain back the momentum. In the real life also, professionally there are tough situations which may pull you down mentally and when someone acknowledge your efforts, it does gives a great sense of assurance to move forward. This act just spreads positive energy.

Taking a break and rethinking your strategy helps more than you expect
Well organized Long distance running events have the break points where in the participants can take very short water, energy breaks to refresh the participants. The refreshment time is very vital for the participants to successfully complete the run. This not only give the opportunity to the participants to hydrate themselves but also rethink strategy to complete the remaining part (thinking about speed, moving with long steps or short steps etc.). Without these breaks, it would really be hard to complete the run. Similar analogy in our professional lives- Generally people who work very hard to attain their and organization's objectives forget about the importance of taking sufficient breaks and this leaves them at a risk of a burnout leading to shortage of problem solving ideas. This situation neither helps them nor their organizations. The key here lies in realizing that you are getting in a rut and need to slow down. The focus and overall output after a well thought out break is far enriched.

I think being out of your comfort zone helps one learn quite a bit and the above write-up is a result of many such running experiences. Do share what you think and share your experiences!

Monday, September 7, 2009

Uncovering myths about Globalization Testing- Reusing Test Automation

Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing

The idea of making a Software test Software without any human intervention is something that is the basis of automated testing. In my experience, i have seen fewer things that catch the fancy of management other than a well crafted Test automation strategy. I was recently studying one of the Surveys listing the success of Software projects across different Software development models. While it is interesting to notice how the project success ratio varies from different Software development methodologies but one important point to note here is that irrespective of the Software development methodology used, the success ratio is far less than maximum. Before i sound like deviating further in this post, the idea here is not to compare how different Software development methodologies fare in the real projects but certainly to draw an analogy that like the success ratio of Software projects, the success rate of Test automation projects (the lifecycle of which is quite similar to Software development projects, though on a smaller scale) is also quite far from ideal. I don’t have a real data to quote here and this inference is quite based on my observations and experience.

While the reasons of Test automation projects' failure can be plenty and its not my intention to dive deeper into those here but in this post i would be focusing on one of the main reasons automation efforts fail to scale up for International languages' testing.
To start with, It’s actually a colossal myth that the test scripts meant for English language automated tests cannot be reused for testing with International languages. I call it "colossal" because the root cause of the automated test scripts for any projects not working on International platform is no less than a design flaw or a lack of forethought at the time of scripts’ design. In my belief, the Software organizations (which went global quite late) have spent sizable costs due to rework relating to introduction of Internationalization quite late in the overall life cycle. On the similar lines as this, Test automation projects have also suffered great deal of rework because the test automation scripts were not Internationalized upfront. Let me try and elaborate what i mean here-

- For a Software product to be properly Internationalized i.e. ready to be sold in International markets- the product design should-
• be Unicode enabled i.e. the product should be able to process and display data in any language
• have all the strings externalized i.e. none of the strings that show up on User Interface should be hard coded.
• have the capability to know under what language OS is it running on i.e. if the product is installed in Japanese, the product logic should recognize that.
• Should be able to read locale specific details from underlying OS
• be robust enough so that the same code base can be used across all the languages that the product support.


- On the similar lines, for Test automation script to be fully internationalized i.e. working successfully on different languages,
• The Test tool should have a capability of being installed and running on different language OS.
• The Test tool and hence, the automated test scripts should have the capability to process the Unicode i.e. any language text and characters. This is because any testing that's done on International test environments makes use of International character sets(which is what the customers would do)
• The Test scripts should have a capability to understand under what language OS is it running.
• The Test data is not hard coded in the Test automation scripts and is Externalized to a file or any database. This helps because, once the Test scripts detects the language of the OS, the "right" language Test data files can be loaded.
• There should not be separate Test scripts per supported language but a single version of Test scripts should be capable to run on multiple languages.

I must admit the above is not a comprehensive list of features required for enablement of Internationalization in automated scripts but i feel it is good enough list to give an idea on things that need to be kept in mind while designing automation scripts which are scalable in multiple languages. Traditionally, the automated scripts are designed keeping in mind that they have to be run on English environments only. To me, that is a sort of cardinal sin because it robs the Software organizations of reaping multi-fold benefits from automation efforts. Consider this- if by automating the English language Build verification tests, the team handling English testing saves 1 man month of effort, it is just a simple mathematics to judge the benefits the same automated scripts will reap if they are designed to run on 10 languages.

In today's global market place, if your product currently doesn’t support International markets that does not mean that it would not in future also. If it is not already, Globalization of Software products would eventually be required for survival of organizations. In such a dynamic scenario, it is imperative that like smart individuals- we think of future possibilities upfront and include Internationalization in our Test automation design right from the word go.

I would be exploring this area further in detail in the upcoming posts and I am keen to hear your views and experiences around Test automation in general and specifically on leveraging Test automation scripts in International environment.