A look into the world of HTML5 support and browsers

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%~

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.

Test Automation: What Are The Real Costs?

For quite some time now i've found myself questioning the adoption of test automation. Is it that i'd seen no value in it or believed that it's had no valid applications? No, but I had witnessed a rise in its adoption that had left me questioning the broad embrace of automation that appeared to be happening.

In the cost cutting world we live in today it could not be of any real surprise that companies and thus people are looking to ways which will cut costs, reduce overheads and streamline operations. It seems quite logical really, the alternatives could be seen to result in a loss of jobs but is that the real cost and likewise is the approach of automation a real benefit in the wider scope of things?

The answer to this of course is not straight forward, it's not simple and much depends on what is being worked upon. Why? Because a project's scale, the people behind its testing, its time frame and other factors all contribute to either making a case for or against test automation.

A simple example would be taking a smaller scale project or one with a short time frame where manual execution of testing would be quicker than any automation could provide. Whilst i'm sure this is a situation that i'm sure many test automation fans would agree on that automation would not be appropriate for, it does not prevent organisations employing these testers requesting such things.

A more complex example is where manual testing facilitates someone performing testing without requiring a completed framework in place due to the cognitive skills applied, so where an ever developing product is being tested it will not fail if elements are presently missing and likewise if revisiting the same area but with new content it allows a distinction between spending time covering existing content in an area vs covering new content only. An automation suite may look to cover everything in a particular area and therefore the implications of separating the automation into separate scripts may potentially double the overhead involved in test automation design / implementation and maintenance for that area.

Another example is where an ever changing (dynamic) product is in development, the ability for anything automated to respond to a constantly changing goal post would likely result in such a large overhead on an on-going basis due to the test automation that with the turn around times involved it may be unable to match the pace that development on the product is occurring.

Critically, there are two primary areas of risk I would identify that automation introduces. The first is it only confirms existing beliefs / existing knowledge, or to rephrase it, it doesn't know what it doesn't know. When we manually test something this hands-on approach allows us to identify that which was never documented and during a previous iteration of testing may have not existed in the application through a process of cognitive analysis.

Think about this for a moment, what do we do when we test, we look to inform on issues with the programming of others. So yes, through review one can test the automation that is used to do the testing through a tester by testing the automation tests but surely that sounds like a whole lot of extra overhead that is introduced through this approach (..and is quite a mouthful to say too!).

Likewise this approach if not properly tested becomes just as fallible in terms of risks as what we are attempting to test in the first place, so instead we end up with both the risks the product itself may hold in addition to the risks the automation in place may hold. To make assumptions that the automation is any less fallible is like a programmer claiming their code has no defects, and considering that when people are primarily testers and not programmers then it also likely means that a tester is not able to say they are as refined in that skill as they might be with their testing either.

Due to the significantly clearer traceability that manual testing often involves it means that the time involved to maintain tests and identify what they do / do not cover is likely significantly quicker than the time spent debugging, re-writing or removal / addition of code used within automation too.

The answer to many of the points above then often turns to 'well we can do exploratory testing too' which then begs the question as to how much of what is covered in exploratory testing then only duplicates what the automation is doing, meaning the same area may now be covered twice (..if not more). The exploratory process is something that only goes to confirm the validity and importance of both cognitive and emotive approaches to testing.

Now it's not that in saying all this that I believe there is no value in automation. Automation to my mind makes for a handy and useful tool for sanity / smoke checking or a simplified regression check on a longer term and larger scale project. It does streamline this area to provide us with a cursory impression as to the state of a product as well as allowing people to quickly re-confirm their existing beliefs / knowledge as to a product and the state of previously known issues. In addition to this automation can also be utilised for things such as concurrency checks and data creation (where a large volume of test data is required for testing to be performed).

Whilst the results of automation can be interpreted and explored by people who can then further investigate these things it must be remembered that due to the absence of a cognitive and emotive application during the actual process that all automation is able to achieve during its execution is checking and even that checking is then more fallible than that of the manual tester due to various of the reasons listed above.

So when automation is introducing new risks into something being tested one must always properly evaluate as to whether what it does provide really is of greater benefit to a project or not.

Think For Yourself, Question Everything

Earlier this year I wrote a piece entitled The Importance of Being Independent. I covered my belief that those who are still new to the field of testing or have limited experience would be best served by avoiding social networks and to avoid joining any form of community groups either.

I suggested instead that they would be best served purely observing and experiencing on their own the various systems and methodologies out there, not just on a theoretical level but within a real workplace environment where their decisions ultimately impact the outcome of that which they are working with. In addition to this I suggested that they seek to learn as much as they can by both reading up on their topics of interest that could relate to or assist them within their roles as well as to read articles, opinion pieces and tutorials that relate to testing.

It is my belief that these foundations give us a structure, a basis from which to judge experiences we have after that point, a basis where we can come from knowledge and not just opinion as to what we believe is the most appropriate thing. These experiences when formed in an environment largely free of much of the social influences that may otherwise pollute or bias ones belief system allow us to become better independent thinkers. It is only at this point that it is my belief that a tester should then explore the world of testing beyond that and join these social structures that exist based around an interest in testing.

The Internet is full of self and socially appointed experts, whether by merit or otherwise these people have become known figures within their respective communities. Whether these people were just those making the most out of an existing system or those looking to break the rules those that succeeded became figure heads that others would listen to or follow.

The emperor's new clothes...
It is common enough that the rebels, the fighters and the rule setters become the people's new leaders, particularly amongst those who are disillusioned with existing systems. This frequently however leads to something which creates an illusion, one that is in itself misnomer, in that those following the new leader are the rebels, the individuals, the defiant ones.

The reality however becomes that the rebels simply become the new conformists whose greatest point of distinction is that their rules are different to the group(s) that came before them but nevertheless these new collectives end up with rules of their own and ultimately contradict the whole point of being rebels in the first place.

Those of us who work to address quality are aware that there is no such thing as perfection and thus all any of us can do is seek to find something that works for them self and abide by their own beliefs. Subsequently the very idea of people who primarily just follow others whether they are new thinkers or existing ones are putting a level of trust into these people that essentially implies that these systems are somehow perfect models or methodologies in their own right, a flaw in it self.

Always the rebel...
A true rebel will never stop questioning, never follow others but instead take inspiration and ideas from others, allows themselves to be challenged and is willing to challenge others, embraces failure for the opportunity it can be and never stops learning.

As such whether you question or agree with this piece, to be a real critical thinker I believe one should form your opinion and hold your own view and to never let the view of others dictate or cloud your objectivity. For some to conform and follow is something that some choose to do and that is their right as much as it is the true for the rebels who go against it.

So one should never stop questioning authority and never stop thinking for yourself, as those who become true leaders in this world, those who change the world are those who never just rest on the shoulders of others and who never just accept the status quo but those who seek to challenge it.

The Case of the Cases, an iPhone 4 and Your Protection

There's been a lot of winging in recent weeks. It has been around the
launch of the iPhone 4, Apple's golden child, well its new one. It
comes from the line of products that much of the world fell in love
with, drove up Apple's profit margins to new heights and turned the
mobile industry on its head as well as helping facilitate the rebirth of
the bedroom programmer.

Apple's iPhone 4 though unfortunately came along with a design defect,
one they have in fashion that was quite typical of their previous
behaviour been in denial over and whilst there is no question the issue
regarding the aerial is a reflection of some poor testing what strikes
me is the reaction to this issue given what the solution to the problem
actually is, a case.

It struck me as odd that people would with such fervour be so quick as
to strike Apple down so harshly over this issue, whilst they could be
criticised for their (poor) PR when it's come to the handling of the
matter, what the remedy is is actually something users should be
adhering to anyhow.

The whole incident made me cast my mind back to an experience of mine
in the Apple Store. I was there to book a Mac in for repairs and there
were a number of those around me who had brought in their iPhones
having either cracked the device or it ceased to function after being dropped. The first thing that passed my mind is what kind of fools were these people to buy something as volatile as a smart phone yet not get some kind of casing for it. A year later when finally purchasing one myself the first thing I purchased with it was a case and a screen protector. Why? Because I like to protect my investments.

I understand the value of aesthetics to many people but in a world where
one can purchase an infinite variety of different types of phone cases
it can hardly be said that there isn't a phone case to match peoples
tastes for this aspect to even be an issue. So is the issue price? Well
considering they are spending up to £600 on the device is investing a
further £15, £20, £30 really spending that much more?

As someone with a lot of technology I like to protect my investments.
I have, not often, but it has happened on occasions, dropped items that
I have owned and the cases could be in part thanked for saving these
devices from otherwise potentially being destroyed or damaged. So when
reports say people can remedy the one usability issue of a device that
Consumer Reports says is otherwise the best smart phone on the market
with a measure that protects their investment is it really such a problem?

Would some of these same people go to equal lengths with other devices
they own? Let me list some examples here...

• dSLR / Compact cameras - The screens on these often can quite easily be scratched so a screen protector makes sense to avoid this, it also is a form of protection against impact if the device is dropped and falls on its back. In addition to this most people also buy cases for their cameras which also protect them
• dSLR and other lenses - These are extremely sensitive pieces of glass and much more so than any screen on an electronic device, it is both advised and extremely common that people have an associated UV/Sky filter that fits the thread size of the lens they have bought. This once again protects the lens from impact and prevents the glass from being scratched. Lenses also come with cases too
• Laptops - There's nothing preventing people from carrying these around without a case or a laptop bag, but you don't see many who do. It's not just a matter of practicality but also ensures that this piece of machinery does not get too battered or damaged as easily
  when transported in a case/bag
• iPods - Anyone who has ever owned an iPod would know they scratch and like any other device with a portable hard drive in they can also be damaged by shock / impact, so there was no shortage (if not a plethora) of cases and screen protectors one could buy for these
• Portable gaming devices - These too often have a variety of cases available for them as like the other electronic devices it is just a matter of fact that it is good practise to have one

But let's take the analogy one step further and go to a software level.
Would you put a Windows based machine onto the internet without some
form of anti-virus / anti-spyware software? or would you do on-line
banking / purchases without a secure connection?

Those who do not take these measures I would take a moment to thank.
As these people can be credited with keeping companies more buoyant
due to the frequency with which they replace items due to having had
some kind of accident with them and subsequently the amount of cash
they hand over due to not just repairing but often having to replace
these items as they did not wish to spend a minor amount protecting
them.

So this whole situation with the iPhone 4 and the remedy to its
primary issue is left with one question begging to be asked. If the
remedy is something which will protect your investment, is of relatively
minor expense and at the same time provide you with greater satisfaction then what REALLY is the issue?

A Question Of Character

You can run but you cannot hide..

The internet and real life are two different worlds, whilst these worlds now collide and overlap in many a way that they previously stood apart there still remains differences between the two.

In real life a greater sense of accountability and responsibility for ones actions can lead to often a greater requirement for those who would otherwise prefer to run and hide to actually deal with situations rather than choosing the path of avoidance.

Care of the Internet and social networking / instant messaging one is able to choose to just 'block' those they wish not to deal with and thus can choose the path of avoidance. As a result of this the Internet serves as an interesting medium for revealing the true character of an individual.

Whilst peoples on-line persona can conflict and be at odds with their 'real life' persona this does not alter the fact that both these personas are the creation of one and the same person. As such this means it can be a great revelation into the psychology and mindset of a person when it comes to how they act on-line as to their true nature. This has never been more relevant than now where privacy issues have highlighted that a person’s actions, their words and the thoughts they share on-line can be documented / recorded for time-lengths yet unknown and where a person’s words alone can be sufficient for them to land up in a court or jail.

Despite the fact these two worlds are now closer than ever before this has not prevented people from still demonstrating the kind of behaviour on-line that would be less likely to be accepted within a real life situation. So when an individual selects to just 'block' another over a single discussion or single action it does leave one to question why.

If there has been a succession of circumstances where the issue after numerous attempts still has shown no sign of change then it could be considered understandable to potentially take such measures. This though is in itself an important distinction as it demonstrates a level of maturity from the individual in question as they have made an attempt to find a resolution or to settle the matter rather than choose the easy way out, avoiding the situation and just blocking the person in question.

This action can also occur when someone is presented with an idea that conflicts with their own beliefs or ideologies and that they had found the whole idea so confronting that their only retort was to take an action that could be considered as little more than an emotional response by blocking that user, an action that bears great parallels with that of censorship itself and a certain sign of being closed minded.

Obviously this point does not relate to strangers though who are just out to spam users or the likes as such users are considered little different to receiving junk mail and they neither are engaging the user in discussion and are often little more than some automated script that does not care too much for what its' results are.

To Err Is To Be Human

The feelings associated in discovering a failure with ones actions are unlikely to stir joy in the average person. It is quite natural if ones desire is to seek something approaching perfection that it is possible that when the outcome, the result falls short of expectation to be disappointed.

As a tester we regularly deliver information of this nature on a regular basis to developers for their own work so it is because of this that the way we communicate that information is so important, to take out notion of blame or fault and rather just explain the results of what was found to them so with as little emotion as possible they can digest this information as objectively as possible and seek to find a resolution to the issue.

The difference though is when one discovers an action of their own that has measured short that there is no immediate separation of fault from actions, especially when one is aware of their own actions, then achieving objectivity is something the tester can only arrive at after the fact.

As someone who prides himself on his work and the quality of what he assists in delivering I would be lying if I did not find such experiences a bitter-sweet experience. Even though moments where a short-coming in my actions have occurred are few and far between, when they do occur it becomes a moment of disappointment as I am immediately aware as to the circumstances of the matter and know it was an area of my responsibility.

Whilst these moments are not ones I seek out they are ones that ultimately prove beneficial. In such situations I have often found myself having been acutely aware of what I had been thinking and what I had or had not been doing at the time when the mistake occurred.

Resultantly and what I believe is the distinction between an average and a good tester is recognising the situation for what it is, an opportunity to analyse what my shortcomings were in that situation and where there is room for improvement and what else I am able to take/learn from the experience. I also value the humility it brings in the reminder of the discovery of one owns short comings, so in short, the whole experience becomes something potentially positive and becomes an opportunity to grow.

So, even though one should never seek to fail, one can still fail to succeed if they let arrogance or ego get the better of them and miss chances like those as an opportunity and something to embrace regardless of any initial feelings associated with it all.