When it comes to figuring out what browsers supported HTML5 and when they supported it you discover things are grey as grey can get.
Various browsers initially supported features that made it into the HTML5 specification which included the likes of even IE6-IE8, but this support represented a comparably limited subset of the available features in the current version of HTML5 (thus these browsers scored rather low scores in HTML5 browser tests).
2008 is when HTML5 started seeing its first semi-official support implemented.
Safari 3.1 (March 2008), Opera 9.5 (June 2008) had introductory support for the standard under the title of being HTML5. Firefox 2.0 had some limited support but they never announced it as HTML5 support but they included a few additions that were some of the key areas of HTML5.
Opera 9.6 (June 2008) / Safari 3.2 (November 2008) / Firefox 3.0 (June 2008) all extended support for these features too. Opera 9.6 also introduced HTML5 audio support in a limited form.
By the time Chrome hit version 2.0 (January 2009) it had a fair subset of HTML5 support in this release, but this support paled compared to its current support for the standard.
With the release of Firefox 3.5 though (June 2009) HTML5 Video and Audio tags were supported and helped HTML5 'go mainstream' as they announced it to all new users of the browser. Likewise with Safari 4 (June 2009) HTML5 support was greatly enhanced and video/audio support was also added. Opera 10 in June 2009 was the highest rated HTML5 supporting browser in browser tests but had no initial HTML5 video support till Opera 10.6 (Late 2009).
Chrome continued to throughout its releases grow increasing support for HTML5 at a rapid rate (so it's harder to pin point specific support) but by Chrome 6 (May 2010) it had gained HTML5 video/audio support and by Chrome 8 (October 2010) there was already support for all but two of the key elements of HTML5.
The first official version of IE to support HTML5 (despite having had some incidental support since IE7/8 days) was IE9 which only hit final release in March 2011.
So as things have progressed there has been browsers with significant support for HTML5 since mid-2009 (with the exception of IE which didn't hit the market with proper support till this year). With Safari 4.0, Opera 10.6, Firefox 3.5, Chrome 8 browsers onwards all offering support representing the majority of the HTML5 standard. HTML5 support continues to evolve across all mainstream browsers.
Additional References:
Those interested in learning more can check out a few references to see more details on this subject:
http://caniuse.com/
http://html5readiness.com/
http://www.deepbluesky.com/blog/-/browser-support-for-css3-and-html5_72/
http://www.findmebyip.com/litmus
Browser Market Share:
For those interested in the approximate market share of browsers offering significant degrees of HTML5 support as of August 2011 the stats site show:
W3C Counter: Supporting browsers 54.38%~
Firefox 3.6+ - 24%~
IE 9 - 6.53%
Chrome 12+ - 18.52%
Safari 5 - 5.33%
W3Schools: Supporting browsers 78.7%~
IE 9 - 4.2%
Firefox 3.5+ - 39.6%
Chrome 8+ - 29.3%
Safari 4+ - 3.8%
Opera 10+ - 1.8%
StatCounter: Supporting browsers 55.3%~
Firefox 3.5+ - 22%~
Chrome 8+ - 23%~
Safari 5 - 2.25%
IE9 - 8.05%
StatOwl: Supporting browsers 57.09%~
Firefox 3.x - 8%~
Firefox 4+ - 14%~
Opera 11 - 0.32%
IE9 - 10.7%
Chrome 9+ - 13.37%
Safari 4+ -10.7%~
NetApplications: Supporting browsers 52.75%~
Firefox 3.5+ - 23%~
Chrome 8+ - 16%~
Opera 10.x+ - 1.54%
IE9 - 7.91%
Safari 4.0+ - 4.3%~
Tuesday 18 October 2011
Monday 27 June 2011
Test Automation: Let’s Break It Down
Whilst having a conversation with a friend of mine recently we got onto the topic of test automation. During the discussion on the topic they came up with the suggestion that if automation required a programmer to produce the code so that it could be executed, should a programmer not also be the person responsible for the creation of said code?
Now the person I was speaking to was not a tester themselves but it was precisely that thinking outside the box mentality that allowed them to come up with an idea that on reflection appeared to be a real no-brainer.
Why should the testers not be the ones to use their skill of working out areas to test, what to test and how? Likewise why should the programmers not be the ones who use their experience and their knowledge to produce the code to automate this?
As I had covered in my piece where I had examined what the real costs of test automation are, I raised the point that as individuals we most likely will only possess a single skill that we can truly consider our primary skill, our core strength, the area of greatest focus. To use the cliché, those who attempt to become a jack-of-all-trades often then become the master of none.
As such an approach that enables a development team to allow people to draw on their greatest strengths and areas of experience, an approach that through working together still produces the desired results, could potentially allow the team to amplify the quality of what could be produced.
How this could be broken up in terms of the development team could vary based on resources and skill sets within the team but where possible there could be the following groups within the team: the testers, the test automation programmers and the application/web programmers. Where resources are more limited the application/web programmers could potentially be used for the creation of the test automation suites.
In breaking the team up in to their core strengths it allows people to really focus on their responsibilities. It minimises the requirement for having a tester side track work they were in the midst of doing just to update an existing automation script or suite, causing them to lose focus and potentially overlook or forget something they might had otherwise covered.
It also reduces the risks created through having someone either less trained or focused on coding producing the automation code. As is often already the practice the automation that then requires testing could be still tested by the testers to verify that the intended functionality has been implemented (...and to ensure there is greater than zero degrees of separation between creator and tester).
Much in the way a good development team has testers working directly with programmers, in such an environment the testers and the test automation programmers would be even more intrinsically linked. As a tester often has an evolving knowledge of the product, its quirks and its re-occurring issues, they can feedback this knowledge throughout the process to the automation programmers. Likewise any feedback on issues encountered during automation could also be communicated.
This feedback loop will allow automation suites to continue to improve and provide more meaningful coverage without interfering in the responsibilities of the tester, will assist with reducing risks in the development process and through this approach allow all team members to really concentrate on their core areas and thus produce a superior product.
Now the person I was speaking to was not a tester themselves but it was precisely that thinking outside the box mentality that allowed them to come up with an idea that on reflection appeared to be a real no-brainer.
Why should the testers not be the ones to use their skill of working out areas to test, what to test and how? Likewise why should the programmers not be the ones who use their experience and their knowledge to produce the code to automate this?
As I had covered in my piece where I had examined what the real costs of test automation are, I raised the point that as individuals we most likely will only possess a single skill that we can truly consider our primary skill, our core strength, the area of greatest focus. To use the cliché, those who attempt to become a jack-of-all-trades often then become the master of none.
As such an approach that enables a development team to allow people to draw on their greatest strengths and areas of experience, an approach that through working together still produces the desired results, could potentially allow the team to amplify the quality of what could be produced.
How this could be broken up in terms of the development team could vary based on resources and skill sets within the team but where possible there could be the following groups within the team: the testers, the test automation programmers and the application/web programmers. Where resources are more limited the application/web programmers could potentially be used for the creation of the test automation suites.
In breaking the team up in to their core strengths it allows people to really focus on their responsibilities. It minimises the requirement for having a tester side track work they were in the midst of doing just to update an existing automation script or suite, causing them to lose focus and potentially overlook or forget something they might had otherwise covered.
It also reduces the risks created through having someone either less trained or focused on coding producing the automation code. As is often already the practice the automation that then requires testing could be still tested by the testers to verify that the intended functionality has been implemented (...and to ensure there is greater than zero degrees of separation between creator and tester).
Much in the way a good development team has testers working directly with programmers, in such an environment the testers and the test automation programmers would be even more intrinsically linked. As a tester often has an evolving knowledge of the product, its quirks and its re-occurring issues, they can feedback this knowledge throughout the process to the automation programmers. Likewise any feedback on issues encountered during automation could also be communicated.
This feedback loop will allow automation suites to continue to improve and provide more meaningful coverage without interfering in the responsibilities of the tester, will assist with reducing risks in the development process and through this approach allow all team members to really concentrate on their core areas and thus produce a superior product.
Subscribe to:
Posts (Atom)