Ways of working with thirdparties #264
Conversation
just the basic draft skeleton file
corrected MDlint
updated have read through it but need another pair of eyes
There was a problem hiding this comment.
Should this file be here? Looks like it should be deleted
| 3. Whilst the installation and configuration are conducted then we need a clear process for defect resolution. | ||
|
|
||
|
|
||
| **OLD STUFF BELOW** |
There was a problem hiding this comment.
This old stuff needs to be removed from the PR
| ## Overview | ||
|
|
||
| This is intended to provide some guidance as to a more productive interation with suppliers though setting out | ||
| the terms of engagement. |
|
|
||
| ## The when to get involved | ||
|
|
||
| suggested when to be involved is below for guidance :- |
There was a problem hiding this comment.
This section is confusing. Perhaps just replace the whole section with:
"It is suggested that Test Leads are involved in deliveries as soon as possible. Ideally this will be during the initial inception of work packages. Failing that, Test Leads should review Statement of Requirements documents before they are released for tender."
|
|
||
| ## What are the deliverables for QA | ||
|
|
||
| For the QA Deliverable there are 3 types of models that need to be taken into account, which are |
There was a problem hiding this comment.
What is the "QA Deliverable"?
Perhaps change to just "There are three types of models that need to be taken into account:"
| 1. Independent third party solutions | ||
|
|
||
| ### UKHO teams | ||
| These will follow all guidlines and deliver the following TSR documentation, at this point the Test Leads confirm that the test approach in the TSR - |
There was a problem hiding this comment.
I don't think it's necessary to repeat test types from the TSR. I think just refer to the TSR and also link to the TSR process https://github.com/UKHO/docs/blob/main/quality-assurance/Test-Approach-TSR-Reviews.md
|
|
||
| #### Bespoke solution | ||
| The following should be considered for the delivery | ||
| 1. Documentation in the form of a TSR should be delivered at the outset of the work and agreed with the UKHO test leads to be acheiving our standards as a minimum. |
There was a problem hiding this comment.
Not sure they need to achieve our standards do they? They need to follow the suppliers' standards, which we deem to be acceptable.
| #### Bespoke solution | ||
| The following should be considered for the delivery | ||
| 1. Documentation in the form of a TSR should be delivered at the outset of the work and agreed with the UKHO test leads to be acheiving our standards as a minimum. | ||
| 2. Where appropriate, the WP will produce a Formal Acceptance Test Document (FAT). This needs to be agreed with UKHO test leads to confirm suitable level of coverage. |
There was a problem hiding this comment.
FAT normally means Factory Acceptance Testing. Do you mean that?
This section describes how you've been working on some of your projects, but in other places (e.g. Penrose / ADDS world) we don't really use those terms (FAT / SAT). It's more relevant for old-school stuff (e.g. in your projects) that gets tested on their site (FAT) and then afterwards tested after deployment on our network (SAT). That language doesn't seem right for for cloud-based products or ADDS projects. The more usual progress is through increased levels of integration with our systems.
| 2. Where appropriate, the WP will produce a Formal Acceptance Test Document (FAT). This needs to be agreed with UKHO test leads to confirm suitable level of coverage. | ||
| 4. A FAT schedule for test execution will need to be agreed so that UKHO can arrange if needed to wittnessed. | ||
| 5. Where appropriate, a Site Acceptance Test document (SAT) will be delivered. This needs to be agreed with UKHO test leads to confirm suitable level of coverage. | ||
| 6. If the solution is part of a wider programme of delivery there will be a need for UKHO involvement to cover the End-2-End flows through the system. |
| 5. Where appropriate, a Site Acceptance Test document (SAT) will be delivered. This needs to be agreed with UKHO test leads to confirm suitable level of coverage. | ||
| 6. If the solution is part of a wider programme of delivery there will be a need for UKHO involvement to cover the End-2-End flows through the system. | ||
|
|
||
| #### COTS |
There was a problem hiding this comment.
This section doesn't include any info on testing. Perhaps we should be seeking evidence of their QA processes (instead of FAT)? And then we will normally do SAT which tests correct deployment and configuration.
draft file no longer needed
this is just a start point of what we should expect from third parties.
its not complete just a list of thoughts at the moment and something to discuss.
Please can you read it and then i'll organize a meeting to discuss