Page History
| Table of Contents |
|---|
Begreber
| Begreb | Forklaring |
|---|---|
| Projektleverandør | Den leverandør som initielt er bestilt til at udvikle/ændre komponenten i forbindelse med et projekt. Leverandøren er ofte midlertidig og overdrager til vedligeholdelsesleverandøren efter idriftsættelse/hypercare. Eksempler på projektleverandører er Capgemini, Nine, Trifork |
| Vedligeholdelsesleverandør | Den leverandør som har det løbende vedligehold af komponenten for så vidt angår fejlrettelser og ændringsønsker (RFC'er). Eksempler på vedligeholdelsesleverandør er KvalitetsIT (KIT) |
| QA leverandør | Den leverandør som varetager kvalitetssikringsopgaven (sikring af overholdelse af husregler samt at test er afviklet) i forbindelse med modtagelse af leverancer til NSP platformen. Eksempler på QA leverandør er Arosii. |
Testtyper
Der foretages følgende test i forbindelse med idriftsættelser på NSP platformen:
Integrationstest
Der udvikles automatiseret integrationstest for alle komponenter, som både kan køre lokalt og på NSPs testmiljøer. Beskrivelse af dem ligger under siden Testvejledning for de enkelte komponenter.
...
Integrationstests vil altid blive afviklet før deploys på NSPs testmiljøer, og det er en forudsætning for accept af leverancen, at integrationstesten afvikles uden fejl.
Regressionstest
Regressionstesten tester de forskellige services i kombination med de øvrige NSP services.
...
Regressionstesten er beskrevet yderligere her: 4 Automatiseret regressionstest
Test af RFC'er
Når komponenterne på NSP er under vedligehold, så foregår alle ændringer til dem gennem Request For Changes (RFC'er), styret i Jira projektet NSP - SDS JIRA (nspop.dk).
...
- Dækket af eksisterende automatiseret regressionstest
- Udbygning af automatiseret regressionstest
- Manuel test
- Test ikke relevant, eks for analyseopgaver
Test af releasesager
For hver release sag oprettes en testplan. I testplanen sikres det at der er taget stilling til alle RFC'er. I testplanen beskrives hvilke RFC'er der kan testes (in scope) og hvilke der ikke er mulige at teste (out of scope).
Testplanen skal indeholde
- Description
- En kort beskrivelse af hvad testplanen skal teste
- Opdeling af RFC'er i følgende
- In scope (testes manuelt)
- Out of scope (kan ikke testes)
- Testes indirekte (testes via regressionstesten)
- Ønskes der test med anvender: Ja/nej
- Aktører (ved større releases kan en test med en anvender være ønsket, her angives hvem der ønskes testet med. Ellers sættes den blot til Arosii)
- Evt tidsplan
Template/ eksempel:
Beskrivelse af test: Følgende testplan tester mindre rettelser til fælles stamkort
In scope (manuel test)
(liste af RFC'er)
Out of scope (kan ikke testes)
(liste af RFC'er)
Testplanens status: Under udvikling/Beskrevet
Ønskes test med anvender: Ja/Nej
Aktør (udfører testen): CHO
Resultat:
Proces for fejl fundet i test
Når der findes en fejl i forbindelse med afvikling af test hos QA leverandøren, så oprettes der en RFC, som visiteres internt af QA leverandøren og derefter overgår den til den almindelige NSP ændringsproces beskrevet her: NSP Change Managementproces - Ændringsanmodning på NSP