Last week, Richard Bradshaw posed a mini testing question on a slack channel, asking whether anyone could reproduce a particular problem with an O2 webpage (see below) which has since been fixed. I’ve seen this type of issue quite frequently and had a hunch about how it could be reproduced, and as it turned out my hunch was good. However, it was only when Richard asked me about why I tried a particular course of action that I realised that I had a bespoke heuristic tucked away in the back of my mind that I hadn’t given a name to, so here it is. My quick and easy heuristic for testing webpages:
RAZOR
- R – Resize
- A – Accessible
- Z – Zoom
- O – Optimisation
- R – Refresh
Resize – Is the page responsive? How does it handle being resized to minimum viewable dimensions (and beyond)? What about maximum dimensions (for your display resolution)? What if you go beyond that and spread it across multiple monitors?
Accessible – How accessible is the webpage? Need some help? Give it a little wave using the WAVE (Web Accessibility) Evaluation Tool for Chrome
Zoom – A much overlooked manipulation and in the example above, how I found the issue originally highlighted by Richard. I tend to use this habitually (even when not explicitly testing something), especially when I’m using my 13” MacBook display and screen real estate is at a premium.
Optimisation – Is the page displayed optimally for the device you’re viewing it on? No need to break your multitude of devices just yet – try using something like the User Agent Switcher to get a quick feel for how the page renders on other devices.
Refresh – Is the webpage layout identical when you refresh it? What about a force refresh (where you force a refresh of your browser’s cache)?
As with all heuristics, the above is of course fallible, but hopefully you’ll find it easy to remember as well as useful.
PS: The above was achieved by zooming to 90% (and has been fixed)
Finding Deefex 
2 comments for “RAZOR – A Webpage Testing Heuristic”