4.2.6 Test Process

When the deployable policies are in place at the local policy repositories, they will be tested. This process is necessary because dynamic runtime-constraints may be overlooked in the refinement process. The already existing policies at the local repository are in most cases also not considered during the development and refinement of a high-level policy. Even the compliance with a (technical) standard (e.g., ISO 900x) or law may entail detailed testing and logging of the results.

The test process may retrieve policies from other local policy repositories, as shown in figure , for instance when there is a chance that the new policy interferes with them.

As mentioned at the beginning of this section, it is not necessary that each process is implemented by a separate computer process. So, the test process may use functionality of the enforcement process, or be actually the same component as the enforcement process. In this case, the enforcement process would just work in a testing mode, which is switched to real enforcement when the testing is done. When a policy has passed all tests, it is marked as ``ready'' for the enforcement. The policy can now be activated by the enforcement process.

When the test process encounters a problem which restricts the enforcement of the new policy, the test process either notifies the refinement process, or the delegation process, or both. This depends on the local practice and on the problem. The notified process has to take actions to solve the problems occurred. Until then the policy will not pass the test process.

At present little is known about testing and ways to efficiently carrying out tests. It seems that the test process must be highly customised for different sets of policies, or in worst cases for every policy in a particular environment. This may be necessary, because a policy can be integrated in various kinds of (dynamic) environments.