Test-blunders during my last project

I would be the last person to boast that I am the best tester on earth. However, I also wouldn’t say that I don’t know what I’m doing. Still, I made some stupid mistakes during my last project and would like to share them with you. Hopefully you’re already doing those things, because they’re pretty basic (ugh, I really feel like banging my head against the wall sometimes for having made these mistakes).

Ok, background first. We made a web application that required customers to fill in their address and so forth. A couple of forms basically. Really easy to test that right? For Dutch customers, they would just have to fill in their zipcode and housenumber and we would auto-complete their address with street-name and city. We had a list in the database with zipcodes and corresponding addresses. It looked like this when filled correctly:

As you can see, the customer is not able to edit the street and city.

Ok, so I tested some different zipcodes. For example, when you live in a certain area of the Netherlands, you cannot get a certain service so I verified if the right error messages were displayed. So far so good.

When the system went into production though, we had complaining customers. There were a couple types of complaints.

Stupid mistake 1: City name was not accepted, customer could not submit form. Major fault! How did this happen? To prevent cross-site scripting we had whitelisted characters. – & < > were not accepted as input. However, Dutch city-names sometimes have dashes in them.

Example:

So the city had a dash in it….crap!? There was no workaround for this customer to get the form accepted…. We fixed this very quickly but yeah….could have easily been prevented.

Stupid mistake 2: An address that was ‘too new’. The excel sheet containing all the zipcodes wasn’t updated in quite awhile. I didn’t test new zipcodes, so it went unnoticed. Funnily, in my pretty short career (3 years now) I have seen this happen more than once already. So mental note: never forget to mention this in a next project. Could have been prevented too. It was also quite bad, because the customer couldn’t submit the form.

Stupid mistake 3: number-addition that couldn’t be accepted. When you live in a flat for example, you can add ‘3-hg’ (3rd floor) to your house-number. But, because of the whitelisting mentioned earlier, this input also didn’t submit. It was fixed in the same patch as stupid mistake 1.

After I was done hanging my head in shame I noted a couple of lessons learned:

• test zipcodes that result in places with ‘odd’ characters in them. (‘s Gravenhage, Babyloniënbroek, ‘t Lage van de Weg, Oost-, West- en Middelbeers [wtf, this one is really weird])
• zipcodes that end up with really long street-names. In the Dutch case the winner is 1509BP: Haaldersbroekerdwarsstraat (try pronouncing that, dear foreign reader!) Is such a long street-name accepted by the database?
• or cities: Westerhaar-Vriezenveensewijk (longest in NL)
• adding weird additions to the house-numbers ‘3-hg’ etc.
• in general: KNOW which characters are accepted and which aren’t.
• are diacritics accepted? What type of unicode does your database use? ‘é, ï, ß’

Ok, hopefully you snickered a little. I think you’ll believe me when I say that I’ll never make these mistakes again!

Thanks for reading, care to leave a comment about your own stupid test-mistake?