Image by Shahid Abdullah from Pixabay

A few weeks ago, Eight Lady Jilly debuted her new website. Because my previous life was in software development, before it went live I offered to create a test plan and test the site for her. Being British, she’s very polite, so she accepted.

It’s a beautiful site and was delivered in very good working order. Even so, there was some value in creating a test plan that laid out all the things she wanted the site to do and how each of those things gets triggered.

My own site, in contrast, was a little buggy when I got it, so my (very similar) test plan was very useful both in nailing down how I wanted the site to work and in communicating the problems with my developer. The plan allowed me to tell my developer both how I expected the site to work and how it was actually working, and it let me keep track of what had been fixed.  All of this cut down on the time required to get the site cleaned up and ready to go live.

Since some of our readers may have reason to want to build a website, I thought I’d share a bit of the the plan so you can see how to put one together.

The first column is used to denote whether the test case passed or failed when executed.

The second column is just a unique number assigned to the test case to make it easier to communicate with the developer.

The third column is the page to be tested (Home, Books, Meet Jilly, Secrets & Treats, News & Events, Blog, Contact).

The fourth column is the major function to be tested (e.g. Menu Buttons, Social Media icons, etc.).  If your software is built with good design principles, reusing the code rather than coding each page separately, it should only be necessary to test these once, but it’s not a bad idea to test at least a few of them from different pages to ensure that’s true.

The fifth column is the sub-function to be tested (e.g. within the Social Media buttons, the Instagram button or the Twitter button.)

The sixth column lets you break the function down even further, if necessary. For example, on the Home page, within the Menu Buttons, there’s a Books button. If you hover over the Books button, two options appear: All Books and The Seeds of Power, which will be Jilly’s first book (and which was a Golden Heart Finalist!). You’ll want to break each function down to it’s smallest component to ensure you’re testing everything.

The seventh column is the Action to be taken, generally Click or Hover.

The eighth column is, to my mind, the single most important one. It lets you document how you expect your website to work. I can’t overemphasize the value of this information, not just for communicating with the developer, but for letting you make it really clear in your own mind what you’re expecting.

Columns 2-8 should be filled out before you ever start testing. In fact, if you have the expertise to clearly visualize all the functions of your website before it’s built, it would be a good way to communicate your expectations to your developer.

The final column records what actually happened when you executed the test case. As you can see, in the final test case listed above, I expected that the “Read More” button in the Coming Soon section at the bottom of the Home page would link directly to The Seeds of Power page. Instead, it linked more generally to the Books page, where The Seeds of Power was listed at the top. If the Books page will be set up to always feature the book that corresponds to the Coming Soon title, this isn’t a problem. If, however, the Books page doesn’t always list the “Coming Soon” book at the top, it’s not always going to take the website user where they expect to go.

Like a good tester, I left that to Jill and her developer to work out.

Once all the bugs have been discovered and fixed, it’s a good idea to run back through the entire test plan from the top, testing each function against the final code. This is because it’s really easy to break something while you’re fixing something else.

Do you have a website? If so, how did you test it?