Skip to end of metadata
Go to start of metadata

This document describes the tests that (aspiring) participants should 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. It is the responsibilty of the (aspiring) participants to demonstrate interoperability and to create trust and confidence with the other participants related to their implementation. 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.

The (aspiring) participant contacts the Beheerorganisatie when ready for executing chain test and for readiness of production go-live.  The (aspiring) participant must proof  their readiness to the BO by means of a demonstration of the functionality and a presentation of the testproces and results.  Based on the outcome of this proof, it is determined whether or not technical issues are remaining which should be solved before joining. 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