ZOOM STEERING OF THE IMPLEMENTATION: COMPLIANCE CONTROL TESTS   [return to "Risk Management"]

Compliance tests are an essential part of the steering of the implementation of a system, risk reduction measures, a deployment, etc.

 

1. Test strategy

 

A complete test strategy is applied in all the steps of a project:

  • during the conception – when compliance aspects have to be taken into account

  • during the deployment, the production or the implementation – then it is quality control

  • during the SAT (Site Acceptance Test) – and if possible already during the FAT (Fabric) – for the performance, fitness for duty, compliance of the interfaces, etc. controls

  • during the operational life span of a system: as an example, the maintenance services can be tested to control if the contractual clauses are effectively respected and if is not the case, implement the contractual payment penalties agreed upon in the SLA (Service Level Agreement

  • if an existing system has to be replaced, non-regression tests are necessary, particularly for third party systems and services

 

In some cases, only some steps are necessary, but the reception tests at the end of the works are the minimum because they validate the quality of the carried-out work and insure that the contractual requirements have been respected.

 

In order to deploy the test strategy that will be used for each step, it is naturally necessary to define it right from the beginning of the project.

 

 

2. Scope of the tests [return to "Risk Management"]

 

The scope of the tests is contractually defined. The contract determines which specification will be tested during which step of the operation life of a system. The specifications usually define the scope of the tests and are mentioned in the tender.

 

Each specific requirement can be controlled by one or several tests. A traceability matrix permits to link, for each step of the operational lifespan of the system, the requirements and the tests. It also permits to check if there is no orphaned requirement – i.e. a requirement that will not be tested. Here again the concepts of testability – capacity to be tested – and discernibility – capacity to identify unequivocally the origin of a defect based on the results of a battery of tests – can be found.

 

This is why it is so important to define the test strategy right from the beginning, because the test strategy can influence the conception of a system, as the testability concept sometimes needs to integrated in the conception.

 

 

3. Test methodology

 

The test methodology includes:

  • the basic standards that have to be followed during the execution of the tests: standards or norms, rules issued by the governmental authorities or the contractual agreements

  • the definition of the test equipment and, depending on the case, what data has to be used to make the tests

  • the definition of the expected test results as well as pass / fail criteria

 

If more than simple visual verifications are needed, test specifications (test cases or test scenarios) define the methodology that will be used and serve as secondary standards for the controls.

 

 

4. Responsibilities

 

In this context, the word “responsibilities” defines „who does what“ in terms of controls and tests. This applies to making the required equipment available, the tests in themselves and the exploitation, as well as the safekeeping, of the (deliverable) test results.

 

 

5. Documentation

 

All the documentation that defines and traces the executed (deliverable) tests that are done on a system during each step are an integral part of the system and accompanies it during its whole operational lifespan.

 

[return to "Risk Management"]