Blog

Corner (of the Eye) Cases (Hiccupps)

On March 24, 2012, in Syndicated, by Association for Software Testing
0

When you’re testing you’re observing, mapping, inspecting. Sometimes it’s non-specific – you’re exploring, trying to understand the size, shape, performance envelope, functionality, scope, stability, usability or other characteristics of an application. Sometimes it’s very specific – you are implementing an attack vector that you think you can exploit to expose a bug. Sometimes it’s neither of those things or a combination of those things.

Whatever it is, it always involves looking and when I’m looking at a system I try to apply what I think of as peripheral testing by analogy to peripheral visionthe ability to see objects and movement outside of the direct line of vision. I have my main focus on the thing I’m interested in, but I permit and encourage part of my focus to wander briefly, just a little, but often, while I’m there.

Let’s say we’re working in a GUI. I’ll take a few seconds to hover over all the components in a dialog to see whether tooltips are present and correct. If there are multiple tabs I’ll click through them all quickly – a kind of blink test – to see whether there’s empty fields where I’d expect values, enabled fields which should be unavailable given the context, odd colouring, inconsistent component size or naming and so on.

In any chooser I might try clicking on a few options that I know I don’t want, just to see what happens, before choosing the one that I do want. I might browse down a few levels in a file chooser, or open all of the sub-folders in one folder wondering whether there is inconsistent presentation or missing data, and then move on. I don’t give this my full attention. Often I’ll do it while I’m thinking about what I actually want to do next.

If I’m working in a configuration file at the command line, I’ll scroll through the whole thing to get to the point I want to edit rather than searching through the file. I’ll be skimming, looking for typos, missing comments, unexpected comments, obviously incorrect definitions or documentation, out of date names, incorrect copyrights or other attributions etc.

When I’m in the bin directory of an installation on a Linux machine, I might just type ‘ls -l‘ to check the date stamps of all the files in there and quickly eyeball them to see that all the files, which should have come from the same installer at the same time, have the same date stamp. Or I might type ‘file *’ and scan for any files that have an unexpected type or word size, given the build I’m working on.

These kinds of things take hardly any time. They are done idly, they are not systematic or exhaustive, they give your unconscious the chance to operate. They are not the main focus of a mission and they shouldn’t detract from it but the technique can and does find bugs – often the kinds of bugs you wouldn’t have found otherwise.
Image http://flic.kr/p/3yt5HU

 

Comments are closed.


Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!