the underlying HTML content).
The third problem was more insidious and initially more difficult to
detect. GWT used a hidden IFRAME
in the Web page to store the history of
Web pages visited by the user (so the
user could navigate with the browser
navigation controls such as “Back”).
We discovered, however, that one of
the initial tab characters was directed
to the hidden IFRAME. This was confusing for users, because the cursor
disappeared, and it was also mildly
annoying, as they had to press an additional Tab character to get to where
they wanted in the user interface.
Once the problem was uncovered, the
fix was easy: add a TABINDEX=“- 1” attribute to the hidden IFRAME.
The next heuristic we considered
was that the sum of the number of
tabs should be identical for both forward (Tab) and reverse (Shift+Tab)
keystrokes. The first part of the test
used the same code as that used for
the initial heuristic, where the count
of tabs issued is incremented for each
element visited. Once the test reached
figure 2. testing for forward tab counts.
figure 3. testing for reverse tab counts.
the initially selected element, it start-
ed generating the Shift+Tab keyboard
combination, which caused the navi-
gation to go in reverse. Again, the
number of Shift+Tab keystrokes was
counted. Each time an element was
visited, the value set in the title prop-
erty of that element was added to the
current value of the counter. The sum
of the tab-orders should be identi-
cal for every element visited. If not,
there is a hysteresis loop in the user
interface indicating a potential issue
worth investigating. Figures 2 and 3
show the tab counts for each element
visited. We can see that each pair of
values for a given Web element add
up to nine (for example, Button B’s
counts are: 4 + 5 = 9; and Button A’s
counts are 6 + 3 = 9). So this test pass-
es. [Note: the figures do not include
extra tabs required for the browser’s
address bar, etc.]
The final heuristic was that the
flow of navigation should match a
regular pattern such as down a logical
column of input fields and then right
and up to the top of the next column.
figure 4. typical navigation flows.
Horizontal, then vertical, flow
Vertical, then horizontal, flow
Figure 4 shows two typical flows.
Here we can detect whether the
expected pattern is being followed by
obtaining the (x,y) location of each element on the Web page. The pattern
may be explicit (if we know what we
want or expect) or implicit (for example, based on how similar Web pages
behave). A tolerance may be used to
allow slight variations in alignment
(where we consider these to be acceptable).
Our automated tests rely on WebDriver, now part of the open source
Selenium test-automation project
and known as Selenium 2.0. WebDriver aims to interact with a given Web
browser as a person would; for example, keystrokes and mouse clicks
are generated at the operating-system
level rather than being synthesized
in the Web browser. We describe this
as generating native events. Sometimes WebDriver cannot generate native events because of the technical
limitations of a particular operating
system or Web browser, and it must
compensate by using alternative in-