System test pack

Introduction

These guidelines assist participants through the system testing phase to ensure the required quality standards are met in preparation for acceptance into the PDP pre-production environment for integration testing.

The approach covers where system testing fits into the onboarding process, reference documents to be used in conjunction with the test pack, test script and test data high-level information, the benefits of using the Pensions Dashboards Programme (PDP) test harness, and the support process offered.

The test harness administrator guide, test harness testing guide, detailed test scripts including test data, test evidencing submission document and defect form will be provided as separate documents.

Downloads

Download system test pack materials

This zip folder contains:

• PDP VP system test cases v1.9.xlsx
• MaPS System Testing.postman_collection September 2024.json
• PDP system testing evidence v1.3.docx

Context

System testing for successful onboarding

The first phase of participant system testing will be based on technical standards v1.1.

Test scripts, test data and the test harness will all be based on the same version. There will be a requirement to perform additional testing against future technical standards and reporting standards, but these will be separate to this current system test phase.

This test pack will be used to assist participants with their testing development and test execution during system testing, a separate test pack will be issued for integration testing in the PDP pre-production environment.

Test phases

Participant testing and test execution within the connection journey

The system testing development and test execution phases performed in the participants own environments are supported by this test pack.

The process to support the integration testing phase within the PDP pre-production environment will be documented in the integration test pack.

1. Local development and unit testing.
2. System testing.
3. Pre-production connection.
4. Integration testing.
5. Operation acceptance testing.
6. Production connection.

End-to-end connection journey

Reference documents

Before embarking on system testing, participants need to be completely familiar with the standards documents:

1. Data standards.
2. Technical standards (including supporting JSON schemas and OpenAPI specs)
3. Reporting standards.
4. Code of connection.

Draft versions of standards can be found on the PDP website.

Test pack contents

Test cases

Test cases for participant system testing have been written against technical standards v1.1 and will be provided in a separate document.

The test case spreadsheet contains 7 work sheets:

• Document _CTRL: Document control listing the reference documents and versions used.
• PRE_TEST_SETP: Details the pre-test setup for the resource server and postman collection.
• TEST_CASE _STEPS: Lists the 30 test scripts detailing the test scenarios number, functional area, test name, pre-requisites, test data, test steps, expected results and the instructions to resource tester. The test script functional areas of find and view are broken down into 6 areas:
  • find request
  • validate the contents of the find request
  • persist find request
  • update match status
  • delete a resource
  • view request
• TEST_DATA_DETAILS: Contains the test data.
• VIEW_DETAILS_JSON: Details the view details for JSON.
• PUBLIC_KEY-JWT-SIGNATURE: Details the public key for JWT Signature.
• GLOSSARY: Glossary for all terms used in the test script sheet.

Test data

The participants will be supplied with the test data necessary to carry out the system tests. This takes the form of:

• A Postman collection, containing the find and view requests that will be sent to the resource server under test.
• A table of users and their identifiers. Participants will use this to set up data in the resource server under test so that the desired match is achieved by the resource server’s matching criteria when a find request is processed.
• An example of the view data that can be returned. It is not necessary to use this particular example; participants have the option of returning their own view data. What is important is that the view data for a possible match conforms to that part of the schema, and the view data for a full match conforms to that part of the schema.
• The public key for validating the signature in the user_token. This is supplied in 2 ways:
  • In the test case spreadsheet.
  • In the response for a GET request to the JWKS (/jwk_uri) endpoint of the MaPS test harness.

Postman collection

There are find (POST) requests supplied for test cases 1 to 20. These will also be used to provide prior matches for test cases 21 to 30 view (GET) request.