Bilag 14. Hovedtestplan. Udbud af Medical Device Information Collection

Transkript

1 Bilag 14 Hovedplan Udbud af

2 INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse. Formål med Bilag: Formålet med dette Bilag er at beskrive Hovedplan for MDIC udbud. Instruks vedrørende Bilag: I forbindelse med afgivelse af tilbud, skal Tilbudsgiver ikke udfylde eller besvare Bilaget. Evaluering af besvarelse: Bilaget evalueres ikke. Tilbudsgivers forbedringsforslag: Det vil være muligt at angive forbedringsforslag i Bilag 80, Tilbudsgivers forbedringsforslag. Sådanne forslag kan blive drøftet i forhandlingsfasen, men vil ikke nødvendigvis blive det. Side 1 af 17

3 Indhold INDLEDNING OG VEJLEDNING... 3 Indledning... 3 Begreber... 3 Tidsplan... 3 Vejledning... 3 Regionens Strategi HOVEDTESTPLAN Testtilgang Formål Fremgangsmåde Angivelse af Risikoprofil Identificering og prioritering af cases Beslutning om omfang Prøver og typer Fabriksprøve Installationsprøve Overtagelsesprøve Driftsprøve Testplan Formål Indhold Testrapport Formål Indhold Godkendelse af en prøve eller type Testdata Fejlhåndtering Fejlhåndteringsprocess Beskrivelse af trinene i processen fejlhåndtering: Fejlkategorier Reaktioner ved fejl Godkendelseskriterier Testværktøj Organisation og ansvar Ansvarsfordeling Leverandørens deltagelse Side 2 af 17

4 14.1 Indledning og vejledning Indledning Dette bilag beskriver hvilke prøver og typer, der kan afvikles i forbindelse kvalitetssikringen af leverandørens Løsning Begreber Kunden benytter ISTQB -begreber og forventer ligeledes at Leverandøren benytter denne termilogi. Region Syddanmark Hovedplan Testplan Testrapport Prøve Testtype Beskrivelse En overordnet plan for gennemførsel af de prøver og typer, der skal til for at kvalitetssikre Løsningen. En detaljeret plan for gennemførsel af henholdsvis en prøve og en type. En rapport over den gennemførte prøve eller type. En prøve er den overordnede betegnelse for en række typer der skal gennemføres og indeholder derfor flere typer. En gruppe aktiviteter, som sigter mod at e en komponent eller et system med fokus på et specifikt formål, fx funktionel, brugervenligheds, regressions etc. En tsttype kan afvikles i flere prøver Tidsplan Hvornår de enkelte prøver og typer skal afvikles, fremgår af den til enhver tid gældende Tidsplan. Tidsplanen skal indeholde de enkelte prøver og typer samt forudsætningerne for disse, i form af milepæle Vejledning Dette bilag er Kundens forslag til en Hovedplan, som beskriver hvilke prøver og typer en given Leverance fra Leverandøren kan gennemgå, før Leverancen sættes i drift. Den endelige Hovedplan udarbejdes i forbindelse med afklaringsfasen, i samarbejde mellem Kundens og Leverandørens manager Regionens Strategi Det er vigtigt for Kunden, at de IT-Løsninger, som bliver implementeret hos Region Syddanmarks slutbrugere, har en så høj grad af kvalitet og stabilitet som muligt, uden at der benyttes uhensigtsmæssigt mange ressourcer. Region Syddanmark har typisk mange brugere på de forskellige IT- Løsninger, hvorved selv små fejl i løsningerne, kan give store økonomiske og ressourcemæssige udfordringer for de enkelte forretningsenheder. Regionen forventer derfor, at de leverandører, som leverer IT-Løsninger til Regionen, påtager sig et medansvar for, at de løsninger, de leverer, er kvalitetssikret i overensstemmelse med Kundens forventninger, således at de IT-Løsninger der ibrugtages, har en høj grad af kvalitet og stabilitet. Regionen anser kvalitetssikringen af en kommende IT-Løsning, som en fælles indsats i samarbejde med Leverandøren. For at dette samarbejde kan fungere, er det vigtigt, at begge Parter har en stor grad af åbenhed og ærlighed. Regionen ønsker at undgå diskussioner om bod og misligholdelse af kontrakter, men ønsker i stedet løsninger på udfordringer, når Løsningen skal afprøves. Regionens tilgang bygger på en risikobaseret fremgangsmåde, hvor der på baggrund af en risikovurdering af produktets elementer besluttes, hvordan og hvorledes produktet kvalitetssikres bedst muligt. Side 3 af 17

5 14.2 Hovedplan Hovedplanen beskriver alle de prøver og typer, som den samlede Løsning skal gennemgå forud for idriftsættelse Testtilgang Region Syddanmark benytter en Risikobaseret tilgang til at identificere hvilke elementer af Løsningen, der skal fokuseres mest på i forbindelse med kvalitetssikring Formål Formålet med den risikobaserede tilgang er, at fokusere på de områder af Løsningen, hvor risikoen for fejl er størst. Der hvor Kunden ser de største risici er ved nyudvikling og ved større ændringer eller konfigureringer af standardløsningen Fremgangsmåde Leverandøren opdeler Løsningen i logiske mindre elementer, som tilsammen beskriver den tilbudte Løsning. Elementerne skal have en tilpas størrelse til, at elementet kan vurderes i forhold til kompleksitet og konsekvens. Se nedenstående Tabel 1. Hvert element risikovurderes af Leverandøren ud fra kompleksitet eller risiko for, at der vil være fejl i netop det element af Løsningen. Vurderingen angives med høj, mellem eller lav og skal være velbegrundet. Samme element vurderer Leverandøren ud fra en forventning om hvilken konsekvens elementet har for Kundens forretning. Vurderingen angives med høj, mellem eller lav og skal være velbegrundet. Samme fremgangsmåde benytter Kunden til risikovurdering af den tilbudte Løsning, på baggrund af de elementer Leverandøren har opdelt systemet i. I afklaringsfasen afstemmes forventningerne til risikoprofilerne med baggrund i Leverandørens risikovurdering og Kundens risikovurdering. Derefter fastsætter Kunden i samarbejde med Leverandøren det endelige omfang af, de enkelte prøver og typer, der skal gennemføres, for at kvalitetssikre Løsningen på bedst mulig måde. Side 4 af 17

6 Kompleksitet Angivelse af Risikoprofil Kompleksitet og Konsekvens lægges sammen og angiver derved, hvilken risikoprofil elementet har. I Tabel 1 ses hvorledes risikoprofilen angives ud fra kompleksitet og konsekvens. Høj Medium Lav Konsekvens Lav Medium Høj B A A C B A C C B Tabel 1 Risikomatrix med angivelse af Risikoprofil i forhold til konsekvens og kompleksitet Risikoprofil A Risikoprofil A er den højeste risikoprofil, der opereres med. Profilen er kendetegnet ved, at en eller begge vurderinger er defineret til værende Høj og ingen vurdering har værdien Lav. Risikoprofil B Risikoprofil B er defineret ved, at kun en af vurderingerne er Høj, hvor den anden er Lav, eller begge er vurderet til Mellem. Risikoprofil C Risikoprofil C er den laveste kategori et element kan have. Profilen er kendetegnet ved, at en eller begge vurderinger er defineret til værende Lav og ingen vurdering med værdien Høj Identificering og prioritering af cases Testcases identificeres med udgangspunkt i Leverandørens Systembeskrivelse og de krav, Kunden har stillet til Løsningen. Identificeringen af cases sker i samarbejde med slutbrugere af Løsningen og med hjælp fra faglig personale. Efter identificeringen af cases prioriteres casene ud fra hvor vigtigt det er, at casen gennemføres set i relation til det enkelte elements betydning for den samlede Løsning. Alle cases skal forsynes med en prioritet, angivet mellem 1 og Beslutning om omfang Ud fra risikoprofilen beslutter Kundens manager jf. afsnit hvor omfattende en af det enkelte element skal være. Det er kun i forbindelse med planlægning af Overtagelsesprøven at Risikoprofilerne benyttes, da omfanget af de andre prøver er fastlagt jf. afsnit og skal gennemføres uanset Risikoprofil. Risikoprofil A Har den højeste risikoprofil, hvilket betyder at det enkelte element skal es grundigt. Alle cases skal afvikles for dette niveau uanset prioritering. Risikoprofil B Den risikoprofil ligger midt mellem den høje og den lave hvilket betyder, at en af det pågældende element er vigtigt. Alle cases med prioritet 1 og 2 skal afvikles for dette niveau. Risikoprofil C Har den laveste risikoprofil, hvilket betyder at det enkelte element ikke behøver, at blive et så grundigt. Alle cases med prioritet 1 skal afvikles for dette niveau. Side 5 af 17

7 Prøver og typer Tabel 2 indeholder en oversigt over hvilke prøver, der indgår i kvalitetssikringen samt de typer de enkelte prøver består af. En type er således at betragte som et delelement af en prøve. Prøve Testtyper Beskrivelse Miljø Leverandør Kunde Type Fabriksprøve Leverandørens egen kvalitetssikring af Leverancen. Testmiljø hos Leverandøren Installationsprøve Afprøver ved installation i et nyt miljø om Leverancen kan installeres og er i funktionsdygtig stand. Alle miljøer hos Kunden Installations Tester om et softwareprodukt kan installeres på et givet miljø. Alle miljøer hos Kunden Nonfunktionelle Smoke Kontrollerer at de vigtigste funktioner kan tilgås og overordnet fungere. Alle miljøer hos Kunden Funktionelle Systemintegrations Tester grænseflader og integrationer til andre systemer. I forhold til installationsprøven verificeres at integrationerne overordnet fungerer. Alle miljøer hos Kunden Funktionelle Overtagelsesprøve Kundens miljø Kontrollerer om den aftalte funktionalitet og dokumentation er leveret, korrekt installeret, konfigureret og overholder Servicemålene. Forretningsvendte Afprøver systemets brugervenlighed jf. krav herom i Kontrakten. Kundens miljø Brugervenligheds Brugervenligheds Tester grænseflader og integrationer til andre systemer. Kundens miljø Systemintegrations Funktionelle Dokumen- Tester om den fremsendte dokumentation opfylder kravene og fremgår af aktivitets- Ingen og Udfø- Dokumentations Side 6 af 17

8 tations oversigten. rende og Review Funktionel krav Tester alle funktionelle krav til Leverancen. Kundens miljø Funktionelle Regressions Test af et tidligere et program efter modificering for at sikre, at defekter (fejl) ikke er tilført eller afdækket i uændrede dele af softwaren som følge af de gennemførte ændringer. Kundens miljø Funktionelle Tekniske Belastnings Tester om Leverancen overholder de specificerede krav til svartider. Belastningsen gennemføres på minimum en time, både under normal belastning og under spidsbelastning. Produktionsmiljø Nonfunktionelle Skalerbarheds Tester hvor skalerbart softwareproduktet er i forhold til antal samtidige brugere. Bruger kan i dette tilfælde f.eks. være følgende: Medicoteknisk apparatur. Produktionsmiljø Nonfunktionelle Systembruger. Integrationer, f.eks. CPRkomponenten. Anvendersystemer. Stabilitets Tester hvor stabilt systemet er over længere tids belastning. Stabilitetsen skal som minimum gennemføres på 12 timer og belastes med ca. 80% af max brugerantal. Max brugerantal identificeres i forbindelse med Skalerbarhedsen. Produktionsmiljø Nonfunktionelle Fail over Tester om Leverancen reagerer planmæssigt i tilfælde af, at der sker nedbrud på de enkelte systemkomponenter/systemet. Produktionsmiljø Nonfunktionelle Tester hvor sikkert et softwareprodukt er i forhold til sikkerhedsmæssige trusler. Sikkerheds Produktionsmiljø Nonfunktionelle Side 7 af 17

9 Leverandøren Kunden Backup Tester om der kan foretages backup og at denne backup kan bruges til at reetablere systemet efter eventuelle nedbrud. Produktionsmiljø Nonfunktionelle Driftsprøve Formålet med driftsprøven er at konstatere, at Leverancen fungerer iht. krav og Servicemål. Produktionsmiljø Alle typer Drifts Afprøver programmet, supportorganisationen og de tilhørende processer i en reel driftssituation for at konstatere om specifikationer, Servicemål og processer er overholdt i drift. Produktionsmiljø Alle Typer Tabel 2 - Oversigt over prøver og typer Fabriksprøve Det er Leverandørens ansvar at Løsningen kvalitetssikres på bedst mulig måde hos Leverandøren, inden Løsningen afleveres til kvalitetssikring hos Kunden. Kunden blander sig ikke i, hvorledes Leverandøren kvalitetssikrer Løsningen, men forventer dog, at Løsningen har en høj kvalitet, inden Kunden får den til kvalitetssikring. Leverandøren skal dog som minimum levere en rapport jf. afsnit over resultatet af Fabriksprøven Installationsprøve Installationsprøven skal sikre, at Løsningen kan installeres på Kundens miljø ud fra installationsvejledningen. Installationsprøven skal afvikles på alle de miljøer, hvor Løsningen skal installeres. Herunder ses processen for Installationsprøven. Installationsprøve Installationsvejledning godkendt Godkend rapport Installationsprøve godkendt Planlæg installationsprøven Udfør installationsprøve (miljø) Udarbejd rapport Lever rapport Figur 1 Proces for Installationsprøven Side 8 af 17

10 Leverandøren Kunden Startbetingelser Følgende startbetingelser skal alle være opfyldt, før installationsprøven kan starte: Der forelægger en plan for prøven og typerne, som er udarbejdet af Leverandøren. Testplanerne skal være godkendt af RSD. Hardware på miljøet, hvor installationen skal foregå, er etableret af RSD. Installationsvejledningen skal være godkendt af RSD. Leverandøren har registreret alle krav til installationsprøven i værktøjet, og der er sikret Sporbarhed mellem cases og alle krav. Slutkriterier Følgende slutkriterier skal alle være opfyldt, før installationsprøven kan afsluttes: Alle planlagte cases, uanset prioritering, for installationsprøven og de tilhørende typer er afviklet og alle cases har enten status Passed eller Failed. Tiden afsat til Prøven er udløbet Overtagelsesprøve Overtagelsesprøven skal sikre, at Løsningen opfylder alle kravene i Kontrakten. Overtagelsesprøve Planlæg overtagelsesprøven Udfør overtagelsesprøve (miljø) Udarbejd rapport Lever rapport Overtagelsesprøve godkendt Systembeskrivelse godkendt Udarbejd Løsning og dokumentation Installer Løsning (Installationsprøve) Ret evt. fejl i Løsning og dokumentation Figur 2 Proces for Overtagelsesprøven Startbetingelser Følgende startbetingelser skal alle være opfyldt før overtagelsesprøven kan starte: Installationsprøven skal være godkendt. Systembeskrivelsen skal være godkendt. Godkendt plan for prøven. Godkendt tesplan for typerne. Alle krav er registreret i værktøjet, og der er linket cases til alle krav, inklusiv krav til dokumentation. Slutkriterier Følgende slutkriterier skal alle være opfyldt før overtagelsesprøven kan afsluttes: Alle planlagte cases, jf. risikoprofilen, for overtagelsesprøven og de tilhørende typer er afviklet og alle cases har enten status Passed eller Failed. Tiden afsat til prøven er udløbet Driftsprøve Driftsprøven skal sikre, at den komplette Løsning fungerer i drift, herunder processerne omkring supportorganisationen. Driftsprøven skal ligeledes sikre, at Løsningen opfylder Servicemålene målt over en periode på minimum 30 dage. Side 9 af 17

11 Leverandøren Kunden Driftsprøve Overtagelsesprøve godkendt Planlæg driftsprøve Afvikl driftsprøve Godkend driftsprøve Udarbejd rapport Lever rapport Driftsprøve godkendt Installer Løsning i driftsmiljø Support og vedligehold af Løsningen Figur 3 Proces for Driftsprøven Startbetingelser Følgende startbetingelser skal alle være opfyldt før driftsprøven kan starte: Overtagelsesprøven skal være godkendt. Der forelægger en plan for prøven. Løsningen skal være implementeret og ibrugtaget jf. implementeringsplanen. For alle udestående fejl skal der være udarbejdet en handlingsplan. Overvågning af svartider skal være sat op og kørende. Slutkriterier Følgende slutkriterier skal alle være opfyldt, før driftsprøven kan afsluttes: Tiden afsat til prøven er udløbet Testplan Formål Testplanens formål er at beskrive prøven og typens indhold og omfang, samt hvilke rammer typen skal afvikles under Indhold En plan skal som minimum indeholde følgende oplysninger: Formål: Kort overordnet beskrivelse af en og dens formål. Tidsplan: Detaljeret tidsplan for en, eventuelt som henvisning til projektets tidsplan. Start- og slutkriterier: Hvornår kan en starte og hvornår kan en slutte. Testdata: Beskrivelse af data og hvem der er ansvarlig for fremskaffelse af disse. Scope for en: Hvilke områder, der es. Testcases: Hvilke cases, der skal afvikles og hvor casene kan findes. Testdækning i forhold til krav, hvilke krav er dækket af hvilke cases. Sporbarhed: Sporbarhed fra krav til dokumentation til cases. Testmiljø: Beskrivelse af det miljø en skal udføres i. Testelement: Hvilke dele af Løsningen es (hardware og software). Udstyr: Medicoteknisk apparatur, der skal bruges i forbindelse med en. Rapportering: Hvilke rapporter, der udarbejdes i forbindelse med en. Personressourcer: Hvilke ressourcer skal være tilrådighed, fra både Kunde og Leverandør. Godkendelseskriterier: Hvilke kriterier skal være opfyldt, før en kan godkendes. Side 10 af 17

12 Testrapport Formål Testrapportens formål er at angive resultatet af prøvens eller ens gennemførsel. Testrapporten er det dokument, der danner grundlag for godkendelse af en prøve eller type. Der udarbejdes en rapport pr. type og en rapport for en prøve. Testrapporten skal leveres senet 5 arbejdsdage efter endt prøve eller type Indhold En Testrapport skal som minimum indeholde følgende: Ledelsesresume: Samlet resultat af en. Opfyldelse af startkriterier: Var startkriterierne opfyldt. Resultat af cases: Samlet overblik over cases inkl. status. Hvor mange fejl/problemer, der er fundet i alt og med hvilken kategori. Hvor mange fejl/problemer, der er udestående og med hvilken kategori. Oversigt over eventuelle udeståender. Handlingsplan for eventuelle udestående fejl/problemer (Kræver input fra Leverandøren). Er slutkriterierne opfyldt. Eventuelle afvigelser i forhold til planen (inklusive tidspunkter, involverede personer, data, scope osv.). Opfyldelse af godkendelseskriterierne Godkendelse af en prøve eller type Godkendelsen af en prøve eller type sker på baggrund af rapporten samt godkendelseskriterierne i afsnit Det er alene Kunden, der kan godkende en prøve eller type. Kan prøven ikke godkendes, skal Kunden senest 10 Arbejdsdage efter prøvens afslutning give Leverandøren meddelelse om årsagen til den manglende godkendelse. Såfremt Kunden ikke afgiver meddelelse om godkendelsen inden fristen, kan Leverandøren afgive meddelelse om, at prøven anses for godkendt, medmindre Kunden inden 5 Arbejdsdage afgiver meddelelse om afvisning af prøven. Såfremt Kunden udsteder godkendelse af en prøve, uanset at der består Fejl, som Parterne er opmærksomme på, skal disse anføres i handlingsplanen for eventuelle udestående Fejl/problemstillinger listen. Manglende optagelse i denne liste indebærer intet afkald fra Kundens side på at kræve en Fejl/problemstilling afhjulpet Testdata Til generering af data skal Leverandøren levere en Stub, som simulerer flere Medicotekniske apparater, der er tilkoblet en patient. Stubben benyttes til at definere hvilke data, der skal sendes ind i Løsningen, således man har fuld kontrol over dataflowet i forbindelse med en. Krav til stubben kan findes i Bilag 3, Leverancebeskrivelse og Kravspecifikation i afsnit: Krav fra andre bilag Fejlhåndtering Alle fejl skal være dokumenteret i værktøjet. Kundens manager er ansvarlig for at visitere alle fejl og sikre, at de er klassificeres korrekt jf. afsnittet om Fejlkategorier. Som udgangspunkt er det Kunden der fastsætter fejlkategorien. Hvis Leverandøren ikke er enig i denne fejlkategorisering, afholdes der et møde mellem Kundens og Leverandørens Testmanager, hvor der forsøges at nå til enighed. Hvis dette ikke lykkes eskaleres problemstillingen jf. eskalationsproceduren beskrevet i Bilag 10 Samarbejdsorganisation. Hvis der konstateres fejl under en i et givet miljø, skal Leverandøren rette disse i udviklingsmiljøet og ikke i det miljø, hvor fejl er konstateret. Når fejl er rettet i udviklingsmiljøet, genes rettelsen i Side 11 af 17

13 Leverandøren Kunden hvert af de efterfølgende miljøer, startende med Kundens miljø, indtil fejlrettelsen er godkendt i det miljø, hvor fejl blev konstateret. Sådanne gens baseres om muligt på cases, der indgår i regressionsen. I forbindelse med afklaringsfasen skal der udarbejdes en fejlhåndteringsproces, som beskriver hvorledes fejl håndteres, så der til enhver tid er enighed om, hvem der er ansvarlig for en given fejl Fejlhåndteringsprocess Nedenstående tegning illustrerer forslag til fejlhåndteringsprocessen. Fejlhåndtering Fase Ny fejl identificeret Fejl afvist Fejl klar til Teststatus Fejl et, OK Fejl lukket Fejl et, ikke OK Vurder fejl Fejl åbnet Fejl rettet Beskrivelse af trinene i processen fejlhåndtering: Trin Status Handling Beskrivelse 1 Ny fejl identificeret En fejl observeres, denne dokumenteres, vurderes og klassificeres. 2 Vurder fejl Fejl vurderes af Leverandøren. 3 Fejl afvist Fejlen, der er indmeldt, er ikke en fejl eller der mangler information, før det kan afgøres. 4 Fejl åbnet Fejlen er accepteret og dokumenteret fyldestgørende. Fejlen beskrives i detaljer, således den nemt kan genskabes ud fra beskrivelsen. Der vedlægges skærmbilleder og beskrivelse af det data, der er blevet brugt. Fejlen vurderes. Hvis: Fejlen ikke er fyldestgørende dokumenteret, returneres den til indmelder med information om mangler og tildeles statussen Afvist. Der ikke er tale om en fejl, opdateres fejlen med begrundelse og tildeles statussen afvist Det er en fejl, tildeles statussen åben. Fejlen opdateres med mangler og sendes retur til Leverandøren. Når det er endeligt afgjort at fejlen, der er indmeldt, ikke er en fejl, lukkes den med den relevante afslutningskode. Den videre analyse påbegyndes. Resultatet af denne skal benyttes i prioriteringen og planlægningen af fejlrettelsen. Side 12 af 17

14 Trin Status Handling Beskrivelse 5 Fejl rettet Fejlen er rettet, men ikke leveret. Leverandøren har rettet og et rettelsen internt. Fejlen prioriteres og planlægges til en Leverance. 6 Fejl klar til Rettelsen er leveret. Leverancen, der indeholder rettelsen, er leveret til hos Kunden. Kunden gener fejlen. Hvis der observeres afledte eller nye fejl indmeldes disse selvstændigt. 7 Teststatus Fejlen es. Fejlen es. Hvis: Fejlen er et OK, tildeles statussen Fejl et, OK. Fejlen er et ikke OK, tildeles statussen Fejl et, ikke OK. 8 Fejl et, ikke OK Rettelsen er ikke verificeret. 9 Fejl et, OK Rettelsen er verificeret hos Kunden. Den ansvarlige er hos Kunden har et rettelsen og kan genskabe fejlen. Fejlen tildeles statussen Fejl et, ikke OK og fejlen returneres til Leverandøren. Den ansvarlige er hos Kunden har et rettelsen og kan ikke genskabe fejlen. Fejlen tildeles statussen Fejl lukket. 10 Fejl lukket Fejlen lukkes. Fejlen opdateres med den relevante afslutningskode: Tabel 3: Trin i processen Fejlhåndtering Løst, softwarerettelse. Løst, hardwarerettelse. Løst, konfigurationsrettelse. Løst, specifikationsrettelse. Kan ikke længere genskabes. Afvist, duplikat. Afvist, fejl i ware. Afvist, lukket af kunde. Afvist, anden grund. I forbindelse med alle statusskift skal det sikres, at dokumentationen stadigvæk er fyldestgørende og det skal ligeledes overvejes, om der er kommet ny viden der har betydning for prioritering og fejlklassifikationen. Udover statusfeltet er der en række andre metaoplysninger, der skal tilknyttes og vedligeholdes for de enkle hændelser. Metadata: Status. Overskrift/kort beskrivelse. Fejlbeskrivelse. Fundet i Version. Testtype/Aktivitet hvor fejlen blev fundet. Modul/funktionsområde. Planlagt til løsning i Version. Løsning verificeret i Version. Afslutningskode (se trin 10 i Tabel 3). Side 13 af 17

15 Fejlkategorier Fejl, fundet i forbindelse med en type, kategoriseres med hensyn til hvor alvorlige de er, idet kategorierne beskrevet i nedenstående Tabel 4 benyttes. Tabellen illustrerer hvordan fejl skal kategoriseres i forhold til de forskellige typer. Nr. Betegnelse Fejlkategorier ved Funktionelle Fejlkategorier ved Non-funktionelle Fejlkategorier ved Brugervenligheds Fejlkategori ved Dokumentations og Review 1 Kritisk fejl Fejl der medfører, at en arbejdsgang ikke kan gennemføres, heller ikke ved ændringer i arbejdsgangen. Fejl der øger risikoen for sammenblanding af data. Hvis det målte resultat afviger med mere end 60 % fra kravet. Backup fejler. Fail over- fejler. 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. Dokumentet indeholder fejl som bevirker, at dokumentet ikke lever op til Kontraktens krav eller til efterfølgende dokumenterede afklaringer. Dokumentet indeholder fejl eller unøjagtigheder som gør læsningen og forståelsen af dokumentet meget svær eller umulig. 2 Alvorlig fejl Fejl der medfører, at en arbejdsgang kun kan gennemføres ved væsentlig ændringer i arbejdsgangen. Hvis det målte resultat afviger med mere end 30 %, men lig med eller mindre end 60 % fra kravet. Dokumentet indeholder beskrivelser, som er inkonsistente med andre beskrivelser i samme eller andre dokumenter. Fejl der medfører, at data mistes. 3 Betydende fejl Fejl der medfører, at en arbejdsgang kun kan gennemføres ved mindre ændringer i arbejdsgangen. Hvis det målte resultat afviger med mere end 10 %, men lig med eller mindre end 30 % fra kravet. Problem, der er forstyrrende for brugen af produktet og indebærer, at brugeren anvender uforholdsmæssigt meget tid på at løse en opgave. Dokumentet indeholder væsentlige fejl eller formuleringer, som gør det vanskeligt at forstå for den modtagergruppe, dokumentet er tiltænkt. 4 Normal fejl Fejl der ikke hindrer arbejdsprocessen i at kunne gennemføres normalt, men hvor fejlen kan være generende for gennemførsel af arbejdsprocessen. Hvis det målte resultat afviger med mere end 5 %, men lig med eller mindre end 10 % fra kravet. Indholdet har behov for uddybning eller præcisering, eller der er andre fejl, som hverken er Kritiske eller Betydende. 5 Mindre betydende fejl Ubetydelig eller kosmetisk fejl, men hvor der er fejl i forhold til aftalegrundlaget. Hvis det målte resultat afviger med 5 % eller mindre fra kravet. Observationer, der ikke har større betydning for brugervenligheden, men som dog generer det generelle indtryk af brugergrænsefladen. 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 4 - Fejlkategorier Side 14 af 17

16 Reaktioner ved fejl Dette afsnit beskriver hvordan Leverandøren skal reagere på indmeldelse af fejl i forbindelse med en perioderne. Tabel 5 herunder beskriver, hvordan Leverandøren skal reagere på identificerede fejl og problemer. Nr. Betegnelse Reaktion ved Alle typer 1 Kritisk fejl Identificeres en sådan fejl under en prøve eller, kan Kunden vælge at afbryde prøven/en, 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 2 kalenderdag, skal Leverandøren levere bindende planer til Kunden for hvorledes, den/de kritiske fejl vil blive udbedret inden for perioden. 2 Alvorlig fejl Kunden kan vælge at indstille en/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 3 kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes, den/de alvorlige fejl vil blive udbedret inden for perioden. 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 4 kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes, den/de betydende fejl vil blive udbedret inden for perioden. 4 Normal fejl Leverandøren skal, uden ugrundet ophold, udbedre den eller de normale fejl. Hvis Leverandøren ikke er i stand til at udbedre den/de betydende fejl inden for maksimalt 5 kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes, den/de normale fejl vil blive udbedret inden for perioden. 5 Mindre betydende fejl Leverandøren skal, uden ugrundet ophold, udbedre den eller de mindre betydende fejl. Hvis Leverandøren ikke er i stand til at udbedre den/de betydende fejl inden for maksimalt 7 kalenderdage, skal Leverandøren levere bindende planer til Kunden for hvorledes, den/de mindre betydende fejl vil blive udbedret inden for perioden. Tabel 5 - Oversigt over reaktioner ved fejl Side 15 af 17

17 Godkendelseskriterier Dette afsnit beskriver hvilke godkendelseskriterier, der er fastsat for en prøve eller type. Det gælder for alle prøver og typer, at alle cases skal være afviklet og alle cases har enten status Passed eller Failed. Nedenstående tabel viser, hvor mange fejl af hver kategori, der maximalt må være i forbindelse med godkendelse af en prøve eller type. Den yderste kolonne til højre angiver, hvor mange fejl der maximalt må være for en given prøve. Nr. Betegnelse Funktionelle og Non-funktionel Brugervenligheds Dokumentations og review Max antal fejl for en Prøve 1 Kritisk fejl Alvorlig fejl Betydende fejl Normal fejl Mindre betydende fejl Tabel 6 Godkendelseskriterier Tabellen skal forstås på den måde, at for de funktionelle og Non-funktionelle, maximalt må være 2 fejl for den funktionelle type og maximalt må være 2 fejl for den Non-funktionelle typer Testværktøj Kunden benytter HP ALM værktøjet til styring af cases, krav og resultater af. Værktøjet benyttes til planlægning, gennemførelse, styring, sporbarhed og dokumentation af forløbet, herunder også til oprettelse og styring af fejlrapporter i forbindelse med gennemførelsen. Leverandøren er velkommen til at benytte værktøjet til deres interne, efter nærmere aftale med Kunden. Leverandøren skal selv stå for uddannelse af det personale, der skal havde adgang til værktøjet. Side 16 af 17

18 Organisation og ansvar Ved prøver og som Kunden har ansvar for, er det Kundens manager, der forestår den daglige ledelse i form af detailplanlægning, herunder uddelegering af arbejde til de enkelte medarbejdere knyttet til en. Kundens manager informerer Leverandøren i form af planer, rapporter og eventuelt andet relevant materiale. Leverandøren skal ikke godkende materiale fra Kunden, men det står Leverandøren frit for at fremsende kommentarer Ansvarsfordeling Ansvarsfordelingen mellem Kunden og Leverandøren fremgår af Tabel 2. Den, som har ansvaret for den pågældende prøve eller type, er den udførende i forhold til udarbejdelses af plan, gennemførsel og udarbejdelse af den afsluttende rapport Leverandørens deltagelse I forbindelse med prøver og typer skal Leverandøren deltage, således at de fejl og problemstillinger, der opstår undervejs, kan afhjælpes hurtigst muligt. Side 17 af 17