There’s more to testing your rockin’ church website than making sure your slick-new AJAX supported features deprecate for older browsers and mobile devices. Your testing should also insure that your cool church web site succeeds in encouraging and facilitating visitors and members to execute real-world actions along conversion goals you’ve established for your inspiring church web site.
Simply put, your church website should have real-world, action-oriented goals that in general:
- speak to a demographic of seekers, members, missionaries and/or ministers
- gets and/or helps said demographic to do things, like visit and/or volunteer
Doing this means testing your church’s Internet offering at least at two levels:
- business – do the things that work, help visitors work towards a desired goal? Like find the sermon feed, and then add it to their aggregator?
To test the ‘business’ we need to go back to the ‘goals’ and build scenarios of likely user interactions, or in geek-speak: use cases.
Unfortunately those fluent in ancient geek may not be the best equipped to design such scenarios – as exemplified in the broad and conflicted definition of ‘use cases’ currently offered by the WikiPedia which reads:
“… a technique for capturing functional requirements of business systems and, potentially, of an IT system to support the business system.”
Uh … no … it’s about business rules and work flow, not functional requirements and certainly not about IT systems support!
Rather than collude the waters more, I’d like to point out an excellent set of articles by Matt Stephens over on the Register’s developer blog entitled:
Read as order as the later-written article nicely enumerates the elements that comprise a successful and effective use cases in pragmatic real-world terms that include:
- Writing cases in the active versus passive voice
- Descriptions of functional requirements versus behavioral objectives
- Knowing how many ‘rainy day’ scenarios are enough to get the job done
- the pros and cons of comprehensive versus minimal testing templates
- Whether to reference domain classes by name
- Whether to reference UI elements (screen/page names, buttons etc.)
I would suggest that anyone who hasn’t thought through the user interactions in terms of real-world scenarios do so – and with specificity. As anyone in my line of work, vague test cases have no other path than to vague results … or as Mr.Stephens correctly asserts:
“… Don’t write vague use cases, write concrete, specific use cases that leave nothing to the imagination instead.”
Put another way, you don’t receive good results because you’re not asking the right real-world, objective-centric questions.