Indledning

Denne side beskriver de krav som projekterne skal overholde vedrørende funktionel test, når de udvikler til NSP, inden projektet kan overdrages til NSP Vedligehold.

Det er op til projektet at vurdere omfanget af nødvendig funktionel test.

I de fleste projekter er der en tilknyttet teststrategi eller andre krav til testprocessen. Disse krav skal selvfølgelig overholdes. 

Dette dokument skal ses som et supplement til projektkontrakternes testkrav. 

Generelle krav

Unittest

Alle unittests og integrationstests skal indeholde test af fejlhåndtering ved forkerte inputdata. Alle invarianter skal dokumenteres, implementeres og testes.

Listen herunder er til inspiration og skal ikke ses som en udtømmende liste:

  • Test for manglende feltværdier, herunder null og den tomme streng (mandatory og optionelle)
  • Test af forkert format, eks strings i et integerfelt, forkert datoformat, forkert id format, negative værdier, meget store værdier/lange tekster m.m.
  • Test af forkerte koder i ENUM felter (eks. pårørendetype "denneherfindesikke")
  • Test af meningsløse værdier, eks et 4 cifret CPR nummer
  • Test af lange strenge/store tal i tekst/integerfelter
  • Input som ikke findes (eks ikke eksisterende cprnumre)
  • Forretningsvalideringer

Formålet er at sikre, at der er korrekt fejlhåndtering omkring forkert anvendelse af snitfladen, og at der leveres brugbare fejlbeskeder tilbage til anvenderne

Systemtest

Ved leverance af nye/ændrede komponenter skal der foretages systemtest af alle brugerhistorier.

Systemtesten skal dække både positiv test (at brugerhistorier er dækket) samt negativ test (at fejlscenarier håndteres, således at brugeren hindres i at anvende komponenten forkert).

Integrationstest

Integrationstest skal verificere korrekt deployeret komponent. 

Regressionstest

Projekterne skal levere et sæt af regressionstestcases til NSP Vedligehold.

Regressionstestcasene skal være funktionelle og end-to-end på tværs af NSP platformen.

Testcasene skal være dokumenteret i Gherkin syntaks, såfremt dette er muligt. Alternativt tillades manuelle testcases med steps.

Alle testcases skal indeholde beskrivelse af:

  • hvilken usecase/brugerscenarie, som testcasen verificerer
  • forudsætninger, herunder data der skal være til stede, og hvordan disse kan tilvejebringes
  • fremgangsmåde, herunder hvad brugeren skal gøre/hvilke services der skal kaldes
  • verificeringer, herunder hvad der skal undersøges for (retursvar, opdaterede feltværdier i kontrolkald mod samme og andre NSP services)
    Det er projektet selv, der vurderer hvilken testdybde, der er anbefalet for regressionstesten, og det er projektet selv, der skal sikre, at de leverede testcases modsvarer den anbefalede testdybde.

Projekterne skal også levere en testrapport, der dokumenterer den test, som projektet selv har gennemført i forbindelse med modtagelse af leverance fra leverandørerne. Testrapporten kan leveres i formerne:

  • En Confluenceside
  • Et PDF dokument
  • En Jira XRAY testplan/testset

Der ud over indkaldes NSP testmanager til en gennemgang af testrapport og resultater.

Såfremt regressionstestcases er automatiseret af projektet, så skal vedligehold af testcases overdrages til NSP Vedligehold.

End to End test

Det er ikke et krav, at der foretages E2E test med de anvendere, som skal anvende de nye NSP services.

Men det er en klar anbefaling, at der som minimum foretages test af enkelte E2E scenarier, så det sikres, at de nye/ændrede komponenter kaldes korrekt af anvenderne. 

Projekterne bør identificere hvilke anvenderapplikationer, der danner data til projektets applikationer og henter data fra projektets applikationer og inddrage disse i en samlet test.

Eksempler på E2E test:

Der udvikles en NSP komponent som kan levere et elektronisk coronapas (CBS) → CBS projektet tester med SSI, Coronapas App og Sundhed.dk som hhv leverer data til coronapas og viser coronapas.

Et telemedicinsk projekt danner spørgeskemaer, som vises på Sundhed.dk → Det telemedicinske projekt bør involvere Sundhed.dk i en E2E test, så det sikres, at der er overensstemmelse mellem det borgren oplever i den telemedicinske løsning og på Sundhed.dk. 

Specifikke krav

Levering af nye dokumenttyper til dokumentdelingsservice

Alle projekter, som leverer nye eller ændrede dokumenttyper til dokumentdelingsservicen bør gennemgå denne testprotokol NSP DROS testprotokol-1.1.xlsx. for at verificere, at metadata er korrekt udfyldt.

Det er metadata, som sikrer, at dokumenter kan fremsøges korrekt, og at borgerens spærringer slår igennem, så der kun deles det, som må deles.


  • No labels