“A stitch in time saves nine”, one of those classic old sayings that defies social, technological and spiritual upheavals and constantly rings true. Unlike “You want to have your cake and eat it too” which never made any sense to me because what is the point of cake if you cannot eat it, but I digress.

The concept of a little preventative action early on, allowing us to avoid lengthy, costly, frustrating and embarrassing re-work down the track. This is a concept that applies directly to eLearning development too and for eLearning development our stitch in time is testing.

elearning developmentThis testing falls under a number of banners, testing whilst we develop, testing once the content piece is complete and testing when we receive SME or client changes. Lets explore each of these periods in the development of piece of eLearning and take note of what you need to check at each stage.

Testing whilst you develop

It seems like a bit of a no brainer but the easiest way for you to save time and stress whilst you develop your elearning content is to constantly test your content as you build, with special focus on:

  • Timeline based animations – Are they happening at the correct time, for the correct duration and with the correct entrance and exit settings. Also if you have multiple items are their timelines synced correctly with one another or with the slide audio.
  • Layers – Do they appear and disappear at the correct times or actions, do they have correct information, are the layer timelines correct.
  • States – Are any programmed object states displaying at the correct time or with the correct user action, are the states consistently applied, do the states automatic triggers get overridden by other manual triggers.
  • Triggers – Are the triggers firing where, when and how they are supposed to fire, do the triggers contradict one another, are the triggers in the correct order (especially important when dealing with variables)

You can see from the above that whilst you are in development mode there are many items to check to ensure they are working. You can seriously improve this to check processes however by checking each function as you build it e.g if you build a trigger to update a variable when the timeline starts on a slide:

  1. Insert a text box on the slide
  2. “Reference” your variable into that text box
  3. Insert Tab/Reference (Next to the Text Box button)/ Select the variable to be referenced/Click OK
  4. Preview the slide
  5. You should see the referenced variable change when the timeline starts

Apply this rule to all of your development so that you build one piece then test, then build then test. If you adopt this approach any errors will present themselves on the stop and you won’t have to go searching through timelines, states, layers and multiple triggers to find problem.

Testing once the content piece is complete

So you have tested each of your design and interactive ideas whilst you have been developing however there are certain items that you cannot test in the preview mode.

Some of the main items that you cannot preview are:

  • Links to external URL’s
  • JavaScript
  • Completion and scoring concepts
  • Player functionality

To test these items it is a simple process to Publish your content and then run it through a browser to check Links, JavaScript and Player functions. If you have a piece of content that requires the testing of completion and scoring, one of the best places to test is in the SCORM Cloud. https://cloud.scorm.com/sc/guest/SignInForm  This site allows you to create an account, then upload your SCORM packages, check the functionality then get an immediate report on what the content is passing back.

It’s also a really good idea to take notes as you develop of items that you cannot test in preview, this gives you a target list when you do publish and review your content from a browser or the cloud.

SME or client changes

Finally, testing when our clients and/or SME’s come back to us with their change requests. It is so easy to make a simple change and then to expect it to work without checking to make sure it does e.g. the SME sends you a new link for the users to access when they click a button on screen, so you change the URL in your trigger. If you do not test this in a browser afterwards it would be quite embarrassing if the link does not work when you send the changes back.  Also it provides another opportunity to test the link supplied is correct. So even the smallest change should always be tested.

So in summary then. Test whilst you build, test when you have built, test both of these again when you change your content.

Ben Saunders About Ben Saunders
For the past 10 years Ben has been immersed in the world of learning and communication (and training and development), from planning and design to build and implementation, from both the client and vendor perspectives. His experience bridges the gaps between business expectation, technology and learning theory, importantly this allows Ben to translate and articulate business needs into defined learner outcomes. He has experience with various LMS implementations including Moodle, Docebo, Plateau, SABA, DOTS as well as bespoke solutions. Ben is a Solutions Designer and Certified Articulate Trainer with B Online Learning.