...

There are 2 key concerns for our internal Test team

1. Are the branding process & pipelines fit for purpose? Is it well-documented, usable etc.?

2. Actually testing the branded versions of the apps, ahead of use by a customer.

It is likely that as we get comfortable with the process, we will get a sense of where the key risks lie in Branding, and be able to tailorr the testing under 2 to just focus on these risk areas, rather than having to retest the whole app. In the short term, while we are still developing this understanding, we should expect to perform a pretty comprehensive test of the first few branded apps.

We also need to consider how the custmer will test their branded version.

• For Android, we can distribute APKs

• For Apple, we will presumably need to use TestFlight. Some thought needed to make that work.

• (maybe we should put a “rough”version of the branded app - maybe not even branded at all yet - into the App store submission immediately at the start of the process, to reduce delays later)

Operationalizing the Pipeline

We will need clear definitions for the customer regarding:

• What they can brand

• What they can’t brand

• What assets they must provide for the things they want to brand, and what formats are acceptable (SVG, hi-red bitmaps etc.)

In the short term, the key for efficiency will be precisely defining this set of information/assets, so we can collect with minimal iterations.

Manual collection of these assets (and manual check-in into the Repo) is probably acceptable in the near-term, at least for the first few brandings. More automation here starts to be necessary as we move into 10s of brandings.

Assumptions / Restrictions

Selection of Health Authorities will be as per the standard app, with all HAs available for subscription, and recommendations/auto-subscriptions made based on location, rather than based on branding.

We won’t offer any means of pre-provisioning HAs, or restrcting access to other HAs.