1 Bilag 10 Test og kvalitetssikring
2 I N D H O L D S F O R T E G N E L S E 1. Indledning... 3 2. Formål med test og kvalitetssikring... 3 3. Teststrategi... 3 3.1 Testforløb... 4 3.2 Testniveauer og Testtyper... 5 4. Testdokumentation... 6 4.1 Hovedtestplan... 6 4.2 Testniveauplan... 7 4.3 Teststatusrapport... 8 4.4 Testniveaurapport... 8 4.5 Specifikation af testcases... 9 5. Reviewstrategi... 10 5.1 Testarbejdsprodukter og dokumentation der vil være genstand for reveiw... 10 6. Gates og Generiske Godkendelseskriterier... 10 6.1 Gate 0: Overtagelse af standard leverance fra Underleverandør til... 11 6.2 Gate 1: Overgang fra Krav til Design... 12 6.3 Gate 2 Overgang fra Systemtest til FAT... 13 6.4 Gate 3: Overgang fra FAT til SIT... 15 6.5 Gate 4: overgang fra UAT til produktion... 16 6.6 Gate 5: Overgang fra skærpet drift til normal drift... 17 7. Defectcklassificering og håndtering... 17 7.1 Severity og leverancetidspunkt... 18 7.2 Samarbejde vedr. defects... 21 8. Testdatamanagement... 21 9. Som del af Software Assurance forpligter leverandøren sig i øvrigt til at udvikle en mere komplet løsning ifht. håndtering af test data management. Dette er indeholdt i roadmap for Standardproduktet, men endnu ikke planlagt til en specifik release. Kunden vil blive inddraget i dialogen med Underleverandøren herom, som beskrevet i bilag 3, kapitel 5.Testmiljøer og infrastruktur... 22 10. Teststyringsværktøj... 23 Appendiks A Leverancer og ansvarsfordeling... 25
3 1. INDLEDNING 2. FORMÅL MED TEST OG KVALITETSSIKRING Nærværende Bilag 10 fastlægger de overordnede rammer for kvalitetssikringsaktiviteter udført i relation til Hovedaftalen. De overordnede rammer skitseret i nærværende bilag er udgangspunktet for en teststrategi, som skal udarbejdes i aftaleimplementeringsperioden. Foruden beskrivelse i nærværende bilag af teststrategi og øvrig testdokumentation henv i- ses også til Bilag 4 Dokumentation. I relation til test og øvrige kvalitetssikringsaktiviteter, er begrebsa pparat fra ISTQB så vidt mulig anvendt. Se www.dstb.dk for ordliste mv. 3. TESTSTRATEGI Der skal i aftaleimplementeringsperioden udarbejdes en teststrategi, der beskriver testog kvalitetssikringsaktiviteter på tværs af kunde/leverandørforholdet. Teststrategien vil være gældende for alle leverancer under indeværende rammekontrakt. Teststrategien forventes at indeholde beskrivelse af følgende emner: Samarbejdsmodellen for testen mellem Kunden og herunder af roller og ansvar for testaktiviteterne. Testniveauer og testtyper Aftalte kvalitetssikringsaktiviteter Gatekriterier Ansvarsfordeling for udførelse og godkendelse Forventet indhold i Hovedtestplaner Forventet indhold i Testniveauplaner Forventet indhold i Teststatusrapporter Forventet indhold i Testrapporter Anvendelse af Teststyringsværktøj Testmiljøer Defecthåndtering herunder betydning af status og kategorisering.
4 Teststrategien skal beskrive en risikobaseret tilgang til test og skal lægge vægt på tidlig test. Som et bærende element i den risikobaserede tilgang til test, gennemføres en Pr o- duktrisikoanalyse både som baseline for det samlede produkt (fastholdes i Teststrat egien) og for de enkelte leverancer (fastholdes i Hovedtestplanen). Første baseline PRA gennemføres ifm. udarbejdelsen af Teststrategien. Teststrategien skal sikre design af en tilgang til test og kvalitetssikring, der sikrer, at disse aktiviteter lægges så tidligt som muligt i de enkelte leverancefo rløb. I afsnittene nedenfor er angivet forventede elementer i den udarbejdede teststrategi. Kunden er dokumentansvarlig for udarbejdelse og vedligeholdelse af teststrategien. 3.1 Testforløb For hver leverance, med tilhørende leverancebilag, udarbejdes en hovedtestplan, hvor de specifikke test- og kvalitetssikringsaktiviteter i det pågældende projekt beskrives. A f- hængigt af leverancens indhold og kompleksitet, udarbejdes et antal Testniveauplaner. I figur 10.1 er dokumentstrukturen omkring teststrategi, hovedtestplaner og testniveauplaner skitseret. Figur 10.1
5 3.2 Testniveauer og Testtyper I hovedtestplanen beskrives det hvilke testniveauer, testen til en given lev erance skal omfatte. I forbindelse med test af leverancer opereres der med forskellige testnivea uer. Et testniveau dækker over testaktiviteter, der gennemføres i en bestemt fase i projektfo r- løbet. Med mindre andet aftales mellem Kunden og, vil nedenstående testniveauer være omfattet af testen til en given leverance: Systemtest (ST): Processen at teste et integreret system for at verificere, at det overholder specificerede krav. Udføres af i s testmiljø. Systemintegrationstest (SIT): Test af integrationer af systemer og pakker, test af grænseflader til eksterne organisationer. Udføres af Kunden i Kundens testmiljø. Factory Accepttest (FAT): Accepttest udført på det sted, hvor produktet er udviklet. Udføres af for at afgøre, hvorvidt en komponent eller et system o p- fylder kravene, som normalt omfatter hardware såvel som software. Udføres af i Kundens testmiljø. User accepttest (UAT): Formel test i forhold til brugerbehov, krav og forretning s- processer udført for at fastlægge, om et system opfylder acceptkriterierne, og som gør det muligt for bruger, Kunde eller anden berettiget instans at afgøre, om systemet kan accepteres. Udføres af Kunden i Kundens testmiljø. User accepttest (UAT) inkluderer aktiviteten Overtagelsesprøve jf. Hovedkontraktens pkt. 3.4.5.2 Formålet med overtagelsesprøven er at konstatere, om den aftalte funk tionalitet og Dokumentation som helhed opfylder Leveringsaftalens Kravspecifikation For alle Testniveauer gælder, at disse dels dækker over test af ny funktionalitet eller nye integrationer, dels skal dække over relevant regressionstest vurderet ud fra leverancens indhold. Valg af øvrige testtyper afhænger af leverancens karakteristika, og vil blive sp e- cificeret i Hovedtestplanen. Testen i et givent Testniveau kan dække over flere forskellige Testtyper. Valg af testtyper til brug på en given leverance vil afhænge af leverancens karakteristika og vil blive specificeret i Hovedtestplanen.
6 4. TESTDOKUMENTATION Nedenfor beskrives den testdokumentation, der forventes udarbejdet i forbindelse med leverancer. Kunden stiller skabeloner til rådighed for for al testdokumentation. 4.1 Hovedtestplan Hovedtestplanens formål er at give et overblik over rammerne omkring testen. Hovedtestplanen udarbejdes pr. leverance, og vil som udgangspunkt indeholde beskrivelse af følgende emner: Opgaveformulering og scope med angivelse af, hvilke sager testen dækker Grundlag for Hovedtestplan Beskrivelse af organisation incl. roller, opgaver, ansvar og mødestruktur Beskrivelse af teststatusrapportering Henvisning til relevant dokumentation Henvisning til teststrategi Produktrisikoanalyse Beskrivelse af Testniveauer Beskrivelse af Fremgangsmåde Overordnet tidsplan og milepæle Beskrivelse af Gates og godkendelseskriterier Testmiljøer og infrastruktur Beskrivelse af testproces og defecthåndtering Testrisici Indholdet i Hovedtestplanen specificeres nærmere i Aftaleimplementeringsfasen. er dokumentansvarlig for Hovedtestplanen. Kunden leverer input til Hovedtestplan for de Testniveauer, som Kunden har ansvar for. er ansvarlig for afholdelse af Produktrisikoanalysen, med aktiv deltagelse fra Kunden. leverer en Hovedtestplan forud for opstart af Systemtest til en given leverance. Med mindre andet aftales, leveres Hovedtestplanen senest 10 arbejdsdage forud for opstart af systemtesten.
7 Hovedtestplanen sendes til godkendelse hos Kunden. Har Kunden indsigelser til Hove d- testplanen fremsendes disse til senest 5 arbejdsdage efter Kundens modtagelse af Hovedtestplanen. Har ikke modtaget indsigelser til Hovedtestpl a- nen senest 5 arbejdsdage efter fremsendelse heraf, betragtes Hovedtestplanen som v æ- rende godkendt. Indsigelser til Hovedtestplanen, der ikke umiddelbart kan efterkommes eller som vil me d- føre, at Hovedtestplanen ikke kan godkendes senest 10 arbejdsdage efter den oprindelige leverance af Hovedtestplanen eskaleres til projektleder. Hvis Projektleder ikke kan go d- kende Hovedtestplan, eskaleres der jf. det i Bilag 8 beskrevne styringsorgan. Såfremt indsigelser til Hovedtidsplanen resulterer i rettelse og genfremsend else af Hovedtestplanen, vil fristen for Kundens godkendelse af den reviderede Hovedtestplan være 2 arbejdsdage. Såfremt ikke modtager indsigelse fra Kunden inden fristens udløb, betragtes Hovedtestplanen som værende godkendt. 4.2 Testniveauplan Inden opstart af testen for et givet Testniveau udarbejdes en Testniveauplan. For testniveauerne FAT, SIT og UAT gælder, at Testniveauplan sendes til hhv. Kunde eller Lev e- randør for kommentering. En Testniveauplan uddyber Hovedtestplanen der, hvor det skøn nes nødvendigt, og skal foreligge senest ved opstart af afvikling af det givne testniveau. Testniveauplanen vil som udgangspunkt indeholde beskrivelse af følgende emner: Scope for testniveau med angivelse af, hvilke sager testen dækker Forudsætninger for test Beskrivelse af fremgangsmåde incl. start og acceptkriterier Testmiljø og data Roller og ansvar, inkl. ressourcer Testrelaterede projektrisici og forebyggelse af disse Tidsplan for testaktiviteterne s eller Kundes deltagelse i testaktiviteter, som den anden organisation er ansvarlig for Kontaktperson ved udfordringer vedr. testmiljø, nedbrud mv. Indholdet i Testniveauplanen specificeres nærmere i kontraktimplementeringsfasen.
8 Det fastlægges i Hovedtestplanen, for hvilke Testniveauer i en given leverance, der skal udarbejdes Testniveauplaner. Med mindre andet aftales, udarbejdes der Testniveauplaner for følgende testniveauer: FAT SIT UAT Dokumentansvarlig er for de Testniveauer, som er ansvarlig for og Kunden for de Testniveauer, som Kunden er ansvarlig for. 4.3 Teststatusrapport Under testafvikling for FAT, SIT og UAT rapporteres fremdrift på testen. Teststatusrapporten har til formål at give et overblik over fremdrift i afvikling af testen, oplevede problemer og udfordringer samt at give et overblik over status på fundne fejl. Målgruppen for statusrapport er testens interessenter, herunder leverandørens og kundens Projektl e- dere og Testmanagere. Ansvarlig testmanager for det aktuelle testniveau er ansvarlig for at ud arbejde teststatusrapport. Hyppighed for statusrapporter fremgår af det enkelte projekts Hovedtestplan. Kunden stiller skabelon til rådighed for leverandøren, og der aftales metrikker og tolera n- cer inden testafvikling starter. 4.4 Testniveaurapport Ved afslutning af Testniveauerne Systemtest (ST), Systemintegrationstest (SIT), Factory Acceptance Test og User Acceptance Test (UAT) udarbejdes en Testniveaurapport. Testniveaurapporten sammenfatter testaktiviteter og testresultater. Rapporten har til formål at beskrive testens resultat som den foreligger ved testens afslutning, herunder at beskrive om testen er afviklet som planlagt, at angive eventuelle udeståender samt at angive status på eventuelle åbne defects. har ansvar for udarbejdelse af en Testniveaurapport for de Testniveauer, som har ansvar for. Kunden har ansvar for at udarbejde en Testniveaura p- port for de Testniveauer, som Kunden har ansvar for.
9 Testniveaurapportens specifikke indhold aftales mellem Kundens og Leverandør ens test manager og vil fremgå af teststrategien. Kunden stiller dokumentskabelon til rådighed. Som udgangspunkt vil testrapporten indeholde følgende oplysninger: Testens scope Årsag til evt. afvigelser fra tidsplanen, Opfyldelse af start- og acceptkriterier Testens resultat, herunder tilbageværende risiko ud fra Produktrisikoanalyse Fordeling af fundne defects, samt oversigt over åbne defects Plan for udbedring af eventuelle udeståender Testsporbarhed Konklusion og anbefalinger Testniveaurapporten skal foreligge senest 5 arbejdsdage efter afslutning af testen i et givent Testniveau. Testniveaurapporter for tests gennemført af godkendes af kunden. Har Kunden indsigelser til Testniveaurapporten fremsendes disse til Levera n- døren senest 5 arbejdsdage efter Kundens modtagelse af Testniveaurapporten. Har ikke modtaget indsigelser til Testniveaurapporten senest 5 arbejdsdage efter fremsendelse heraf, betragtes Testniveaurapporten som værende godkendt. Indsigelser til Testniveaurapporten, der ikke umiddelbart kan efterkommes eller som vil medføre, at Testniveaurapporten ikke kan godkendes senest 10 arbejdsdage efter den oprindelige leverance af Testniveaurapporten eskaleres til vurdering i Styregruppen. Såfremt indsigelser til Testniveaurapporten resulterer i rettelse og genfremsendelse af Testniveaurapporten, vil fristen for Kundens godkendelse af den reviderede Testnivea u- rapport være 2 arbejdsdage. Såfremt ikke modtager indsigelse fra Kunden inden fristens udløb, betragtes Testniveaurapporten som værende godkendt 4.5 Specifikation af testcases specificerer testfokus og indhold i systemtest af alle systemændringer, der introduceres som resultat af ændringsanmodninger, fejlrettelser, opgraderinger eller andet. Specifikationen vil ske i form af oprettelse test cases i teststyringsværktøjet og/eller i form af testbeskrivelser i sagsstyringsværktøjet. Design af testcases skal ske gennem struktureret brug af testdesignteknikker.
10 Test cases til FAT udarbejdes af kunden, og genbruges i forbindelse med UAT, dog her suppleret med test af kliniske arbejdsgange. Test casene skal dække validering af alle krav i leverancen, og reviewes af. Se i øvrigt beskrivelse af Gates. 5. REVIEWSTRATEGI Nedenstående afsnit skitserer de overordnede rammer for en reviewstrategi. I teststrat e- gien bliver reviewstrategien yderligere uddybet. Alle dokumenter og produkter jf. bilag 4 Dokumentation kan gøres til genstand for r e- view. Graden af formalisering af reveiwproces afhænger af f. eks. juridiske og lovregulerede krav, behovet for revisionsspor, kompleksiteten i en given leverance mv. Valg af reviewtype afhænger af formålet: at finde defects, at opnå forståelse, skabe di s- kussion eller at opnå konsensus om en beslutning. 5.1 Testarbejdsprodukter og dokumentation der vil være genstand for r e- veiw Testarbejdsprodukter til reveiw Type review Godkendende instans Teststrategi Formelt reveiw Director og Afdelingschef RSD Hovedtestplan Formelt review Testmanager RSD Testniveauplan Uformelt review Testniveaurapport Walk-through Testmanager RSD Testafslutningsrapport Uformelt Projektleder RSD 6. GATES OG GENERISKE GODKENDELSESKRITERIER Dette afsnit beskriver de aftalte Gates med tilhørende kriterier for at kunne overgå til næste Testniveau. Udover generiske gates, vil der for hver leverance være mere eller mindre specifikke opstarts-, afbrydelses- og godkendelseskriterier som skal dokumenteres i de til Testniveauerne tilhørende Testniveauplaner.
11 I nedenstående figur er udviklingsaktiviteter, testniveauer og gates placeret på en tidsli n- je: Foruden de i dette bilag nævnte Gates kan der i Hovedtestplanen tilføjes yderligere g a- tes. I tilfælde hvor opstart af s test forudsætter leverance(r) fra underlev e- randør, kan specifikke gatekriterier for opstart af s test efter leverance fra Underleverandør tilføjes. Såfremt Gates i nedenstående Gatekriterier ikke er opfyldt, gælder følgende eskalation s- vej: Test manager eskalerer til projektledelsen, som herefter har til ansvar at eskalere til styregruppen. 6.1 Gate 0: Overtagelse af standard leverance fra Underleverandør til Gate 0 beskriver kriterier for godkendelse af Standardleverance 1 fra Underleverandør af COSMIC applikationen, inden man kan færdiggøre tilpasning og påbegynde test af de af udviklede danske tilpasninger. Nr Gatekriterie Uddybende beskrivelse Ansvarlig. 1 Releasenote fra Releasenote skal indeholde oversigt over leveret Underleverandør Underleverandør funktionalitet, nødvendige konfigurationsæ n- er modtaget af dringer, oversigt over leverede fejlrettelser og oversigt samt beskrivelse af kendte fejl i leverancen. 2 Releasenote godkendes af s godkendelseskriterier i relation til standard leverancer fra Underleverandør er mødt ( udfylder krav) 1 Standardleverancer fra Underleverandør er Versioner, Releases, Feature Pack og Service Pack
12 3 Godkendt releasenote fremsendes til Kunden 6.2 Gate 1: Overgang fra Krav til Design Nedenfor angives gatekriterier, der skal være opfyldt som forudsætning for, at kan overtage ansvaret for design af endelig løsning. Nr Gatekriterie Uddybende beskrivelse Ansvarlig. Pr krav 1 Krav er angivet Krav skal dokumenteres som del af samlet lø s- Kunden på sagen 2 ningsdokumentation. Krav skal angives på punktform med ét krav pr. punkt. Krav skal være fyldestgørende. Krav skal være realistiske/realiserbare. Krav skal ikke tage afsæt i løsningsdesign. 2 Acceptkriterier er Alle krav skal dækkes af mindst ét acceptkrit e- Kunden angivet på sagen rie. Det skal være angivet hvilket krav, det givne acceptkritere er relateret til. Acceptkriterierne skal være testbare. 3 Krav og acceptkriterier er godkendt Godkendelse sker i form af en angivelse på den enkelte sag i sagsstyringsværktøjet af, at krav og acceptkriterier er modtaget og at de vurderes at opfylde de kriterier, der er angivet i g a- tekriterie 1 og 2. Godkendelse er samtidig en tilkendegivelse af, at vurderer, at de leverede krav og acceptkriterier er tilstrækkelige til at kan udarbejde en løsningsbeskrivelse/specifikation. 2 Termen sagen referer her til pågældende opgave/sag i sagsstyringsværktøjet
13 4 Igangsætning af løsningsspecifikation godkendt 5 Bestilling af opgave eller løsning overholder de i Bilag 13 beskrevne retningslinier. Godkendelse sker i form af en angivelse på den enkelte sag i sagsstyringsværktøjet af, at Kunden godkender, at igangsætter arbejdet med udarbejdelse af en løsningsbeskrivelse. Kunden Kunden 6 Leverancens scope er fastlagt 7 Produktrisikoanalyse er gennemført Pr leverance Aftalt scope er dokumenteret af og godkendt af Kunden jf. milepæl i projektplanen. Leverancens aftalte scope danner udgangspunkt for gennemførelse af en produktrisikoanalyse (PRA). PRA gennemføres med deltagelse af såvel Leverandør som Kunde. Det erkendes, at såvel Kunden som under arbejdet med udarbejdelse af en løsningsbeskrivelse kan blive klogere på, hvad krav og a cceptkriterier til en given opgave skal være. I skabelonen til tidsplanen for en release indsættes derfor en milepæl, der ligger midt i specifikationsforløbet. Denne milepæl angiver tidspunkt for, at krav og a c- ceptkriterier endeligt fastfryses. 6.3 Gate 2 Overgang fra Systemtest til FAT Inden påbegyndelse af Factory Acceptance Test (FAT) hos skal følgende kriterier være opfyldt: Nr. Gatekriterie Uddybende beskrivelse Ansvarlig 1 Testcases til Udarbejdelse af testcases til accepttest påbegy n- Kunden test op mod des når acceptkriterier er godkendt, og leveres acceptkriterier foreligger og er løbende til Leverandør for review og godkende l- se. Test cases skal være endelig godkendt senest
14 Nr. Gatekriterie Uddybende beskrivelse Ansvarlig godkendt af 2 Kunden er informeret om krav til opsætning af konfigurationer i Kundens testmiljø 3 Software applikationen er installeret i Kundens testmiljø 4 Konfigurationer i Kundens testmiljø er etableret jf. konfigurationsbeskrivelse 5 Systemtest hos er afsluttet 6 Evt. åbne defects af kategori 1 og 2 ved FATopstart medfø- 10 arbejdsdage inden planlagt opstart af FAT. Detaljeret plan for Kundens leverance af test cases og for s godkendelse heraf skal fremgå af tidsplanen for projektet. har senest 5 arbejdsdage forud for FAT-testens start fremsendt konfigurationsbeskrivelse (beskrivelse af samtlige konfigurationer i en leverance med anvisning af værdier, såfremt det er der definerer disse) til Kunden om krav til konfigurationer i testmiljøet. Milepæl herfor skal være angivet i projektets tid s- plan. Klienten installeres i Kundens testmiljø jf. insta l- lationsvejledning. Klient skal være installeret min. 5 hverdage inden FAT-opstart, for at Kunden kan sikre konfigurationer i miljøet. Hvis en given leverance indeholder omfattende konfig u- rationer, skal der tages højde for dette med ekstra tid til konfiguration i testmiljøet. Kunden har senest 2 dage forud for start af FATtesten tilrettet konfigurationerne i testmiljøet jf. konfigurationsbeskrivelse, og har informeret s test manager om, at dette er sket. Milepæl herfor skal være angivet i projektet tidsplan. Planlagt test i henhold til PRA er gennemført med tilfredsstillende resultat Kunden
15 Nr. Gatekriterie Uddybende beskrivelse Ansvarlig rer udvidelse af FAT til at omfatte regressionstest i relation til nødvendige fejlrettelser. 6.4 Gate 3: Overgang fra FAT til SIT Inden ansvar for test kan overdrages fra Leverandør til Kunde skal følgende kriterier/krav opfyldes: Nr Gatekriterie Uddybende beskrivelse Ansvarlig. 1 Hovedtestplan er godkendt af Kunden 2 Testniveaurapport for ST og Testansvar kan ikke formelt overdrages til Kunden før den/disse rapporter er modtaget og FAT er modtaget og godkendt godkendt. SIT kan starte op, men ikke afsluttes før leverandørtestrapporter er godkendt. 3 har dokumenteret Det skal fremgå af enten opdateret Hovedtestplan eller Testniveaurapport, hvordan anbefaling til test anbefaler Kunden at teste. Testanbefaling hænger uløseligt sammen med PRA, og tilbageværende risici på tidspunktet for overdragelse af testansvar fra Leverandør til Kunde. 4 Leverancedokument r leveret af Inden overdragelse af testansvar kan finde sted, skal leverancedokument være leveret til Kunden. 3 Leverancer under indeværende kontrakt kan være enten leveranceaftaler eller opgaver. Opgaver ved kan være store projekter ved Kunden, i disse tilfælde udarbejdes Hovedtestplan af Kundens testmanager, ved leveranceaftaler har s testmanager ansvar for udarbejdelse af Hovedtestplanen.
16 Nr Gatekriterie Uddybende beskrivelse Ansvarlig. 5 Overløb fra leverandørens testni- port, og overholder følgende: døren Åbne defects er dokumenteret i testniveaura p- Leveranveauer er indenfor aftalte ram- Ingen 1 og 2 ere Max. 5 3 ere Max. 30 4 ere mer Testniveaurapporten indeholder tillige en a f- hjælpningsplan for åbne defects, uafhængig af alvorlighedsgrad. 6 Reviews jf. strategi er gennemdøren Leveranført 6.5 Gate 4: overgang fra UAT til produktion For at Kunden kan beslutte en godkendelse til ibrugtagning af en leverance, kræves følgende: Nr Gatekriterie Uddybende beskrivelse Ansvarlig. 1 Åbne defects er Åbne defects er dokumenteret i hovedtestra p- Kunden inden for aftalte port, og overholder følgende: rammer i kontrakten Ingen 1 og 2 ere Max. 5 3 ere Max. 30 4 ere indeholder tillige en afhjælpningsplan for åbne defects, uafhængig af alvorlighedsgrad. 2 Afhjælpningsplan udarbejder en afhjælpningsplan for åbne defects for åbne defects, uafhængig af alvorlighed s- er godkendt ved grad, hvor aftalt leverancedato fremgår. kundens releasemanager 3 Overtagelsesprøve godkendes statere, om den aftalte funktionalitet og Dok u- Overtagelsesprøven er en aktivitet der skal kon- Kunden mentation som helhed opfylder Leveringsaft a- lens Kravspecifikation. 4 Ud fra en samlet vurdering anbefaler hvorvidt Kunden kan ibrugtage en leve- anbefaler GO til
17 leverancen 5 Kundens testmanager anbefaler GO til leverancen rance. Planlagt test i SIT og UAT er gennemført med tilfredsstillende resultat. Kunden 6.6 Gate 5: Overgang fra skærpet drift til normal drift Efter godkendt Overtagelsesprøven, gennemføres en driftsprøve jf. Hovedkontraktens pkt. 3.4.5.3. Nr Gatekriterie Uddybende beskrivelse Ansvarlig. 1 Driftsprøven gennemføres Driftsprøven tager sigte på at måle servicemål i Kunden med Kundens normale driftssituation. Driftsprøven tilfredsstillende resultat i kundens driftsmiljø for en given Leverance er bestået, når Kunden har accepteret ophør af Skærpet Drift, som a n- givet i Idriftsættelsesaftalen (se, Hovedkontra k- tens pkt. 3.4.5.3) 2 Skærpet drift Kunden afsluttes, og Systemet er tilbage i normal drift. 7. DEFECTCKLASSIFICERING OG HÅNDTERING I et hvert leveranceforløb gælder følgende: I begge organisationer udpeges en dedikeret medarbejder til at varetage Defectm a- nager-opgaver. Opgaver der varetages af Defectmanager uddybes i Teststrategi. Defectklassificering (en given fejls alvorlighed) afhænger af hvor mange patienter og/eller brugere som bliver påvirket af fejlen, samt hvor alvorlig konsekvensen af fejlen er. En given defects severity definerer hvor hurtig denne fejl skal rettes. Se afsnit 7.1. Defecthåndtering: i teststrategien vil aftalt defectflow fremgå. Heri indgår såvel gyldige statusser og ejer af defects på forskellige tidspunkter i en defects livsc y- klus.
Impact 18 7.1 Severity og leverancetidspunkt En afvigelses alvorlighedsgrad (severity) afgøres af score på hhv. urgency og impact, se nedenstående tabeller. Urgency 1 2 3 1 1 Kritisk 2 - Alvorlig 3 - Betydende 2 2 Alvorlig 2 - Alvorlig 4 Lav 3 3 - Betydende 4 - Lav 4 - Lav Godkendelseskriterier for enkelte testniveauer findes i gatekriterier i kapitel 6. Det tilstræbes, at alle defects fundet i en testperiode leveres rettet til næste tes tperiode på samme testniveau.
Urgency Definition Eksempler 19 1. High Risiko for alvorlig skade ifht. patientsikkerhed, lovovertrædelse, data, sikkerhed, anseelse, økonomi Kan ikke gennemføre en eller flere væsentlige arbejdsprocesser. Ingen realistisk workaround. Svartider forringet i så stor grad at servicen i praksis ikke er tilgængelig. 2. Medium En eller flere væsentlige arbejdsprocesser kan kun gennemføres ved væsentlig ændring i arbejdsprocessen. Man skal anvende uforholdsmæssig meget tid på at løse en opgave. 3. Low Arbejdsprocesser kan gennemføres, evt. ved mindre ændring i arbejdsproces. Det er ikke muligt at logge på systemet Det er ikke muligt at oprette kontakter på patienter Det er ikke muligt at oprette rekvisitioner i ROS Risiko for alvorlig medicineringsfejl Fejlen blokkerer for videre test En eller flere ikke-essentielle funktioner er utilgængelige, men systemet kører fortsat. Performance i en afdelingsliste er dårlig, og en arbejdsgang tager meget længere tid end normalt. Det er ikke muligt at gennemføre afregning på patienter, fejllister hober sig op. Problemstillingen skal løses inden frist for afregning. Kritisk fejl ved alternativ arbejdsgang, men ved brug af standard arbejdsgang fungerer systemet som det skal. Kosmetiske fejl, fokus og tabulatorfejl, stavefejl og ligne n- de. Funktioner i en dialog kan kun anvendes ved brug af mus.
Impact Definition Eksempler 20 1. High Omfang: >100 patienter, >100 brugere Omdømme: Det er betydelig risiko for tab af omdømme/goodwill Driftssikkerhed: Det er betydelig risiko for datatab eller nedbrud 2. Medium Omfang: 20-100 patienter, 20-100 brugere Omdømme: Der er risiko for tab af omdømme/goodwill Driftssikkerhed: Der er risiko for datatab eller nedbrud. 3. Low Omfang: <20 patienter, <20 brugere Driftssikkerhed: Der er minimal risiko for datatab eller nedbrud. Læger kan ikke godkende epikriser Flere sygehus kan ikke oprette nye diktater Der er betydelig risiko for patientsikkerhed App-server cache ryddes ikke, og servere bryder ned med out of memory-fejl. En specifik kontaktårsag kan ikke anvendes i skadekonta k- ter En personalegruppe kan ikke tilgå en sekundær oversigt En type indgående beskeder kan ikke modtages på 3 afdelinger. Plejeplan kan ikke færdiggøres for en patient Genoptræningsplaner kan ikke afsendes for 10 patienter i en afgrænset periode. En afdeling kan ikke redigere i opsætning af overblik
21 7.2 Samarbejde vedr. defects I Teststrategien fastlægges defectflow med gyldige statusser og hvem der har ansvar på et givent tidspunkt i en defects livscyklus. Jf. gatekriterier accepteres en begrænset mængde åbne defects ved overgang mellem testniveauer, og ved overgang fra test til produktion. For at honorere dette, gælder fø l- gende: Defects dokumenteres af tester ved oprettelse. Nødvendig information i en defect - rapport angives i Teststrategien. Såfremt behøver yderligere information, skal defects tildeles Kundens Defect Manager hurtigst muligt for besvarelse. Såvel Kunde som Leverandør forpligter sig til arbejde på at holde turnover-tid på defects så lav som muligt. Det er s såvel som Kundens mål, at en defect, der kræver nyt byg, leveres rettet med først kommende leverance til testmiljøet. 8. TESTDATAMANAGEMENT Det påhviler at stille testdata til rådighed, som overholder gældende dansk lovgivning. Dette forudsætter, at der mellem Kunde og Leverandør findes en løsning på udestående anonymiseringsproblematik ift. komplethed af anonymiseringen. For SIT og UAT gælder, at Kunden ønsker nedenstående behov i relation til testdata o p- fyldt. Kundes testmiljø indeholder relevante testdata inden testafvikling på aktuelt testniveau kan starte Kundens testmiljø indeholder kopi af konfiguration fra produktionsmiljøet Testdata er anonymiseret, og anonymisering overholder gældende dansk lovgi v- ning Sammensætningen af testdata skal være repræsentativ, svarende til fordeling af produktionsdata Testdata skal kunne bruges i test af integrationer/3. partssystemer. Dog vil ansv a- ret for oprettelse af specifikke testdata, der modsvarer testdata i 3. partssystemer påhvile Kunden.
22 Testdata skal indeholde Test-CPR-numre, som kan anvendes i Kundens test-cprkomponent. Ansvaret for oprettelse af disse CPR-numre ved at de pushes over i COSMIC fra regional CPR-komponent vil påhvile Kunden. Nationale test-cpr-numre, der anvendes af CPR-kontoret, må ikke manipuleres. Ansvaret for oprettelse af disse CPR-numre ved at de pushes over i COSMIC fra regional CPR-komponent vil påhvile Kunden. Testdata indlæses/restores minimum 2 gange årligt eller efter aftale. Som en del af at KÆ67 implementeres, sikres at nedenstående punkter er opfyldt i den fuldt anonymiserede database: Anonymiseringsscript udvides, så det kan rumme en fuld produktionskopi uden redundans i CPR-numre i testdata. Som led i anonymisering slettes alle EPJ-notater eller al fritekst erstattes med tegnet X i nøgleord af typen fritekst i notaterne. Dog fastholdes alle notater indeholdende procedure- og diagnosekoder. Anonymiserede CPR-numre skal have fiktive gadeadresser, men (anonymiserede) postnumre og gyldig kommunetilhørighed. Såfremt ved aftaleindgåelse ikke kan opfylde ovennævnte krav, forpligter sig til at i løbet af aftaleimplementeringsperioden at udarbejde en tidsplan for hvornår Kunden kan forvente ovennævnte krav opfyldt. I kontraktens løbetid vil der opstå behov for test på ikke-anonymiserede produktionsdata. I disse tilfælde forpligter leverandøren sig til at stille disse data til rådighed i et testmiljø med adgangskontrol og logning, svarende til produktionsmiljøet. 9. SOM DEL AF SOFTWARE ASSURANCE FORPLIGTER LEVERANDØREN SIG I ØVRIGT TIL AT UDVIKLE EN MERE KOMPLET LØSNING IFHT. HÅNDTERING AF TEST DATA MANAGEMENT. DETTE ER INDEHOLDT I ROADMAP FOR STANDARDPRODUKTET, MEN ENDNU IKKE PLANLAGT TIL EN SPECIFIK RELEASE. KUNDEN VIL BLIVE INDDRAGET I DIALOGEN MED UNDERLEVERANDØREN HEROM, SOM BESKREVET I BILAG 3, KAPITEL 5.TESTMILJØER OG INFRASTRUKTUR Som minimum skal Kunden have to testmiljøer, svarende til et testmiljø for kommende release (test 1), og et forvaltningstestmiljø svarende til produktion (test 2). Krav til
23 hardware og infrastruktur beskrives i driftskontrakt. Krav til servicemål mm. beskrives i bilag 5 Servicemål. Såfremt en Leveringsaftale kræver andet setup i forhold til testmiljøer, skal dette afklares og aftales i pågældende aftale. Følgende krav til testmiljø gælder ved testafvikling: Stabilt testmiljø: testmiljøet skal fungere stabilt, uden uplanlagt arbejde som insta l- lation og konfiguration Overvågning: har fokus på maksimal oppetid og proaktiv håndtering af eventuelle problemer i testmiljøerne. Kunden skal som minimum have adgang til teknisk hotline for support under testperioder. Transparens: Synlig status på testmiljøer Alle testmiljøer skal være forberedt til at kunne bruge Test-Regis. Kunden forventer kun behov for 2 testmiljøer koblet op mod Test-Regis. Hvis denne forventning viser sig ikke at holde, vil det være op til den enkelte Leveranceaftale at fastlægge rammer herfor. 10. TESTSTYRINGSVÆRKTØJ stiller teststyringsværktøj til rådighed for kunden (aktuelt Quality Center). kan i kontraktperioden vælge at skifte system, blot det nye system har ti l- svarende funktionalitet som det eksisterende. Såfremt vælger at udskifte teststyringsværktøj, påhviler det at flytte Kundens testcases mm. I teststyringsværktøjet dokumenteres følgende: Testcases og -scrips Defects Sporing mellem krav og testcases Sporing mellem testcases og produktrisiko Resultater af test Med baggrund i teststyringsværktøj overvåges og rapporteres på fremdrift indenfor fø l- gende hovedområder: Fremdrift i udarbejdelse af testcases, inkl. kravdækning jf. udarbejdede testcases Fremdrift på afvikling af testcases
24 Fremdrift på defecthåndtering og fejlrettelse
25 Appendiks A Leverancer og ansvarsfordeling Nedenfor angives en oversigt med beskrivelse af ansvarsfordeling i relation til de i Bilag 10 beskrevne opgaver og leverancer. Afsnit Leverance Opgave Ansvarlig Bidragyder Godkender 3. Teststrategi Dokumentansvarlig Kunden Leverandør Kunde og for udarbejdelse og Leverandør vedligeholdelse af Teststrategi 3.2 Systemtest (ST) 3.2 SystemIntegrationsTest (SIT) 3.2 Factory Acceptance Test (FAT) 3.2 User Accepttest (UAT) Forberedelse og Leverandør udførelse af testen Forberedelse og Kunden udførelse af testen Forberedelse og Leverandør udførelse af testen Forberedelse og Kunden udførelse af testen 4.1 Hovedtestplan Dokumentansvarlig Kunden Kunden for udarbejdelse af Hovedtestplan 4.1 ProduktRisiko- Analyse (PRA) 4.2 Testniveauplan for Systemtest (ST) 4.2 Testniveauplan for FactoryAcceptTest (FAT) Ansvarlig for afholdelse Leverandø- Kunden og dokuren mentation af ProduktRisikoAnalyse Udarbejdelse af Testniveauplan Udarbejdelse af Testni- Testniveauplan veauplan- sendes til kommente-
26 Afsnit Leverance Opgave Ansvarlig Bidragyder ring hos Kunden 4.2 Testniveauplan Udarbejdelse af Kunden Testni- for SystemIntegrationsTessendes Testniveauplan veauplan- til (SIT) kommentering hos 4.2 Testniveauplan Udarbejdelse af Kunden Testni- for UserAcceptTest (UAT) sendes til Testniveauplan veauplan- kommentering hos 4.3 Teststatusrapportskabelon 4.3 Teststatusrapport for FATtest 4.3 Teststatusrapport for SITtest 4.3 Teststatusrapport for UATtest 4.4 Dokumentska- Udarbejdelse og Kunden vedligeholdelse af skabelon for Teststatusrapporter Udarbejdelse af Teststatusrapport Udarbejdelse af Kunden Teststatusrapport belon for vedligeholdelse af ren TestNiveau- Rapport skabelon for Test- NiveauRapporter Udarbejdelse af Kunden Teststatusrapport Udarbejdelse og Kunden Leverandø- Godkender
27 Afsnit Leverance Opgave Ansvarlig Bidragyder 4.4 Testniveaurapport Udarbejdelse af Leverandø- efter Testniveaurapport ren afsluttet Systemtest (ST) 4.4 Testniveaurapport Udarbejdelse af Kunden efter Testniveaurapport afsluttet SystemIntegrationsTest (SIT) 4.4 Testniveaurapport Udarbejdelse af Leverandø- efter Testniveaurapport ren afsluttet FactoryAcceptanceTest (FAT) 4.4 Testniveaurapport Udarbejdelse af Kunden efter Testniveaurapport afsluttet Use- racceptance- Test (UAT) 4.5 Test cases til Systemtest (ST) 4.5 Test cases til FactoryAcceptTest (FAT) og UserAcceptTest (UAT) 4.5 Test cases til SystemIntegrationsTest (SIT) Specification af test cases til Systemtest (ST) Specification af Kunden test cases til FactoryAcceptTest (FAT) og UserAcceptTest (UAT) Specification af Kunden test cases til Sy- stemintegrations- Test (SIT) 5 Testafslut- Udarbejdelse af Kunden Godkender Kunden Kunden
28 Afsnit Leverance Opgave Ansvarlig Bidragyder Godkender ningsrapport Testafslutningsrapport 6.2 Krav Krav angivet på Der henvises til bilag 4 - Dokumentation sagen 6.2 Acceptkriterier Acceptkriterier angivet på sagen Der henvises til bilag 4 - Dokumentation 6.3 Leverancedokument Udarbejdelse af Der henvises til bilag 4 - Dokumentati- incl. Leverancedokuon oplysning om ment incl. oplysning konfigurationetioner om konfigura- 6.3 Software applikatioon Software applikati- Leverandø- installeret i ren Kundens testmiljø 6.3 Konfigurationer Konfigurering i Kunden Kundens testmiljø 8 Testdata Testdata stilles til rådighed 10 Teststyringsværktøj Teststyringsværktøj stilles til rådighed