The CUSS Handbook  /  Certification and interoperability testing

Certification and interoperability testing

Certification is what turns a written specification into a usable guarantee. Without it, “CUSS compliant” would mean whatever a supplier wanted it to mean, and an airline would still have to test against every airport individually — which is the cost the standard exists to remove.

What certification asserts

The standard's certification arrangement ensures that platforms and applications follow the defined processes and specification, and verifies two symmetric claims:

• that a specific platform can operate multiple applications; and
• that a specific application runs on different platforms.

Both halves are necessary and neither implies the other. A platform that runs one airline's application flawlessly has demonstrated nothing about the next one. An application that works on the platform it was developed against has demonstrated nothing about portability, which is the only property that makes it worth writing to a standard in the first place.

The process is described as an independent, IATA-controlled one. Independence is the load-bearing word: self-certification by the party with a commercial interest in the result is not certification, and a deployment that accepts it has quietly reintroduced the integration risk it was trying to avoid.

What certification does not assert

It is important to be clear about the limits, because certified equipment is routinely assumed to have properties it has never been tested for.

• It is not an accessibility certificate. Conformance to the standard says nothing about whether a machine satisfies the legal requirements of the jurisdiction it is installed in. Those are separate, they are set by regulators, and in the United States they are prescriptive down to the level of tactile controls and speech output. See kiosk accessibility.
• It is not a security assurance. A certified platform still has to be deployed, networked, patched and monitored competently.
• It is not a usability finding. An application can be entirely conformant and still be one a passenger cannot complete unaided.
• It is not permanent. Certification attaches to a version. New platform releases and new application releases raise the question again, which is why the release process belongs in the service level agreement.

What gets tested

The detail lives in the published certification documentation — the CUSS toolkit includes a certification document template for exactly this purpose — but the shape of it follows from the architecture. Testing concentrates on the boundary between application and platform:

• Device abstraction. Does the application work against the interface rather than against a particular device? A common failure is an application that silently assumes a printer's behaviour on the platform it was written for.
• Lifecycle. Does the application take control cleanly, release it cleanly, and behave correctly when a session is abandoned or interrupted?
• Error and exhaustion states. Out of paper, jammed, offline, partial read, device present but unavailable. This is where most real-world failures live, and it is the part that is tedious to test and therefore tempting to skip.
• Isolation. Does one application leave anything behind that affects the next one? On a machine shared between competitors, this is not merely a hygiene question.
• Return to a known state. After any ending, good or bad, does the kiosk return to the launch screen ready for an unrelated passenger?

The effect of a machine-readable specification

The move to CUSS 2 changes what certification can practically do. The toolkit publishes the API and data model definitions in YAML, and an interface with a machine-readable contract can be validated automatically. That shifts a meaningful part of conformance testing from manual scripts to automated checks, and it makes continuous conformance — testing every release rather than every major version — realistic for the first time.

It does not remove the manual work. Nothing automated will tell you whether a passenger can complete the flow, and nothing automated will exercise a genuinely jammed printer.

Practical advice for buyers

Three questions are worth asking of any claim of conformance, and they are worth asking in writing.

1. Certified against which version? “CUSS certified” without a version is not an answer, particularly across the 1.x to 2 generational break.
2. Certified by whom? The value is in the independence of the process. Establish who performed it.
3. Certified with which counterparties? A platform certified against a broad set of applications, or an application certified across a range of platforms, is evidence of the portability you are buying. A single pairing is not.

These belong in the requirement document rather than in the evaluation conversation. See evaluating a common-use deployment.