/complete-your-testing

[emmagifford]

Description

As part of this PR, I've:

• added a new page about the testing process as part of CCM-8034
• tweaked /onboard-with-nhs-notify by stripping back the testing step guidance and instead linking to this new page

The new content covers:

• integration testing
• NHS App testing
• smoke testing

It gives a high level overview of the steps, and outlines what we expect from integrators and NHS Notify's role.

Some of the steps, particularly integration testing, are quite vague, and I did try to elicit more detail from Josh about how users should actually do certain things. However, Josh explained that it's largely down to the user to decide how to carry out their testing and what to include. He said if we go into too much detail, that leaves us at risk of being held responsible if the user misses out something critical that we happen to not have listed.

In terms of where this content lives, I did contemplate publishing it on the API and MESH pages separately. However, Emily strongly felt that it should go on our website because it ties in so closely with the onboarding process. Also:

• you don't need to be technical to carry out a large portion of the testing - you just need someone who can send requests if you're using the API (MESH doesn't need anyone technical)
• the process is the same regardless of whether you're using API or MESH, other than where you send requests from

I was going to put this in the /get-started section as I thought it related most to onboarding but Jake felt it fit better in /using-nhs-notify, so I've gone with that. I've put it under a new section header, Getting ready to go live.

I've moved the proofing page in here too as this seems to be the most logical place for that.

Context

This content is needed because until now, we've only documented the process internally. We were sending some of the steps to integrators as a PDF file via email, which is obviously not accessible, scalable or efficient. We now need to convey this process externally in a plain language, user-centred format.

This has been reviewed and approved by Emily and Josh. Sian did a 2i check of a previous iteration of this.

Type of changes

• Refactoring (non-breaking change)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would change existing functionality)
• Bug fix (non-breaking change which fixes an issue)

Checklist

• I am familiar with the contributing guidelines
• I have followed the code style of the project
• I have added tests to cover my changes
• I have updated the documentation accordingly
• This PR is a result of pair or mob programming

---

Sensitive Information Declaration

To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

• I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

[jakecosgrove]

Looks great Emma, don't need to address the comment right now, well done!