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.

However, the hours and dates they were open were hard-coded in a javascript file.

The web design company went in and blocked out Christmas and a few other days for the next five years, to ensure the design had a bit of a lifespan. However, if you wanted to change any of the days/times, you would need to go in and edit the custom javascript file.

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

Using the base javascript they developed, I used custom fields in wordpress to allow the owners to manually block days, as well as set custom hours for any given day.

They were wanting to go a little less expensive, so I did not develop a full plugin, just a simple text-based solution.

The end result was a php generated javascript file, with nice formatting, which pulled data from the custom-fields of a post to open/close days and hours.

I did it programatically, so the javascript output was controlled by a few functions, making changes easier. Although the logic behind it took a bit to get right, I think it ended up being elegant enough and easy to update.

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.

The Fix

Once I saw what I overlooked, javascript that could literally NEVER work in IE7 on XP, I had a head meets wall moment. I have run into this bug before and it is very well documented.

There are a few javascript based fixes, including adding css “disabled” class to the select or changing it to an optgroup. However, in this case, a lot of javascript was already in place and those types of solutions would have been A LOT more complicated.

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!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s