W3C

Guidelines for writing device independent tests

Editors:
Dominique Hazaël-Massieux, W3C
Carmelo Montanez, National Institute of Standards and Technology

Abstract

As support for Web technologies grows, it is important that tests writers develop test suites that will work as well as possible across devices. This document offers guidance in the form of simple guidelines to follow to create device-independent tests.

Status of this document

These guidelines were produced by members of the Mobile Web Test Suite Working Group which is part of the Mobile Web Initiative (see About).

Comments on, and discussions of this document can be sent on the (archived) public mailing list public-mwts@w3.org (see instructions). W3C Members can also send comments directly to the Mobile Web Test Suites working group.

These guidelines represent the current thinking of the working group and as such may be updated, replaced or rendered obsolete by other W3C documents at any time. Its publication does not imply endorsement by the W3C membership or the Mobile Web Test Working Group.

Patent disclosures relevant to the Mobile Web Test Suites Working Group may be found on the Working Group's public patent disclosure page.

Introduction

This document provide a set of guidelines for writing test cases that can be run effectively across devices, in particular on mobile devices.

Existing work

The Authoring Challenges for Device Independence [ACDI] explore these different limitations in the general context of writing device independent content, and the Mobile Web Best Practices 1.0 [MWBP] give specific guidance on writing content targeted at mobile devices.

The CSS2.1 Test Case Authoring Guidelines [CSSTCAG] provides guidance on how to write test cases, and sets device-independence as a goal. The SVG Test Suite Manual [SVGTS] also offers advices on writing test cases.

Inspired by this existing work, and based on the experience gathered by the Mobile Web Test Suites Working Group while reviewing test cases and their fitness to mobile devices [MWTSSURVEY], this document explores the specific aspects to take into account when writing test cases to ensure greater device independence.

Lowest common denominator

Consider recording the browser identifier with the widely implemented window.navigator.userAgent, as there might be several browsers on one device.

When designing device-independent test cases, it is important to acknowledge the limitations of most devices:

  1. Screen
  2. Memory available
  3. Network bandwidth, latency and cost
  4. CPU power

For tests that require interaction (either for running the test or for submitting results), consider:

  1. Keyboard or pointing device access and ease of use
  2. Human cost of correctly submitting the results
  3. Start your test automatically with <body onload="beginTest();">

Guidelines

Screen limitations

Screen size matters when designing visual test cases - e.g. where the tester needs to assess whether the rendering of a test cases matches a reference rendering.

Across devices, the following screen parameters vary widely:

  1. screen resolution
  2. page zooming capability, scrolling
  3. physical dimensions
  4. number of colors
  5. contrast

In general, to avoid problems when running test across devices:

  1. Keep your tests as simple as possible. Do not include any visible information that might obfuscate or get in the way of the result.
  2. Avoid tests based on absolute dimensions.
  3. Be as concise as possible to avoid scrolling.
  4. When using colors to express the result of the test, consider conveying the result also with text.

Bad test:

Image depcting how a test from the CSS1 test suite looks on a mobile browser. Due to the amount of visible meta data included, it is impossible to see the actual test result.

Good test:

Image depicting a simple CSS test case consisting of a pass condition (“There should be a green block under this paragraph”) and a green block indicating that the test has passed.

Memory limitations

To avoid hitting memory limitations of the devices on which the technology under test run:

  1. Keep the number of style sheets, images, objects or scripts to a minimum.
  2. On markup based documents, keep the document object model (DOM) tree as small as possible.
  3. Keep the number of data structure created dynamically (e.g. by scripts) to a minimum.

Less is more.

Network bandwidth, latency and cost

The characteristics of network access across devices vary greatly, in particular in terms of bandwidth available, the latency induced by network requests, and the cost of transferring content over the network.

To cater for test environments where network is slow or costly:

  1. Keep the number of external resources loaded along with the test case to a minimum; prefer including the content (e.g. using internal style sheets instead of external ones) rather than loading it, except if it can be cached and re-used across test cases.
  2. Keep the number of network requests originated from scripts to a minimum to speed up data transfer.
  3. Take care when triggering DOM operations that they will not require downloading DTDs.
  4. Be aware that mobile networks are can be aggressively cached or transformed, therefore you might need to adjust originator HTTP headers depending on the nature of your test.
  5. Eliminate any white space in your tests.

CPU power

CPU-intensive operations on mobile devices can drain the battery, and are likely to be much slower than on larger hardware. As a result:

  1. Avoid unneeded images processing operations, such as scaling up or down raster images.

Extension capabilities

Most mobile devices have limited capabilities when it comes to plugins, additional fonts, or software extensions in general. Therefore do not rely on non-standard features such as specific fonts to be installed.

Keyboard or pointing device access

Many mobile devices don't provide a full keyboard, and thus require several key presses to enter a given character.

  1. Minimise interactive tests
  2. Provide helpers to reach the test suites using short URLs, 2D-barcodes, etc.
  3. Enable httpd directory listings to allow simple navigation between tests

References

ACDI
Authoring Challenges for Device Independence, Rhys Lewis, Editor, W3C Working Group Note, 1 September 2003 (See http://www.w3.org/TR/2003/NOTE-acdi-20030901/)
CSSTCAG
CSS2.1 Test Case Authoring Guidelines, Tantek Çelik, Ian Hickson, Elika J. Etemad, Editors (See http://www.w3.org/Style/CSS/Test/guidelines.html)
MWTSSURVEY
Conformance Test Suites for mobile web technologies (See http://www.w3.org/2005/MWI/Tests/matrix)
MWBP
Mobile Web Best Practices 1.0, Basic Guidelines, Jo Rabin, Charles McCathieNeville, Editors, W3C Recommendation, 29 July 2008 (See http://www.w3.org/TR/mobile-bp/)
SVGTS
SVG Test Suite Manual, Lofton Henderson, Editor, 1 September 2001 (See http://www.w3.org/Graphics/SVG/Test/svgTest-manual.htm#TestReviewGuidelines)
TESTFAQ
Test Development FAQ, Patrick Curran, Editor (See http://www.w3.org/QA/WG/2005/01/test-faq)