Monday, 24 August 2009

Testing in IE6

Ask about the 20% or so of users who still use IE6 in a development environment and there'll be a lot of rolling of eyes and general muttering.

The point is, until usage figures drop low enough to justify ignoring them, your dev team will still need to code, and you will still need to test, web sites in IE6. We'd all like them to upgrade but wishing it won't make it true. Unless you're in the privileged position where a client comes to you and states "make my site work only in IE7 and above", you can't afford to lose a fifth of your audience. But that's exactly why no-one will ever come to you with those requirements!

It's here for another couple of years yet. Grin and bear it.

Thursday, 20 August 2009

Selenium /is/ Compatible with Firefox 3.5

One of the great things about Firefox's Check for Updates function is that it will check the next release is compatible with all of your add-ons and extensions (and warn you if not). Trouble is it claims that Selenium IDE only works up to FF 3.0, which put me off upgrading to 3.5 for some months.

However, Selenium is Compatible with Firefox 3.5, it's just not marked as such. Download it from the official site.

If you're a Selenium user and haven't upgraded Firefox yet, you can do so.

If you're not a Selenium user, it could be just what you need to start automating tests.

Caveat: Having said all that, Test Automation is not the be-all and end-all it's sometimes claimed to be. Proceed with caution!

Friday, 29 May 2009

XKCD Touches on Tester Humour

CNR

It could so easily have used cloning as a theme to arrive at "could not replicate" instead :)

Tuesday, 24 March 2009

Perfect Software

I'm aware it's been some time since I posted. However, in lieu of a "proper" blog post, I can tell you I've started reading Jerry Weinberg's Perfect Software and will likely discuss it in a later post. I've heard good things about Jerry so it should be an informative read...

Friday, 6 February 2009

MyVoucherCodes does not Like Sex

One of the side effects of testing is you develop a distrust of most software products, especially web sites. It's a bit like the critic who can never really enjoy a show because he can never snap out of "review mode". So it's with some trepidation that I ever enter any punctuation marks into search fields, especially that most-abused of marks the apostrophe. Combine that with the fact that conscientious developers should always escape/strip quotation marks when passing user input to a query and you get this:

http://www.myvouchercodes.co.uk/code-store-search/domino's

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's') AND c.title NOT LIKE '%sex%' AND c.is_archived='0' AND c.is_expired='0' at line 4

The gem is unintentionally revealing how puritan your search facility is :)

Update: they've fixed this one now.

Friday, 16 January 2009

The Next Train to Depart from Platform 1 will be the 0.76875 Service to London St Pancras

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! ;)

Wednesday, 14 January 2009

Testing Gone Stale? Try This...

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...