The simple things in life…

Does your system accept real world data? Does it restrict the lengths of fields and/or prevent certain characters from being entered? How do you know when you are allowing the right kinds of data?

While chatting with colleagues about the NOTAG bug and some of the features of the system we are working on (it is vehicle related), it became clear that many testers never bother to confirm whether field validations on everyday data items are actually appropriate.

For instance, many systems in Australia are developed on the East coast of Australia. Now, I haven’t had to check this out for a while, and my records are buried in some old notes, but the important point is that in Australia’s two most populous states the longest license plate you can have is six characters.

Most systems that I have tested which collected vehicle registration details, happily assumed that this held true for the rest of the country also. And for a while, I think this was true. Western Australia has, however, had nine-character license plates for at least a couple of years now. Some other states allow seven. I know of more than a few systems that probably aren’t going to accept your HIWAY2HEL plate.

So here’s my question: In systems that you are testing, how many of the everyday data fields have you researched to find out whether the specified constraints were actually appropriate?

I’m thinking of things like –

– A phone number. There must be at least a few people out there with global roaming.
– An address.
– An international postcode.
– A surname. On a credit card. Here’s your credit card Mr. Saravanalanganingham. Or not.
– An email address.
– A URL.

While your at it, it might be a good idea to check what characters are valid in that email address or URL before you plan testing for that validation feature. The days when I am no longer allowed to enter my .info email address are thankfully much fewer now.

Google is usually the place to start when you’re looking for this kind of information, but there are other resources too. We also make assumptions about the behaviour of other things, and there are references for those too –

– The printed white pages and yellow pages can be a great source for finding real addresses and names, as can city street maps. The Australian white pages has a bunch of other handy references, including international dialling examples and a list of all postcodes.
– Speaking of postcodes, you can find a complete list of Australian postcodes and cities here.
– Curious to know what you might need to handle in that email or URL field? Read the RFC…
– Want to know who to blame for that website not working on your browser of choice? On another recent project, we couldn’t help but feel that keyboard navigation was a bit clunky on a select list control. There were also differences in IE and Firefox. It turned out that neither browser was actually behaving correctly. How did we know? We looked at the spec…www.w3c.org is your friend.

RFC.net is also a great resource for performance testers, or any time you need to work with the guts of the internet – HTTP and TCP/IP. On a recent project using AJAX, this was a vital resource for troubleshooting caching issues in our application. Mozilla/Firefox’s livehttpheaders extension was a great help too. It monitors the HTTP headers of webpages as they are received by your browser.

One final question: How many of you have been bitten when perfectly legitimate data couldn’t be accepted by a software system you needed to use? Care to share some stories?