Skip to end of metadata
Go to start of metadata

This document describes the tests that (aspiring) participants must perform.To ensure that new releases and the application process of participants go smoothly, it is required that new functionality or systems are tested thoroughly before taken into production. This document distinguishes Simulator test cases and Chain test cases. The simulator tests are executed utilizing the Elektronische Toegangsdiensten simulator, an instrument for initiating requests and validating responses. Focus on these tests is conformity with the Afsprakenstelsel. Chain tests are executed in a separate network of systems, each in its own DTAP A-environment. During the chain tests, the focus is interoperability of all participants' systems.

Test cases are formulated and a check list is available on which the participants can document the test results. The Beheerorganisatie receives a filled in checklist before an applicant may join. Based on these checklist the Beheerorganisatie shall advice on the admission and/or period of the remaining trajectory. When all tests have been properly run, the Beheerorganisatie will continue to executing tests regarding the joining of the participant. These tests are basically a check on the validity of the self-declaration. The Beheerorganisatie uses the same test cases, the same testing network and the same test tooling. Based on the outcome of these tests, it is determined whether or not technical issues are remaining which should be solved before joining.

Testing native apps

Support for native apps through OAuth2 protocol is mandatory for ADs and MRs and optional for HMs and DVs. When a party supports OAuth2, the same test cases apply and where present both the OAuth2- and web-functionality should be tested. Tests for native apps only have to be performed for one version of the platform, e.g. in case of mobile apps only an iOS-version or Android-version of the native app, not both, on any device needs to be tested. For native apps using the OAuth2 protocol, the test cases for refreshing tokens SHOULD be completed.

This document describes the testing procedures for (aspiring) participants in the network. A Dienstverlener (DV) should contact their Herkenningsmakelaar (HM) for guidance on testing their implementation.

In case the Herkenningsmakelaar would connect a DV to the simulator or DTAP-A environments of other participants, the Beheerorganisatie does not support this. Furthermore, the Herkenningsmakelaar is liable for any damages or delays of other participants or Beheerorganisatie, inflicted by their service providers. During chain tests and implementations of new releases, an Herkenningsmakelaar should make sure that other participants or Beheerorganisatie are not affected in any way by their service providers.

Continue here

  • No labels