Frooxl

How to Polish Your e-Learning Development Cycle: Catch and Bash Bugs the Right Way

Whether you’re reading a textbook or the great American novel, watching the news or a weekly drama, or catching up on trends at your favorite websites, nothing is more jarring than when you see a mistake. It can be something as simple as a typo, or as major as misrepresented facts, but it always breaks an unspoken trust you didn’t realize you had.

When you see a final product, as a newscast or as a published article, there’s an assumption that what you’re reading is being provided by someone who is knowledgeable in what they’re telling you. That simple typo – whether it is pertinent to the subject matter or not – will shake that assumption. If this publication allowed one mistake through, what other mistakes could there be?

This is even more important in the e-Learning industry, where your learners assume that what you’re teaching comes from a place of authority and borderline mastery of the subject. While we want our learners to know that their instructors are human and approachable – and therefore, not infallible – finding mistakes in the coursework will undermine the learner’s confidence in the information provider, as well as in the information itself.

That’s why it’s important to find mistakes as early as possible and to correct them. The problem is how to do it. What’s needed is an issue-management system that makes sure no issue is found and then forgotten, and which also ensures that any problems are addressed in order of importance.

The Old Ways

Not too long ago (or perhaps still, in some cases), finding an issue in a course meant adding an entry on a piece of lined paper that would get passed around the office, from developer to developer. Needless to say, this method was antiquated and full of pitfalls. Having a sole piece of paper meant that only one bug or defect could be worked at a time. Having a single copy also meant losing it could be catastrophic.

Of course, you could make copies of the paper, but that just meant you’d have multiple instances of this paper floating around, with no central auditor to maintain order. This would bring the risk of having multiple people working on solving the same problem.

Issues were often worked in the order in which when they were found (and subsequently added to the list), as opposed to the order of importance or severity. Of course, you could assign a level of importance to each item, but what happened if you assigned something first priority, then suddenly found an even more important issue? Now, you would either have to create a new, higher priority (super serious first priority?) or re-prioritize the entire list.

The New Way

This gets us to the new (and improved) way. First of all, put down the notebook. Unless you’ve got a basement full of potable water and canned food and are just waiting for Skynet to pull the trigger, there’s no reason not to track your issues electronically. Once you’ve done that, we can move on to the next steps.

1. Choose an Issue Tracking System

There are a few choices here. The key is to opt for something that is web-based. Giving multiple people access to a database of issues not only simplifies the ability to create issues and add them to the queue, but it also gives project managers and sponsors the ability to prioritize a single list of defects and either assign them to developers or allow the developers to claim defects to correct. This way, anyone interested will know which defects are being worked on, and which have yet to be addressed.

There are a number of choices that fall into three separate categories, when it comes to tracking system options:

2. Hire Actual Testers

Developers have a knack for overlooking or explaining away issues they introduce. Spending all of your time in a development environment can often lead to a “that’s just the way it is” mentality. Having someone separate from the development process actually review and test the course, as it’s developed, can reveal issues that would otherwise be overlooked.

In an e-Learning development house, you should have two types of quality assurance (QA) engineers. One should be specialists in the course content. Typos are bad enough, but presenting information that is false is the fastest way to lose credibility in your chosen profession. Having an expert review your course content early will ensure that all information presented is accurate.

On the other end of the spectrum, you need people experienced in testing software. These people need to test the interfaces and the interactions, to ensure they all behave as expected as the code is developed. If you wait until the end, you may find a significant list of defects.

An added benefit of these QA engineers is that they can test your course content in another way. It’s one thing to have your coursework approved by an expert, but ensuring it’s palatable to a general audience is another.

Catching issues and defects as well as verifying course content is as important to do early and often as any other aspect of development. Putting down the lined paper and logging into a sophisticated project management system will ensure that the course you publish and deliver will be the best it can be while maintaining the confidence in your authority that learners expect.