rockidscience.com Instructional Design Basics

28Oct/10Off

No Respect

A comedian I wasn’t supposed to watch when I was growing up was Rodney Dangerfield; so naturally, I would watch his act whenever I could.  And though much of his subject matter was over my head at the time, I did find myself laughing at his material.  His no respect routine was a favorite:

My psychiatrist told me I was crazy
So I said I wanted a second opinion.
He said okay, you're ugly too.
Rodney Dangerfield

Goodness that is good stuff and as a kid, the no respect thing was something that I could relate to. Even as an adult, Rodney’s bit holds weight and this is especially true if your job involves quality assurance/testing.

In this regard, few understand or want to understand the contribution carried out by the lowly tester. Today I’ll talk about this humble hero and show you why good testers are necessary in order to produce a great course.

Why You Need Them
In a perfect world no one makes mistakes—everything we write is free of grammar and spelling errors; our courses function without hiccups; and the images in our courses are crisp and appropriate for the content.  Unfortunately we don’t live in a perfect world and this is why dedicated people are needed for testing activities on our projects. Without these folks your final course may have:

  • Spelling/grammar mistakes;
  • Poor navigational features;
  • Dead links, images, buttons and other resources;
  • Improper bookmarking and completion tracking; and
  • Inconsistent styles.

Such mistakes can be costly to the students taking your courses.  Here mistakes can damage the creditability of your content or make it difficult for your students to process/internalize the information.   Either result is bad for your course, so don’t mess around in this regard—dedicate time and resources to testing.

When to Test
Testing isn’t a one-time process and ideally you should start this activity early in your project. In this regard, things are much easier to fix on paper so your testing should begin at the storyboard level rather then when the content gets online.

The main type of quality assurance (QA) you will do at the storyboard level is Content verification.  It is at this point that SMEs, Editors, and Instructional Designers review the content to make sure that it matches the course requirements and that the information is clear.  Some typical areas that these groups should review can be found here.

Functional reviews are the next type of testing that you need to perform. These activities are performed as your course is being built.  Here people are checking the course to make sure everything is performing like it should.  Typical tests that should be verified at this level can be found here.

Having access to the storyboards, style guides and other documentation is necessary at Functional reviews as these resources define how the course should look/operate.

A key thing to remember with your testing is the need to be systematic—every page in your course should be tested and every test case must be verified for each page.  This approach will ensure that all of your content is consistent and as error free as you can make it.

How to Report a Problem
It is crucial to maintain clear communication as you test—here you need to make sure you document the exact problem and what the resolution should be.  This is easily done at the storyboard level as tools like Microsoft Word have features that facilitate this need.  With Word you can use the track changes and comment features to clearly identify the problem and what the change should be.

Communication becomes a little more challenging at the Functional level as these features may not be available.  Despite this, you still need to communicate the problem and resolution.  This is important as the developer needs to be able to find the problem in the course before they can fix it.  In addition, the developer may need to duplicate the issue in order to understand what is causing the problem.

So when reporting problems your descriptions should indicate:

  • The location (URL, page, frame) of the problem within the course,
  • The exact steps you have to do to produce the problem,
  • The specific problem you encountered and
  • The expected behavior for the course.

Once you report the problem though your work is not done.  The next step is to verify the fix once the developer has updated the course.  This is important as they developer may have failed to fix the issue entirely or they may have introduced another issue into the course while fixing the original problem.  Having a collaboration tool like a database or spreadsheet that everyone is working from can help keep track of these back and forth interactions.

Getting Respect
Testing a course can be a tedious job—hitting every page and running the same list of test cases over and over again can quickly put one to sleep.  But if you want a quality course, it’s a job that needs to be done and done well.  Once you have that great course then you’ll get your respect.

And as to Rodney, well he has since passed away but I think he got his respect in the end.