Software release is no longer a task confined to a core English market. Global doors are open to take in newer software that is entering the market. Development teams are obviously very cognizant of this and are ensuring localization is done right and done soon so as to enable release of local software along with the English version. Over the years, product teams have gained proficiency in developing such localized software including optimizing processes, working with global teams etc. to get this done on time and within the defined budget.
However, another important angle here is that not just the localized software goes to these local markets. The English version is also going to be available globally. So, let us say a software is being made by a US ISV which is now released globally. In Germany, this software will be available not just in German, but also in English. In France, this software will be available not just in French (fr-fr), but also in English. In Canada, the software will be available not just in French (fr-ca), but also in English (en-ca). A lot of emphasis is often placed in ensuring the software is locale ready, but not necessarily that it is English ready for global locations. One may argue that this is already covered as part of the internationalization testing. Yes, to a large extent. The product team is ensuring that the code base is culturally neutral and localizable. To ensure it is localizable besides internationalization, pseudo localization testing is also done. However, all of this is done with a key focus on localization. Once the base testing is done, the code base is quickly passed on for localization. However, when the product team is getting software globally ready, in the core English language as well, there are a few additional checks that need to be done to ensure the product is local market ready not just in the locale, but in the English version too. More than functionality or rendering, a lot here has to do with the content itself. Ensuring the content is suitable to the cultural palette of the local market is one main aspect. Secondly, ensuring the content is legally compliant to the market of release is another core focus area. Intuitiveness of the content is also an important point to consider as the vocabulary of the English language varies a lot across varied global locations. All of these may sound simple, but are often very time consuming given the volume of content that the evaluator is combing through and how the ones needing edits are often buried in the fine print of a large chunk of content. Herein, a combination of subject matter experts (such as legal advisors, local market specific sales and business people) are very useful. Additionally to gauge the intuitiveness elements, a select set of end users also come in very handy.
At the end of the day, while taking software into global markets, considerably expands its market share, it has a lot of intricate pieces to handle and an often overlooked yet important piece is this one on “Ensuring the English version of the software is also ready for a specific geography besides the localized version”. In this context, a great read is available on the msdn repository at: http://msdn.microsoft.com/en-in/goglobal/bb978434.aspx#EBF

An often debated question is whether “manual testers should learn programming and be able to code”. While there is no unanimous answer to this question, I look at this debate slightly differently. While at the very core we will continue to need both manual and automation testers and each of them bring in their unique value propositions, it is definitely going to be beneficial to expose both groups to what the other group is working on. Doing so, is helpful in several ways including:
1. Ramping up one group to take on relevant portions of the other group’s work – when the two groups of testers work in isolation there is a lot of wasted effort, disconnect and more importantly lack of a concerted testing effort in building the right test coverage. If the manual testers are exposed to what the automation testers do and vice versa, apprehensions if any are reduced and in the process, they are learning newer things they can take on, on their plate
2. Load balancing the team’s tasks – The ramp up we talked about in the previous point, whether or not is helpful on an ongoing basis, definitely comes in handy in situations where one team is overworked. For example, typically a lot of the automation heavy lifting may be done earlier in the testing cycle, while in the later stages, they are being run in an unattended mode calling the tester’s attention primarily for results analysis. In such situations the automation tester who is trained to help with manual testing as well, is able to bring in much better value to the team and to the product under test
3. Developing a sense of appreciation for each other – Cross ramping of testers, if not for anything else, should be done to build appreciation for each other’s role. Automation testers, sometimes tend to look down upon manual testers, while manual testers may have their own inhibitions about test automation. Such a cross exposure, builds a great sense of appreciation for each other promoting better collaboration in the testing team
With the increased acceptance of Agile in the software development world, the lines between a developer and tester, a manual and automated tester are all blurring. While one may not completely gobble another, it is becoming increasingly important for one to understand and train on the other, to step in as and when required. As for the manual tester, automation is no more a long shot. With versatile frameworks that are shaping up (both as commercial out of box solutions and customized open source solutions), test automation is well within the reach of manual testers, who have no prior experience with programming. Their functional product knowledge with an appreciation for test automation can easily help them take on test automation, ably supported by the automation engineers. When this happens, there is no longer the debate of whether manual testers should learn programming or whether automation is reserved to a select few. Manual testers have now expanded their impact and taken on relevant portions of test automation still letting their automation counterparts, drive tasks they are best at. So, let’s shatter any inhibitions and make it an open swing door that exists between manual and automated testing.