As we were progressing with functional test automation for one of the major upcoming platforms for one of the clients, a request for automating corss browser compatibility test case up as a hot topic. Many a times, the source of inspiration and sparking of an idea are beyond any ones control. And many a times, people do not wait for the Newtonian apple to fall on their heads to get ideas! And, in services industry, we all know that the time from the ideas strikes to shouting "Eureka!" to publish to the world till finding someone to 'implement' the idea is generally measured in nano-seconds.So, sooner that I realised, I was also part of this team solving the issue of browser compatibility (or incompatibility).
Everyone was looking for something that will automatically test the application across a whole bunch of browsers and their different versions. Something that learns what the user will do on that application, and then, one-by-one open differnt browsers and repeat the same and check if everything works fine. It does sound simple. But, the more I thought about it, the less excited I became. Is this so simple? It was the non-convincing simplicity of the solution that made me think about the problem more. I did a search of the web to find the tools that can do the job. I found a dozen odd tools and each one claimed capable of doing things that others can't. The problem started looking more complex than I originally thought. I decided to dig much more deeper. The result was really interesting, and I decided to post it in my blog - rather a series of posts.
There were several questions that I needed to answer to validate the solution that I already had. Why do we need to test the same code on different browsers? Is testing on different browsers enough? These were the two basic questions I decided to strat with.
Browsers are essentialty intermediaries that translate the HTML code to what we see on a web page. Internally, browsers use layout engines or rendering engines to generate the content based on HTML pages. One of the oldest issues is browser companies building custom tags which require specific browsers to interpret them. But this is becoming a non issue as most browsers are following the W3 standards.
As we all know, HTML standards are developed and maintained by the World Wide Web Consortium (www.w3.org) and is dynamic - means it is continuously evolving and udating. For example, HTML5 standards have been published, but is still evolving.If the standards are universal, who do browsers process them differently?
The standards are dynamic and evolving also means that generally all browsers have to do a catch-up with the standards as they are developed and published.This means that different browsers will comply with the standards in varying degrees. This will also mean that the un-spoorted part of the code is left for the browser to handle in its own way!
Also, the HTML standards are never un-ambiguosly well defined. While the tags and their syntax are well defined, there are numerous attributes to the tags that are not mandatory, but do not have a 'default' value. In most cases, it is not mandatory to define values to these attributes as well. This means that the browsers are free to define their own default values, This is one cause of difference in display between browsers.
Contents that require specific plug-ins to display are another cause of difference in page rendering across browsers. Different browsers will require plug-ins specific to that broser and not all browsers will have supported plug-ins for all content. In such cases, differences in the plug-in ans also the way a browser handles un-spported contents wil cause difference in displays.
Browsers are also evolving as the standards and technologies evolve and advance, and always there is a drive to push out newer and better versions to the market before the competition. This puts pressure on the browser developers and the push to crunch the timelines causes bugs to leak out to the market. Especially with the browsers that have 'automatic updates', these bugs are pushed to the end user without their knowledge.
We also know about the defects that the developers of the application have introduced that will have its own effect in the browsers (That should be the reason why this problem started!). I have read an interesting statistic in the website of one of the HTML syntax testing tools websites - 85% of the few million pages that they have tested has atleast one HTML tag related defect!
In the next post, we will look at a few more considerations of browser compatibility before we define the objective of the test and discuss a strategy for the test.
I test. Therefore I am.
