Sometimes you just grind to a halt when testing: you’ve exhausted the test plan, tried most reasonable combinations of inputs, even thought of and exploited the most devious set of circumstances to trip up the application, all that stuff. Now your eyes are starting to glaze over. It happens, especially if there are no opportunities to pair test or hand over to a colleague.

Well the following technique worked for me and I didn’t even know that it was anything special or realise it would yield a fresh batch of bugs. So here’s what you do…

List stuff!

Yep, look at the whole screen and list things in the order they appear. I mean actually type the headings, titles, etc, into a spreadsheet or whatever your favourite note-taking method is. Then compare these views with the functional and technical specs, if available. Your mileage may vary, but you might find some subtle bugs.

It’s really that simple. And it can work: after a while you become blind to the design, layout and behaviour of the software under test. Force yourself to read everything. You may feel you’re going over things you’ve already seen a million times but truth is you may never have looked at them that closely to begin with.

As an example, I was testing an application which stored the names, addresses, etc of a list of clients the customer dealt with regularly. The list was rendered as a datasheet: column headings across the top, draggable, clickable to sort up/down. Nothing special at all. Then I noticed one of the columns was called “Country”. Did the customer have any international clients? Was there a field on the input form to specify a country? In any case, were these even requirements? No to all three. So there was a completely useless column sat there (copy-and-paste code?) and neither I nor anyone else had noticed after testing for over a month. There’s the rub: after seeing the same old screens day in day out I had become as good as blind to them, until I adopted a fresh way of looking at things…