Formål

Denne side beskriver omfang af den automatiserede regressionstest f.s.v.a MinSpærring komponenten.

Testgenstand

MinSpærring testen dækker både kald direkte til ADMIN services med borgercertifikat (POCES) samt kald, der sker automatisk ved kald af DDS registry servicen med MOCES.

DDS anvendes som indgang til at teste spærringer, da det vil være gennem DDS at servicen oftest kaldes.

Nedenstående illustration viser et overblik over hvilke komponenter, der indgår i testscope for regressionstesten.

Kun de sorte kasser/pile er implementeret. De røde udestår.

Testomfang

Regressionstesten omfatter på nuværende tidspunkt kun test af Negative Consent (spærring) og ikke test af Positive Consent (samtykker), da sidstnævnte ikke anvendes endnu.

Administration af spærringer

Der testes CRUD operationerne:

• Opret
  • WHO
  • WHAT
• Modificer
• Slet
• Hent

Anvendelse af spærringer

Der testes for tre typer spærringer:

• WHO - spærring for specifikt sundhedsfagligt CPR
  • Der testes også På vegne af i sammenhæng med den spærrede person
• WHAT - spærring for aftaler fra specifik SOR kode
  
  • Der testes både med og uden underorganisationer
• WHAT Periode - spærring for alle data fra en specifik periode

Opkald til DDS registry anvendes for at tjekke om en spærring virker. Der testes ikke fra andre applikationer end DDS registry.

Testdesignteknikker (TDT)

Der anvendes følgende testdesignteknikker:

• Ækvivalensklassepartitionering
• Fejlgætning

Der laves ikke grænseværditest i regressionstesten, da denne formodes testet af unittests.

Testcases for MinSpærring:

Herunder ses nuværende testcases for MinSpærring service samt deres sidste afviklingsstatus.

I Jira kan man under Test Execution se, hvilke scenarier der går godt og hvilke, der fejler:

Årsagen til de fejlede testcases kan findes i Jira ved at se på den sidste testkørsel samt de relaterede RFC'er for det enkelte testscenarie.