Make Testing a Part of Your Contract

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):

18. Delivery & Guarantee

(a) The application as specified in this Agreement will be considered “delivered” when all items outlined in the application task list have been satisfied. Satisfied will be defined as allowing a user with step by step instructions to use each item in the application task list without an error on the most current browser edition of Microsoft’s Internet Explorer and Mozilla’s Firefox.

(b) Any testing performed on the website which raises business decisions to be made by the Client will not be cause for delaying the progress or delivery of the application, and will grant JS the right to code the application to adhere to a "typical" standard for that industry to keep the project moving forward. Any modifications required will need to be addressed, priced, and paid in a separate addendum to this Agreement.

Example: Client's billing process is not specific for each possible case that may come through the application. This requires a long analysis of the business's billing practices and delays the progress of the application. In this scenario JS has the right to perform a site modification which will satisfy normal business billing methods.

(c) Any "special scenarios" that have not been specifically accounted for in the application outline or addendums to this agreement will be considered out of the scope of this Agreement and will need to be quoted and agreed to in an addendum to this Agreement.

(d) While computer “bugs” are a normal part of any computer programming environment, it will not allow Client to withhold payment to JS unless a specific item of the website fails to work on a regular basis with instructions as mentioned above since computer bugs can sometimes be attributed to an end user’s method of using the website, their computer environment, etc. However JS will always attempt to accommodate a majority of the typical browsers, operating systems and user methods when programming the website.

(e) JS agrees to stand behind their work for one (1) year from the application’s delivery date to insure that all items are working properly since it is sometimes several months before a particular function of the website is discovered not to be working as agreed upon. Client will not be charged for these adjustments and fixes to the code. This guarantee does not include, and is not limited to the following list of possible circumstances where JS would not be responsible for repairs to the website:

a. A new browser version appears in the web community and said browser does not allow the site to function as originally intended.

b. A government regulation or law requires changes to the website to comply with said regulation.

c. Client’s payment processor changes their requirements to process payments from the web.

d. Client’s method of doing business changes, therefore requiring modifications to the site.

By using this in your contract you are doing two things. First, you are letting the client know that they must provide you with any "exceptions" to the standard rules they are asking you to code, knowing that if they are that important, it will affect the price of the application.

Second, you are making certain the client understands that if their testing of the application raises a red flag they didn't raise ahead of time, that shouldn't delay your ability to keep the project moving. If you don't, the project will get sidebared while they sort out their business issues and you'll move on to another project, get involved there, and then be forced to come back to this one and somehow squeeze it in. Not a good scenario.

Please don't hear what I'm not saying....lol......this is just as much of a protection for the client as much as it is for the developer. I tell all my coders it is their responsibility to keep the client on track, not the other way around. By doing so you'll deliver an application as promised, on time, and hopefully within budget. It is that important...so go ahead and start using this in your contracts and as I said before, send me an email at doug[at]justicesolutionsllc.com and let me know your thoughts. Til then....happy coding.

Doug.

<<	January, 2009					>>
S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31