Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Deployment Toolkit - Test Plan

Test Plans Overview

Planning is essential to successful testing when numerous parties are involved. The test needs careful orchestration and for each of the actors involved to know the plan and their roles and resposibilities within it.

This section will outline the precursive setup and management steps, the actors involved and provide an example of what to expect of a typcial Test Run.

Types of Test

In the process of building a solution a supplier will be involved in several phases of testing, progressing through different maturity levels and environments -

  • Like-Live (INT)
  • Provider (Production)
  • Business Go Live

Test Plans must be adopted for testing on any of these environment. However, there are circumstances where testing could occur on INT in isolation, without the paraphernalia of a full Test Plan. For example, when a supplier is initially deploying and configuring their solution and testing against other suppliers who are already deployed and assured.

Roles & Responsibilities

The actors from the numerous parties must know what is expected of them during a planned test. This ensures the test has the best chance of success and valuable time is not wasted through trial-and-error attempts.

Actors

There is a requirement to cover these core roles for any level of planned test. There may be others involved or some individuals may perform multiple roles.

Organisation Expertise Individual Role
NHS Digital Booking Delivery Manager
NHS England (regional) DoS Configuration Lead
Supplier (Software solution*) Consumer (software) Technical Support
Service Provider (e.g. 111 Provider) Consumer Project Lead
Service Provider (e.g. 111 Provider) Consumer System User
Supplier (Software solution*) Provider (software) Technical Support
Service Provider (e.g. ED) Provider Project Lead
Service Provider (e.g. ED) Provider System User

* Potentially the same organisation. Some suppliers have developed both Booking Provider and Consumer functionality.

Prerequisites

The solutions deployed with in any of the environments must be configured and checked prior to the test taking place.

The list of prerequisites outlined assumes a supplier is starting from the beginning and not worked on similar projects in the past.

Both Service Systems (Provider & Consumer)

  • Certificates obtained and installed – Provider & Consumer
  • Connected to INT – Provider & Consumer
    • ASID supplied for connecting system/service
    • Interactions for ASID assigned via SDS
  • Software upgraded to appropriate version
  • Software configured to support functionality
  • Users with appropriate system access and knowledge to perform and verify functionality, including

Provider

  • Confirm Booking endpoint is running and accessible (firewalls updated)
  • Confirm Referral endpoint is running and accessible (firewalls updated)
  • Slots added to Schedule configured on the DoS or alternative Service Discovery Tool

Consumer

  • Access to DoS or alternative Service Discovery Tool
  • Local configuration of firewalls/ports to make requests of spine services (SSP/SDS)
  • Identify PDS traceable patient

DoS

  • Service for Provider system configured
    • Scheduling Endpoint configured
    • Referral Endpoint configured
    • Optional ‘requirebooking’ attribute added and set to TRUE
  • Note following supported by service to assist Consumer
    • Age range
    • DX code
    • Opening Times

Test Plan Management

Pre test -

  • Arrange the meeting date agreed by all
  • Provide contact details for -
    • DoS Lead
    • Software Supplier - Product Lead
    • Consumer service - Project Lead
    • Provider service - Project Lead
  • Share Test Plan with all key stakeholders, including
    • DoS Service(s) to be utilised
    • PDS traceable patient
  • Verify all parties have completed the prerequisite steps

Post test -

  • Brief review of test, stating sucess or failure
  • Document actions and any next steps

Test Run

The steps below outline a typical test run but the agreed Test Plan should be adhered to.

The recording of the session as a whole or snapshot of screens and log data should be taken where appropriate to verify functionality (especially, if being submitted for the SCAL) or recording error data for later investigation.

Steps in the test -

  • Consumer system performs triage/consultation resulting in appropriate outcome code to make request of DoS Service
  • Perform Service Discovery (DoS or alternative)
  • Selects configured DoS service
  • Selects option to initiate request for Slots
  • View available slots
    • Indicate where no slots are available to user
  • Confirm slot data offered by the Provider is reflected on the Consumer system
  • Verify slots outside of outcome code timeframe adhere to user type (Clinical/Non-clinical) requirements
  • Select slot
  • Request booking
    • Indication Booking has been made
  • Confirm booking exists in the Provider system
  • Send referral
  • Verify referral (supporting document) exists and marrys up to booking (Provider System)
  • Triage/consultation complete
  • SMS transferred to patient

Additional test within Consultation

  • Verify user is able to change the booking
  • Verify user is able to cancel the booking

After triage/consultation

  • User is able to cancel booking outside of triage/consultation window

Test Plan Resources

Here you will find some links to testing files that will be useful for providers looking to perform end to end testing prior to go-live:

Here you will find some links to testing files that will be useful for suppliers looking to perform product assurance:


All content is available under the Open Government Licence v3.0, except where otherwise stated