Test profile - A key to customized and efficient content validation

To estimate the benefits of Truugo validation service, one should first get familiar with how it streamlines your validation process and how it helps locating and reporting errors.

Test profile

A test profile is a concept used for chaining a number of operations to verify that an uploaded message fulfills its predefined requirements. It enables bundling of separate tests to produce just one combined test report. A test profile consists of three parts: preprocessing, test phases and visualization.

Test profiles can be defined into various needs:

Standard:
General requirements specified for a message format by a standardizing party.
User community:
Additional requirements specified for a use of a message format by a user community.
Organization:
Detailed requirements specified for a use of message format by a receiving organization.

1. Preprocessing phase

A test profile may contain any number of preprocessing phases which are performed to format a message before a 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 may consist of any number of test phases. Each executed test phase returns either "passed" or "failed" status. Each test phase is either based on a schema (DTD or W3C XML Schema) or a test assertion set containing any number of related test assertions.

A criticality factor is assigned to each test phase. It defines how possible "failed" status impacts on a test execution and to a 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 instruct about best practices or to proactively inform about becoming requirements.

Test assertion

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

Test assertions can be divided on a rough level into four categories (below description and example of each):

Data cardinality:
A message schema contains virtually without exception some optional data which is mandatory in practice. These gaps must be filled with test assertions.
"Invoice contains a due date."
Data format:
Some simple data format constraints can be specified on a message but all in all its level of expression is very limited. For example many identifiers contain computational check digits which can't be checked by a schema. It's also common that a message format supports a generic method for stating an identifier where identification scheme is provided as a qualifier (XML attribute). This kind of data relationship cannot be checked a message schema but a test assertion is required.
"Legal business is stated in a format nnnnnnn-n, where a last number is a computational check digit."
Allowed codes:
Use of coded data values is a common practice in electronic data interchange. Message schemas are usually defined by standardizing party containing number of codes not supported by a certain industry or a receiving organization or whole enumeration is specified on an industry or an organization level. A test assertion can be used for specifying a set of codes which are appropriate in each use case and thus a standardized message schema can be used as such.
"Country code is specified according to ISO 3166-1 alpha 2 enumeration where, for example, Finland is presented with a code 'FI'."
Data integrity:
Message schemas are lacking ability to describe data dependencies and relationships. In other words it's not possible to describe a technical constraint or a business rule using a message schema but a test assertion is required. 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."

It's also possible to specify a precondition for a test assertion to match even complex requirements. A test assertion will be executed only if a given precondition is fulfilled. Thus it's possible to cover a number of use cases with a single test profile by using preconditions.

3. Visualization layout

Message visualization may be provided as a supplementary tool for interpreting a test report. For example, one may provide a document layout for visualizing an invoice as a "paper format".

Next article: Test report - A formal and sensible feedback