Indholdsfortegnelse
Intro
Formålet med denne side er at beskrive, hvordan vi tester dokumentdeling gennem NSPs dokumentdelingsservice.
Forkortelser
| Forkortelse | Beskrivelse |
|---|---|
| SUT | System Under Test |
| Kildesystem | System der leverer dokumenter til dokumentdelingsinfrastrukturen gennem DROS |
| Modtagersystem | System der søger og henter dokumenter i dokumentdelingsinfrastrukturen gennem DDS - DokumentDelingsServicen |
| Anvendersystem | En fælles betegnelse for kilde- og modtagersystemer. |
| SIT | SystemIntegrationsTest - se yderlige beskrivelse under |
Test typer
| Nummer | Test type | Beskrivelse | Ansvarlig |
|---|---|---|---|
| 1 | Leverandørens systemtest | Her verificerer leverandøren at deres løsning virker lokalt | Leverandør |
| 2 | Dokumentdeling Systemintegrationstest forkortet (DDSIT) | Her verificeres at der er en teknisk sammenhængende løsning mellem en anvender og NSP Dokumentdelingsinfrastrukturen: Dokumentregistrerings og Opdateringsservice (DROS) og Dokumentdelingsservicen (DDS). Der er en standard testprotokol for systemintegrationstest som altid skal køres. Den er forskellig for Kildesystem og Modtagersystem. | Projekt og Leverandør |
| 3 | Certificering | Der er en egentest og en livetest af at standarden overholdes indholdsmæssigt og at metadata udfyldes korrekt ved alle kald. Se yderligere veskrivelse her: Test og certificering - MedCom Forudsætning er, at DDSIT er gennemført. | Medcom |
| 4 | Forretningsregel test | Det skal aftales som en del af projektet, hvornår og hvem der udfører forretningsregeltesten. Den kan foretages som en del af E2E, og dele af den kan løbes igennem i DDSIT. Forretningsreglerne løbes igennem på et møde mellem SDS, Medcom og projektledelse, hvor det afgøres i hvilke testtyper forretningsreglerne behandles. Testcases beskrives i denne template (se afsnit Testcase template) Eksempler på forretningsreglerne er dokumenteret her: Et Samlet Patient Overblik ESPO (aftaler, diagnoser, forløbsplaner, stamkort): Test af Et Samlet Patientoverblik Høremappe: Test af Høremappe | Projekt |
| 5 | E2E test | Her verificeres, at løsningen forretningsmæssigt fungerer efter hensigten på tværs af kildesystem(er) og modtagersystem(er). Testen bør involvere klinikere til at validere at indhold angivet korrekt og uforvansket i mellem kilde- og anvendersystem. Der er retningslinier for, hvad E2E testen bør indeholde, men testcases vil typisk være defineret specifikt til projektet. E2E testen tester flowet i dokumentdelingen, samtykke- og frabedelser, behandlingsrelationsnotifikationer, rettigheder samt minlog registreringer. Forudsætning er, at Certificering er gennemført. | Planlægges af projekt SDS-NSP TM deltager |
Testcase template
Test ID# | Test Scenarie | Forudsætninger | Forventet resultat | Resultat | Afvigelse | Kommentar |
Id for testscenarie | Beskrivelse af testscenarie | Beskrivelse af forudsætninger for testscenariet | Beskrivelse af det forventede resultat for testscenariet | Aktuelle resultat af testen | Beskrivelse i forhold til om testresultatet afviger fra det forventede resultat | Evt. kommentarer |
Test arkitektur
Dette viser ikke den fulde dokumentdelingsinfrastruktur, da mange systemer er involveret.
Dette er blot et udsnit for at illustrere test scope for henholdvist systemintegrationstest og E2E test.
Hvornår skal test gennemføres?
Nedenstående tabel viser retningslinier for hvilke testtyper, der kræves.
Det er altid IT systemleverandørens ansvar at kvaliteten af data er korrekt.
| Scenarie | Situation | Hvilke tests skal gennemføres? | |||||
|---|---|---|---|---|---|---|---|
| Leverandørens systemtest | DDSIT kilde | DDSIT modtager | Certificering | Forretningsregel test | E2E test | ||
1 | Ny anvender på eksisterende IT system begynder at levere eksisterende dokumenttype. Der er ikke væsentlig forskel på konfigurationen af den pågældende implementering i forhold til tidligere certificererede implementeringer. Eksempel: en kommune implementerer et eksisterende EOJ system, som allerede er certificeret. Konfiguration der vedrører dokumentdelingsdata er identisk med tidligere konfigurationer i andre kommuner | X | (X) | (X) | |||
2 | Ny anvender på eksisterende IT system tager eksisterende dokumenttype i brug. Der er væsentlig forskel på konfigurationen af den pågældende implementering i forhold til tidligere certificererede implementeringer. For eksempel fordi der anvendes andre komponenter til upload af dokumenterne. Eksempel: En kommune implementerer et eksisterende EOJ system, som allerede er certificeret, men komponenterne i arkitekturen er anderledes end den, der blev certificeret. | X | X | Der foretages egentest ved anvendelse af Medcoms protokoller. |
| ||
3 | Nyt IT system begynder at levere eksisterende dokumenttype, som allerede er E2E testet Eksempel: Et nyt bookingsystem begynder at levere aftaler | X | X | X | X | X | |
4 | Nyt IT system begynder at hente og vise eksisterende dokumenttype, som allerede er E2E testet Eksempelvis: En ny App viser forløbsplaner | X | X | X | X | X | |
5 | Ny dokumenttype og/eller format introduceres både i kildesystemer og anvendersystemer Eksempelvis: EHMI beskeder skal fremover deles gennem dokumentdelingsinfrastrukturen Projektet skal overveje, om slutbrugere skal involveres i test. | X | X | X | X | X | X |
6 | Nye valideringsregler for dokumentregistrering introduceres Eksempelvis: Der opsættes regler for metadata ved upload af aftaler | X | X | ||||
Når E2E test er påkrævet, kan denne først foretages, når mindst et kilde- og et anvendersystem er færdigimplementeret. Det betyder, at denne test tidsmæssigt kan ligge et stykke efter certificeringen af den første part.
(X) betyder, at formel test IKKE er påkrævet, men leverandøren skal vurdere om der ønskes involvering fra Medcom og SDS. Det anbefales, at projektet selv validerer kildesystemets uploadede dokumenter i et relevant modtagersystem fx Sundhed.dk eller Sundhedsjournalen.
Ansvar
Ansvarsfordeling mellem MEDCOM, SDS/Arosii, projekter og leverandører
R= Responsible (udførende på opgaven), A=Accountable (ansvarlig for at opgaven udføres), C=Consulted (konsulteret), I=Informed (Informeret)
| Aktivitet | SDS PO | SDS TM | Medcom | Projekt | Projektets leverandører (modtager/afsender systemer) |
|---|---|---|---|---|---|
| Systemintegrationstest | |||||
| Vedligeholdelse af checkliste til testprotokol | A | R | I | C | I |
| Systemintegrationstest (Egentest) | I | C | A | R | |
| Certificering | |||||
| Planlægning af certificering | I | I | A | R | C |
Testcase udarbejdelse til egentest og certificering | I | I | A | R | |
| Egentest (forberedelse til certificering) | A | C | R | ||
| Medcom Certificering Metadata | I | I | A/R | C | R |
| Medcom Certificering indhold | I | I | A/R | C | R |
| E2E test | |||||
| Vedligeholdelse af checkliste til testprotokol | A | R | C | C | |
| Planlægning af E2E | C | C | C | A/R | C |
| Godkendt testmiljø | A | R | I | I | |
| Test case udarbejdelse | A | R | C | I | I |
| Test case eksekvering | A | R | C/I | R | R |
Test rapportering og dokumentation *Medcom har arkivering ansvar | I | R | A/R | A | C |
SDS publicering af bestået E2E test | A/R | R/C | I | I | I |
| Tilbagemelding på test | I | R | I | A | I |
Forudsætninger
| Testtype | Forudsætning | Ansvarlig |
|---|---|---|
| SIT | DROS dokumentdelingsinfrastruktur til dokumenttype under test skal være til stede | Projekt bestiller SDS etablerer |
| SIT | DROS skal være konfigureret til dokumenttype (Skabelon for bestilling DROS oprettelse) | Projekt bestiller SDS etablerer |
| SIT | Udvikling af den tekniske integration hos leverandør og systemtestet | Projektets udviklings leverandør |
| SIT | Adgang til sundhedsdatanettet samt whitelisting skal være etableret | Projekt bestiller Operatør etablerer |
| E2E | Medcom certificering godkendt | Projektet |
| E2E | Test borgere der kan anvendes til alle systemer der indgår i testen er oprettet inkl MitID hvis nødvendigt *Test borgere kan oprettes via: https://stamdata.nspop.dk/dtg-webservice/ | Projektet |
| E2E | Data til generering af dokumenter i kildesystem skal være etableret (eller kunne etableres let under selve E2E test udførslen) | Projektet |
| E2E | Som udgangspunkt sikring af at alle parter der skal indgå i E2E er tilgængelig | Projektet |
| E2E | Alle systemer, der indgår i testen skal være færdige, testede og deployede på et miljø, der er sammenhængende med NSP Test2 | Projektet SDS for NSP komponenter |
Proces for planlægning af test
| Aktivitet | Hvornår | Deltagere |
|---|---|---|
| Planlægning af testforløb, cirka tidsplan, bookning af E2E møder og certificering | 3 mdr før ønsket E2E | Projektleder tager intitiativ Deltagere: Medcom, SDS, SDS TM, relevante projektdeltagere |
| Gennemgang af projekt og afklaring af hvor i testprocessen de forskellige forretningsregler verificeres | 2 mdr før ønsket E2E | Projektleder tager intitiativ Deltagere: Medcom, SDS, SDS TM, relevante projektdeltagere |
Tilpasning af SIT/Egentest + E2E testprotokoller/checklister til konkret projekt Afklaring af forudsætninger for testgennemførsel samt hvem der er ansvarlig for at sikre det | 1 mdr før ønsket E2E | Projekt indkalder SDS PO og SDS TM |
| Statusmøde vedr testklargøring, verificering af, at alle E2E forudsætninger er til stede | 1 uge før ønsket E2E | Projekt indkalder SDS PO og SDS TM |
*MedCom og SDS koordinere testcases, således vi undgår redundante testscenarier.
Test protokoller
De testprotokoller, som skal gennemføres til Egentest / SIT test, ses herunder. Der tages en kopi af protokollen og den tilpasses i forhold til de retningslinier, som er beskrevet.
For E2E tests skal en ny protokol skrives hver gang. Der er en checkliste med punkter, som man som minimum skal i gennem i en E2E test, men da dokumenttyper og forretningsregler er forskellige, kan der ikke laves en generisk test protokol for E2E tests. Det er dog helt tilladt at finde inspiration i tidligere testprotokoller og derfor er der uploadet og linket til et antal eksempler.