Her beskrives hvordan testing av nye versjoner av Medusa organiseres nasjonalt, herunder ansvar og fremgangsmåte for testing før en ny versjon settes i produksjon
1. Hensikt
Hensikten med testing er å redusere risiko for at feil i nye programversjoner eller feil i nasjonale eller lokale tilpasninger/integrasjoner vil medføre ustabilitet, driftsavvik og/eller utilgjengelighet i Medusa.
Medusa er et nasjonalt system og alle helseforetak benytter samme programversjon til enhver tid. Test i forbindelse med nye Medusaversjoner koordineres nasjonalt for å kunne avdekke feil på et tidlig tidspunkt, slik at alle helseforetak kan ta i bruk funksjoner i nye programversjoner så raskt som mulig.
2. Ansvar
Ressurser til gjennomføring av tester gjøres tilgjengelig i hvert enkelt helseforetak, basert på egne behov og kompleksitet, og i samsvar med egen ibruktakelse av de ulike moduler av Medusa.
Det er den lokale systemeier for Medusa i hvert HF som har det formelle ansvaret for at Medusa som produkt samt alle integrasjoner og lokale tilpasninger fungerer etter hensikten i eget HF. Medusa består av mange funksjonsområder og bruksområder og støtter mange ulike arbeidsprosesser. De ansvarlige for hver arbeidsprosess (slikt ansvar kan f.eks. være knyttet til ulike roller som f.eks. seksjonsleder, servicekoordinator, superbruker, ingeniør) må i samråd med lokal systemeier sørge for ressurser innenfor egen enhet til gjennomføring av testing som er kritisk i egen virksomhet i forhold til risiko ved feil i produksjonsmiljøet.
Medusa er et nasjonalt system, det innebærer at nye versjoner rulles ut samtidig til alle helseforetak. Ansvaret for å starte opp en testperiode ligger hos det nasjonale forvaltningsrådet for Medusa (FvR), i samråd med programvareleverandør SoftPro og driftsleverandør NHN. Beslutning om utrulling til produksjonsmiljøet gjøres av FvR etter endt testperiode uten kritiske feil i produktet Medusa. Kritiske feil betyr feil som blokkerer for utrulling. Hvert HF har ansvar for å følge en fastbestemt prosess for å melde inn alle funn av feil, og det er FvR i samråd med leverandørene som avgjør om en feil er kritisk.
Det enkelte helseforetak kan eie lokale eller regionale integrasjoner eller tilpasninger som støtter opp under lokale arbeidsprosesser. Det er det enkelte HF som eier eller bruker en slik tilpasning som er ansvarlig for å teste den. Slike komponenter må kvalitetssikres av den enkelte bruker av integrasjonen/tilpasningen, dette er ikke dekket gjennom leverandørens testing av produktet Medusa. Ved lokal testing av Medusa må derfor slike komponenter vies særlig oppmerksomhet.
3. Fremgangsmåte
De følgende punktene beskriver fremgangsmåte for gjennomføring av uttesting av en ny medusaversjon fra den gis ut av leverandøren til den er satt i produksjon nasjonalt.
1. Beslutning om installasjon av ny medusaversjon i testmiljøene
Når leverandør annonserer en ny versjon av Medusa vil FvR i samarbeid med SoftPro og NHN legge en tidsplan for en samordnet installasjon i samtlige testmiljøer nasjonalt. Ved hoved-releaser vil NHN rutinemessig kopiere inn friske data fra produksjonsmiljøet over til testmiljøet. Det må gis særskilt beskjed til NHN dersom man IKKE ønsker en slik kopiering. Ved mindre bugfix-oppdateringer i testmiljøet blir data ikke overført fra prod.
2. Varsling om oppstart testperiode
Tidsplanen gjøres kjent i alle regioner gjennom ordinær informasjonsflyt fra FvR til regionene. Deretter videre regionalt til de enkelte HF. Testmiljøene oppdateres normalt innenfor normal arbeidstid slik at nedetid må påregnes. Lokal systemforvaltere informerer egne brukere om at ny medusaversjon planlegges inn i testmiljøene, herunder oppstart og planlagt varighet av testperiode.
Det er en fordel om planlagt aktivitet i testmiljøene (f.eks. gjennomføring av opplæring) tar hensyn til varslet nedetid og mulig ustabilitet i testperiodene.
3. Forberedelse til testing
Som forberedelse til testperioden bør alle som er involvert i testing lese gjennom “release notes” (se referanser) for den aktuelle versjonen. Den utgis av SoftPro og beskriver alt som er rettet av funksjonalitet og alt som er nytt i brukergrensesnittet. Den vil være til hjelp for å identifisere områder som er spesielt viktig å ha fokus på ved testing. Uttesting av eksisterende funksjonalitet bør ha høyest prioritet i forhold til testing av nye funksjoner.
4. Gjennomføring av testing
Medusa består av ulike funksjoner som støtter ulike arbeidsprosesser. Hver funksjon bør testes av en eller flere personer som bruker de respektive funksjonene i sitt daglige arbeid og dermed avdekke om egne arbeidsvaner blir påvirket av den nye versjonen.
Alle funksjoner trenger naturligvis ikke å bli testet av alle, men noe redundans vil bidra til å redusere risiko for å overse kritiske feil.
Hvor systematisk testingen gjennomføres henger ofte sammen med tilgjengelige ressurser og hvilken risiko systemeier ønsker å ta i forhold til å introdusere feil i produksjonsmiljøet.
Om testing basert på sjekklister: Grunnleggende funksjoner i Medusa, typisk de som er dekket av veiledere, kan testes ved å utarbeide generelle sjekklister. Slike generelle sjekklister samles i FvR og kan gjenbrukes av ulike HF ved behov. En generell sjekkliste fanger ikke nødvendigvis opp feil som kan oppstå ved bruk av egne «arbeidsvaner”, ved at man bruker Medusa på en ikke tiltenkt måte, eller feil som skyldes en kombinasjon av feil i egne datasett og nye funksjoner i Medusa. En sjekkliste som er individuelt tilpasset vil kunne avdekke feil i helt spesielle funksjoner, tilpasninger eller integrasjoner, og de bør utarbeides av de personer/faggrupper som bruker disse funksjonene.
5. Innrapportering ved funn av mulige feil
Nasjonalt er det ingen krav til dokumentasjon av hva som testes samt testresultater. For å kunne følge opp feil overfor leverandørene og redusere risikoen for kritiske feil i produksjonsmiljøet er FvR avhengig av at feil funnet i test, uansett årsak, blir innmeldt.
6. Utrulling av ny medusaversjon til produksjonsmiljøene
En testperiode avsluttes når det ikke lenger finnes kritiske feil i testmiljøet. Nasjonalt forvaltningsråd vil da sammen med SoftPro og NHN legge en tidsplan for produksjonssetting. Denne varsles i god tid til alle regioner. Utrulling av ny versjon til produksjon gjøres utenfor avtalt tilgjengelighetstid for Medusa (man-fre 0600-2000) med mindre noe annet er avtalt med det enkelte helseforetak. Umiddelbart etter at produksjonsmiljøet er oppdatert vil det være anledning for brukere til å verifisere installasjonen og i ytterste konsekvens kunne be om rollback på et tidligst mulig tidspunkt.
4. Referanser
SoftPro sine “release notes” – dokumentasjon om nye programversjoner finner du her https://medusaforvaltning.no/medusa-releaseinformasjon/
Registrering av feil funnet ved testing, se innmelding av feil i Medusa