I've recently changed my contracts to include some specific information about testing and testing scenarios.  You'll recall my blog about how important testing is to the success of a website retaining its visitors, but I'd also like to point out how testing can really get in the way of your contractual obligations as well.  Take this example (and no Mike M. this isnt' you....LOL)

You have a contract which outlines what a site will need to do....allow a company to login, create a job for a customer, do the job, bill the job.  Sounds simple right?

However throw in the variables such as, they don't have any standard billing methods (not ones that could be followed by an application at least), multiple scenarios of "exceptions", and a staff that doesn't seem to talk to one another.

Now from a legal perspective, if the contract is simply written outlining the issues above, we're sunk.  The client can take as much time as they want to test, to work out their own billing practices, etc.  However if you add a paragraph which specifically outlines how the system will be tested and what to do if "exceptions" to those rules come up, you'll be in much better shape.

So here's my paragraph (feel free to use in yours, and send me an email letting me know you found it helpful):

 

---

 

If I had to single out a reason why sites fail that really can be avoided, it would be the lack of testing.  It always seems as though sites are up against the wall to go live and do...only to fail when their users can't use the site for the sole reason it was created.  If adequate testing had been done on the site prior to launch the users' experience would be much more pleasant and better conversion rates would result.  However, it's not as simple as it seems.

What I've discovered over the years is coming up with testing scenarios, while a key to the success of the site, really comes down to how well the client really knows its own clients or potential users. While you are building a site for a client, it would be helpful to have your client coming up with scenarios to test the site.  The typical user scenario is pretty easy.  The ones that are difficult are the unusual users who may be coming to the site.  Now, my friends....I am not saying "unusual" meaning strange.  I mean unusual in the sense that they are not the typical user a client will expect to use their site. 

If you want to help find out what is the atypical user, consider these questions:

1.  Who would your typical user be, and who would your typical user be most likely to tell about your site.

2.  Consider geographical areas, meaning terms you would use that someone from another part of the country wouldn't.

3.  Consider ages.  A person who uses your site could potentially tell their elderly parent who is somewhat new at the internet...would they know exactly what to do on your site...could they get to the parts of the site you want them to.

4.  Consider gender.  Lowe's has increased the amount of sales, and sales decisions by females almost 30% more than its known competitor, Home Depot.  Why?  Because Lowe's considered the female perspective for what would make going to a hardware store (for all intensive purposes) more enjoyable for women, but yet still cater to their target market.  So they were able to keep their focus on the target market of males 25 - 40+ and still increase their sales.  So consider the fact that you may in fact have other genders visiting your site, and consider their perspective.

I don't expect you to be able to test every type of scenario, but perhaps by considering the atypical user, you may actually be able to have a much more stable application/website and really take advantage of those new site surge visitors.

 

 

 

I had one of those very strenuous days today.  These are the ones that as a web developer you just feel like taking your computer and throwing it from the highest location you can find.  The problem?  A website checkout process that was failing over 50% of the time with its users. 

I sat back and said a prayer for a moment since I believed that getting angry was not going to solve my problem.  And just like that I had a thought....approach this problem as if I were my 6 year old son using the form.  Within minutes I had the problem figured out, put in a quick javascript validator to make sure the values would be entered correctly and just like that...the problem was solved.

So I decided to blog about this since many times not only developers, but business owners will have their websites so complex that it will cause more problems than successes simply because they are not thinking like a user who's prime source of income would be a nice chocolate chip cookie.

I've actually had my son test quite a few of my websites and even though I may have to read the form to him to fill out, he has discovered some issues with my sites and I've coded appropriately to deal with them.  So the next time you're ready to launch a new form, or a new functionality of your site, think to yourself....if I were 6 how would I look at this.  Or better yet, if you can snag a youngster from your family or your close friends, use them to test it themselves and pay them with a nice big cookie for their good work.

Happy Coding!

Doug.