Testbed Taskforce - Testbed vision

Owned by Klaus Vilstrup Pedersen (Unlicensed)
Last updated: Jul 17, 2018
2 min read

Background

  • OO decision

Requirements


Vision (Philip)

Testbed Scenario.png

Building Blocks:

  • UI - Web/Portal/Registration
  • Orchestartion
  • AP administration interface
  • TB AP
  • Virtual TB AP with proxy endpoint
  • System Under Test (SUT)


GITB and ISA Testbed (Klaus)

Onboarding test - test of

Conformance test - test of a products level of conformance to specifications

Interoperability test - test of interoperability between products


Stage 1 - Scope

  1. Testbed Controller covers listed test cases and operates with a minimum of manual intervention
  2. Ability to verify compliance on a technical level in terms of the PEPPOL AS2 profile
  3. Ability to verify compliance on a technical level in terms of the PEPPOL AS4 profile
  4. Ability to verify compliance on a technical level in terms of the E-SENS AS4 profile
  5. Implemented as a web-based application with a self-service user interface. Self-identification based on PEPPOL test certificate based on PKI v3 is foreseen. Not open to everyone.
  6. Provide efficient and (best effort) scalable self-service Testbed on-boarding, for connectivity testing (not for Backbone AP integration)
  7. The main purpose of the Testbed from the viewpoint of the tester: to support developers and operations with manual processes
  8. The main purpose of the Testbed from the viewpoint of OpenPEPPOL: to check the maturity and verify the compliance of an onboarding entity
  9. The Testbed Controller is controlled (managed, maintained, operated and supported) by OpenPEPPOL operations.
  10. The Testbed Controller is being hosted by a 3rd party in a generic setup (provider) and implemented in a way to ensure minimal maintenance activities. SLA is mandatory between 3rd party host and OpenPEPPOL
  11. The Testbed should enable the usage of different PEPPOL compliant AP implementations (like Oxalis, ph-as2 ...) as Backbone APs. The same implementation can be available in different versions.
  12. The Testbed should produce a report with the result of executed test cases and which Backbone AP implementations were tested. It should be possible to assert the authenticity of the report.
  13. Testbed Controller implementation strategy should cater for scalability in scope and functionality
  14. A bullshit AP (naming (c) Anna-Lis) implementation must be created that sends out crappy documents without validation (for the negative tests)

Out of scope for version 1.0, in scope for a later version

  1. BIS document validation and content conformance
  2. SMP server onboarding test (SMP client is in scope)
  3. Local or regional requirements mandated by OpenPEPPOL Authorities.
  4. Having a history of reports sent out (in scope for future Implementations)
  5. Identify scenarios where a production certificate might make sense
  6. Handle specific HTTP header values appropriate (Connection header, special status codes, ....)

Out of scope forever (until management decides different)

  1. Hosting of 3rd party Backbone AP implementations on behalf of OpenPEPPOL are not considered as part of the Testbed operation