It’s ninety percent complete, this on-line course you’ve been working on for months. The ones you love are sick and tired of hearing about all the interesting things you have learned about your subject matter and you’re not sure if there is anything left to learn about it. Your eyes are bleary from looking into the unending depths of your computer screen. Your brain is crammed so full of the course content, images, navigation, and assessments that you don’t care if you ever see this course or anything that has to do with your topic again for as long as you live. If you are lucky, your course has nothing to do with chocolate or ice cream.
At this point in the development process you’re ready to take your course out on the town, parade it around and get a little feedback. That’s right, it’s Beta Testing time. Pulses quicken, faces flush, hearts race at the fun times ahead. The excitement of the imminent vetting of your flawless work makes you giddy and high-spirited.
This is true unless, of course, you are in the normal, non-geeked-out, majority. You know, the rest of us who got into course development for reasons other than running tests, surveys, and data collection. Believe it or not, there are people who don’t get thrilled at the prospects of Beta Tests. People who are not even really sure how to run a Beta Test. People who get a little queasy about Beta Testing their baby in front of a bunch of strangers who have no comprehension of the amount of work it takes to put such a course together. Normal people.
For us normal folks, let’s take a look at Beta Testing and see if we can make it a bit easier to understand, perform, and use this process.
Beta means “not perfect”
Many developers believe that Beta Tests should only be conducted when the course reaches 100% completion. Our group at the California Department of Transportation (CalTrans) practices otherwise. For us, beta means not perfect. When we reach about 90% completion, we start talking Beta Test. This practice may have developed from compressed schedules, eagerness to capture feedback, or a desire to proceed with the process while the Web developers, Flash geniuses, and graphic artists were fine-tuning the last bits and pieces of the course. In our experience, early Beta Testing — before the product has reached 100% — has not significantly hindered our results and may give us other benefits with schedule and participant feedback.
When it comes to showing their work in progress, course developers are often like artists, no peeking until it’s finished. Most developers are hesitant to release an unfinished product for testing. This is a reasonable and normal concern. Nobody likes to be opened up to critical comments, no matter how helpful, when they are not even finished with the product. However, when it comes to Beta Testing, in our group unfinished is just fine and even preferred. There is still time to make a few tweaks, and developers can continue working on the project while the Beta Test is in process. In my experience, testers are more willing to make comments when they can see that the work is in progress and not a finished product waiting for their blanket stamp of approval.
Beta Tests for on-line courses are not meant to review the content. A subject matter expert (SME) provided the content, and probably double- and triple-checked it for accuracy. The purpose of the Beta Test for an on-line course is simply to check the effectiveness, usability, and functionality of the course from a typical user perspective. Is it easy to understand the navigation? Are the assessments intuitive or well explained? Do users get bogged down anywhere? Do …
Subscribe or log in to read the full article.
You can log in using your eLearning Guild username and password.
