1. Begreber

BegrebForklaring
ProjektleverandørDen 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ørDen 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. 

2. Testtyper

Der foretages følgende test i forbindelse med idriftsættelser på NSP platformen:

2.1. 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 vedligeholdes, udbygges og versionsstyres sammen med ændringer til servicen.

Det er Projektleverandørernes ansvar at lave integrationstest og sikre forudsætninger for succesfuld afvikling. Det er Vedligeholdelsesleverandørens ansvar at vedligeholde integrationstests.

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.

2.2. Regressionstest

Regressionstesten tester de forskellige services i kombination med de øvrige NSP services. 

Der er et vist overlap mellem Integrationstest og Regressionstest, og visse scenarier vil findes i begge testsuiter. Forskellene er:


IntegrationstestRegressionstest
TypeWhiteboxBlackbox
UdviklingLøbende sammen med nye/ændrede featuresLøbende efter risikovurdering og samlet prioritering af NSP platformens testniveau. 
Scope

Den enkelte komponent/service

Eks:  Givet en borger har adressebeskyttelse, så leveres teksten "ADRESSEBESKYTTET" i alle navn og adressefelter i SCES services

Hele NSP platformen, der testes på tværs af komponenter og services, hvor det giver mening

Eks: Givet privat adresse er markeret via DTG service, så vil et opslag i FSK via DDS ikke returnere navn og adresseoplysninger 
Den nævnte testcase berører komponenterne, DTG, DRG, DDS, FSK, SKR, SCES samt stamdataimportere

DataDatagenerering indeholdt i testenData kan være indeholdt i testen men visse data er forudgenereret og genbruges fra kørsel til kørsel
AfviklingIfm QA før deploy af komponentændringer på den specifikke komponent til TestmiljøerneDagligt eller on demand
Succeskriterie0 fejl

0 kritiske fejl

DokumentationTeknisk beskrevet, ligger i kodenForretningsmæssigt beskrevet, ligger i Jira
AnsvarligProjekt/VedligeholdelsesLeverandørQA Leverandør


Regressionstesten afspejler den aktuelle tilstand på testmiljøet og testcases går på tværs af komponenter.

Der findes 2 typer testcases:

  • Testcases med typen Cucumber er automatiseret, så de kan køres ved hver release eller dagligt.
  • Testcases med typen Manuel forklarer i detalje, hvordan man manuelt kan afteste funktionaliteten og er således anvendelig for både projektdeltagere, PO'er og andre, der blot ønsker at afprøve komponenten.

Regressionstesten vil ofte køre og fail'e på kendte fejl. Hvis en testcase fejler, så analyseres det, om det er en kendt fejl i servicen, og i så fald oprettes en Request For Change (RFC) i NSP jiraprojektet.

RFC'en linkes til testcasen, så det er tydeligt hvilke testcases, den pågældende fejl påvirker. Når fejlen er rettet og deployet, skulle testcasen gerne kunne pass'e. 

Det er Systemforvalterens ansvar at vedligeholde integrationstests og sikre forudsætninger for succesfuld afvikling.

Regressionstesten er beskrevet yderligere her: 4 Automatiseret regressionstest

2.3. 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).

Processen er beskrevet her: NSP Change Managementproces - Ændringsanmodning på NSP - NSP services - Global Site (nspop.dk)

Der tages stilling til, hvordan de enkelte ændringer skal testes:

  • Dækket af eksisterende automatiseret regressionstest
  • Udbygning af automatiseret regressionstest
  • Manuel test
  • Test ikke relevant, eks for analyseopgaver

3.  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

  • No labels