distributedlife

Technical Compliance

Technical compliance is the assurance that the data being sent is valid with respect to a previously agreed schema. If we are using XML to transfer to your data, this would be an XSD.

On the sending side of the solution, as a tester you would be responsible for ensure that all content generated by the source system can be represented by the schema. If it can’t you either need to get the schema changed, to not send the content, or to send the subset of the content.

On the receiving side of the solution, as a tester you need to ensure that all valid representations of the schema are accepted by the target system without error.

Technical compliance is a standard systematic testing processes. Technical compliance testing can also by automated.

Semantic Compliance

Semantic Compliance is the assurance that the data being sent has the same meaning to users of both systems. This is achieved by ensuring that an agreed data dictionary exists in advance and accurately documents the meaning of the content.

Semantic compliance is a lot harder to test, is tested at two different stages of the software development life cycle and cannot be automated. Initially, as testers, we should work with the business analysts to ensure that the requirements document specifies that the information being published adheres to the data dictionary. This is not trivial. A good understanding of the business domain is required as well as frequent consultation with the users to ensure the semantic compliance is achieved as early as possible.

The second phase of semantic compliance occurs at the same time as technical compliance is being tested. We need to ensure that when the content from the source system is being displayed in the target system, that the original context of the content is preserved.

Architecture and the impacts on testing.

Semantic compliance becomes even more complicated if you are exporting your source content to multiple systems without going through a consolidated data repository first.

Consider the following diagram. Your content is being provided to more than one system.

As such you need to ensure that your content is being represented correctly in each system. While they may all comply with the data dictionary, the target systems may be presenting content in their own way. As such you need to confirm within each system that both semantic and technical compliance is occurring.

Consider the next diagram. Each system is both providing and consuming content to a central repository.

This is easier to test than the previous system. Each system still complies with the technical schema and semantic data dictionary. Each system is required to ensure that their data remains its meaning within the central repository and that the data sourced from the central repository has its meaning preserved. As such we can leverage this to logically state that as all data that reaches the central repository must conform both semantically and technically. Therefore we don’t need to ensure that the other systems, that may in external organisations, represent our content correctly. They have to if they represent their own.