TheTrainLine.com deserves praise as it will let you check if two single fares are cheaper than the equivalent return fare when you search for a journey. They almost always are and this fantastic feature saves you a packet for just about every return trip you make. (Such are the vagaries of the ATOC/National Rail fares system, but there we are.)

Anyway I wanted to remind myself what time my train goes tonight, so checked the booking/journey confirmation email. However it has a bit of a flaw in presenting a critical piece of information (which I have highlighted):

Dear MR PAUL BERRY,

With your journey approaching we wanted to remind you of your travel details.

Collection Reference: 352CHH7W

Be Sure to bring this reference with you along with the payment card used to make the booking as both will be required to collect your ticket from the Self Service Ticket Machine.

From: SHEFFIELD

To: LONDON ST PANCRAS INTL

Date: 16/01/2009

Departure time: 0.76875

All your journey details are available in the my account section of our website.

If you need help with your booking, please visit our help section or call us on 0871 244 1545*

We hope you have a safe and enjoyable journey,

thetrainline team

*Please note that calls to this number cost 10p per minute plus network extras

Now this looks like a classic “time stored as decimal” formatting issue, as you sometimes see on raw spreadsheet data. The mystery is solved if you consider the time as a fraction of a day. 24 hrs * 0.76875 = 18.45 hrs or 18:27 in sexagesimal. Double-checking the times (since I’d already lost trust in the accuracy of the data) on National Rail Enquiries does indeed show a train departing Sheffield for London at 18:27 tonight.

I’m just thinking a bit further here of the person who goes through the trouble of doing the maths to work out the time but doesn’t do the final step so they get 18.45, which looks reasonable enough, and turn up for their quarter-to-seven train having missed it by 15 or so minutes! (Of course if the decimal hours come out at, say, 18.67 then that’s clearly not a time and in itself would be a prompt to complete the conversion but the above scenario still stands.)

What was Steve Krug‘s mantra again?

I wonder how many phone calls they get because of this? Could be a nice little earner! 😉

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…

What’s wrong with just stating “when prompted, cancel request” in your test case? Well, just think about the ways in which a dialogue box can be dismissed:

* click the close box (if present)
* click the [Cancel] button
* press escape
* press tab until the [Cancel] button is highlighted then press space
* press tab until the [Cancel] button is highlighted then press enter
* press tab until the [Cancel] button is highlighted then press return
* press alt-c or whatever letter in “Cancel” is underlined when alt is held down (if present)

Do you test each of the seven ways with each dialogue box you see? Why not? Because they all do the same thing? Well, one of the methods might trigger something the others do not (and yes, it has happened to me). Then again, even if I did adhere to these strict methods there might be yet another legitimate way of hitting [Cancel] that I’ve never thought of.

But a man can become paranoid. Clearly you have to be realistic in how you test and that will only come with experience. Don’t sweat the small stuff and don’t get bogged down in detail. Let’s take another look at these seven methods of invoking [Cancel]. They can be split into two groups: those triggered by mouse action and those triggered by the keyboard. Suddenly not so daunting.

Part of a tester’s workload is the proofreading of text, more or less. So, here are three pairs of terms that every web and application content writer must know when to use and when not to.

Signup vs sign up
Setup vs set up
Login vs log in

There are others, but in my experience these are the most commonly abused. So frequently, in fact, that I do a double-take when I see the correct term used! You will notice the left term is the noun, the right the verb. Wait, you knew that? I thought you might. Well, stop getting it wrong then.