Fast exploratory tests with IFrames
While working with a search quality development team, I was asked to collect information from their result pages across all the supported languages. The aim was to quickly get an overview, and then manually look through them for irregularities. One option would have been to grab the pages using tools like Selenium or WebDriver. However, this would have been complex and expensive. Instead, I opted for a much simpler solution: Display each language variation in a separate IFrame within the same HTML page.
An example of how this looks, can be seen here, where the Google Search page is shown in 43 different languages. There are also some links for other Google sites, or you can type in your own link, and the query attribute for language, "hl=", will be appended at the end.
(Warning: Do not try this with YouTube, as 43 Flash windows on the same pages will crash your browser. Also, Firefox 2 is known to be slow, while Firefox 3 works fine.)
The JavaScript Code
Creating the IFrames is easy using JavaScript, as can be seen in the example below. I assume that the array of languages to iterate over is retrieved by the function getLanguages(). Then a simple loop uses document.write(...) to dynamically add the IFrames. It is worth mentioning that this method seemed to be the best way of dynamically creating them; using the document.createElement(...) resulted in some complex race condition issues when adding the IFrames and their content at the same time.
var languages = getLanguages();
for (var lang, i = 0; lang = languages[i]; i++) {
document.write('<hr><a name="' + lang + '"/>' +
'<h2>' + lang + '</h2><center>' +
'<iframe src="' + url + lang +
'" width="' + queryMap['width'] +
'" height="' + queryMap['height'] +
'"></iframe>' +
</center><br/><br/>');
}
The rest of the source code, can be seen in this example. Nothing else is needed to get the overview.
Conclusion
The example in this article shows that a very simple and inexpensive solution can be useful for exploratory testing of web pages; especially when quickly looking over the same pages in multiple languages. The small amount of code required, makes it easy to customize for any project or page, and the fact that the requests are done dynamically, gives a view which is always up to date.
Of course, this type of overview lends itself best to very simple stateless pages, which do not require complex navigation. It would for example be more difficult to get the same list of IFrames for Gmail, or other complex applications. Also, as the IFrames are loaded dynamically, no history is kept, so tracking when a potential bug was introduced in the page under test might prove more tedious.
Furthermore, it should be noted that the overview only simplifies a manual process of looking at the pages. In some situations, this might be very beneficial, and enough for the developer, while in other projects more automated tests might be designed. E.g., it could be difficult to automate tests for aesthetic issues, but easy to spot them manually, while it may prove more beneficial to automate checks for English terms in other languages.
Finally, a word on the issue of translations and language skills. The overview in this example, quickly highlights issues like incorrect line wrapping, missing strings, etc. in all variations of the page. Also, it was easy to spot strings not already translated in some of the languages, like Japanese, and in fact I reported a bug against the Search front page for this. However, for other issues, more language specific skills are necessary to spot and file bugs: E.g. should the Arabic page show Eastern or Western Arabic numerals? And have the Danes picked the English term for "Blogs", while the Norwegians and Swedish prefer a localized term? I don't know.
This is a really good example of quick and effective testing. A small bit of code allows you to cover aesthetic, layout and formating issues (none of which are easily automated) very quickly.
OdpovedaťOdstrániťThe other big advantage of this approach is the amount of test coverage provide by this short code based solution. I would have thought you could achieve even more by quickly sending the URL out to the whole test team saying please give me your feedback.... making this not only a quick solution, but solution that easily gets good coverage from dissemination to lots of other testers (or even developers).
Yes it could be argued that this approach might not be a very thorough and scientific approach. It may also take a long time to go through each iFrame in detail. Having said that, you can quickly pick out the big issues and get the developers working to resolve those in a very short space of time.
So whilst the code gets the focus here I think the approach used here should be held up as a great example of good testing too.
William Echlin
SoftwareTesting.net