What does conformance testing mean?
A SCORM test suite checks whether content, or an LMS, follows the SCORM specification. ADL, which maintains SCORM, published conformance test suites for SCORM 1.2 and SCORM 2004. They test manifest validity, the order and correctness of API calls, and data model usage. Passing proves the package follows the specification, not that it works everywhere.
Conformance is a narrow, precise claim. It means that when the package is checked against the rules written in the specification, it breaks none of them. That is valuable: a conformant package has a valid manifest, calls the API in a legal order, and writes values the data model allows. But the specification leaves room for interpretation, and LMSs fill that room differently. Conformance testing measures the package against the rulebook, not against any particular LMS.
Both sides of the SCORM conversation can be tested. Content testing checks packages and SCOs. LMS testing checks that a platform implements the runtime and sequencing correctly. If you build courses, the content side is the one that concerns you.
What a SCORM test suite checks
A content conformance test works through the package in layers, from structure to behaviour:
| Layer | What is checked | Typical failure |
|---|---|---|
| Package | imsmanifest.xml is at the root, is well-formed XML, and validates against the schemas for its declared version | Manifest inside a subfolder; missing or mismatched schema files |
| Manifest references | Every href and identifierref resolves; identifiers are unique | Launch file renamed after the manifest was written |
| Runtime | The SCO finds the API, initialises once, and terminates or finishes the session | No terminate call; a second initialise in the same session |
| Data model | Every element read or written exists, is used in the right mode, and holds a legal value | Writing a read-only element; a status value the version does not allow |
| Sequencing (2004) | Sequencing rules in the manifest are valid and consistent | Rules that make an activity unreachable |
The runtime checks work by launching each SCO inside a test harness that provides its own API object and logs every call the content makes. The harness then compares the log to what the specification permits. That is why test suites catch errors no learner would notice: a call that returned "false" but that the content ignored is invisible on screen and obvious in the log.
Conformant is not the same as working
A package can pass every conformance check and still misbehave in your LMS. The common reasons are not failures of the specification but gaps in it:
- Launch differences. LMSs open content in frames, new windows or embedded players. The specification allows all of them, and the API can end up somewhere the content did not expect.
- Commit and timing behaviour. Some platforms throttle or batch saves. A course that is legal in every call can still lose its last write.
- Interpretation of status. Platforms differ in how they combine completion, success and score into the result an administrator sees.
- Enforced limits. Platforms handle over-long values differently: some reject them, some truncate them silently.
- Edition support. An LMS that accepts SCORM 2004 may implement sequencing less fully than the test suite expects.
The platform-specific failures are listed in SCORM not working in your LMS, and most of them can only be found by testing on the platform itself.
Lighter checks you can run yourself
The formal test suites are thorough but heavyweight to set up and run. For day-to-day work, most of their value comes from a few lighter checks:
- Schema validation. Validate
imsmanifest.xmlagainst the XSD files for its declared version. Any XML validator can do this, and it catches the structural failures in the first two rows above. - Reference check. Confirm every file the manifest names exists in the zip with matching capitalisation. Many servers treat
Index.htmlandindex.htmlas different files. - Runtime call log. Launch the package in any player that logs API calls and return values. Read the log for one initialise, legal writes, a commit after the final status, and a terminate.
- Resume test. Exit half way, relaunch, and confirm the bookmark and suspend data came back intact.
Together these catch most of what a full conformance run would find, in minutes rather than hours.
A sensible testing order
Run the checks from cheapest to most expensive, and stop to fix problems as soon as one appears:
- Validate the manifest and its references.
- Launch with a call log and read it end to end.
- Complete, exit and relaunch; then exit half way and resume.
- Run a full conformance test suite if a contract or platform requires formal evidence.
- Test on the destination LMS with its real launch settings before learners see the course.
Step five is the one most teams skip and the one that catches the most surprises. A step-by-step version of the first three is in how to test a SCORM package before the LMS does.
Where SCORM Central fits
SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.