Testers Heads Up Display

In 2008 I was fortunate to be invited to the Google Test Automation Conference 2008 in Seattle, USA. One of the talks I was most looking forward to was a talk by James Whittaker on the Future of Testing.

During the talk, James Whittaker talked about the idea of a Testers Heads Up Display. He took the idea that while playing video games you always have some form of Heads Up display that gives you some advantage in the game. This can be your health status or a radar. What this Heads Up Display does is give you little bits of information that make the game more enjoyable. And as you get better with the game you rely more and more on this information.

In testing the concept of a Heads Up Display it means that you suddenly you have a huge amount of data in one go for testing your application. Our T.H.U.D. is just a layer that has been created on top of the eChannel application. It works by doing a number of REST type calls to different services and then gathers all this information into the extra layer so we can have a view of what is happening in the system.

At smartFOCUS DIGITAL the Tests Heads Up Display was first created to compliment the reporting of our Performance Reporting Project that was worked on by David Henderson and myself.

The T.H.U.D would show the the exact same data as our reporting portal except using sparklines and would not take up the entire screen to render. This allows us to view our site but with the added benefit now of being able to view our YSlow performance Data as shown below.

But the T.H.U.D still had not hit its potential for the needs of the testers. For it to be a decent Heads Up Display it needs to give you all the information that may be useful while testing.

The Editor became the next area to get the T.H.U.D. The Editor is an extremely complex sub-system of the smartFOCUS DIGITAL eChannel application because it needs to handle the numerous idiosyncrasies that each browser has in its rendering engine.

The T.H.U.D was expanded to show what was happening in the editor when using the editor in "Normal" mode. This would show the HTML that the browser was generating while the user was working on creatives. Below you can see a copy of our editor with the T.H.U.D showing what the HTML really looks like with links to create bug reports. This means that bugs can be raised a lot quicker to have quicker and better feedback loops.

A lot of this is possible with very little effort because our application lives within a browser. We are just creating a new layer on our application and extending it with REST type calls to different applications that may hold the external information. It has become an invaluable tool in our testing arsenal.