SCORM Experts / Building it

Test on the system it will actually run on

A preview inside the authoring tool proves almost nothing.

Every authoring tool has a preview mode, and every preview mode runs the content without the delivery system that will hold it in production. That means the entire tracking layer, which is where most faults live, is simulated or absent. Content that previews perfectly can fail on import, fail to record completion, or fail to resume, and none of that is visible until it is on the real system.

The minimum useful test is a full pass on the target platform with a real test account: import, launch, complete, close, reopen, and then look at what the platform recorded. That is perhaps fifteen minutes and it catches the overwhelming majority of production faults.

It is worth keeping a permanent test area for this, with its own courses and its own test learners, rather than testing in a live category and tidying afterwards. Tidying afterwards is how test enrolments end up in a report, and how a half-finished course ends up visible to a cohort.

Where an organisation runs more than one delivery system, or is planning to change, the test matters more rather than less, because the whole value of using a standard is the portability, and portability that has not been demonstrated is a claim rather than a property.

Keeping a permanent test course also solves a problem that appears later, which is how to verify a platform upgrade. When the delivery system is updated, the question of whether existing content still behaves has to be answered somehow, and the practical answer is a small set of packages of known behaviour that are run before and after. Assembling that set once, from content you already understand, converts an upgrade from an act of faith into a check.