Help TOC > Instructions for DEX developers > DEX testing
DEX testing Date: 2010/02/10 16:56:25
Revision: 1.8

DEX testing

This document focus on the need to establish a framework for testing that supports the overall objectives of the PLCS Technical Committee of OASIS. This will apply to different targets,

Quality checks applied to Capabilities

This quality check relates to the definition of a complete capability, which is,

When DEXs using the Capability has reached Level 2 and Level 3 there is higher levels of quality for this Capability. This should be reflected in a master listing of the Capabilities.

Testing applied to the DEXs as deliverables

The testing of DEXs as deliverables relates to the definition of a completed DEX. The completeness of a DEX is divided into four (4) levels,

Level 1 - Drafting the DEX documentation

Level 2 - Testing by mapping

Level 3- Testing by exchange

Level 4 - Published

Testing applied to example data sets

The availability of test data sets is vital in establishing a critical mass of software implementations. It is important that such data sets are published in support of the formal DEX documentation and developed in conjunction with the DEX. (The development of test data sets provides necessary feedback on the DEX and its documentation). Data sets may be presented in a variety of formats,

It is anticipated that data sets will fall into two major categories,

Independent of format it is suggested that the following criteria are applied,

All of the above criteria merit further explanation and expansion. Data sets that meet the above criteria should be made available through a version-controlled repository.

Testing of software implementations

The following types of testing could apply to software implementations,

Of these, interoperability testing is the closest to the desired business functionality. Conformance testing also merits further consideration it that it can be used as the basis for a certification program, allowing vendors of software implementations to support their claims. Given that, at the time of writing, there are very few implementations that could claim conformance and AP239 has yet to complete DIS balloting, it is reasonable to treat development of testing processes for implementations as a lower priority