Test profile - A key to customized and efficient content validation

The key to understand the benefits of Truugo, is to understand how it helps to speed up validation process and to enhance data quality.

Test profile

A test profile is our concept for chaining a number of validation operations seemlessly together. It enables complete message validation, both structure and content checks, at once.

Test profiles can be created for outgoing and incoming messages. For outgoing messages it helps to ensure that implementation & documentation are aligned especially after system/version updates. For incoming messages it helps to provide an enhanced message validation as a self-service for senders (trading partners).

Test profiles should be created on various levels to ensure maximum interoperability:

Standardizer:
Requirements common for all users of a message format.
Industry:
Additional requirements common to a user group.
Organization:
Detailed organization specific requirements, usually published by the receiving organization.

Technically a test profile consists of three parts: preprocessing, test phases and visualization.

1. Preprocessing phase

A test profile may contain preprocessing phases which are performed to format a message before validation. General preprocessing phases are for example unwrapping of a message envelope and pretty-printing of a message to assign a unique line number for each element.

2. Test phase

Validation consists of a number of test phases. Each test phase is based on a schema (DTD or W3C XML Schema) or a set of test assertions.

Each test phase has a customizable "importancy" parameter which defines how validation errors affect on test execution and final test result:

Critical:
Must be passed to continue validation any further.
Mandatory:
Must be passed to pass a whole validation acceptably.
Recommendation:
Informative test phase to inform about best practices and forthcoming requirements.

Test assertion

A test assertion is a requirement specified either for a message structure or content. If there exists at least one test assertion which is not passed, a test phase returns a "failed" status. Test assertions are used to fulfill requirements not covered by a message schema. Number of test assertions required varies depending on a desired level of accuracy and a scope of a message format.

Test assertions can be divided roughly into four categories (below description and example of each):

Data cardinality:
A message schema contains usually optional data elements which are mandatory in practice. These gaps must be filled with test assertions.
"Invoice contains a due date."
Data format:
Simple data format constraints can be specified on a DTD/XSD schema but its expression power is very limited. For example, many identifiers contain computational check digits which can't be checked by a schema. It's also common that message formats support a generic method for stating an identifier where identification scheme is provided as a qualifier (XML attribute). These data relationship cannot be checked using a schema but are easily implemented as test assertions.
"Legal business ID is stated using a format nnnnnnn-n, where a last number is a computational check digit."
Allowed codes:
Use of coded data values (codelist / enumeration) is a common practice in electronic data interchange. Message schemas can be used to specify a full list of acceptable codes where as test assertions can be used to specify valid codelist subsets for each context.
"Country code is specified according to ISO 3166-1 alpha 2 and valid codes are 'FI', 'DE' and 'FR'."
Data integrity:
Message schemas are lacking ability to describe data dependencies and relationships. The most common integrity checks are related to computational sum checks and rationality of dates.
"A total VAT amount specified in an invoice summary matches a sum of VAT amounts on each line."

Preconditions can be specified for test assertions to match complex requirements. A test assertion is executed only when a precondition is fulfilled. Preconditions make is possible to cover a number of scenarios with a same test profile.

3. Visualization layout

Message visualization/simulation can be added to e.g. visualize an invoice message as a "paper format". This can be provided as a supplementary aid for detecting errors.

Next article: Test report - A formal and sensible feedback