Bilag 14. Prøver. Til Kontrakt. Den Nationale Henvisningsformidling

Bilag 14 Prøver Til Kontrakt OM Den Nationale Henvisningsformidling Bilag 14 Prøver Side 1/25

INSTRUKTION TIL TILBUDSGIVER: Bilag 14 skal gennemarbejdes af Tilbudsgiver som del af tilbuddet. Udfyldelse skal ske i overensstemmelse med nedenstående retningslinjer. Formål med bilag: Formålet med Bilag 14 er at beskrive Kundens ønskede niveau og mængde af test af Løsningen. Instruks vedrørende bilag: Tilbudsgiver skal i sin besvarelse vedlægge et Bilag 14A som udgør selve Hovedtestplanen. Endvidere skal konkurrencekravene jf. pkt. 14.14 besvares i underbilag 3C Ordregiver Konkurrencekrav. Kundens deltagelse under prøveforløb og lignende hvor Leverandøren er ansvarlig angives i tilknytning til Bilag 11 om Kundens deltagelse. Evaluering af besvarelse: Tilbudsgivers besvarelse af bilaget indgår i tilbudsevalueringen i tilknytning til underkriteriet Kvalitet i Leverancen. Evalueringskriterierne er anført i bilaget i tilknytning til de enkelte konkurrencekrav. Udbudsbetingelsernes bilag X: Det vil være muligt at angive forbedringsforslag i Udbudsbetingelsernes bilag X, Leverandørens forbedringsforslag. Sådanne forslag kan blive drøftet i forhandlingsfasen, men vil ik ke nødvendigvis blive det. Bilag 14 Prøver Side 2/25

14.1 INDLEDNING... 4 14.2 OPBYGNING AF HOVEDTESTPLAN... 4 14.2.1VARIATIONER I OPBYGNINGEN AF HOVEDTESTPLANEN... 5 14.3 KRAV TIL DEN OVERORDNEDE TIDSPLAN... 5 14.4 PRØVER OG TEST... 6 14.4.1 FABRIKSPRØVE... 6 14.4.2 FUNKTIONSPRØVE... 7 14.4.3 HOVEDLEVERANCEPRØVE... 7 14.4.4 DELLEVERANCEPRØVE... 9 14.4.5 OVERTAGELSESPRØVE... 9 14.4.6 DRIFTSPRØVE... 10 14.5 TIDSPLAN OG TESTFORLØB... 11 14.6 TESTPLANER... 12 14.7 TESTMILJØER... 12 14.7.1 KONFIGURATIONSSTYRING... 13 14.8 TESTDATA OG TESTCASES... 13 14.8.1 TESTDATA... 13 14.8.2 TESTCASES... 15 14.9 TESTVÆRKTØJER... 15 14.9.1 FEJLRAPPORTERINGSVÆRKTØJ OG STYRING AF TESTCASES... 15 14.10 TESTGENNEMFØRELSE... 16 14.11 FEJLKATEGORISERING... 16 14.11.1 REAKTIONER VED FEJL... 18 14.12 RAPPORTERING AF RESULTATER... 20 14.12.1 HÅNDTERING AF HÆNDELSER OG STATUSRAPPORTERING... 20 14.12.2 RAPPORT OVER PRØVE-/TESTFORLØBET... 20 14.12.3 GODKENDELSE AF PRØVE/TEST... 20 14.12.4 FEJLTOLERANCER... 21 14.13 ORGANISATION, ROLLER OG ANSVAR... 22 14.14 OVERSIGT OVER KRAV TIL TEST... 23 Bilag 14 Prøver Side 3/25

14.1 Indledning Dette bilag skal opfattes som en beskrivelse af det ønskede niveau og mængde af test af Løsningen. I dette er også en samling af mindstekrav til test. Bilaget beskriver de typiske krav til hver enkelt prøve og test, og dokumenterer hvornår den er bestået. Bilaget beskriver også den tidsmæssige udvikling i testforløbet og fordeler ansvaret for de enkelte prøver og test. Ansvaret for og frekvens af rapportering defineres også. Hvor en delmængde af test eller testmæssige aspekter udgør konkurrencekrav, er dette specificeret i bilaget. Jo bedre Leverandørens besvarelse rummer det foreslåede niveau og mængde af test, eller anvender velbegrundede alternativer, jo flere point vil besvarelsen blive tildelt. Foruden beskrivelser af de forskellige krav er der i slutningen af bilaget en opsummering af kravene i en kravboks. Denne tjener til hurtig reference, men erstatter ikke resten af dokumentet. 14.2 Opbygning af Hovedtestplan Leverandøren skal i sin besvarelse af dette bilag beskrive den Hovedtestplan som Leverandøren forventer at bruge i forbindelse med sin del af testarbejdet. I denne skal Leverandøren beskrive hvordan det koordinerede testarbejde som foregår i samarbejde med Kunden kan se ud. Ydermere skal det beskrives hvordan og hvad Kunden forventes at teste. Beskrivelsen skal indeholde følgende punkter: Prøve- og testtyper: Beskrivelse af de forskellige test og deres indbyrdes forventede vægtning. Tidsplan og testforløb: Hvordan er den tidsmæssige fordeling af de individuelle test under forløbet? Fasetestplaner: Hvordan er den individuelle plan for hver test? Testmiljøer: Hvilke miljøer er der brug for? Testdata og testcases: Hvad er der brug for og hvordan skabes det? Testværktøjer: Hvilke testværktøjer anvendes? Testgennemførelse: Beskrivelse af processen til gennemføring af prøver og test. Reaktioner ved fejl: Hvilke procedurer og flow skal anvendes? Prioritering: Hvordan prioriteres fundne fejl ift. hinanden? Rapportering af resultatet: Hvordan rapporteres testresultater? Organisation, roller og ansvar: Den organisatoriske opbygning af testorganisationen beskrives. Produktrisikoanalyse: Hvilke risici er forbundet med produktet i forløbet? Sporbarhed: Hvordan sikres sporbarhed fra krav til test gennem testforløbet? Besvarelsen skal dække følgende vinkler på afprøvningen: Testtilgang: Hvilke principper og arbejdsmetoder anvendes til testarbejdet? Testmæssig risikostyring: Hvilke risici imødegås med teststyringen? Testdækning: Hvor stor en del af målsætningen vil de planlagte test rumme? Beskrivelsen i Hovedtestplanen bør være informativ og dækkende, således at Kunden får indsigt i hvordan Leverandøren opfatter testforløbet. Dette er et konkurrencekrav. Besvarelsen skal indeholde Leverandørens forventede tidsplan for test, samt angivelse af allokerede ressourcer. Dette kan være indeholdt i hhv. tidsplanen for projektet og bilaget med Kundens ressourcer, men skal være specificeret i detaljer. Kunden vægter tidlig test, samt kontinuerlig test under forløbet højt. Denne tilgang er ligeledes et konkurrencekrav. Tidlig test skal stadig være realistisk og meningsfyldt. Bilag 14 Prøver Side 4/25

14.2.1Variationer i opbygningen af Hovedtestplanen Variation 1 Leverancen kan testes som beskrevet i det følgende. Der er tale om et vejledende forslag der er bygget på anerkendte principper og Kundens erfaringer. Kunden anerkender at Leverandøren kan vælge at beskrive et anderledes forløb på baggrund af kendskab til produktet eller andre forhold. Uagtet forløbet forventer Kunden dog at leverancens komponenter er testet inden første test hos kunden påbegyndes, og at testen sammensættes så den både er dækkende og forudseende. Leverandøren skal fremsende testrapporter over de udførte test således at Kunden bliver bekendt med produktets kvalitet. Der er begrænsninger for variationer. Generelt vil der være større frihed i starten af testforløbet, mens der er mindre rum for variation senere i testforløbet. Således må Hovedleveranceprøve, Overtagelsesprøve og Driftsprøve ikke undlades. En sund Hovedtestplan vil typisk indeholde en række prøver, hvor hver prøve indeholder en række test. Et eksempel er indeholdt forneden. Oversigt over prøver: Fabriksprøve Funktionsprøve Hovedleveranceprøve Delleveranceprøve Overtagelsesprøve Driftsprøve Variation 2 Det antages at Delprojekt 1 vil blive efterfulgt af Delprojekt 2. Hvis dette sker, vil testen være opbygget som illustreret i efterfølgende tabel. Tabellen definerer den samlede tidsplan for de enkelte prøvers indhold af test, hvem der er typisk er ansvarlige for dem, og henvisninger til nærmere defineringer af de enkelte test. 14.3 Krav til den overordnede Tidsplan Delprojekt 1 Prøve Test Henvisning Hovedansvarlig / deltager Fabriksprøve Komponenttest Leverandør Komponentintegrationstest 14.4.1 Leverandør Systemtest Leverandør Funktionsprøve IT-tilgængelighedstest Leverandør Funktionel kravtest 14.4.2 Leverandør Systemintegrationstest Leverandør / Kunde Hovedleveranceprøve Funktionel kravtest Leverandør / Kunde 14.4.3 Failovertest Leverandør Bilag 14 Prøver Side 5/25

Migreringstest Leverandør / Kunde Kodereview (eventuel) 3. Part Dokumentationstest Leverandør / Kunde Delprojekt 2 Delleveranceprøve Funktionel kravtest Leverandør / Kunde Systemintegrationstest 14.4.4 Leverandør / Kunde Regressionstest Kunde Dokumentationstest Kunde / Leverandør Overtagelsesprøve Brugeraccepttest Kunde / 3. Part Sikkerhedstest 14.4.5 Leverandør / Kunde / 3. Part Belastningstest Leverandør / Kunde Kodereview (eventuel) 3. Part Delprojekt 3 Driftsprøve Driftstest 14.4.6 Kunde Tabel 1. Oversigt over prøver og test En prøve omfatter en eller flere test, som illustreret i ovenstående tabel. Hvis Kunden beslutter at afstå fra Delprojekt 2, vil indholdet i overtagelsesprøven overgå til hovedleveranceprøven, og gennemføres som led heri. Hovedleveranceprøven vil i dette tilfælde blive benævnt overtagelsesprøve. Det er et mindstekrav at alle tests som man vælger at inkludere i testplanen gennemføres, dokumenteres, og resultaterne er sporbare fra krav til udført test. Ud over de beskrevne test står det Leverandøren frit at gennemføre andre test efter behov. Disse skal meddeles Kunden inden start af testperioden. 14.4 Prøver og test 14.4.1 Fabriksprøve Fabriksprøven gennemføres hos Leverandøren som et led i egen kvalitetssikring af løsningen. Dette omfatter afprøvning og fejlretning af systemets funktionalitet inden tilslutning/frigivelse til Kundens it-miljø. Formålet er at kontrollere, at den aftalte funktionalitet er funktionsdygtig og har en kvalitet som giver Leverandøren og Kunden en forventning om, at Leverancen opfylder de kriterier, der testes i de efterfølgende prøver. Der er ikke krav om at Kunden gøres bekendt med hvad Leverandøren lader indgå i fabriksprøven, men Kunden skal informeres om hvilke elementer/objekter der godkendes under fabriksprøven. Fabriksprøven skal være godkendt inden systemet frigives til Kundens første testaktivitet. For fabriksprøven gælder at testdokumentationen skal gøres tilgængelig for Kunden. Dokumentationen skal som minimum indeholde oplysninger om tidsperioden for testforløbet, antallet af testressourcer tilknyttet, samt oplysninger Bilag 14 Prøver Side 6/25

om antal og natur af fundne fejl og resterende/åbne fejl. Testrapporten skal ligeledes gøres tilgængelig for Kunden. Hvis Kunden vurderer at der er signifikant forskel mellem testrapportens indhold og systemets kvalitet som dokumenteret ved test hvor Kunden medvirker, kan Kunden kræve fabriksprøven gentaget. Fabriksprøven kan bestå af følgende test: Komponenttest Testen har til formål at afprøve om de individuelle softwarekomponenter virker efter hensigten. Fokus er på at finde alle programmeringsfejl så de efterfølgende kan rettes. Komponentintegrationstest - Tester om de udviklede/tilrettede komponenter, som indgår i Leverancen, fungerer sammen indbyrdes. Testen har fokus på grænseflader og samspil mellem komponenter. Systemtest Tester at alle funktioner beskrevet i kravspecifikationen er til stede, og fungerer efter hensigten. Prøven skal leve op til disse slutkriterier for at den kan godkendes: De inkluderede tests er gennemført Der foreligger en testrapport der dokumenterer resultaterne. Testrapporten skal godkendes af Kunden. Resultaterne fra tests ligger indenfor fejlmargin (afsnit 4.7 i tabel 7). 14.4.2 Funktionsprøve Funktionsprøven indeholder test af afgrænsede delmængder af Leverancen, grupperet i enkelte test. Leverandøren udformer prøven, der udføres som funktionstest, hvor det kontrolleres, at den aftalte funktionalitet, herunder integration til andre systemer og dokumentation, er leveret i en tilfredsstillende kvalitet. Der skal for hver test foreligge en detaljeret fasetestplan (se afsnit 14.6) som Kunden skal godkende. Funktionsprøven indeholder følgende test: IT-tilgængelighedstest Afprøver om de enkelte elementer lever op til standarder og retningslinjer for tilgængeligt webdesign. Funktionel kravtest - Tester alle funktionelle krav til Leverancen Systemintegrationstest Tester grænseflader og samspil mod andre systemer Prøven skal leve op til disse slutkriterier for at den kan godkendes: De inkluderede tests er gennemført Der foreligger en testrapport der dokumenterer resultaterne Resultaterne fra test ligger indenfor fejlmargin (afsnit 4.7 i tabel 7) 14.4.3 Hovedleveranceprøve Hovedleveranceprøven indeholder test af hele Leverancen, hvor det systematisk testes om alle funktionelle krav er opfyldt. Det testes også hvordan failover på Leverancen fungerer, ved at simulere nedbrud på forskellige elementer af Løsningen. Funktionel kravtest og failovertest udføres begge som funktionstest, hvor det kontrolleres, at den aftalte funktionalitet, herunder integration til andre systemer og dokumentation, er leveret i en tilfredsstillende kvalitet. Bilag 14 Prøver Side 7/25

Ydermere skal det testes at Løsningen kan modtage og håndtere migrerede data hensigtsmæssigt, det er dog ikke sikkert at denne test (Migreringstesten) udføres som en del af Hovedleveranceprøven. Tidspunktet for migreringstesten bestemmes af en mængde faktorer og vil blive defineret under afklaringsfasen. Løsningen vil også blive testet af slutbrugere under en. Testens formål er at dokumentere hvor der er fejl og mangler ift. brugernes behov for funktionalitet i Løsningen. Brugerne til testen skal være klinikere der har erfaring med anvendelse af den hidtidige løsning, Henvisningshotellet. Endvidere forbeholder Kunden sig ret til at lade et uvildigt analyselaboratorium måle kvaliteten af kildekoden. Hvis Kunden beslutter sig for dette, vil det finde sted under Hovedleveranceprøven. Inspektionen vil ske i henhold til ISO/IEC 25010 standard for Software Product Maintainability. Hvis kildekoden opnår en score på 3,0 eller mere iht. ovennævnte standard, er testen bestået. Hvis den opnåede score er mindre end 3,0 er testen ikke bestået. Endelig vil der blive udført en dokumentationstest hvor det testes om al den nødvendige dokumentation er til stede og tilgængelig for Kunden. Leverandøren leverer input til dokumentationstesten der udføres som review af mængde og kvalitet af dokumentationen. Der skal for hver test foreligge en detaljeret fasetestplan som Kunden skal godkende. Hovedleveranceprøven indeholder følgende test: Funktionel kravtest - Tester alle funktionelle krav til Leverancen Failovertest - Tester om Leverancen reagerer planmæssigt i tilfælde af, at der sker nedbrud på de enkelte systemkomponenter/systemet i drift. Migreringstest Tester om eksisterende data fra Henvisningshotellet kan migreres over i Den Nationale Henvisningsformidling uden ændringer i volumen eller kvalitet Tester via slutbrugernes brug af Løsningen om de forventede funktioner er tilgængelige og i funktionsduelig stand. Kodereview måler kvaliteten af kildekoden. Testen er eventuel. Dokumentationstest - Tester via review om den aftalte dokumentation opfylder kravene Hvis Kunden vælger at afstå fra Delprojekt 2 vil der yderligere blive gennemført de forskellige test der er angivet under Overtagelsesprøve : Brugeraccepttest En repræsentativ gruppe af brugere afprøver den implementerede Leverances brugervenlighed. Sikkerhedstest - Tester om Leverancen lever op til sikkerhedskravene defineret i bilag 2. Belastningstest Tester via simulerede belastninger at Løsningen kan håndtere den forventede mængde samtidige, aktive brugere og overholder servicemålene defineret i bilag 6. Prøven skal leve op til disse slutkriterier for at den kan godkendes: De inkluderede tests er gennemført Der foreligger en testrapport der dokumenterer resultaterne Resultaterne fra test ligger indenfor fejlmargin (afsnit 4.7 i tabel 7, samt servicemål i bilag 6) Prøven gennemføres hovedsagelig af Leverandøren, med assistance fra Kunden. Bilag 14 Prøver Side 8/25

14.4.4 Delleveranceprøve Det antages at der under implementeringsforløbet vil blive identificeret behov for funktionalitet, som ikke er en del af den oprindelige kravspecifikation. Til at håndtere testen af ny funktionalitet der udvikles for at dække disse behov, foretages der et antal delleveranceprøver af det programmel der udvikles under Delprojekt 2. Såfremt Kunden vurdere at der ikke er behov for Delprojekt 2, bortfalder delleveranceprøven. Formålet med de delleveranceprøverne er at konstatere, om den aftalte funktionalitet og dokumentation for delleverancerne er leveret, og at funktionaliteten fungerer korrekt i samspil med andre komponenter. Det forventes at der vil finde flere delleveranceprøver sted og at de kan startes dynamisk under de iterative forløb. Med dette forstås at testen kan påbegyndes så snart der leveres komponenter/elementer til test. Hvert enkelt iterativt forløb afsluttes med en test af forløbets scope af funktionalitet. Det testes også om dokumentationen er til stede i korrekt mængde og kvalitet, og der foretages en regressionstest af Løsningens kerneydelser. Delleveranceprøver indeholder følgende tests: Funktionel kravtest - Tester alle funktionelle krav til Leverancen Systemintegrationstest Tester grænseflader og samspil mod andre systemer Dokumentationstest - Tester via review om den aftalte dokumentation opfylder kravene Regressionstest Tester tilstanden af Løsningens kerneydelser Prøven skal leve op til disse slutkriterier for at den kan godkendes: De inkluderede tests er gennemført iht. deres forudsætninger og individuelle specifikationer Der foreligger en testrapport der dokumenterer resultaterne. Testrapporten skal godkendes af Kunden Resultaterne fra tests ligger indenfor fejlmargin (se afsnit 14.13, tabel 7) Prøven gennemføres af Leverandøren, med assistance fra Kunden. 14.4.5 Overtagelsesprøve Formålet med overtagelsesprøven er at konstatere, om Løsningen lever op til den oprindelige kravspecifikation. Overtagelsesprøven skal afholdes uanset om Delprojekt 2 iværksættes eller ej. Overtagelsesprøven indeholder følgende tests: Brugeraccepttest Afprøver den implementerede Leverances brugervenlighed med en repræsentativ gruppe af brugere. Sikkerhedstest - Tester om Leverancen lever op til de krav til sikkerhed, der er stillet i bilag 2. Belastningstest Tester via simulerede belastninger at Løsningen kan håndtere den forventede mængde aktive brugere og overholder servicemålene. Kodereview måler kvaliteten af kildekoden (denne test er eventuel) Overtagelsesprøven kan startes når de forudgående prøver er godkendte. Således startes overtagelsesprøven når Hovedleverancen er testet og godkendt, hvis Kunden beslutter at udelade Delprojekt 2. Hvis Delprojekt 2 gennemføres, kan overtagelsesprøven påbegyndes når leverancerne fra delprojektet er implementerede og testmæssigt godkendte. Der kan dog være elementer som bliver afprøvet tidligere, såsom brugeraccepttesten der kan påbegyndes med demonstrationer/workshops med brugere, for at få tidlige reaktioner på planlagt design. Således kan Bilag 14 Prøver Side 9/25

visse dele af overtagelsesprøven gennemføres sideløbende med andre prøver/test. Andre dele, såsom belastningstest, kan ikke gennemføres før at de forudgående prøver og test er afsluttet. Belastningstesten vil altid være den sidste test der gennemføres under Overtagelsesprøven. Ved overtagelsesprøvens gennemførelse skal der foretages en konstatering af, om systemet opfylder de i Bilag 6 anførte servicemål. Dette testes gennem simulerede belastninger, som gennemført i belastningstest. Belastningstest - Tester om Leverancen overholder de specificerede krav til ydeevne (kapacitet, stabilitet og robusthed) som fremgår af Bilag 6, Servicemål. Denne test er vigtig idet Kunden har dårlige erfaringer med andre løsninger som har været underdimensionerede, og slutbrugere har underkendt løsningerne. Kunden kan vælge at lade et uvildigt analyselaboratorium gennemføre et yderligere kodereview ifm. Overtagelsesprøven. Kravene vil være de samme som til det kodereview der er nævnt i 14.4.3. Prøven skal leve op til disse slutkriterier for at den kan godkendes: De inkluderede tests er gennemført iht. deres forudsætninger og individuelle specifikationer Der foreligger en testrapport der dokumenterer resultaterne. Testrapporten skal godkendes af Kunden. Resultaterne fra test ligger indenfor fejlmargin (afsnit 4.7 i tabel 7, samt Bilag 6 - Servicemål) Når testen afsluttes skal det være dokumenteret hvordan de enkelte henvisningstyper opfylder kravene fra overtagelsesprøven. Leverandøren bedes beskrive hvordan testen tænkes gennemført. 14.4.6 Driftsprøve Inden driftsprøven påbegyndes, skal overtagelsesprøven være godkendt af Kunden. Driftsprøven påbegyndes først, når Kunden har givet Leverandøren meddelelse herom. Driftsprøven gennemføres af Kunden med Leverandørens medvirken, og udføres for Systemet som helhed. Driftsprøven skal afholdes uanset om Delprojekt 2 iværksættes eller ej. Formålet med driftsprøven er at konstatere, at Leverancen er implementeret, taget i brug og fungerer iht. specifikationerne, med særlig fokus på opstillede servicemål, jf. Bilag 6. Under driftsprøven har Leverandøren ret og pligt til løbende at optimere Systemets ydeevne i det omfang, at det måtte være nødvendigt, samt afhjælpe eventuelle konstaterede mangler. Desuden skal Leverandøren være Kunden behjælpelig i forbindelse med besvarelse af Kundens spørgsmål vedrørende brug af Systemet, herunder yde hotline service etc. i det omfang som er specificeret i servicebilaget. Hvis Kunden vurderer at systemet er væsentlig forandret under driftsprøven, eller at forudsætningerne for testen har ændret sig, kan Kunden kræve at driftsprøven startes forfra. Driftsprøven skal omfatte mindst 40 Arbejdsdage i træk, hvori Systemet har været i drift med normale funktioner. Driftsprøven vil udgøre en bred brug af systemet, men med særligt fokus på leverancens kerneydelser. Test med særligt fokus på kerneydelser vil herefter udgøre regressionstesten. Fristen for driftsprøvens afslutning skal fremgå af Leverandørens Hovedtestplan (bilag 14a). Bilag 14 Prøver Side 10/25

14.5 Tidsplan og testforløb I nedenstående tabel fremgår det hvordan de enkelte prøver og test afhængighedsmæssigt ligger i forhold til hinanden, og hvorvidt der kan være overlap. Delprojekt 1 Prøve Test Sekventiel Parallel Kommentarer Fabriksprøve Komponenttest Komponentintegrationstest Systemtest Funktionsprøve (Afhænger af Leverandørens proces) (Afhænger af Leverandørens proces) (Afhænger af Leverandørens proces) IT-tilgængelighedstest x IT-tilgængelighedstest vil typisk indlede efterfølgende test og udføres dermed ofte simultant. Funktionel kravtest x Kan kombineres med anden test Systemintegrationstest x Kan kombineres med anden test Hovedleveranceprøve Funktionel kravtest x Kan kombineres med anden test Failovertest X Kræver at systemet ikke bruges af andre Migreringstest X Kræver at datagrundlaget ikke forandres Brugeraccepttest X Kræver at systemet ikke bruges af andre Kodereview x Kan udføres når kildekoden er tilgængelig Dokumentationstest x Kan udføres når dokumentation er tilgængelig Delprojekt 2 Delleveranceprøve Funktionel kravtest x Kan kombineres med anden test Systemintegrationstest x Kan kombineres med anden test Regressionstest x Kan kombineres med anden test Dokumentationstest x Kan udføres når dokumentation er tilgængelig Overtagelsesprøve Brugeraccepttest x Kan udføres når funktionaliteten er på plads Sikkerhedstest x Kan kombineres med andre test Belastningstest X Kræver at systemet ikke bruges af andre Kodereview x Kan udføres når kildekoden er tilgængelig Delprojekt 3 Driftsprøve Driftstest X Kræver at der kører ren drift Tabel 1. Oversigt over afhængigheder mellem de planlagte test. Bilag 14 Prøver Side 11/25

14.6 Testplaner Hovedtestplanen for projektet suppleres af en testplan for den enkelte test/prøve. Testplanen for en given test eller prøve udarbejdes af den part der er ansvarlig for gennemførelse af testen/prøven (Kunden eller Leverandøren). En testplan for en test kaldes en fasetestplan. Der skal være sporbarhed mellem alle elementer i testen. Fra testplanen og teststrategien og mellem testplanen og kravene som er beskrevet i bilag 3 og de tilhørende underbilag samt andre relevante bilag, der udtrykker krav der testes. Dette betyder at der skal være en struktur, fx en træstruktur, der gør det muligt at følge sammenhængen fra et element til et andet forbundet element. Det kan fx være fra løsningsbeskrivelsen, til systemdokumentationen, til testcases og til sidst til resultatet af en test. Det vægtes positivt (konkurrencekrav) at en testplan udarbejdet af Leverandøren indeholder en alsidig tilgang til test. Bortset fra Fabriksprøven, som der er færre krav til, skal en testplan som minimum indeholde følgende oplysninger: Kort overordnet beskrivelse af testen og dens formål Detaljeret tidsplan for testen med angivelse af aktiviteter, milepæle og produkter Start- og slutkriterier Beskrivelse af testdata og de enkelte testcases der skal gennemføres med reference til hvor de forefindes. Blandt andet beskrives dækning og prioriteringer Beskrivelse af sporbarhed fra krav til systemdokumentation til testcases Beskrivelse af det miljø testen skal udføres i Beskrivelse af eventuelle testværktøjer og metoder der anvendes Beskrivelse af software, herunder systemets versionsnummer og eventuelt hvilken anden software der skal være til rådighed Beskrivelse af hvordan testen gennemføres, inklusive planlægning, udførelse og rapportering Personressourcer, herunder hvilke krav der er til Kundens involvering Standardindholdet af en testplan skal fremgå af Leverandørens Hovedtestplan, som en del af besvarelsen af dette bilag: Leverandørens Hovedtestplan (bilag 14a). I de tilfælde hvor Leverandøren er ansvarlig for en prøve eller test, skal den detaljerede testplan leveres til Kunden senest femten arbejdsdage før påbegyndelsen af den pågældende prøve eller test. Kunden reviewer testplanen og afgør om den kan godkendes. Tilbagemelding til Leverandøren vedrørende godkendelse skal ske senest 10 arbejdsdage efter testplanen er modtaget af Kunden. Ved manglende godkendelse skal Leverandøren hurtigst muligt rette op på de identificerede fejl og fremsende planen til Kunden igen, som uden unødigt ophold skal foretage review af testplanen. Herefter gives besked herom til Leverandøren. Det er en betingelse for igangsættelsen af en prøve eller test at testplanen er godkendt af Kunden. Kunden udarbejder en testplan for hver af de prøver og test Kunden er ansvarlig for. Under hver testtype i afsnit 14.4 fremgår eventuelle krav til Leverandørens deltagelse i testen. Leverandøren tilsendes Kundens testplaner, som dog ikke skal godkendes af Leverandøren. Kunden ønsker et konstruktivt review af testplanerne. 14.7 Testmiljøer Kundens integrationsplatform (IP) skal anvendes i forbindelse med udvikling og test, og kan forbindes til de miljøer der er listet nedenfor. Bilag 14 Prøver Side 12/25

Det er et krav at der i testen inkluderes test via VANS idet der sker konverteringer mellem XML og EDIFACT her, og dette ikke kan simuleres med teststubbe. Da hele leverancen skal driftes af Leverandøren, stilles der ikke specifikke krav til antal af testmiljøer. Der er dog nogle mindstekrav som anført i bilag 3. Således skal der mindst være, dog ikke begrænset til, de følgende miljøer: Testmiljø for Kundens egen udvikling Systemintegrationstestmiljø Præ-prodmiljø Produktionsmiljø Leverandøren skal angive det forventede behov for miljøer, og for tid (kalendertid) til at oprette og klargøre de enkelte miljøer. Leverandøren bedes beskrive hvordan anvendelsen af miljøerne tænkes, og hvilke miljøer der efter implementering overgives til forvaltning af Løsningen. Installation af Leverancen i et givet miljø skal ske hos Leverandøren, idet denne selv skal forvalte miljøerne. 14.7.1 Konfigurationsstyring Leverandøren skal etablere en Configuration Management Database (CMDB/SKMS) som indeholder tilstrækkelig information om relevante relationer mellem de enheder, der indgår i miljøerne. Informationen skal fremlægges som dokumentation i overensstemmelse med bilag 4, Dokumentation. Endvidere skal Leverandøren bevise at det er muligt at flytte en konfiguration fra ét miljø til et andet. 14.8 Testdata og testcases 14.8.1 Testdata I dette afsnit gennemgås, hvilke data der er behov for at anvende i Den Nationale Henvisningsformidling, og dermed hvilke test data der skal være til rådighed. Endvidere ses hvor der er identificeret snitflader. Henvisningstyper Alle nedenstående henvisningstyper har praktiserende læge som snitflade, og deltager desuden i et afregningsflow: Henvisning Beskrivelse Snitflader REF01 REF02 Sygehushenvisning Pakkehenvisning Billeddiagnostisk henvisning Sygehus Region Syddanmark Sygehus Region Syddanmark REF06 Speciallægehenvisning Speciallæge REF07 Fysioterapeuthenvisning Fysioterapeut REF08 Fodterapeuthenvisning Fodterapeut Bilag 14 Prøver Side 13/25

REF10 Psykologhenvisning Psykolog REF12 Øfeldthenvisning Specialfysioterapeut XREF15 Kommunehenvisning Stadig fremtidig Bin01 Bin02 Dis91 Binær dokumenttransport Henvisningsbilag Korrespondencebrev Tabel 3. Oversigt over testdata og snitflader. Testdata til arbejdsgangenes dataflow Udover at henvisningstyperne skal understøttes, skal der tilvejebringes tilstrækkelige mængder testdata i den rette kvalitet til at teste de arbejdsgange der er identificerede: Data til arbejdsgange ift. aktører Standardarbejdsgang med henvisning fra praktiserende læge: Ydernummer Uden ydernummer Kommentar Testdata skal dække begge scenarier ift. ydernummer. Dataflow i arbejdsgang for Psykologer Dataflow i arbejdsgang for fysioterapeuter Her skal bl.a. klippekort markeres som taget, og mængde af forbrugte klip Dataflow i arbejdsgang for fodterapeuter Dataflow i arbejdsgang for kiropraktor Dataflow i arbejdsgang for sygehushenvisning inklusiv pakkeforløb Dataflow ift. henvisning fra sygehus Dataflow ift. henvisning til sygehus Data til Sundheds.dk Praksys afregning og opdatering Praksys skal opdatere klippekort Praksys kontrol af henvisning Annullering af henvisning Datawarehouse processer Logon validering Brugeradministration Brugere med og uden ydernr Superbruger administration Web grænseflade Bilag 14 Prøver Side 14/25

Teknisk dataflow WAN Sundhedsdatanettet Videre visitering af henvisning Tabel 3A. Oversigt over testdata og snitflader. Tilvejebringelse af testdata Leverandøren skal altid sørge for at systemet forsynes med den nødvendige mængde testdata ved opsætning af et givent miljø, så funktionsprøven kan finde sted. Leverandøren skal i sin besvarelse af bilaget beskrive hvilke livscyklusser testdata vil have. Hvordan skabes, eller hvor hentes testdata til et givent system, hvilke mængder skal være til rådighed, hvordan vedligeholdes data, og hvilke faktorer der afgør om data slettes eller opdateres. I alle systemer skal testdata være anonymiseret således at det ikke er muligt at forbinde testdata med virkelige personer. Dette gælder dog ikke en eventuel migrering af produktionsdata fra det eksisterende produktionssystem til det nye produktionssystem. 14.8.2 Testcases Enhver testcase skal indeholde en beskrivelse af formål, forudsætninger, hvilke detaljerede trin der skal gennemløbes med angivelse af input, forventet resultat og en angivelse af hvilke(t) krav der testes. Det skal beskrives i Leverandørens Hovedtestplan, hvordan testcases dokumenteres over for Kunden, samt hvordan det dokumenteres at Leverancen lever op til de krav en given testcase tester. Leverandøren skal senest 20 arbejdsdage før en given prøves / tests afholdelse udlevere de testcases Leverandøren vil benytte til prøven / testen. Kunden skal senest 10 arbejdsdage før testens afholdelse meddele Leverandøren eventuelle kommentarer og indsigelser til de udleverede testcases. Prøven / Testen kan ikke påbegyndes før Kundens indsigelser er indarbejdet i Leverandørens testcases. Leverandørens testcases skal dække de krav der er til leverancen. Der skal være sporbarhed fra krav, til testcases, til resultater af gennemført test. Dette er et mindstekrav. 14.9 Testværktøjer 14.9.1 Fejlrapporteringsværktøj og styring af testcases Med henblik på at kunne styre testcases, håndtere sporbarhed mellem testcases, krav og testforløb samt håndtere fejl, skal Leverandøren benytte et testværktøj. Værktøjet benyttes til planlægning, gennemførelse, styring og dokumentation af testforløbet, herunder også til oprettelse og styring af fejlrapporter i forbindelse med testgennemførelsen. Kunden ønsker at der registreres og følges op på fundne fejl, samt at der er adgang til et samlet overblik over testens resultater. Til projekter der drives i Kundens eget regi anvender Kunden HP ALM 12.20, og Bilag 14 Prøver Side 15/25

dette produkt kan vise sig at være anvendeligt ift. behovet for et testværktøj. Hvis ALM vælges til at være testværktøj, skal der indgås en særskilt aftale om brugen af det. Leverandøren skal i sin besvarelse beskrive hvordan testens aktuelle resultater er tilgængelige under implementeringen. 14.10 Testgennemførelse En prøve eller test gennemføres indenfor de rammer der er afhandlet mellem Leverandør og Kunde. Eksemplet af den enkelte prøve/test kan ses i afsnit 14.3. Leverandøren skal beskrive, hvordan de forskellige test i prøverne afvikles i henholdsvis Leverandørens testmiljø, i testmiljø stillet til rådighed for Kunden og hos tredjeparts leverandør af f.eks. kliniksystemer/epjsystemer. Det vægter positivt, at leverandørens beskrivelse er detaljeret omkring omfang og tidspunkter for inddragelse af klinikere og øvrige fagfolk, som skal varsles i forhold til overenskomstmæssige krav til vagtplanlægning og frikøb fra privat klinik eller anden privat virksomhed. Hvis der konstateres fejl under en prøve/test i et givet miljø, skal Leverandøren rette fejlen(e) i udviklingsmiljøet/rne, og ikke i det miljø hvor fejlen er konstateret. Når fejlen(e) er rettet i udviklingsmiljøet/rne distribueres konfigurationen og Leverancen gentestes i hvert af de efterfølgende miljøer startende med [det relevante miljø], indtil man er tilbage ved det miljø man oprindeligt konstaterede fejlen i. Leverandøren skal beskrive, hvordan Løsningen funktionstestes i forbindelse med håndtering af ændringer, således driften af systemet påvirkes mindst muligt og kan reetableres efter en fejlslagen ændring. Dette er et konkurrencekrav, og der lægges vægt på at der kan dokumenteres sammenhæng mellem Security Incident and Event Management System og Information Technology Infrastructure Library procedurer. Hvis Kunden retter henvendelse med ønske om status på test, skal Leverandøren uden unødigt ophold oplyse hvad der er blevet testet samt testens aktuelle resultat. 14.11 Fejlkategorisering Fejl fundet i forbindelse med en test kategoriseres med hensyn til hvor alvorlige de er. Kategorierne beskrevet i Tabel 5 benyttes. Der skelnes mellem kategorier brugt ved funktionelle test, kategorier brugt ved non-funktionelle test og kategorier brugt ved brugeraccepttest. Som udgangspunkt træffer Kunden beslutning om hvordan en fejl skal kategoriseres. Ved uenighed har Leverandøren dog mulighed for at eskalere afgørelsen jf. kontrakten. Nr. Betegnelse Beskrivelse Fejlkategorier ved funktionelle test 1 Kritisk fejl Fejl der medfører at ingen af de arbejdsprocesser der testes i regressionstesten er mulige at gennemføre, ej heller ved ændringer i arbejdsgangene. Fejl der øger brugerens risiko for at sammenblande data mellem patienter. Fejl der medfører forhøjet risiko for fejl i patientbehandling eller fejl i patientlogistik (behandlingssted, indkaldelse etc.) Bilag 14 Prøver Side 16/25

2 Alvorlig fejl Fejl der medfører at flere væsentlige arbejdsprocesser ikke kan gennemføres eller kun kan gennemføres ved væsentlige ændringer i arbejdsgange. Fejl der medfører at data mistes. 3 Betydende fejl Fejl der resulterer i at arbejdsprocesser ikke kan gennemføres eller kun kan gennemføres ved ændringer i arbejdsgange. 4 Normal fejl Fejl der ikke hindrer arbejdsprocessen i at kunne gennemføres normalt, eventuelt med mindre ændringer i arbejdsgange for at omgå fejlen. 5 Mindre betydende fejl Ubetydelig eller kosmetisk fejl, men hvor der er fejl i forhold til aftalegrundlaget. Fejlkategorier ved belastningstest 1 Kritisk fejl Hvis det målte resultat afviger med mere end 60 % fra kravet. 2 Alvorlig fejl Hvis det målte resultat afviger med mere end 30 % men lig med eller mindre end 60 % fra kravet. 3 Betydende fejl Hvis det målte resultat afviger med mere end 10 % men lig med eller mindre end 30 % fra kravet. 4 Normal fejl Hvis det målte resultat afviger med mere end 5 % men lig med eller mindre end 10 % fra kravet. 5 Mindre betydende fejl Hvis det målte resultat afviger med 5 % eller mindre fra kravet. Fejlkategorier ved brugeraccepttest 1 Alvorligt brugervenlighedsproblem 2 Forstyrrende brugervenlighedsproblem 3 Kosmetisk problem Problem af så alvorlig karakter, at det kan risikere at påvirke Kundens troværdighed. Det er svært eller direkte umuligt at gennemføre opgaven eller fortsætte brugen af brugergrænsefladen på en meningsfyldt måde. Brugeren må eksempelvis have hjælp fra andre for at komme videre. Til denne kategori hører også situationer, hvor brugeren synes, at produktet forlanger unødvendige oplysninger eller handlinger. Problem der er forstyrrende for brugen af produktet og indebærer, at brugeren anvender uforholdsmæssigt meget tid på at løse en opgave. Observationer, der ikke har større betydning for brugervenligheden, men som dog generer det generelle indtryk af brugergrænsefladen. 4 God ide Et brugerforslag, der kan forbedre brugergrænsefladens brugervenlighed. Fejlkategorier ved dokumentationstest og review 1. Kritisk fejl Dokumentet indeholder fejl som bevirker, at dokumentet ikke lever op til kontraktens krav eller til efterfølgende dokumenterede afklaringer. Eller dokumentet indeholder fejl eller unøjagtigheder som gør læsningen og forståelsen af dokumentet meget svær eller umulig. 2. Væsentlig fejl Dokumentet indeholder beskrivelser som er inkonsistente med andre beskrivelser i samme eller andre dokumenter, eller dokumentet indeholder væsentlige fejl eller formuleringer som gør det vanskeligt at forstå for den modtagergruppe, dokumentet er tiltænkt. 3. Mindre væsentlig fejl Indholdet har behov for uddybning eller præcisering, eller der er andre fejl som hverken er kritiske eller væsentlige. 4. Skønhedsfejl Der er mindre fejl i dokumentet, fx stavefejl, grammatiske fejl eller andre fejl, som ikke hindrer læsning af dokumentet, men som alligevel forstyrrer øjet der læser. Tabel 5. Fejlkategorier. Bilag 14 Prøver Side 17/25

Ad non-funktionelle test: Det fremgår af Leverandørens løsningsbeskrivelse (bilag 3) om der måles på hele svartidsforløbet fra input til output, eller om der kun måles på de dele Leverandøren har ansvaret for, samt hvorledes målingerne vil blive gennemført. Ad brugeraccepttest: En fejl fundet gennem en brugeraccepttest klassificeres som et brugervenlighedsproblem. Som grundlag for at definere hvor alvorligt et givet brugervenlighedsproblem er, vurderes følgende: Hvad er frekvensen eller hyppigheden af fejlen/problemet? Hvilken indvirkning har problemet/fejlen på brugernes anvendelsessituation? Vil det være let eller svært for brugeren at komme uden om problemet/fejlen? Er problemet vedvarende eller er det en engangsfejl/et engangsproblem, som brugeren kan overkomme, når denne først ved hvordan, eller vil brugeren gentagne gange blive generet af problemet/fejlen? Hvilken indvirkning har problemet/fejlen på tilliden til Kunden? Har fejlen stor eller lille betydning for Kundens troværdighed i brugernes øjne, hvor selv mindre fejl objektivt set kan have markant betydning. Et brugervenlighedsproblem er et problem, uanset om én eller flere brugere har oplevet problemet. Såfremt en bruger oplever problemet, er der en risiko for at andre brugere vil opleve tilsvarende problemer, når Leverancen via brugergrænsefladen bliver taget i brug. Ad dokumentationstest og review: Den anførte kategorisering anvendes ved dokumentationstest, jf. Afsnit 14.12.2, og ved review af øvrige dokumenter udarbejdet af Leverandøren og beskrevet i bilag 4 og andre bilag. 14.11.1 Reaktioner ved fejl En prøve eller test kan afbrydes af Kunden, hvis der findes kritiske eller alvorlige fejl, jf. tabel 6. Kunden beslutter om prøven/testen kan fortsætte mens fejlen udbedres. Kunden beslutter ligeledes om prøven/testen skal starte forfra efter at Leverandøren har udbedret den pågældende fejl, eller om den kan fortsætte fra det punkt man var nået til. Det afhænger af hvorvidt der er ændret på grundlaget for testen. Tabel 6 beskriver desuden hvordan Leverandøren skal reagere på identificerede fejl og problemer. Testperioden er den periode, der er afsat til selve gennemførelsen af en prøve eller test. Nr. Betegnelse Reaktion ved funktionelle test 1 Kritisk fejl Identificeres en sådan fejl under en prøve eller test, kan Kunden vælge at afbryde prøven/testen, idet det ikke giver mening at fortsætte. Leverandøren skal, uden ugrundet ophold, udbedre den eller de kritiske fejl. Hvis Leverandøren ikke er i stand til at udbedre den/de kritiske fejl inden for maksimalt fem (5) kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes den/de kritiske fejl vil blive udbedret inden for testperioden. 2 Alvorlig fejl Kunden kan vælge at indstille testen/prøven, såfremt sådanne fejl identificeres. Leverandøren skal, uden ugrundet ophold, udbedre den eller de alvorlige fejl. Hvis Leverandøren ikke er i stand til at udbedre den/de alvorlige fejl inden for maksimalt ti (10) kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes den/de alvorlige fejl vil blive udbedret inden for Bilag 14 Prøver Side 18/25

testperioden. 3 Betydende fejl Leverandøren skal, uden ugrundet ophold, udbedre den eller de betydende fejl. Hvis Leverandøren ikke er i stand til at udbedre den/de betydende fejl inden for maksimalt femten (15) kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes den/de betydende fejl vil blive udbedret inden for testperioden. 4 Normal fejl Leverandøren skal levere bindende planer til Kunden, der beskriver hvorledes alle normale fejl udbedres inden for testperioden. 5 Mindre betydende fejl Leverandøren skal levere bindende planer til Kunden, der beskriver hvordan og hvornår alle mindre betydende fejl udbedres. Reaktion ved belastningstest 1 Kritisk fejl Identificeres en sådan fejl under en test, kan Kunden vælge at afbryde testen, idet det ikke giver mening at fortsætte. Leverandøren skal reagere som beskrevet for kritisk fejl ved en funktionel test. 2 Alvorlig fejl Kunden kan vælge at indstille testen, såfremt sådanne fejl identificeres. Leverandøren skal reagere som beskrevet for alvorlig fejl ved en funktionel test. 3 Betydende fejl Leverandøren skal reagere som beskrevet for betydende fejl ved en funktionel test. 4 Normal fejl Leverandøren skal reagere som beskrevet for normal fejl ved en funktionel test. 5 Mindre betydende fejl 1 Alvorligt brugervenlighedsproblem 2 Forstyrrende brugervenlighedsproblem Leverandøren skal reagere som beskrevet for mindre betydende fejl ved en funktionel test. Reaktion ved brugeraccepttest Identificeres en sådan fejl under en prøve eller test, kan Kunden vælge at afbryde prøven/testen, idet det ikke giver mening at fortsætte. Leverandøren skal, uden ugrundet ophold, udbedre den eller de alvorlige brugervenlighedsproblemer. Hvis Leverandøren ikke er i stand til at udbedre den/de alvorlige brugervenlighedsproblemer inden for maksimalt fem (5) kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes den/de alvorlige brugervenlighedsproblemer vil blive udbedret inden for testperioden. Leverandøren skal, uden ugrundet ophold, udbedre den eller de forstyrrende brugervenlighedsproblemer. Hvis Leverandøren ikke er i stand til at udbedre den/de forstyrrende brugervenlighedsproblemer inden for maksimalt ti (10) kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes den/de forstyrrende brugervenlighedsproblemer vil blive udbedret inden for testperioden. Leverandøren skal levere bindende planer til Kunden, der beskriver hvordan og hvornår alle kosmetiske problemer udbedres. 3 Kosmetisk problem 4 God ide Lægges i idébunken, og det diskuteres med Leverandøren hvorvidt idéen vil blive implementeret uden beregning eller behandlet som et ændringsønske. Leverandøren er ikke forpligtet til at tage gode idéer i betragtning medmindre Kunden vil betale for det. Reaktion ved dokumentationstest og review 1. Kritisk fejl Identificeres en sådan fejl under en test eller et review, kan Kunden vælge at afbryde testen/reviewet, idet det ikke giver mening at fortsætte. Leverandøren skal reagere som beskrevet for kritisk fejl ved en funktionel test. 2. Væsentlig fejl Leverandøren skal reagere som beskrevet for alvorlig fejl ved en funktionel test. Bilag 14 Prøver Side 19/25

3. Mindre væsentlig fejl Leverandøren skal levere bindende planer til Kunden, der beskriver hvordan og hvornår alle mindre væsentlige fejl udbedres. 4. Skønhedsfejl Leverandøren skal levere bindende planer til Kunden, der beskriver hvornår skønhedsfejl udbedres. Tabel 6. Reaktioner ved identificerede fejl og problemer. 14.12 Rapportering af resultater 14.12.1 Håndtering af hændelser og statusrapportering Gennem en prøve/test registrerer hhv. Kunden og Leverandøren løbende de fejl og problemer der identificeres i det valgte testværktøj. I Leverandørens Hovedtestplan (bilag 14a) skal Leverandørens proces for håndtering af hændelser (incidents) under gennemførelsen af en test være beskrevet. Dette indbefatter rapportering af hændelser der stærkt påvirker planen for gennemførelsen af testen, eller på anden vis bringer usikkerhed ift. om Leverancen kan implementeres som ønsket. 14.12.2 Rapport over prøve-/testforløbet Den hovedansvarlige (Leverandøren eller Kunden) for en prøve eller test, skal udarbejde en rapport over prøve-/testforløbet i form af en prøverapport eller testrapport der dokumenterer prøvens/testens resultat. Der skal udarbejdes 1 rapport pr test, og 1 rapport pr prøve. Hvor der anvendes delleverancer, skal der udarbejdes 1 rapport pr delleverance. Rapporten skal angive resultatet af prøvens/testens gennemførelse og skal som minimum indeholde følgende: Dokumentation af at alle testcases er gennemført samt resultatet deraf. Hvor mange hændelser (fejl/problemer) der er fundet i alt og med hvilken kategori. Hvor mange hændelser der er udestående og med hvilken kategori. Handlingsplan for udestående hændelser. Var startkriterierne opfyldt? Er slutkriterierne opfyldt? Eventuelle afvigelser i forhold til testplanen (inklusive tidspunkter, involverede personer, testdata, scope osv.). Oversigt over eventuelle udeståender. Evt. øvrige relevante forhold. 14.12.3 Godkendelse af prøve/test Kundens godkendelse af en prøve eller test sker på baggrund af den udarbejdede testrapport. Alle oplysninger skal medtages i rapporten (se ovenstående liste). Kunden skal, medmindre andet fremgår under den pågældende testtype, jf. Afsnit 14.4, inden for 5 arbejdsdage efter modtagelse af en testrapport fra Leverandøren skriftligt meddele Leverandøren, om den pågældende test/prøve kan godkendes. Der inkluderes en mangelliste med angivelse af fejl og/eller manglende overholdelse af servicemål. Hvis det er Kunden der har hovedansvaret for en prøve/test, skal Kunden på tilsvarende vis skriftligt meddele Leverandøren om prøven/testen er bestået eller ej. Medmindre andet er aftalt, skal dette ske inden for 5 arbejdsdage efter testen er gennemført og den afsluttende testrapport udarbejdet. Godkendelsen af en prøve/test omfatter to delelementer: Bilag 14 Prøver Side 20/25

Godkendelse af testrapport. Godkendelse af testresultat. Både testrapport og testresultat skal opfylde kravene til godkendelse, før prøven/testen samlet kan godkendes. En forudsætning for Kundens godkendelse af en prøve/test er, at testrapporten er udarbejdet i overensstemmelse med det aftalte Hovedtestplan, herunder at rapporten tydeligt viser at prøven/testen har omfattet afprøvning af alle beskrevne områder af det leverede. Hvis testrapporten ikke er udarbejdet i overensstemmelse med kravene hertil, kan Kunden afvise testrapporten. Leverandøren er herefter forpligtet til at udarbejde en revideret rapport, der uden udgrundet ophold skal leveres til Kunden. Hvis rapporten viser, at prøven/testen ikke har omfattet alle dele af det leverede, som ifølge testplanen skulle have været afprøvet, kan Kunden afvise prøven/testen. Leverandøren er herefter, medmindre Kunden bestemmer andet, forpligtet til at gentage den fulde prøve/test. Kunden skal, på anmodning, have mulighed for fuld indsigt i det materiale der danner grundlag for testrapporten. Det skal i besvarelsen af dette bilag beskrives hvordan dette sikres. Alle prøver/test skal godkendes af Kunden. Åbne fejl (dvs. fejl der endnu ikke er rettet) fra test der hører ind under en prøve, såvel som åbne fejl fra tidligere prøver indgår i opgørelsen over antallet af konstaterede fejl i en prøve. Åbne fejl fra test af samme type (der skelnes mellem følgende typer: funktionel, non-funktionel, brugervenlighed, review) som den der rapporteres fra, tæller med i antallet af konstaterede fejl i testen. Dette betyder at antallet af fejl kan akkummulere sig fra én test til næste, og gøre at den sidste test ikke kan godkendes. I afsnit 14.4 er der for hver enkelt prøve og test angivet slutkriterier, dvs. hvilke kriterier der skal være opfyldt for at prøven/testen kan afsluttes. Dette er dog under hensyntagen til den aftalte testforløb hvor der kan være forskelle. 14.12.4 Fejltolerancer Tabel 7 beskriver hvilke tolerancer Kunden har i forhold til godkendelse af prøver/test. Tolerancerne i tabel 7 indgår som en del af prøvernes godkendelseskriterier, og således er der krav om at disse også skal opfyldes. Fejltolerancer ved funktionelle test Kategori: Det accepterede antal fejl i kategorien Kategori 1 0 Kategori 2 0 Kategori 3 3 Kategori 4 15 Bilag 14 Prøver Side 21/25

Kategori 5 25 For kategori 3, 4 og 5 fejl skal der foreligge en plan for udbedring af fejlene, som skal godkendes af Kunden. Fejltolerancer ved belastningstest Kategori: Det accepterede antal forskellige målinger Kategori 1 0 Kategori 2 0 Kategori 3 1 Kategori 4 3 Kategori 5 10 For kategori 3, 4 og 5 fejl skal der foreligge en plan for udbedring af fejlene, som skal godkendes af Kunden. Fejltolerancer ved brugeraccepttest Fejlkategori: Maksimal procentsats af testpersonerne der må finde fejl i en bestemt kategori: Kategori 1 20 % Kategori 2 30 % Kategori 3 40 % Fejltolerancer ved dokumentationstest og review Fejlkategori Max accepterede antal fejl: Kategori 1 0 Kategori 2 0 Kategori 3 10 Kategori 4 30 Tabel 7. Fejltolerancer. 14.13 Organisation, roller og ansvar Det er den hovedansvarlige (Leverandøren eller Kunden) for en prøve/test som forestår planlægning, gennemførelse, opfølgning, rapportering mv. omkring testafvikling. Hvor Kunden er hovedansvarlig for en prøve / test, skal der i afklaringsfasen aftales i hvilket omfang der forventes bistand fra Leverandøren. Det fremgår af Leverandørens Hovedtestplan hvem der forestår den daglige testplanlægning i forbindelse med de prøver og test, Leverandøren har hovedansvar for, og hvem der på Leverandørens side er ansvarlig ved bistand til prøver og test som Kunden har hovedansvaret for. Det fremgår ligeledes af Leverandørens Hovedtestplan hvilke krav Leverandøren stiller til brug af Kundens personresurser i de prøver og test Leverandøren har hovedansvaret for. Ved prøver og test som Kunden har hovedansvaret for, er det Kundens testansvarlige der forestår den daglige testledelse i form af detailplanlægning, herunder uddelegering af testarbejde til de enkelte medarbejdere knyttet til testen. Bilag 14 Prøver Side 22/25