Quality Assurance’s greatest accomplishments arise when it does something most employees don’t even recognize as its job: eliminating difficulties before they exist, for instance. You probably can think of examples from your own experience, such as the time a QA professional identified and rejected a project “requirement” as untestable or problematic before it was accepted as a requirement. That is easily worth an order of magnitude more than conventional discovery of a bug in software delivered by Development.
HTML5 represents an opportunity for another of those major leaps that perhaps only QA can fully appreciate. Here are six ways to improve the quality of your next Web app development by encouraging a move to HTML5 sooner, rather than later. Take these tips, and save your time and attention for more crucial matters.
Image maps be gone! … or at least roped in a bit
Image maps were a great leap forward in 1993, and they are still quite wonderful now when used with (photographic) images. When image maps implement menu bars or geographic information system look-ups, though, they’re an accident waiting to happen. HTML5 brings us SVG and other graphical conveniences which are considerably more robust. Even if your Web design teammates are comfortable with code based on image maps, tell them it’s time to move on.
A full explanation of all the qualifications and background of image maps is beyond the scope of this article. The fundamental reality, though, is that most uses of image maps involve synchronizing maintenance updates in two different places that are hard for humans to correlate. The result is that every change becomes an adventure, especially for QA.
What do I mean by “two different places”? Here’s a model of a common use for image maps: two buttons, side-by-side, implemented as an image of the buttons:
along with a map of the actions of those buttons:
<map name="planetmap"> <area shape="rect" coords="0,0,40,20" href="left.htm" /> <area shape="rect" coords="41,0,80,20" href="right.htm" /> </map>
Do you see the difficulty? As soon as someone requires apparently-simple maintenance, like substitution of “left button” for “Left”, or replacement of the font used for the texts, two separate source files need to be changed: both the image and the map. In many organizations, these two files aren’t even maintained by the same person; the image might be under the control of a Web designer, while the map requires a programmer. Notice that time-and-material players profit personally from this sort of inefficiency, at the same time as it makes good results more expensive for the team as a whole.
Image maps have other practical defects, too, mostly centered on their lack of geometric sophistication; they only know about polygons and circles.
In contrast, the SVG (“scalable vector graphics”) standard defines declarative links between image and action in a single unified source:
<a xlink:href = 'left.html'>
<rect height = '20' width = '40' fill = 'yellow'
stroke-width = '2' stroke = 'black'/>
<text x = '8' y = '14' fill = 'red'>Left</text>
</a>
<a xlink:href = 'right.htm'>
<rect x = '42' height = '20' width = '45' fill = 'green'
stroke-width = '2' stroke = 'black'/>
<text x = '48' y = '14' fill = 'red'>Right</text>
</a>
This SVG source has semantics that are more like those of human thought. SVG better expresses “take an action whenever I click on the green area,” rather than forcing maintainers and testers to think in terms of “Take an action whenever I click forty-to-eighty pixels to the right of the left border, and zero-to-twenty pixels below the top border.”
Be aware that, for some commentators, SVG isn’t part of HTML5. This distinction is mostly a matter of convention or marketing; for historical reasons, SVG was largely defined in a process separate from other elements of HTML5.
HTML5 in general, though, is more a collection of parts than a coherent and manageable monolith. Get in the habit of explicit specification of the pieces of HTML5 you have in mind at any particular time; the technical and market merits of <audio>, <svg>, slider, and so on at any one time must be analyzed separately. Your end-users might be able to use <audio> and not <svg>, or vice-versa, depending on circumstances.
Further complicating the picture is that the best use of several parts of HTML5 requires co-ordination with CSS3 and JavaScript 1.8. Get in the habit of precision about the exact standard(s) on which your project rests.
Recognize also that there are parts of HTML5 that might never apply to your projects. You won’t use <audio> or <svg> if your applications have no role for those sounds or sights, without regard to which browsers your end-users launch.
HTML5 is a useful standard even without universal compliance. You might conclude, for example, that so many of your end users rely on early versions of Internet Explorer that you can’t assume SVG will render properly. That doesn’t mean, though, that your team gives up on SVG; instead, it’s perfectly reasonable to decide that coders reap the advantage of a well-defined programming interface by writing SVG, and then rely on compatibility libraries to render that SVG in otherwise-incompatible browsers.
Why is this a good idea? Because users of new browsers enjoy all HTML5’s advantages, while those who depend on older browsers receive all the same functionality, at the expense of a little bandwidth and performance. Decisions about a compatibility library are, of course, ones in which QA should be involved from the start.
Slider and spinbox dial in a number the user chooses
HTML5 brings several kinds of semantic change. The previous section described SVG as a more expressive way to achieve the menu bars previously coded as image maps. HTML5 also introduces several new elements that directly implement popular constructs that previously required more-or-less complicated JavaScript. Slider, spinbox, a grab-bag of “date pickers,” and a standardized “drag-and-drop” are good examples of this category.
A “slider” is an entry widget that selects a numeric value from a range:
A spinbox is a closely-related “picker”:
All of the widgets from this category will look familiar to anyone who uses the Web. Essentially every framework — jQuery, YUI, Dojo, MooTools, and so on — defines most or all of these. HTML5 defines them not for novelty, but standardization — and it’s easy to imagine significant payoffs in correctness and other quality attributes will result.
Don’t let the elephants trample you: multimedia
<Audio> and <video> seem like more of the same: widgets whose definitions are new to HTML5, but whose functions have long been familiar on the Web.
Well, yes and no. Multimedia is an arena where large, powerful forces play.
As with the constructs of the previous section, the HTML5 multimedia tags encapsulate familiar concepts. They’re both more complex and controversial than numeric selectors, though. Techies talk about sliders; business executives deliver speeches about billion-dollar intellectual property, patent portfolios, whether Apple or Adobe is more “open,” and the constitutionality of “net neutrality,” all “hot buttons” raised by multimedia tags.
The point for a QA department is that, however the legal and commercial issues play out, HTML5 is an important standard. You’re going to be responsible for QA of Web applications coded with these tags. Just as you developed strategies in the past to test Flash applications, now it’s time to encourage your development team to code with <audio> and <video>, and to be ready to analyze the results. How to do so is a specialized subject beyond the scope of this article; you can start, though, with clarity about exactly what devices (desktop PCs? Smartphones? Tablets? Which ones?) your end-users will have before them. Another important question: Does the availability of <audio> and <video> mean that your Web applications will lose Flash? How would that affect your testing?
Smarter storage
Another breakthrough of HTML5 is “local storage” (also called “DOM storage,” “HTML5 storage,” and “Web storage”). Crudely, local storage is like cookies, except better. Data persist beyond a single pageview or even browser session, but with a security and performance profile superior to the one cookies give. While legitimate uses for cookies remain, it’s time to switch most implementations to local storage. Among other virtues, popular browsers support local storage well.
Most of the consequences for QA are positive. Local storage’s semantics better match typical uses in Web applications, so that programmers can program more economically, and testing also becomes easier. Work with your developers and requirements analysts to ensure their use of local storage is testable; they’re likely to need reminders about how to handle a range of security configurations, whether the application itself should offer to clear local storage, and so on, all of which impact how you test.
Semantic elements
HTML5 has several tags whose benefits are more subtle, in that their value largely involves co-operation with CSS. These are the “semantic tags”: <article>, <aside>, <footer>, <header>, <hgroup>, <mark>, <nav>, <section>, and <time>. Where an older page might have had
<div id = “header”> …
now it has the option to write instead
<header> …
This change is invisible to blackbox testing. You’ll want to talk with your development teammates about their strategy for these semantic tags, though, because of their potential to enhance long-term maintainability.
The sandbox
A final part of HTML5 which presents a particular challenge for QA is the sandbox. Sandbox is an optional attribute to <iframe>, one which improves the security model for display “mashups”. Your application might “quote” a piece from another site.
While this “division of labor” can be immensely productive, it also raises serious security questions. Sandbox has the potential to control the hazards. If your application takes content from a different Web site or host, make sure to explore with your development teammates beforehand whether the use can be sandboxed, and the implications for testing.
I already mentioned that HTML5 is large and “wide;” it’s hard to get your arms around all of it. This brief profile doesn’t even touch on <canvas>, offline operation, or several other innovations that are particularly exciting for Web programmers. Start, though, by planning with your analysts how the six categories above apply in your organization’s development. You’re sure to end up in better shape — much better shape — than if these constructs turned up as surprises only when the programmers pass you their work for final testing.
See more of Cameron Laird’s writing on HTML5 on his own site.
About Cameron Laird
