Vejledning: Side 2 af 36 Bilag 11

Transkript

1 Bilag 11 Prøver

2 Vejledning: Afprøvning af Leverancen sker ved en fabriksprøve, overtagelsesprøve og driftsprøve. Såfremt Leverancen er opdelt i delleverancer, gennemføres der tillige delleveranceprøver på disse. Tilsvarende, såfremt der leveres udstyr, gennemføres der en installationsprøve på dette. Bilaget er opbygget med fælles krav til de forskellige prøver, og som de enkelte prøver, herunder afprøvningsprogram, afprøvningsforskrifter, afprøvningsplaner og godkendelseskriterier, skal udformes i henhold til. I de enkelte bestemmelser i kontrakten til de forskellige prøver er formålet med prøverne kort angivet, jf. kontraktens punkt De enkelte prøver skal tilrettelægges og gennemføres i overensstemmelse med disse formål. Leverandøren fremkommer, som en del af sit tilbud, med afprøvningsprogram, afprøvningsforskrifter, afprøvningsplaner og godkendelseskriterier. Hvis der er særlige forhold, Kunden ønsker adresseret i forbindelse med afprøvningen, herunder krav til godkendelse af en bestået prøve, kan Kunden med fordel vælge at opstille en række overordnede krav hertil som en del af sit udbudsmateriale. Såfremt en delleverance kan ibrugtages af Kunden, kan det være relevant, at delleveranceprøven indeholder test af visse servicemål. Test af servicemål i en delleveranceprøve skal derfor være omfattet af Kundens eventuelle krav til delleveranceprøver i udbudsmaterialet, eller Kunden skal meddele dette til Leverandøren inden afklaringsfasens afslutning. De i bilag 6 anførte servicemål skal, medmindre andet angives i bilag 6, overholdes fra overtagelsesdagen. Kunden skal være opmærksom på, at såfremt overholdelse af sådanne servicemål (f.eks. svartider) skal indgå som en del af overtagelsesprøven, skal dette meddeles Leverandøren inden afklaringsfasens afslutning eller være omfattet af Kundens eventuelle krav til overtagelsesprøven. Kontraktens udgangspunkt er, at en delleveranceprøve ikke omfatter test af funktionalitet, som er godkendt i en tidligere delleverance. Såfremt delleveranceprøven skal omfatte test af funktionalitet, som er indeholdt i en tidligere leverance, skal Kunden meddele dette til Leverandøren inden afklaringsfasens afslutning eller være omfattet af Kundens eventuelle krav til delleveranceprøverne. Dog kan Kunden altid forbeholde sig ret til at få tidligere leveret funktionalitet afprøvet, hvis Kunden kan påvise særlig anledning dertil. I bilag 4 (Dokumentation) skal angives den dokumentation, Leverandøren skal levere ved de forskellige prøver. Afprøvningsprogram, afprøvningsforskrifter, afprøvningsplaner og godkendelseskriterier skal derfor også omfatte den Side 2 af 36 Bilag 11

3 dokumentation, som Leverandøren skal levere ved de pågældende prøver. I bilaget skal fastsættes Kundens godkendelseskriterier for de enkelte prøver. Det kan med fordel her overvejes at indsætte en nærmere definition af, hvornår der foreligger en mangel, som medfører, at prøven ikke er bestået. I K01's prøvebilag er angivet godkendelseskriterier for en overtagelsesprøve og driftsprøve, der kan bruges som inspiration. Kontrakten henviser til bilag 11 i punkt 8 (Afprøvning) Side 3 af 36 Bilag 11

4 1. Indledning 1.1. Formål Dette bilag beskriver den afprøvning, der skal gennemføres i forbindelse med levering af Leverancen, og forløbet relateret hertil. Det fastsætter kravene til hver enkelt test og kriterierne for, hvornår den er bestået, samt kravene relateret til styring af testforløbet gennem hele projektet. De enkelte test vil have indbyrdes afhængigheder, således at der tegnes et forløb fra de indledende test til de afsluttende. Kunden anvender i nærværende bilag en begrebsterminologi vedrørende Prøver, der adskiller sig fra standardterminologien i K02. Derfor gives nedenstående oversigt over Kundens terminologi. De øvrige K02 bilag anvender K02 terminologien. Dette betyder, som det fremgår af tabel 1 omkring testtyper, at hver af K02 prøverne indbefatter de i tabel 1 angivne test, som skal være afviklet, før Kunden kan godkende den pågældende prøve. K02 terminologi Prøve Afprøvningsprogram Afprøvningsforskrifter Afprøvningsplaner Godkendelse af prøver Afprøvningsrapporter Kundens terminologi Test Testtyper Teststrategier Testplaner Godkendelse af test Testrapporter 1.2. Øvrigt Det er en forudsætning for en test, at den i videst mulige omfang gennemføres under forhold, der er sammenlignelige med en normal driftssituation. Ud fra devisen om at Leverancen består af en standardløsning med tilpasninger, forudsættes det, at Leverandøren forud for levering af Leverancen, samt efterfølgende ved nye versioner, udfører dækkende releasetest og regressionstest af standardløsningen, inden den forlader Leverandøren. Hvis Kunden ønsker det, kan Kunden få tilsendt Leverandørens testrapport efter enhver udført test, for at godkende testdækning, prioritering af testcases og testresultat. Side 4 af 36 Bilag 11

5 2. Generelle krav i forbindelse med test 2.1. Oversigt over testtyper Tabel 1 viser en generel oversigt over de testtyper Kunden anvender, og som skal foretages under nærværende kontrakt. Tabel 1 giver også en oversigt over, hvad der testes med hver testtype. Hver testtype er beskrevet i detaljer i afsnit 3. Her er der endvidere for hver testtype anført kriterier for, hvornår den pågældende test kan godkendes af Kunden (acceptkriterier). Søjlen Ansvar angiver, hvem der har hovedansvaret for en given test. Prøver Fabriksprøve Installationsprøv e Review Test, der skal gennemføre s pr. prøve Funktionsog systemintegrationstest Installationstest Smoketest Beskrivelse Tester integration af systemet mod andre (del-) systemer og grænseflader til eksterne organisationer samt systemets funktionalitet. Evaluerer kvalitet og overensstemmelse med krav og klarlægger dermed eventuelle fejl, mangler og forbedringsmuligheder ved et produkt i forbindelse med systemet, f.eks. brugervejledning eller installationsvejledning. Tester om systemet er installeret korrekt og i overensstemmelse med installationsvejledningen, i den rigtige version på det relevante miljø, samt tester, at andre systemer på miljøet ikke er påvirket. Afvikler en udvalgt delmængde af alle definerede/planlagte Ansvar Leverandør Kunde Leverandør Leverandør / Kunde Side 5 af 36 Bilag 11

6 Delleveranceprøv e Konverteringstest Funktionel kravtest/user Accept Test Belastningstest Skalerbarhedstest Recoverytest testcases, der dækker hovedfunktionaliteten i en komponent eller et system, for at fastslå at de vigtigste funktioner i komponenten/systeme t fungerer. Testen går ikke i detaljer. Tester at konverteringsprocesser, der skal konvertere data fra et eksisterende system til et nyt system, virker og har det ønskede resultat, herunder at konverterede data er korrekte og komplette. Tester opfyldelse af forretningsmæssige krav til systemet. Tester om systemet ved øget belastning, f.eks. i form af antallet af samtidige brugere og/eller antallet af transaktioner, reagerer som aftalt. Tester om kravene til skalerbarhed, det vil sige systemets evne til at kunne opgraderes til at kunne klare større belastninger, er opfyldt, Tester systemets genoprettelsesegnethe d, det vil sige systemets evne til at genetablere et specificeret performanceniveau og gendanne de data, der direkte påvirkes i tilfælde af nedbrud. Leverandør Kunde/Leverand ør Leverandør Leverandør Leverandør Sikkerheds- Tester om systemet Kunde Side 6 af 36 Bilag 11

7 Overtagelsesprø ve test Overtagelsestest lever op til de krav til sikkerhed, der er stillet. Afprøver om alle krav til funktionalitet, servicemål og dokumentation er overholdt i forbindelse med det endelige system. Driftsprøve Svartidstest Tester om kravene til svartider er overholdt, jf. bilag 6 (Servicemål). Tabel 1. Testtyper. Driftstest Afprøver systemet i dets driftsmiljø under faktisk brug. Leverandør Leverandør Kunde/Leverand ør 2.2. Teststrategi Leverandøren skal udarbejde en teststrategi, som indgår som en del af bilag 3 (Leverancebeskrivelse). Leverandørens teststrategi skal, inklusive eventuelle tilpasninger efter aftaleindgåelse, være endeligt godkendt af Kunden, før der udarbejdes en testplan for den første test. Leverandørens teststrategi omfatter en generel beskrivelse af den tilgang til test, der vil blive brugt. Den beskriver bl.a. hvilke(n) testmetode(r) Leverandøren benytter, hvilke generelle testmetrikker der anvendes, og hvordan der sikres sporbarhed mellem krav, evt. designspecifikationer, testcases og evt. arbejdsgange, og mellem teststrategi, testplaner og testcases. Teststrategien beskriver også, hvordan Leverandøren effektivt vil måle fremdrift for de tests denne har hovedansvaret for, samt Leverandørens overordnede tilgang til testdækning og prioritering. Leverandørens teststrategi inkluderer en beskrivelse af de testtyper, Kunden har tilvalgt, og deres scope. Beskrivelsen adresserer de krav, Kunden har stillet i forbindelse med den enkelte testtype. De indbyrdes tidsmæssige relationer mellem de overordnede testaktiviteter der skal gennemføres, fastlægges i tidsplanen. I bilag 1 (Tidsplan) bedes Leverandøren indføre, hvornår de enkelte test ligger, hvor længe de varer, og om de eventuelt gentages med et vist interval. Side 7 af 36 Bilag 11

8 Kundens krav til Leverandørens teststrategi ID Kravtype Beskrivelse K 14-1 K 14-2 Leverandøren skal udarbejde en teststrategi, der indgår som en del af bilag 3 (Kravspecifikation) med Leverancebeskrivelse og Løsningsbeskrivelse. Teststrategien skal omhandle følgende punkter: Generelt om test, herunder bl.a. testmetoder og metrikker Jf. afsnit 2.2. Testtyper der er tilvalgt til ydelsen. De testtyper Kunden generelt anvender, fremgår af afsnit 2.1 Tidsplan og testaktiviteter Testplaner, jf. afsnit 2.3 Miljøer, jf. afsnit 2.4 Testdata, jf. afsnit 2.5 Testcases, jf. afsnit 2.6 Testværktøjer, jf. afsnit 2.7 Testafvikling, jf. afsnit 2.8 Fejlkategorisering, jf. afsnit 2.9 Reaktioner ved fejl og ændringer, jf. afsnit 2.10 Regressionstest, jf. afsnit 2.11 Rapportering af resultater, jf. afsnit 2.12 Konfigurationsstyring af testware, jf. afsnit 2.13 Release management på testmiljøer, jf. afsnit 2.14 Organisation, roller og ansvar, jf. afsnit 2.15 Risikoanalyse og risikostyring, jf. afsnit K 14-3 Teststrategien skal godkendes af Kunden. K 14-4 De indbyrdes tidsmæssige relationer mellem de overordnede testaktiviteter der skal gennemføres, fastlægges i tidsplanen, jf. bilag 1 (Tidsplan) Leverandørens besvarelse af krav til Leverandørens teststrategi Krav ID Kravopfyldelsesgrad Leverandørens bemærkninger Ikke Delvist Helt K 14-1 K 14-2 K 14-3 K 14-4 (x) (x) (x) Side 8 af 36 Bilag 11

9 Leverandørens supplerende bemærkninger [Her kan Leverandøren angive sine supplerende bemærkninger] 2.3. Testplaner For enhver test der skal gennemføres, skal der udarbejdes en testplan. Testplanen for en given test udarbejdes af den part, der er hovedansvarlig for testen (Kunden eller Leverandøren), medmindre andet er anført under beskrivelsen af den konkrete testtype i afsnit 3. For testtypen Overtagelsestest skal en testplan i stedet for punkterne 2-12, i nedennævnte liste af krav til testplaner, inkludere en tjekliste for det der skal være afleveret til Kunden i aftalt kvalitet, og en beskrivelse af en workshop hvor Leverandøren vil demonstrere systemet, samt tidspunkt(er) for gennemgang af tjekliste og afholdelse af workshop. For testtypen driftstest skal en testplan ikke adressere punkterne 4-8 i nedennævnte liste af krav til testplaner. Testplanen har i stedet fokus på, hvad der testmæssigt skal ske lige omkring idriftsættelse, og hvordan der måles under driftstesten og afslutningsvist rapporteres til Kunden. Kunden udarbejder en testplan for hver af de test, Kunden er ansvarlig for. Under hver testtype i afsnit 3 fremgår eventuelle krav til Leverandørens deltagelse i testen. Hvis Leverandøren ønsker det, kan Leverandøren få tilsendt Kundens testplaner, som dog ikke skal godkendes af Leverandøren. I de tilfælde hvor Leverandøren er ansvarlig for en test, skal testplanen leveres til Kunden i henhold til aftalt tidsplan. Er det i tidsplanen ikke eksplicit aftalt, hvornår testplanen for en given test skal fremsendes fra Leverandøren, gælder at testplaner leveres til Kunden senest 15 arbejdsdage før testen skal påbegyndes. Kunden reviewer Leverandørens testplan, under brug af de relevante fejlkategorier i Tabel 2, og afgør, om den kan godkendes. For testplaner gælder det, at tilbagemelding til Leverandøren vedrørende godkendelse skal ske i henhold til aftalt tidsplan. Er det i tidsplanen ikke eksplicit aftalt, hvornår tilbagemelding vedrørende godkendelse skal ske, gælder, at fristen ved testplaner er 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 hurtigst muligt skal reviewe den udbedrede plan, afgøre om testplanen nu kan godkendes, og give Leverandøren besked herom. Det er en betingelse for igangsættelsen af en test, at testplanen er godkendt af Kunden Kundens krav til Leverandørens testplan ID K 14 - Kravtype Beskrivelse For enhver test der skal gennemføres, skal der udarbejdes en Side 9 af 36 Bilag 11

10 1 testplan. K 14-2 K 14-3 Testplanen for en given test udarbejdes af den part der er hovedansvarlig for testen (Kunden eller Leverandøren), medmindre andet er anført under beskrivelsen af den konkrete testtype i afsnit 3. En testplan fra Leverandøren skal som minimum indeholde følgende oplysninger: 1. Kort overordnet beskrivelse af testen og dens formål. 2. Detaljeret tidsplan for testen med angivelse af aktiviteter, milepæle og produkter. 3. Startkriterier (forudsætninger for at den pågældende test kan påbegyndes) og acceptkriterier (beståelseskrav). 4. Beskrivelse af testdesignteknik, det vil sige, efter hvilke(n) procedure(r) testcases udledes eller udvælges. 5. Beskrivelse af testdækning og hvordan der prioriteres, hvis det bliver nødvendigt at skære i testen. 6. Beskrivelse af hvordan der sikres sporbarhed mellem krav og testcases. 7. Beskrivelse af testdata, herunder omfang og hvordan de frembringes. 8. Beskrivelse af de enkelte testcases der skal gennemføres med præcis reference til, hvor de forefindes. Hvis det er krævet for testtypen, jf. afsnit 3, så skal testcases være dokumenteret i Kundens teststyringsværktøj, jf. afsnit 2.7.1, før testen afvikles, medmindre andet eksplicit er aftalt. 9. Beskrivelse af det miljø testen skal udføres i. 10. Beskrivelse af eventuelle testværktøjer og metoder der anvendes. 11. Beskrivelse af de testmetrikker der anvendes. 12. Beskrivelse af software, herunder systemets versionsnummer og eventuelt hvilken anden software, der skal være til rådighed. 13. Beskrivelse af hvordan testen gennemføres, inklusiv planlægning, afvikling og rapportering. 14. Dokumentation der udarbejdes som led i test. 15. Personressourcer, herunder hvilke krav der er til Kundens involvering. Standardindholdet af en testplan, inklusive ovenstående punkter, fremgår af Leverandørens teststrategi Leverandørens besvarelse af krav til Leverandørens testplan Krav ID Kravopfyldelsesgrad Leverandørens bemærkninger Side 10 af 36 Bilag 11

11 Ikke Delvist Helt K 14-1 K 14 2 K 14 3 (x) (x) (x) Leverandørens supplerende bemærkninger [Her kan Leverandøren angive sine supplerende bemærkninger] 2.4. Miljøer De miljøer Kunden generelt anvender, og de miljøer der er tilvalgt i forbindelse med den konkrete aftale, fremgår af bilag 2 (Kundens it-miljø). De tilvalgte miljøer fremgår også af Leverandørens teststrategi Testdata Det fremgår under den enkelte testtype i afsnit 3, hvem der er ansvarlig for at levere testdata. Det er i udgangspunktet Kunden, der leverer testdata. Det forventes dog, at hvis Leverandøren allerede har lavet testdata, der med fordel kan genbruges i en test, Kunden har hovedansvaret for, så får Kunden disse testdata udleveret. Det fremgår af Leverandørens teststrategi, om der anvendes konstruerede testdata, eller om der anvendes konverterede data ved testtyper, som Leverandøren er ansvarlig for. Ved brug af konverterede data fremgår mængden (f.eks. 3 % eller 100 % konverterede data), og det er kort beskrevet, hvordan de vil blive konverteret. Hvis det under en testtype fremgår, at Leverandøren er ansvarlig for at levere testdata, og Leverandøren vurderer, at det ikke er muligt uden Kundens aktive medvirken, så fremgår det af Leverandørens teststrategi, hvilke testdata det kræver Kundens hjælp at fremskaffe Testcases Det fremgår under den enkelte testtype i afsnit 3, hvem der er ansvarlig for at levere testcases. Testcases, der afprøver løsningens funktionalitet, skal være defineret ud fra de i usecases, som Leverandøren skal levere i foranalysen. Enhver testcase der lægges i Kundens teststyringsværktøj skal indeholde en beskrivelse af formål, forudsætninger, hvilke trin der skal gennemløbes med angivelse af input, forventet resultat og en angivelse af hvilke(t) krav der testes. Side 11 af 36 Bilag 11

12 Det fremgår under den konkrete testtype i afsnit 3, i hvilke tilfælde Leverandørens testcases skal lægges i Kundens teststyringsværktøj, hvor afvikling af testcases også dokumenteres. Det fremgår af Leverandørens teststrategi, hvordan det dokumenteres, at systemet lever op til de krav en given testcase tester. Leverandøren skal, i henhold til aftalt tidsplan, gøre de testcases, der vil blive brugt, tilgængelige for Kunden og gøre Kunden opmærksom på, hvor de nu ligger til gennemsyn. Kunden skal have mulighed for selv at supplere med yderligere testcases eller bede Leverandøren gøre dette, såfremt de af Leverandøren foreslåede testcases ikke er dækkende. Kunden skal gøre opmærksom på supplerende testcases eller ønsket herom i henhold til aftalt tidsplan. Kunden skal i sidstnævnte tilfælde beskrive, hvilket område/hvilke områder der skal dækkes (bedre). Er det i tidsplanen ikke eksplicit aftalt, hvornår Leverandøren skal gøre testcases tilgængelige for Kunden og gøre Kunden opmærksom på hvor de er, er fristen senest 15 arbejdsdage før testen afvikles. Ligeledes gælder at Kunden så skal gøre Leverandøren opmærksom på supplerende testcases eller ønsket herom senest 5 arbejdsdage før testen skal afvikles Testværktøjer Fejlrapporteringsværktøj og styring af testcases Med henblik på at kunne styre testcases, håndtere sporbarhed mellem testcases, krav og testforløb og håndtere fejl, benytter Kunden som teststyringsværktøj Atlassian JIRA, Zephyr. Værktøjet benyttes til planlægning, afvikling, styring og dokumentation af testforløb, herunder også til oprettelse og styring af fejlrapporter i forbindelse med testafviklingen. Testværktøjet stilles til rådighed for Leverandøren, der skal kunne integrere til dette med henblik på testafvikling og fejlhåndtering. Det fremgår af Leverandørens teststrategi, om Leverandøren kan integrere til Kundens teststyringsværktøj som beskrevet Automatiserede test I det omfang der benyttes automatiseringsværktøjer til at understøtte gennemførelse af visse testtyper, er dette anført i Leverandørens teststrategi sammen med en kort beskrivelse af de enkelte værktøjer, og hvad de vil blive anvendt til. Det fremgår af Leverandørens teststrategi, om Leverandøren kan integrere til Kundens teststyringsværktøj med henblik på en central afvikling af automatiserede tests i de enkelte værktøjer. Side 12 af 36 Bilag 11

13 2.8. Testafvikling og håndtering af fejl og ændringer En test gennemføres inden for de rammer, der er udstukket i beskrivelsen af den enkelte testtype i afsnit 3. Hvis der konstateres fejl under test/brug i et givet miljø, skal Leverandøren rette fejlen(e) i udviklings-miljøet og ikke i det miljø, hvor fejlen er konstateret. Når fejlen(e) er rettet i udviklingsmiljøet og testet, gentestes systemet i hvert af de efterfølgende miljøer startende med systemintegrationstestmiljøet, indtil man er tilbage ved det miljø, fejlen oprindeligt blev konstateret i. Sådanne gentest i tidligere miljøer baseres om muligt på de testcases, der bruges ved regressionstest, jf. afsnit 2.11, som suppleres af en eksplicit test af de(n) rettede fejl, medmindre test af de(n) rettede fejl allerede dækkes via regressionstesten. I Leverandørens teststrategi er Leverandørens generelle proces for håndtering af fejl og ændringsanmodninger beskrevet både i forbindelse med afvikling af test og ved faktisk brug. Herunder beskrives, hvordan Leverandøren i samarbejde med Kunden sikrer, at Kunden også har tid til de nødvendige gentest inden for den periode, der samlet er afsat til en bestemt test. Fejl fra en test (og eventuelle tidligere tests) skal være udbedret (eller Kunden skal have godkendt en udbedringsplan og accepteret at gå videre), inden den næste test påbegyndes Fejlkategorisering Fejl fundet i forbindelse med en test kategoriseres med hensyn til, hvor alvorlige de er. Kategorierne beskrevet i Tabel 2 benyttes. Under hver fejlkategori er listet et antal muligheder for at en fejl hører til i den pågældende kategori. Der kan være tilfælde, hvor flere af mulighederne er opfyldt, men det er tilstrækkeligt, at blot en af mulighederne er opfyldt, for at fejlen kan klassificeres som hørende til i den pågældende kategori. Hvis en fejl potentielt kan høre hjemme i mere end en kategori, idet en eller flere muligheder er opfyldt for flere kategorier, vil fejlen blive klassificeret i den mest alvorlige kategori. Den tid der er tilbage til produktionssætning, eller til en test skal afsluttes, kan påvirke den kategori en fejl placeres i. Jo kortere tid der er tilbage, jo mere kritisk kan det blive at få en fejl rettet, og en fejl kan således vandre op i kategori, hvis den får lov at ligge. 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. bilag 9 (Samarbejdsorganisation). Nr Betegnelse Beskrivelse. 1 Kritisk fejl Der er tale om en kritisk fejl, hvis et eller flere af følgende punkter gælder: 1. systemet som helhed er utilgængeligt Side 13 af 36 Bilag 11

14 2. kritisk funktionalitet eller kritiske data er helt eller delvist utilgængelige eller korrumperet 3. det er umuligt for brugeren at udføre en eller flere kerneopgaver, idet der ikke findes nogen måde at omgå fejlen på for at kunne teste/bruge systemet som helhed eller de berørte dele 4. kritiske data er tilgængelige for brugere, der ikke burde have adgang, eller brugere har adgang til kritisk funktionalitet, de ikke burde have adgang til 5. der er meget alvorlig sikkerhedsbrister, f.eks. i form af at selv amatørhackere nemt kan skaffe sig adgang, eller der er åbent for virusangreb 6. målt svartid er mere end 60 % større end det aftalte maksimum 7. systemet fejler ved en belastning, der, med den aftalte spidsbelastning/det aftalte maksimum fra svartidstesten som udgangspunkt, er mere end 60 % fra det aftalte øvre målepunkt 8. skalering kræver softwaretilpasninger på applikationen, der kræver mere end to arbejdsdage 9. det er ved nedbrud ikke umiddelbart muligt at gendanne data eller genetablere systemet, ej heller ved at følge dokumentationen, eller der dannes inkonsistente data. 10. dokumentet er som helhed eller med hensyn til mindst 50 % fyldt med fejl sproglige fejl som gør det svært eller umuligt at forstå, og/eller grove forretningsmæssige og/eller tekniske fejl, inkonsistenser og unøjagtigheder eller der er afsnit, som helt eller delvist mangler i forhold til kravene. 2 Alvorlig fejl Der er tale om en alvorlig fejl, hvis et eller flere af følgende punkter gælder: 1. væsentlig funktionalitet er helt eller delvis utilgængeligt 2. det er umuligt eller meget besværligt for brugeren at udføre en eller flere væsentlige opgaver, idet der ikke findes nogen måde at omgå fejlen på for at kunne teste/bruge denne del af systemet eller kun en omgåelse, der kan anvendes med besvær af brugeren 3. væsentlige data er tilgængelige for brugere, der ikke burde have adgang, eller brugere har adgang til væsentlig funktionalitet, de ikke burde have adgang til 4. der er væsentlige sikkerhedsbrister, f.eks. ved at det er muligt for professionelle hackere at skaffe sig adgang ved målrettede angreb 5. målt svartid er mere end 30 % større end det aftalte maksimum 6. systemet fejler ved en belastning, der, med den aftalte Side 14 af 36 Bilag 11

15 spidsbelastning/det aftalte maksimum fra svartidstesten som udgangspunkt, er mere end 30 % fra det aftalte øvre målepunkt 7. skalering kræver softwaretilpasninger på applikationen, der kræver mere end ½ arbejdsdag 8. ved nedbrud kan systemet kun genetableres efter en langt mere omstændelig procedure end beskrevet i dokumentationen, eller der skabes inkonsistente data, som viser sig med det samme, men som det alligevel er vanskeligt at rette op på, eller brugeren oplever reaktioner, der er uforståelige eller forkerte 9. dokumentet indeholder hele afsnit med mange fejl sproglige fejl som gør det svært at forstå, og/eller forretningsmæssige eller tekniske fejl, inkonsistenser og unøjagtigheder og/eller mangler. Afsnittene udgør tilsammen maksimalt 50 % af dokumentet. 3 Betydelige fejl Der er tale om en betydelig fejl, hvis et eller flere af følgende punkter gælder: 1. der er begrænset tilgængelighed til, eller begrænset funktionalitet, i en eller flere mindre kritiske dele af systemet 2. brugen af systemet generes, ved at det producerer ukorrekte, ukomplette eller inkonsistente resultater, hvor dette dog er nemt at opdage og mindre kritisk for funktionaliteten 3. det er muligt at gennemføre testen, evt. ved at omgå fejlen, men der vil ved brug af systemet være en eller flere arbejdsprocesser der ikke kan gennemføres eller kun kan gennemføres ved ændringer i arbejdsgangen, hvilket koster brugeren tid 4. data er tilgængelige for brugere, der ikke burde have adgang, eller brugere har adgang til funktionalitet, de ikke burde have adgang til 5. der er sikkerhedsbrister, f.eks. i form af at folk med insiderviden ved målrettede angreb kan skaffe sig adgang 6. målt svartid er mere end 10 % større end det aftalte maksimum 7. systemet fejler ved en belastning, der, med den aftalte spidsbelastning/det aftalte maksimum fra svartidstesten som udgangspunkt, er mere end 10 % fra det aftalte øvre målepunkt 8. skalering kræver ingen softwaretilpasninger på applikationen, men der er valgt en snæver løsning, som gør skalering uforholdsmæssig dyr eller tidskrævende 9. ved nedbrud kan systemet kun genetableres efter en lidt anderledes procedure end beskrevet i dokumentationen, eller der skabes inkonsistente data, som viser sig med det samme, Side 15 af 36 Bilag 11

16 og som forholdsvist nemt kan rettes, eller brugeren oplever reaktioner, der er misvisende 10. dokumentet indeholder en del fejl (sproglige, forretningsmæssige og/eller tekniske) og mangler, som påvirker brugen af dokumentet. Maksimalt 20 % af dokumentet er behæftet med sådanne fejl. 4 Mindre betydelige fejl Der er tale om en mindre betydelig fejl, hvis et eller flere af følgende punkter gælder: 1. fejlen medfører en mindre gene ved brug af systemet, men blokerer ikke for videre test eller efterfølgende brug. Arbejdsprocesser kan stadig gennemføres normalt, eller eventuelt med mindre ændringer i arbejdsgange for at omgå fejlen 2. der er mindre betydelige sikkerhedsbrister, f.eks. omkring brugen af http only cookies eller TCP timestamps 3. målt svartid er mere end 5 % større end det aftalte maksimum 4. systemet fejler ved en belastning, der, med den aftalte spidsbelastning/det aftalte maksimum fra svartidstesten som udgangspunkt, er mere end 5 % fra det aftalte øvre målepunkt 5. skalering kræver ingen softwaretilpasninger på applikationen, men den valgte løsning gør på flere punkter skalering relativt dyr eller tidskrævende 6. ved nedbrud kan der skabes inkonsistente data, som dog viser sig med det samme og er nemme at rette, eller brugeren kan opleve reaktioner, der kan virke forvirrende 7. dokumentet indeholder mindre fejl, inkonsistenser og/eller unøjagtigheder som ikke på nogen væsentlig måde forringer brugen af dokumentet. 5 Triviel fejl Der er tale om en triviel fejl, hvis et eller flere af følgende punkter gælder: 1. fejlen er ubetydelig eller kosmetisk, og ingen dele af systemet fejler 2. der er nogle helt trivielle observationer omkring sikkerhed, som mest har karakter af, hvad man nok burde gøre på længere sigt 3. målt svartid er 5 % eller mindre større end det aftalte maksimum 4. systemet fejler ved en belastning, der, med den aftalte spidsbelastning/det aftalte maksimum fra svartidstesten som udgangspunkt, er 5 % eller mindre fra det aftalte øvre målepunkt 5. skalering kræver ingen softwaretilpasninger på applikationen, men den valgte løsning gør på et enkelt punkt skalering relativt dyr eller tidskrævende 6. ved nedbrud skabes der i sjældne tilfælde inkonsistente data, Side 16 af 36 Bilag 11

17 som dog viser sig med det samme og er nemme at rette, eller brugeren kan i få tilfælde opleve reaktioner, der kan virke forvirrende 7. dokumentet indeholder nogle ubetydelige fejl som eksempelvis få stavefejl eller en mindre afvigelse i design i forhold til det aftalte, men ikke noget der forringer brugen af dokumentet. Tabel 2. Fejlkategorier Reaktioner ved fejl En test kan afbrydes af Kunden, hvis der findes kritiske fejl eller et antal alvorlige fejl som tilsammen betyder, at kritisk funktionalitet er utilgængelig, og at der ikke findes nogen måde at omgå fejlen(e) på, jf. Tabel 3. Kunden beslutter, om testen kan fortsætte, mens fejlen udbedres. Kunden beslutter ligeledes, om 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. Tabel 3 beskriver, hvordan Leverandøren skal reagere på identificerede fejl og problemer. Testperioden er den periode, der er afsat til selve afviklingen af testen. Nr Betegnelse Reaktion. 1 Kritisk fejl Leverandøren skal straks udbedre en identificeret kritisk fejl. Hvis Leverandøren ikke kan afslutte fejlrettelse inden for en arbejdsdag, leveres der med det samme et estimat til Kunden for, hvornår fejlen forventes rettet, sammen med daglig fremdriftsrapportering vedrørende fejlen. Hvis fejlen optræder i et produktionsmiljø, er Kunden af Leverandøren berettiget til afrapportering af status hver time, indtil fejlen er udbedret. En opdaget kritisk fejl udløser straks et telefonopkald fra Kunden til Leverandøren. Kunden er berettiget til at standse en test, mens en kritisk fejl udbedres. 2 Alvorlig fejl Leverandøren skal give det høj prioritet at udbedre en identificeret alvorlig fejl med det samme. Hvis der er så mange alvorlige fejl, at de ikke alle kan udbedres med det samme, eller hvis der er kritiske fejl der skal løses først, skal Leverandøren levere estimater til Kunden for, hvornår de enkelte alvorlige fejl rettes, og hvor lang tid rettelsen af den enkelte fejl er estimeret til at tage. Kunden er berettiget til daglig fremdriftsrapportering vedrørende rettelse af alvorlige fejl. Kunden er berettiget til at standse testen, mens alvorlige fejl udbedres, såfremt de åbne alvorlige fejl tilsammen svarer til en kritisk fejl, ved at flere hovedveje (kritisk funktionalitet) dermed er helt eller delvist utilgængelige, og der ikke findes nogen måde at omgå fejlene på. 3 Betydelige fejl Leverandøren skal rette en identificeret betydelig fejl, så snart der ikke er flere åbne kritiske eller alvorlige fejl. Fejlen skal rettes i Side 17 af 36 Bilag 11

18 4 Mindre betydelige fejl testperioden, og Kunden skal have tid til gentest. Kunden er berettiget til at prioritere rækkefølgen, hvori fejlene rettes. Leverandøren skal rette en identificeret mindre betydelig fejl, når der er tid. Rettes fejl ikke inden for testperioden, skal Leverandøren levere bindende planer til Kunden, der beskriver, hvornår alle normale fejl på en mangelliste udbedres, og som giver et estimat for rettelse af den enkelte fejl. Planerne skal inkludere tid til Kundens gentest for tests som Kunden har hovedansvaret for, og Leverandøren skal have aftalt med Kunden, at tidspunkt for gentest passer. 5 Triviel fejl Leverandøren skal rette en identificeret triviel fejl, når der er tid, og der ikke er vigtigere fejl at rette. Rettes en fejl ikke inden for testperioden, skal Leverandøren levere bindende planer til Kunden, der beskriver, hvornår alle fejl på en mangelliste udbedres. Planerne skal inkludere tid til Kundens gentest for tests, som Kunden har hovedansvaret for, og Leverandøren skal have aftalt med Kunden, at tidspunkt for gentest passer. Tabel 3. Reaktioner ved identificerede fejl og problemer Regressionstest Når fejl er tilrettet, er det vigtigt at teste for disse fejl, men også at sikre, at der ikke er indtruffet nye fejl, og at resten af systemet ikke har taget skade som følge af fejlretningen. Leverandørens teststrategi beskriver Leverandørens tilgang til regressionstest, inklusiv hvordan et sæt af testcases opbygges, hvordan det vedligeholdes, og hvornår og i hvilke situationer det bruges. Automatiseringsgraden og hvilke aspekter regressionstestsuiten dækker (f.eks. funktionalitet, performance, og/eller sikkerhed) og i hvilket omfang, skal også beskrives. Endvidere fremgår det af Leverandørens teststrategi, hvordan Leverandøren bistår Kunden med at etablere en eller flere regressionstestsuiter som kan køres "stand alone" på Kundens computere Rapportering af resultater Løbende rapportering og proces for håndtering af hændelser Under afvikling af en test, som Kunden har hovedansvaret for, rapporterer Kunden løbende de fejl og problemer, der identificeres. Ligeledes gælder, at Leverandøren løbende rapporterer de fejl og problemer, Leverandøren identificerer under en test, som denne har hovedansvaret for. Rapportering og opfølgning sker i Kundens teststyringsværktøj, medmindre andet fremgår under den enkelte testtype i afsnit 3, som dermed til enhver tid kan give et overblik over bl.a. antal fejl, fordeling på fejlkategori og fremdrift på fejlrettelser. Side 18 af 36 Bilag 11

19 Rapport over testforløbet Den hovedansvarlige (Leverandøren eller Kunden) for en test skal udarbejde en rapport over testforløbet i form af en testrapport, der dokumenterer testens resultat. Eventuelle afvigelser fra dette fremgår under den enkelte testtype i afsnit 3. Testrapporten skal angive resultatet af testens gennemførelse og skal som minimum indeholde følgende: Dokumentation af at alle testcases er gennemført samt resultatet deraf. Kunden har ret til indsigt i Leverandørens interne testrapporter, og Leverandøren skal give Kunden adgang dertil på opfordring. Hvor mange fejl og mangler der er fundet i alt og med hvilken kategori. Hvor mange fejl og mangler der er udestående og med hvilken kategori. Er acceptkriterierne (beståelseskravene) opfyldt? Var startkriterierne opfyldt? Eventuelle afvigelser i forhold til testplanen (inklusive tidspunkter og involverede personer). Oversigt over eventuelle udeståender med angivelse af fejl og/eller manglende overholdelse af servicemål. Testrapporten skal belyse konsekvenser ved accept, hhv. forkastelse, af den pågældende leverance. Evt. øvrige relevante forhold, herunder om testen har været afbrudt af Kunden. Fejl, der er konstateret, men ikke korrigeret af Leverandøren, før Kunden godkender testen som bestået, anføres i en mangelliste med angivelse af tidsfrister for, og ansvarsfordeling ved udbedring og gentest. Leverandøren leverer ved anførsel i mangellisten, en fejlårsagsbeskrivelse samt eventuel dokumentation af udførte interne tests til Kunden. I tilfælde af at der som følge af denne udbedring og gentest sker en tidsmæssig forsinkelse, skal dette også fremgå. Selv om en kendt fejl ikke anføres på listen, indebærer dette ikke afkald på afhjælpning af fejlen. Standardindholdet af Leverandørens testrapporter fremgår af Leverandørens teststrategi Godkendelse af test Godkendelse af en test omfatter to delelementer: Godkendelse af testrapport (eller tilsvarende aftalt dokumentation). Godkendelse af testresultat. Både testrapport og testresultat skal opfylde kravene til godkendelse, før testen samlet kan godkendes. En forudsætning for Kundens godkendelse af en test er, at testrapporten er udarbejdet i overensstemmelse med kravene hertil som angivet i afsnit , Side 19 af 36 Bilag 11

20 herunder at rapporten tydeligt viser, at testen har omfattet test af alle relevante 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 hurtigst muligt og inden for 5 arbejdsdage skal leveres til Kunden. Hvis Kunden ikke er enig i den fremsendte testrapport, eller ikke kan godkende en test, skal Kunden på anmodning have mulighed for fuld indsigt i det materiale, der danner grundlag for testrapporten. Efter modtagelse af en testrapport skal Kunden, i henhold til aftalt tidsplan, skriftligt meddele Leverandøren, om den pågældende test kan godkendes. Er det i tidsplanen ikke eksplicit aftalt, hvornår godkendelse skal ske, er fristen 5 arbejdsdage efter modtagelse af en testrapport fra Leverandøren. Leverandøren udarbejder en mangelliste med angivelse af udestående fejl samt en plan for udbedring af hver af disse. Denne liste indgår som en del af godkendelsesdokumentet for testen. Hvis det er Kunden, der har hovedansvaret for en test, skal Kunden på tilsvarende vis skriftligt meddele Leverandøren, om testen er bestået eller ej. Medmindre andet er aftalt i tidsplanen, skal dette ske inden for 10 arbejdsdage efter, testen er gennemført og den afsluttende testrapport udarbejdet. Åbne fejl fra tidligere tests indgår i opgørelsen over antallet af konstaterede fejl i en test. I afsnit 3 er der for hver enkelt testtype angivet slutkriterier, det vil sige, hvilke kriterier der skal være opfyldt, for at testen kan godkendes Konfigurationsstyring af testware Konfigurationsstyring af testware har til formål at etablere og vedligeholde integriteten af produkter relateret til test, så f.eks. al software og alle dokumenter er identificeret og underlagt versionsstyring, så der opretholdes fuld sporbarhed. Det fremgår af Leverandørens teststrategi, hvad der er omfattet af Leverandørens konfigurationsstyring af testware, og hvordan den foregår (infrastruktur og procedurer) Release management på testmiljøer I Leverandørens teststrategi er release management på testmiljøer beskrevet, herunder versionsstyring af systemer og subsystemer på testmiljøer, så det er Side 20 af 36 Bilag 11

21 klart, hvad der testes på, og at der ikke er konflikt med andre sameksisterende systemer Organisation, roller og ansvar Det fremgår af Leverandørens teststrategi, hvem der forestår den daglige testplanlægning i forbindelse med de tests, Leverandøren har hovedansvaret for, og hvem der på Leverandørens side er ansvarlig ved bistand til test, som Kunden har hovedansvaret for. Leverandøren skal om nødvendigt levere ressourcer, som har viden om og forståelse for systemet, til at hjælpe Kunden eller dennes 3. part under test med henblik på at undgå unødigt spild af tid, f.eks. hvis systemet eller dele heraf går ned. Det fremgår ligeledes af Leverandørens teststrategi, hvilke krav Leverandøren stiller til brug af Kundens personressourcer i de tests, Leverandøren har hovedansvaret for. Ved tests som Kunden har hovedansvaret for, er det Kundens testmanager, der forestår den daglige testledelse i form af detailplanlægning, herunder uddelegering af testarbejde til de enkelte medarbejdere knyttet til testen. Kundens testmanager har ansvaret for at godkende Leverandørens testplaner, testcases, testrapporter og eventuelt andet aftalt materiale. Kundens testmanager informerer Leverandøren som aftalt med hensyn til testplaner, testcases, testrapporter og eventuelt andet relevant materiale. Leverandøren skal ikke godkende materiale fra Kunden, men det står Leverandøren frit for at fremsende kommentarer. Side 21 af 36 Bilag 11

22 3. Testkatalog Dette afsnit beskriver de testtyper, Kunden generelt anvender - både testtyper Leverandøren er hovedansvarlig for, og testtyper Kunden er hovedansvarlig for Funktions- og systemintegrationstest Formål Hovedansvar og beskrivelse Startkriterier Beskrivelse Tester integration af systemet mod andre (del-) systemer og grænseflader til eksterne organisationer samt systemets funktionalitet. Hovedansvaret er hos Leverandøren. Leverandøren skal teste at det udviklede/ændrede system (gælder også hyldevarer) fungerer sammen med de andre systemer, det har snitflader til, og om det således opfylder de stillede krav både funktionelle og non-funktionelle. Testen inkluderer, at systemets forretningsmæssige funktionalitet testes. Leverandøren skal sørge for, at Kunden har adgang til, fra start til slut, at se kildekode, testcases og testresultater. Adgangen skal ske fra en brugervenlig grænseflade i form af en slags dashboard, som giver adgang til nemt at følge udviklingen i bl.a. testcases, testresultater og dækningsgrad (coverage). Leverandøren skal via testplanen beskrive, hvordan Kunden vil have nem adgang til at se kildekode, testcases og testresultater, herunder hvilken grænseflade der vil blive benyttet, medmindre dette allerede er beskrevet i en tidligere testplan, der er godkendt af Kunden og ikke har ændret sig. Testplanen skal endvidere give Kunden indsigt i, hvor grundigt der testes (dækningsgrad), og hvilke dele af systemet der eventuelt er udvalgt som de centrale, og dermed dækkes tættere rent testmæssigt. Leverandøren skal også oplyse, om der genbruges testcases fra andre tests, i så fald hvilke, samt i hvilken grad afviklingen af testen er automatiseret. Testen starter, når Leverandøren vurderer, at standardløsning og tilpasninger er så langt, at det ikke giver ressourcespild at påbegynde testen, systemet er installeret i systemintegrationstestmiljøet, og Leverandøren har testet, at det er parat til funktions- og systemintegrationstest. Hvis en konverteret database er en forudsætning for funktions- og systemintegrationstesten, Side 22 af 36 Bilag 11

23 Acceptkriterier Miljø Testdata Testcases skal en konverteringstest være gennemført og godkendt, og den konverterede database skal være en integreret del af det system, der køres funktions- og systemintegrationstest på. Testen kan godkendes, når den er gennemført efter testplanen, og antallet af fejl overholder det af Kunden fastlagte accepterede antal fejl, det vil sige, ingen kategori 1 og 2 fejl og maksimalt 3 kategori 3 fejl, 15 kategori 4 fejl og 25 kategori 5 fejl. Desuden skal testen være dokumenteret i en testrapport, der er godkendt af Kunden. Udføres af Leverandøren i systemintegrationstestmiljøet. Eventuelle testdata leveres af Leverandøren. Udarbejdes af Leverandøren Review Formål Hovedansvar og beskrivelse Startkriterier Acceptkriterier Beskrivelse Evaluerer kvalitet og overensstemmelse med krav og klarlægger dermed eventuelle fejl, mangler og forbedringsmuligheder ved et produkt i forbindelse med systemet, f.eks. brugervejledning eller installations vejledning. Hovedansvaret er hos Kunden. Kunden skal reviewe de produkter, Leverandøren udarbejder i tilknytning til systemet, med henblik på at kvalificere produkterne til en efterfølgende godkendelsesproces. Det kan f.eks. dreje sig om brugervejledning, systemvejledning, testcases, og testrapporter. På baggrund af Kundens kommentarer, opdaterer Leverandøren det produkt kommentarerne angår. Er der tale om et produkt, der andrager mere end hvad der svarer til 30 sider, skal Leverandøren medmindre andet eksplicit er aftalt - fremsende det opdaterede produkt igen inden for 5 arbejdsdage. Ved mindre produkter er fristen 3 arbejdsdage. Der afholdes review, når der er brug for det, altså når som helst Leverandøren har afleveret et produkt, der knytter sig til systemet, og som skal godkendes af Kunden. Testen starter, når Leverandøren i henhold til aftale (tidsplan) leverer et produkt til Kunden, der knytter sig til systemet. Testen kan godkendes, når antallet af fejl overholder det af Kunden fastlagte accepterede antal fejl i en Leverance, det Side 23 af 36 Bilag 11

24 Miljø Testdata Testcases vil sige: ingen kategori 1 og 2 fejl og maksimalt 3 kategori 3 fejl, 15 kategori 4 fejl og 25 kategori 5 fejl. Udføres hos Kunden. N/A N/A 3.3. Installationstest Formål Hovedansvar og beskrivelse Startkriterier Acceptkriterier Miljø Testdata Testcases Beskrivelse Tester om systemet er installeret korrekt og i overensstemmelse med installationsvejledningen, i den rigtige version på det relevante miljø, samt tester at andre systemer på miljøet ikke er påvirket. Hovedansvaret for installationstesten er hos Leverandøren. Leverandøren skal sørge for at få installeret systemet i det relevante it-miljø hos Kunden og herunder sikre, at andre applikationer, der kører i samme miljø, ikke har lidt skade ved installationen. Det forventes, at installationstesten kan gennemføres på maksimalt en dag. Testen udføres hver gang en ny release installeres i et miljø. Testen starter ikke, før der er brug for at installere en ny release af systemet i et af Kundens miljøer, før det relevante miljø er parat, og før Leverandøren har en installationspakke parat. Testen kan godkendes, når den er gennemført efter testplanen, det er verificeret at eventuelle andre systemer ikke er påvirket, Kunden er underrettet om testens udfald, og antallet af fejl overholder det af Kunden fastlagte accepterede antal fejl i en Leverance, det vil sige: ingen kategori 1 og 2 fejl, maksimalt 3 kategori 3 fejl, 15 kategori 4 fejl og 25 kategori 5 fejl. Gennemføres af Leverandøren i det relevante af Kundens miljøer. Eventuelle testdata leveres af Leverandøren. Udarbejdes af Leverandøren Smoketest Formål Beskrivelse Afvikler en udvalgt delmængde af alle definerede/planlagte testcases, der dækker hovedfunktionaliteten i en komponent eller et system, for Side 24 af 36 Bilag 11

25 Hovedansvar og beskrivelse Startkriterier Acceptkriterier Miljø Testdata Testcases Bemærkninger at fastslå at de vigtigste funktioner i komponenten/systemet fungerer. Testen går ikke i detaljer. Hovedansvaret er hos Leverandøren (A) henholdsvis Kunden (B) som følger. A: Hovedansvaret ligger hos Leverandøren umiddelbart efter enhver installationstest. På det tidspunkt udfører Leverandøren en smoketest for at konstatere, om hovedfunktionaliteten i den nye release fungerer efter hensigten og er parat til Kundens test. B: Hovedansvaret ligger hos Kunden, når Leverandøren har meldt en release klar til Kundens test. Kunden kan så vælge at gennemføre en smoketest, før den næste anden test påbegyndes, som Kunden har hovedansvaret for. Kunden bruger smoketesten til at vurdere, om videre testaktivitet giver mening, det vil sige, til at vurdere om hovedfunktionaliteten kan testes. Testens resultat dokumenteres, uanset om den konkrete test er gennemført af Leverandøren eller Kunden, i Kundens teststyringsværktøj, ved at status for afvikling af de testcases, der indgår i smoketesten, angives. Det forventes, at en smoketest kan gennemføres på maksimalt en dag. For Leverandørens vedkommende: Testen starter ikke, før en forudgående installationstest er afsluttet og godkendt, og testcases er dokumenteret i Kundens teststyringsværktøj. For Kundens vedkommende: Testen starter ikke, før Leverandøren har gennemført en installationstest og smoketest, der er godkendt, og har meldt systemet klar til test til Kunden. Testen kan godkendes, når den er gennemført efter testplanen, og antallet af fejl overholder det af Kunden fastlagte accepterede antal fejl i en Leverance, det vil sige: ingen kategori 1 og 2 fejl, maksimalt 3 kategori 3 fejl, 15 kategori 4 fejl og 25 kategori 5 fejl. Desuden skal testens resultater være dokumenteret i Kundens teststyringsværktøj. Gennemføres i det af Kundens miljøer, hvori den forudgående installationstest blev gennemført. Den hovedansvarlige for testen er ansvarlig for at levere eventuelle testdata. Den hovedansvarlige har ansvaret for at udarbejde de testcases, der indgår i smoketesten. Disse testcases dokumenteres i Kundens teststyringsværktøj. Når installation i produktionsmiljøet er fuldført, er det Side 25 af 36 Bilag 11

26 meget vigtigt at teste, at alt kører og fungerer Konverteringstest Formål Hovedansvar og beskrivelse Beskrivelse Tester at konverteringsprocesser, der skal konvertere data fra et eksisterende system til et nyt system, virker og har det ønskede resultat, herunder at konverterede data er korrekte og komplette. Hovedansvaret er hos Leverandøren, men Kunden bidrager aktivt ved at teste de senere prøvekonverteringer for deres korrekthed. Der skal gennemføres konvertering af data. Testen i forbindelse hermed foregår i to tempi: 1. Leverandøren skal udforme og teste de i videst muligt omfang automatiserede procedurer og regler, der skal til for at konvertere alle data. Herunder skal Leverandøren teste de enkelte komponenter og deres indre sammenhæng for at afprøve, om de aftalte regler er implementeret. Reglerne testes ved at overføre nogle få data. 2. Når resultatet af testen under punkt 1 er tilfredsstillende, gennemføres et antal prøvekonverteringer, hvor hele flowet testes. Leverandøren bruger som minimum den første prøvekonvertering til at sikre sig, at konverteringsprocessen fungerer korrekt. Ved senere prøvekonverteringer tester Leverandøren, at konverteringen er gået godt. I den forbindelse testes bl.a. gennemløbstid til konvertering og afstemning af start- og slutbalance (det vil sige, at der ikke er mistet data) samt øvrige afstemninger og kontroller i konverteringsprocessen. Endvidere stiller Leverandøren ved senere prøvekonverteringer data til Kundens rådighed, således at Kunden er i stand at afvikle sine egne testcases, der skal afprøve, om prøvekonverteringen er lykkedes. Konvertering skal starte tidligt nok til, at der kan være en prøvekonvertering, som Leverandøren kan benytte i forbindelse med funktions- og systemintegrationstesten, og tilsvarende skal der være en prøvekonvertering (eventuelt den samme), som kan benyttes ved Kundens efterfølgende test, herunder funktionel kravtest. Det aftales eksplicit, hvor stor en delmængde af de originale data der skal være konverteret og til rådighed for hvilke test. En mere udstrakt test af konverteringen laves indirekte i Side 26 af 36 Bilag 11