you will gain a lot of time.
2) When you want to create a set of screenshots of localized software for a native translator revision. You can also face a situation where your client wants a complete revision of the translation, made by native people, of the running software. You can think of several solutions such as
- hiring all those native speakers and moving them to your office during the testing
- creating remote connections, so those translators can connect to your servers and machines remotely to check the software
- taking screenshots of every possible dialog of the software and sending it to the translators so they can review it
Most probably you will go for the last solution. It is the cheapest one, and you avoid the technical problems and waste of time the second solution can cause. So if you decide to take the screenshots, automation is a very good option. All the automation programs have a utility to take screenshots. If you are able to create tests that run properly in all languages, you will be able to take and save all the screenshots you need, with minimum human support.
3) When you have to perform a lot of setup testing. Launching setup.exe files from different locations (CD, Network, HDD, etc.) is probably the easiest thing you can automate. If you need to do customized setups, most programs can do that just by adding some parameters to the setup.exe command. If your testing involves a lot of setups, then automate it. You will save your team from boring hours in front of a progress bar, and you will save time and money.
4) When you are in charge of localization testing of a huge application, in a lot of languages, and you expect to be testing later versions of the program . In my opinion, this is the only scenario that makes sense for the approach mentioned in the above section (d) Resource Files . The effort of creating and testing the resource files is a project itself, involving programmers, testers, translators, and managers to make it cost effective. If you want your investment in time and money back, you need to apply this approach to a large project in content and time.
Automating software testing is always a difficult decision. Many elements must be taken into account to ensure a successful and profitable automation process. When it comes to localization testing, the task is even more difficult, because to the original elements we must add new ones. To summarize:
- Automation is a complement to localization testing. It can save a lot of money and resources, but it cannot fully substitute for manual testing. There are many things we need to carefully consider before we proceed to utomate our localization testing project:
- We will need to program our scripts almost line by line. We need programmers to automate. "Record and Playback" utilities will not work. Do we have the needed people on our team, or can we hire them at a reasonable price?
- We might need to create resource files linked to translation memories and glossaries, and also linked to the automated scripts. Is the extra programming worth the effort? Will we reuse our work in the future?
- We will need automation engineers supporting our manual testers. Are we ready to have a stable team of automation engineers? Do we have enough projects to keep them busy and saving money for us?
If you can answer "yes" to the previous questions, you have a good chance of success in your automation project, but you still need to