Testing
ID | S69 |
---|---|
Version | 1.0.2 |
Type | Overarching Standard |
Status | Effective |
Effective Date | Apr 11, 2023 |
Contracting Vehicle(s) |
Introduction
Ensures that Suppliers' software delivery test processes are of sufficient quality and rigour.
It is essential that Solutions delivered under the Catalogue demonstrate a high-quality approach to software development and testing. Within the area of software testing, there are various established Standards and many good industry practices in place.
This Standard does not seek to mandate adherence to a particular Standard, it does however, through compliance evidence, look to establish that an appropriate level of quality and rigour are in place with respect to software testing, with ISO/IEC/IEEE 29119 providing a reference point.
According to ISO, Standards are "Guideline documentation that reflects agreements on products, practices, or operations by nationally or internationally recognised industrial, professional, trade associations or governmental bodies". They are guideline documents, therefore not compulsory unless mandated. The Standards and external references within provide a clear benchmark for good industry practices which The Authority would expect a Supplier to follow. As such, they provide a guide to Suppliers on what level of quality The Authority expects from software development testing.
The International Software Testing Standard - ISO/IEC/IEEE 29119
An internationally agreed set of Standards for software testing that can be used within any software development life cycle or organisation:
ISO/IEC/IEEE 29119-1: Concepts & Definitions, published in September 2013
ISO/IEC/IEEE 29119-2: Test Processes, published in September 2013
ISO/IEC/IEEE 29119-3: Test Documentation, published in September 2013
ISO/IEC/IEEE 29119-4: Test Techniques, published in December 2015
ISO/IEC/IEEE 29119-5: Keyword-Driven Testing, published in November 2016
Within the context of the Catalogue, ISO/IEC/IEEE 29119 is used to provide a guidance checklist, used to establish Suppliers entering a Contracting Vehicle demonstrate quality within their software testing. Context and Risk-based Approach ISO/IEC/IEEE 29119 part 1 states "Software testing is performed as a context-managed process". It also states "A key premise of this Standard is the idea of performing the optimal testing within the given constraints and context using a risk-based approach". These statements stand true for almost any testing approach.
Requirements
Testing Requirements
Applicable Contracting Vehicle(s) | Requirement ID | Requirement | Level |
---|---|---|---|
All | TEST-1 | Irrespective of the Software Development Life Cycle (SDLC) implemented (traditional Waterfall to Agile), there will be organisational and project specific test processes underpinned by appropriate artefacts. Example evidence could include but not constrained to:
How are different types of testing either within a traditional SDLC or within Agile iterative-incremental development established, such as:
How testing automation is incorporated into the software build and distribution process, such as continuous build integration:
| MUST |
All | TEST-2 | There will be Test Management Processes covering test planning and design. Example evidence could include:
| MUST |
All | TEST-3 | There will be Test Management Processes covering test execution and management. Example evidence could include:
| MUST |
All | TEST-4 | There will be Test Management Processes covering test completion and Reporting. Example evidence could include:
| MUST |
Test Environments Requirements
Applicable Contracting Vehicle(s) | Requirement ID | Requirement | Level |
| TEST-ENV-1 | A Supplier whose Solution interoperates with the NHS national services (such as PDS, ePS, SCR, eRS, NHAIS, GPES, etc), or provides IM1 or GP Connect APIs, shall provide access to instances of production versions of their Solution(s), such as a Virtual Machine (VM) image, to be installed and maintained in The Authority’s test laboratory. Or alternatively, provide access to Supplier data centre hosted, or cloud-hosted versions, which allow multiple concurrency of connecting systems, such as API consumers for testing. In this context, the production version means a version of the Solution which is reflective of the Supplier’s LIVE estate for that Solution. Where a Supplier has multiple instances and version, the Supplier will provide access to the majority installed version. Note: All the requirements from TEST-ENV-1 to TEST-ENV-14 and LIVE-ENV-1 are required to support testing and assurance of central services, to aid interoperability testing for published messaging Standards, and the assurance of connecting Supplier Solutions. | MUST |
| TEST-ENV-2 | The Supplier must make access available to the latest version 5 days after release in live. If it is provisioned for installation by The Authority, then the software installation package must be accompanied with appropriate instructions for installation and the release notes for the release being installed. | MUST |
| TEST-ENV-3 | The Supplier shall provide access or provision installation any additional requested versions of its Solution(s) within 10 working days of The Authority’s request. These versions could either be compliant or versions for which compliance are being sought. | MUST |
| TEST-ENV-4 | The Supplier shall ensure that test instance(s) of their Solution version(s) (including APIs) which are undergoing assurance are hosted and accessible in their test infrastructure with connectivity to The Authority's 'Path to Live' test environments. This will support the testing and assurance activities of the Supplier's internal teams, The Authority and any third party system Suppliers. | MUST |
| TEST-ENV-5 | The Supplier must ensure that a non-functional test environment is available to do Volumetrics and Performance testing for their Solution. | MUST |
| TEST-ENV-6 | The Supplier shall support end-user organisations to aid training of their users on the Supplier Solution(s) with Spine connectivity, including all Core Messaging and CIS services, enabled through integration with the SPINE Training environments. | MUST |
| TEST-ENV-7 | The Supplier must ensure that their test environments support robust access controls (security features) both at Solution level and Infrastructure level so that only authorised users and authorised external connecting Supplier Solutions can access the test environment. | MUST |
| TEST-ENV-8 | The Supplier must ensure that the test environment(s) availability times and any scheduled downtimes for maintenance activities are made known to all the external connecting Solution Suppliers and The Authority accessing the Supplier hosted test environment. Any changes to the known availability times or scheduled downtimes should be communicated to the Suppliers and The Authority at least two working days in advance. It is acknowledged that there might be compelling reasons in certain circumstances to perform maintenance activities outside the scheduled slots. | MUST |
| TEST-ENV-9 | The Supplier must either provide appropriate Solution test data (including Patient clinical data) in their test environment(s) to aid testing of the external connecting Solution Suppliers and for The Authority to do assurance activities, or when provided by The Authority, the Supplier must preload any provided test data (such as PDS test Patients). If specified by The Authority, the Supplier must ensure Patient test data meets a minimum set of clinical data. The test data must contain Synthetic Data only. It must not contain any sensitive or personally identifiable Patient data. The Supplier must ensure that any maintenance releases/emergency patches deployed to their test environment does NOT erase any of the existing test data as this might adversely impact any ongoing testing. | MUST |
| TEST-ENV-10 | The Supplier shall ensure that the test environment is able to support concurrent testing by multiple external connecting Solution Suppliers. The Solution test data must be discrete for each external connecting Solution Supplier such that they can test independently of others. | MUST |
| TEST-ENV-11 | The Supplier shall support backup and restore functions, to allow restoration of the test environment(s) back to the original clean state or a previously backed-up state. | MUST |
| TEST-ENV-12 | The Supplier shall ensure that the performance of the test Solution is comparable to the LIVE service levels for the restricted volumes in the Test environment, in order to provide a realistic expectation of performance behaviour in the LIVE estate. | MUST |
| TEST-ENV-13 | The Supplier must provide any necessary documentation pertaining to external interfaces to allow the integration of connecting systems. | MUST |
| TEST-ENV-14 | The Supplier must provide the necessary guidance and access privileges to The Authority for interrogating Audit Trail records, system logs and API messaging logs which might aid in early identification of any integration issues. This is applicable where the Supplier has provided the Virtual Machine (VM) images for The Authority to host. | MUST |
Live Environments Requirements
Applicable Contracting Vehicle(s) | Requirement ID | Requirement | Level |
| LIVE-ENV-1 | The Supplier must support use of appropriate Solution test data (including Patient clinical data) in their live environment(s). That support will ensure that test data can be used and exist in live environments in accordance with The Authority's guidance on the Use of Synthetic Data in Live Environments which is published as part of Training for Providers. | MUST |
Applicable Capabilities
All Suppliers Solutions delivering any Capabilities will need to meet this Standard.
Documentation
Roadmap
Items on the Roadmap which impact or relate to this Standard |
---|