3. Testdata
Inledning
För att kunna genomföra SOAP-testerna behöver testdata läggas upp i ditt källsystem. Ibland kan den befintliga mängden testdata som redan finns i din testmiljö vara tillräcklig, om inte så kan den behöva kompletteras. För varje tjänstekontrakts testsvit finns en tillhörande testfalls-beskrivning som är utgångspunkten för vilken testdata som kommer att behövas under verifieringen.
Förberedelser
Vårdgivare, vårdenheter och patienter
Den anropande parten skickar alltid med filter i anropet. Filtrering sker oftast på patient (oftast personnummer) eller vårdenhet, men möjlighet finns att lägga på ytterligare filtrering som t.ex. vårdgivare eller tidsperiod. Sprid testdata över flera vårdgivare, vårdenheter och patienter.
Flera av de tester som ingår i TK-sviterna är av typen filtrerings- eller urvalstester. Syftet med testet är att göra ett urval ur det totala data som finns tillgängligt. Om testets syfte t ex är att göra ett urval för vårdenhet 1 och testdatat endast innehåller vårdenhet 1 så är det inte möjligt att säga att källsystemet returnerade ett korrekt urval. Om det istället är ett flertal vårdenheter i testdatat så kan Inera med större säkerhet säga att just det urvalet fungerar på ett tillfredsställande sätt.
Gå igenom de testfall som är av typen filtrering och se till att det finns en mängd testdata att göra filtrering på.
Ett minimum av två patienter behöver läggas upp. Dessa patienter ska vara kopplade till olika vårdenheter som i sin tur kopplas till olika vårdgivare (om möjligt). Det behövs en patient med personnummer och en med samordningsnummer. Om möjligt även en patient med reservnummer.
Byt ut namn och fyll i HSA-id samt Patient-Id i tabellerna med uppgifter från källsystemet.
Vårdgivare
Vårdgivare | Namn Vårdgivare | HSA id | Kommentar |
VG1 | Namn Vårdgivare 1 |
| Primär vårdgivare |
VG2 | Namn Vårdgivare 2 |
| Privat vårdgivare (om denna saknas lämna tomt) |
Vårdenheter
Vård-enhet | Namn Vårdenhet | HSA id | Tillhör vårdgivare |
VE1 | Namn Vårdenhet 1 |
| |
VE2 | Namn Vårdenhet 2 |
| |
VE3 | Namn Vårdenhet 3 |
|
Testpatienter
Namn patient | Patient-Id (personnummer, samordningsnummer eller reservnummer) | Tillhör vårdenhet |
| Patient (med personnummer) | |
| Patient (med samordningsnummer) | |
| Patient (med reservnummer) |
Mappningstabell
Börja med mappningstabell och utred vilka fält som ej är mappade samt vilka fält som används.
Börja med att begära in mappningstabell som visar vilka fält i tjänstekontraktsbeskrivning som är mappade mot källsystemet (om ingen mappningstabell finns, gå igenom fälten i testfallsbeskrivningen och få bekräftat av leverantören av systemet vilka fält som inte är mappade). Den mängd som kvarstår ska det sedan läggas upp testdata på. Är det fortfarande oklart t ex om verksamhetsexperten inte vet hur detta fält ska fyllas i, så skicka listan på de fält som inte varit möjligt att lägga upp testdata för till leverantören av systemet.
Återanvänd och utöka befintlig testdata
För att spara tid och resurser samt för att utöka testdata så är det till en fördel att testdata sparas mellan anslutningar av olika tjänstekontrakt. Spara testdata efter testerna så sparas tid för nästa anslutning samt att man då kan få en utökning av redan existerande testdata tillsammans med ny testdata. Med tiden så uppnås historisk och färsk testdata som kan hjälpa till att hitta viktiga buggar.
Testdatainnehåll
Olika vägar
Utifrån hur källsystemet fungerar, så kan det vara relevant att skapa testdata via olika vägar, exempelvis om man kan signera på två olika ställen i journalsystemet.
Eller att datan kommer in från olika externa system och behöver transformeras innan det skickas iväg från tjänsteproducenten.
Eller att informationen makulerats, vilket sedan ångrats, eller att det finns tidsbaserade händelser som gör att data automatiskt ska ändras, t.ex. signering i form av ”låsning”.
Testar man bara en väg, så finns det risk att det blir fel för andra vägar.
Olika innehåll
För fritextfält är det bra att testa typiska innehåll från verkligheten, med saker som åäö, icke-europeiska tecken, specialtecken, nyrader, data som förändrats, med mera.
Det kan bli relevanta skillnader i vad som levereras om det är poster med ”mycket” innehåll (signering, avvikande åsikt m.m.) kontra minimalt innehåll.
Utifrån hur källsystemet fungerar, så kan det också finnas olika format på samma sorts innehåll.
Ett exempel är formaterade anteckningar med DocBook kontra rå text.
Ett annat exempel är bifogade bilder med olika bildformat.
Testar man bara en sorts innehåll, så finns det risk att det blir fel för annat innehåll.
Olika mappningar
Verksamhetskompetens behövs för att validera att rätt information verkligen mappats till rätt tjänstekontraktselement, så att det hamnar rätt i tjänstekonsumenten, exempelvis NPÖ.
Utifrån hur källsystemet fungerar, så kan det också finnas mappningar där olika saker blir samma sak ur ett tjänstekontraktsperspektiv.
Ett exempel är att man kan sätta approvedForPatient = false (ska inte visas för medborgare i Journalen) för ”Våldutsatthet i hemmet” och ”Arbetshypotes”.
Eller att man har två olika tillstånd, som båda ska betyda ”Pågående” vårdkontaktstatus.
De HSAID:n som skickas måste vara korrekta för att spärrar och PDL-loggning ska fungera, så identifieringen av vårdgivare/vårdenhet/organisationsenhet/källsystem kan behöva göras på flera ställen.
Testar man bara en sorts mappning, så finns det risk att det blir fel för andra.
MIN och MAX
Lägg upp en post med minimalt och en post med maximalt ifyllda fält på en patient.
Definitionen av MIN-post: En post där endast obligatoriska värden fylls i.
Definitionen av en MAX-post: En post där man fyller i så många värden som systemet tillåter. Fritext-fält ska fyllas till max-gränsen.
Att tänka på
Testdata som filtreras bort
Många tjänsteproducenter har fått OK på att (i strid med regelverket) implementera åtkomstfiltrering baserad på tjänstekonsument.
Om så är fallet, lägg gärna upp poster av den typen (ex: "Våld och utsatthet" eller Psykiatri-besök) så att denna filtrering kan testas.
Specialtecken
Använd typiska texter i kommentarsfält, specialtecken, mycket data/lite data, olika format. Om det inte finns kommentarsfält så bör du som absolut minimum få med åäö i något fält.
Extra viktigt är att få med tecknen "<" och ">", används ofta i dosering osv och är typiska tecken som kan ställa till kommunikationen om de ej kapslas in korrekt.
Tid
Tänk på att en automatiskt låst post kan ta upp till 14 dagar att få till och det är därför viktigt att detta läggs upp så tidigt som möjligt. Det kan vara så att det kontrakt som verifieras inte har automatiskt låsning, notera då detta.
Tänk på att lägga upp alla datum inom en post med så stor spridning som möjligt, så att tiden då posten skrevs inte är lika som t ex start-tiden för besöket om det gäller en vårdkontakt.
Bra om det finns historiska data kompletterat med nyupplagt data. Förändra existerande data för att få ännu bättre spridning på tidstämplar.