How to test a SCORM package before publishing it

To test a SCORM package, run a real learner attempt and inspect the data after each state change. Importing the ZIP without an error proves only that the importer could read enough of the package to accept it. It does not prove that resume, completion, score or question responses work.

Use a neutral SCORM player first, then repeat the same script in the production LMS. That split tells you whether a failure belongs to the package or to platform configuration.

Start with two test packages

Keep two controls available:

1. The package under test.
2. A known-good package that already reports correctly in another conforming player.

If both fail in the target LMS, inspect the LMS settings and launch environment. If only the new package fails, inspect its manifest, resources and runtime calls.

Rustici provides a sample SCORM 2004 golf course from its SCORM Cloud import tutorial. Use a sample that matches the standard you are testing; a SCORM 2004 control does not prove that an LMS handles SCORM 1.2 in the same way.

Check the ZIP before opening an LMS

Inspect the archive without extracting and rezipping it. Confirm:

• imsmanifest.xml sits at the root;
• the manifest is well-formed XML;
• its launch href points to an existing file;
• every file referenced by the manifest exists with matching case;
• URLs use forward slashes;
• the standard and schema version match the runtime code;
• the ZIP contains no parent folder wrapped around the whole package;
• file names avoid characters the target LMS rejects.

A manifest can be valid XML and still be wrong. Check that the organization points to a resource, the resource identifies a SCO where appropriate and the launch file loads all scripts, styles and media from relative paths that exist inside the archive.

Test import in SCORM Cloud

SCORM Cloud's user guide supports SCORM 1.2, SCORM 2004, xAPI, AICC and cmi5 packages. Its course Sandbox allows repeated launches, and its debug log exposes the runtime exchange between content and player.

Import the ZIP and record every parser warning. A warning may be harmless, but it should never be unexplained. Launch the course through the Sandbox rather than opening a file from the extracted archive.

Attempt 1: launch and interrupt

Run this script with a new learner registration:

1. Start the course in normal attempt mode.
2. Open the second or third lesson.
3. Answer one question if the course contains interactions.
4. Wait long enough for any periodic commit to run.
5. Close using the course's exit control, then close the player window.
6. Open the same registration again.

Expected result:

• the initial status changes from not attempted to incomplete;
• the previous location or state is restored;
• elapsed session time is present;
• the attempt does not duplicate itself;
• the debug log contains successful initialize, set, commit and finish or terminate calls.

Also close the browser tab once without using the course control. This is not the ideal learner path, but it exposes whether unload handling loses the final commit.

Attempt 2: complete with a passing score

Choose an answer pattern with a result you can calculate before starting. For example, 6 correct answers out of 8 should report 75 on a 0 to 100 scale.

Finish the course and check:

• the reported completion and success values match the course rule;
• raw score is exactly 75 in the example above;
• minimum and maximum score describe the same scale;
• the pass or fail result matches the configured threshold;
• total time increases after the session ends;
• the interaction report contains eight question records if answer-level tracking is promised;
• each recorded response and result matches the chosen answer pattern.

Do not use random answers for this test. A known pattern turns an unexpected grade into a reproducible defect.

Attempt 3: fail, retry and review

Create a failing result on purpose. Confirm that the LMS distinguishes failed from incomplete and does not award completion through a conflicting LMS rule.

If multiple attempts are allowed, start a new attempt and pass it. Check whether the gradebook stores the first, last, average or highest result according to the LMS configuration. Moodle exposes this choice under Attempts grading.

Open the finished attempt in review or preview mode. Preview should not silently create a graded result. Moodle's SCORM settings document notes that an activity completed in preview is marked as browsed rather than handled as a normal graded attempt.

Test the browser layer

Runtime data can be correct while the course is unusable. Test:

• current Chrome, Edge, Firefox and Safari if your audience uses them;
• a narrow mobile viewport;
• keyboard-only navigation;
• visible focus and logical tab order;
• captions, transcripts and alternative text;
• zoom at 200 percent;
• long translated labels;
• blocked popups when the LMS launches in a new window;
• network requests for missing files;
• browser-console errors.

The LMS often places SCORM inside an iframe. Test the package there even if its standalone preview is responsive.

Repeat the script in the target LMS

Import the same ZIP into a staging course on the target LMS, configured to mirror production. Use a learner account and repeat all three attempts. When the target is Moodle, the activity, grading and attempt settings that affect this comparison are covered in the guide to uploading SCORM to Moodle and verifying completion tracking. Compare:

SCORM interoperability includes LMS configuration. Moodle, for example, lets an administrator alter standard-mode data limits, auto-commit behavior and mastery-score handling. Record those settings with the test result.

Release checklist

Publish only after every required item has evidence:

• ZIP imports without unexplained errors.
• Launch file and all resources load over HTTPS.
• Normal attempt initializes the SCORM API.
• Interrupted attempt resumes correctly.
• Completion fires at the intended condition.
• Known answer pattern produces the expected score.
• Pass and fail both work at the threshold boundary.
• Question interactions reach the report where required.
• Session closes with one finish or terminate call.
• New attempt, review and preview modes behave as configured.
• Keyboard, zoom, mobile width and supported browsers pass.
• The same script passes in the target LMS's staging course.

Attach the package hash, LMS version, activity settings and test date to the release record. When a platform update changes behavior later, those four details turn "it used to work" into a comparison you can investigate.

Need a fresh package for the checklist? Build a SCORM 1.2 course in Course Builder, then run the downloaded ZIP through the three attempts above. If the lessons are not written yet, you can first draft the course with ChatGPT and export it as SCORM 1.2.

Reference documentation

• SCORM Cloud testing and debug logs
• SCORM Cloud sample course import tutorial
• Moodle SCORM activity settings
• SCORM run-time reference