Test Test Test
February 12, 2012
As the saying goes, you should never assume, because you make an Ass out of You and Me.
Recently, I had the opportunity to work behind a local web design company who had built a website for a local restaurant.
When they developed the website, they added a contact form, using jQuery Datepicker and Contact Form 7, so visitors could make a reservation at the restaurant.
I was given the job of creating a way for the restaurant owners to open/close hours and days, blocking reservations for certain times as needed, without having to use a developer for each edit.
A Nice Inexpensive Solution
They were wanting to go a little less expensive, so I did not develop a full plugin, just a simple text-based solution.
Testing the Solution
I did a fair amount of testing, including a bunch of checking in IE8, Firefox, Chrome, Android, and iPhone.
However, I did not do as much as I would normally, because I assummed that the company I worked behind had done some testing as well.
Ultimately, IE7, slipped through the cracks and I did not check the code in Internet Explorer 7.
If I had, I would have found the disabled select options, obviously, were not working in IE7 at all and certain versions of IE8. I have run into this bug before, but let my guard down a little this time.
This is something I am not proud of, as it is out of character of my often rather obsessive website testing practices.
It Always Fails When you Need It
As is often the case with Murphy’s Law, faults in the reservation form did not become apparent for a few months when they finally started using the tool.
It soon became clear that people were able to make reservations whenever they wanted.
I added some testing and soon narrowed it down to iPad as being the main issue. So, I disabled it for the iPad and added some more checks to see what browser people were using.
However, I soon found that people in IE7 could also make reservations at any date, as well as some IE8 users. It was then that I tested for, apparently, the first time ever the design in Internet Explorer 7 and found I had overlooked a glaring bug.
The original web-design company used attr(“disabled”, “disabled”) on the select options to block out times. However, this would never work in IE7, because disabling a select that way is not supported in certain versions of Internet Explorer. The bug extends to Safari Mobile too, which is why it was not working on the iPad.
So, the fix ended up just being changing the logic of how business hours were displayed.
Instead of showing ALL the hours and then disabling closed ones, I completely removed all the hours and ONLY added open times.
Looking for an Out
It is easy to want to blame someone else and for many this is human nature.
In fact, we reached out to the original Web Design company, as soon as we found the iPad issue.
They were quick to blame it on me, suggesting that his coders could fix my “patch” and “…write our own query in java…” to fix my broken code. Whether this is ignorance or he was just trying to use technical jargon to confuse my client, I do not know, but the point is he saw an out and used it.
Despite the code being broken when it shipped and me providing a test site with their original code on it, they have not yet reached out to admit any fault.
No One To Blame But Myself / Test Test Test!
At the end of the day, however, I share just as much blame as the original web design company.
I should have tested it like I do everything else I design, which is essentially EVERY browser I can get my hands on.
Even though it shipped broken, I should have checked and caught this when I rolled out my update. Instead of being lax, because I assumed they would not have shipped broken code, I should have tested it just like any of my other code.
So, the moral of the story is ALWAYS TEST TEST TEST!