Denne prøvestrategi er generisk for AU-projekter, der skal anskaffe og implementere it-systemer i AU. Den retter sig mod udbud og kontraktuelt aftalt samarbejde med leverandører af it-systemer og beskriver AU’s tilgang til afprøvning (modtagekontrol) af leverandørens leverancer i både det kommende implementeringsprojekt og i den efterfølgende forvaltning. Fokus for strategien er afprøvning af anskaffede systemer.
Prøvestrategien definerer således AU’s overordnede krav til rammerne for både selve det generiske prøveprogram og for samarbejdet med leverandøren herom. Rammer og samarbejde aftales endeligt med leverandøren i udbudsprocessens afsluttende kontraktfase.
Som grundlag for udbud og aftaleindgåelse i fbm it-projekter anvender AU SKI’s og digitaliseringsstyrelsens standardkontrakter. Disse kontrakter udstikker indhold og form på en sådan kontrakt mellem en offentlig kunde (AU) og en leverandør. Kontrakten adresserer både AU’s krav til det kommende produkt og AU’s krav til det samarbejde, som AU og leverandøren skal have om implementering af produktet og den efterfølgende forvaltning af det. Denne generiske prøvestrategi er udarbejdet med udgangspunkt i K02-standardkontraktens prøveprogram.
Et væsentligt afsnit i standardkontrakten er afsnit 8, der adresserer afprøvning og samarbejdet her omkring (test af leverandørens leverancer).
Det bemærkes, at denne prøvestrategi suppleres af AU’s teststrategi for IT-implementeringsprojekter. Den prøvestrategi, der aftales med leverandøren i udbudsprocessens afsluttende kontraktfase, skal således alignes med denne it-implementeringsteststrategi.
Leverandøren udarbejder en specifik prøvestrategi, der kommer til at indgå som en del af tilbudsmaterialet, og som, inklusiv eventuelle tilpasninger i forbindelse med aftaleindgåelsen, skal godkendes af AU.
Prøvestrategien adresserer afprøvning af indkøbte produkter. Et produkt kan være af flere varianter:
Det er en forudsætning for en succesfuld anvendelse af prøvestrategien, at kravene til det kommende produkt er defineret klart og testbart. Dette gælder inden for alle opgavetyper, så som udvikling (funktionalitet / non-funktionalitet), migrering, konfigurering, integrationsudvikling, compliance, mv.
AU arbejder ud fra nedenstående generelle principper i tilgang til prøver og test.
AU anlægger et helhedssyn på testarbejdet for at kunne understøtte komplet og effektiv test. AU's testproces, som er baseret på den internationale standard, ISTQB (International Software Testing Qualifications Board), omfatter derfor det samlede testforløb:
Testplanlægning og kontrol
Testanalyse og design
Implementering og afvikling af test
Evaluering af udgangskriterier og rapportering
Testlukningsaktiviteter
Denne testproces er foldet ud i afsnittet Drejebog.
AU forventer, at Leverandørens prøvestrategi ligeledes er baseret på en kravsbaseret strategi i kombination med en risikobaseret strategi. For at sikre en korrekt prøvestrategi på AU forventes det, at der er gennemført en produktrisikoanalyse af standardleverancen med input fra AU og andre interessenter. Det betyder, at leverandøren i sin prøvestrategi eller løsningsbeskrivelse har beskrevet sin testtilgang, hvad angår risikostyring, testdækning, prioritering, sporbarhed, inddragelse af AU samt evt. inddraget erfaring vedr. gennemførelse af produktrisikoanalyser fra andre kunder.
De generelle principper for prøveprogrammet gælder for alle prøvetyper, medmindre andet er specificeret.
I forhold til AU vil det være leverandørens test manager der sammen med AU's test manager, har det overordnede ansvar for, at alle aktiviteter i det specifikke prøveprogram planlægges, igangsættes og afvikles til tiden, og dermed forestår al planlægning, opfølgning, rapportering mv. omkring afviklingen af prøver. En prøve skal gennemføres under forhold, der i videst muligt omfang svarer til en normal driftssituation.
Det påhviler leverandøren at dokumentere det, såfremt eventuelle afvigelser mellem drift og det aktuelle testmiljø ikke er relevant for den aktuelle prøve.
Dette afsnit beskriver de krav til prøveprogrammet, som AU har.
De væsentligste opgavetyper er:
Det beskrevne prøveprogram er gældende for enhver leverance fra leverandøren, uanset den opgavetype, der ligger til grund.
Med mindre andet er angivet, sker afprøvning af leverancer i model af de generiske prøvetyper, som standardkontrakten for K02, Længerevarende it-projekter, udstikker - og suppleret med Demonstrationsprøve, som er en AU tilretning. Digitaliseringsstyrelsens vejledning til K02's prøveprogram ses her: https://digst.dk/media/12790/endelig-bilag-og-vejledning-k02-doc.docx
Det drejer sig om nedenstående, og hver af prøvetyperne er udfoldet som bilag til denne prøvestrategi.
Klik på den enkelte prøvetype i listen ovenfor for at se en beskrivelse af den.
Roller og ansvar i forbindelse med gennemførelsen af den enkelte prøvetype fremgår af prøveoversigten nederst på denne side.
Det bemærkes, at der kan være særlige prøver og godkendelsesprocedurer for tilknyttede ydelser.
Allerede i forbindelse med afklaringsfasen kan det være relevant at sikre en fyldestegørende demonstration af, at den indkøbte løsning faktisk kan forventes at leve op til de fremsatte krav. Dette kan ske i form af en demonstrationsprøve. Optimalt set sikres dette allerede inden kontraktindgåelsen ved en demonstration, som i sagens natur ikke kan være en prøve.
For en leverance indenfor enhver opgavetype har leverandøren ansvaret for at verificere denne med testtyper, der er hjemhørende på komponent- (unit-), komponentintegrations- og systemniveau. Det objektive vidnesbyrd på leverandørens interne tests på disse niveauer er resultatet af den fabriksprøve, som leverandøren designer, planlægger, gennemfører, evt sammen med AU, og dokumenterer og rapporterer, så AU har grundlaget på plads for at vurdere om resultatet kan godkendes. Det bør være kontraktuelt aftalt, at AU har indblik i leverandørens testrapporter på de ovennævnte testniveauer.
AU's efterfølgende modtagekontrol af enhver leverance vil omfatte testtyper, der er hjemhørende på accepttestniveau. Disse testtyper er struktureret i prøvetyperne:
Den enkelte prøvetype er herunder kort beskrevet ved nøgleparametre. For yderligere beskrivelse, klik på prøvetypen i listen ovenfor.
Prøvetype | Adresserer | Fokus | Hovedansvar | Udførende | Miljø | Testniveau | Testtyper |
Demonstrationsprøve | Det fulde standardsystem | Demonstrerer at den tilbudte løsning har de funktioner og egenskaber, som AU har stillet krav om. | Leverandør | Leverandør | Leverandørs | Accept | Funktionel test Non-funktionelt test |
Fabriksprøve | Den enkelte delleverance | Afprøvning af løsningens funktionalitet i leverandørens eget miljø. Udgør leverandørens afsluttende afprøvning af egen udvikling og opsætning af leverancen, inden denne frigives til det videre aftalte prøveprogram hos AU | Leverandør | Leverandør | Leverandørs | System | Funktionel test |
Installationsprøve | Den enkelte delleverance | Afprøvning af, om det anskaffede system, eventuelt tilknyttede integrationer og et repræsentativt sample af migrerede data samt eventuelt udstyr, kan installeres i funktionsdygtig og konfigurérbar stand ved hjælp af leverandørens installationsvejledninger | Leverandør | Leverandør (SaaS)/AU | AU’s testmiljø | System | Review og test af installationsvejledning Test af drifts- og forvaltningsparathed Datamigrering |
Delleveranceprøve | Den enkelte delleverance | Delleveranceprøven måler på, om krav til funktionalitet og/eller krav på det non-funktionelle område er opfyldt for en delleverance. | AU/Leverandør | AU/Leverandør | AU’s testmiljø | System | Funktionstest (E2E) Udvalgte servicemål kan afprøves |
Overtagelsesprøve | Den fulde leverance | Den samlede overtagelsesprøve skal måle på, om krav til funktionalitet og krav på det non-funktionelle område som helhed er opfyldt sammenholdt med de aftalte krav, herunder at systemet kan anvendes i de involverede arbejdsprocesser og systemet er forberedt for og klar til idriftsættelse. | AU/Leverandør | AU/Leverandør | AU’s testmiljø | Accept | User Acceptance Test (UAT) Brugervenlighedstest Systemintegrationstest Review af dokumentation Test af drifts-/forvaltningsparathed Migreringstest Udvalgte servicemål kan afprøves |
Driftsprøve | Den fulde leverance | Under driftsprøven afprøves aftalte servicemål. Driftsprøven måler på drifts- og supporteffektivitet og svartider for løsningen i driftsmiljøet (AU's produktionsmiljø) over en aftalt periode, mens leverancen anvendes. Resultatet af målingerne holdes op mod de specificerede servicemål og andre relevante kontraktdele, og den organisatoriske systemforvaltningsenhed tager teten på systemforvaltningsopgaverne. Bemærk, at såfremt det er aftalt, at kunden kan ibrugtage en delleverance, gennemføres der tillige en driftsprøve af den godkendte delleverance | AU/Leverandør | AU/Leverandør | AU’s produktions | Accept | Operational acceptance test (OAT) |
Krav ID | Beskrivelse |
|---|---|
| Afp 1 | Som en del af tilbudsgivningen udarbejder (eller vedlægger) leverandøren en prøvestrategi, der både deklarerer leverandørens tilgang til egne tests i egen organisation, men også deklarerer leverandørens tilgang til prøveprogrammet i det kommende implementeringsprojekt. |
| Afp 2 | Leverandørens prøvestrategi skal adressere de punkter, der er listet herunder. |
| Afp 3 | Prøvestrategien skal godkendes af AU |
Prøvestrategi template
Overskrift | Beskrivelse |
|---|---|
| Generelt om afprøvninger | I dette afsnit beskriver leverandøren sin generelle tilgang til test, metoder, testtyper, testproces, metrikker samt sikring af sporbarhed. Ligeledes beskriver leverandøren sin generelle tilgang til den prøvestrategi, som AU benytter. |
Prøveprogram | I dette afsnit beskriver leverandøren, hvorledes AUs specifikke prøveprogram (alle eller udvalgte dele af de fem afprøvningstyper) sikres udmøntet. |
| Drejebog | I dette afsnit beskriver leverandøren drejebogen, som indeholder alle de opgaver, som skal gennemføres i forbindelse med afprøvning af leverandørens leverancer. Drejebøgerne skal for hver af de afprøvninger, der er defineret i afprøvningsprogrammet, i detaljer beskrive gennemløbet af afprøvningerne. |
| Miljøer til afprøvning | I dette afsnit beskriver leverandøren overordnet, hvilke afprøvnings-miljøer med hvilke bestykninger, der skal sikres hos både leverandøren og hos AU til den fælles afvikling af de involverede prøvetyper i projektet. De konkrete miljøer skal fremgå af bilag x. Det er et krav, at leverandøren har funktionsadskilte miljøer til hhv udvikling, test og produktion. |
| Data til afprøvning | I dette afsnit beskriver leverandøren, hvorledes nødvendige og korrekte data til afprøvningerne sikres. Stubbe og drivers anvendes efter behov. Leverandøren beskriver også mulighed for pseudonomiserede data og indlæsning af data i løsningen. Det er i udgangspunktet AU, der leverer testdata til prøveafviklingen i de involverede prøvetyper. Såfremt det aftales, at leverandøren selv i specifikke situationer har ansvaret for at levere prøvedata, har AU mulighed for at bede om få disse prøvedata udleveret. |
| Test design / Test cases | I dette afsnit beskriver leverandøren sin analyse- og design for de prøvetyper, som leverandøren har ansvaret for at udarbejde test cases til. Leverandøren sikrer med processen, at AU reviewer test casene og har muligheden for enten selv at supplere med flere testcases, detaljere dem eller bede leverandøren om dette. Tidsfrister for, hvornår testcases skal leveres til AU for godkendelse samt tidsfrist for godkendelse beskrives. Test cases overdrages til AU til kommende forvaltning / regressionstest. |
| Test værktøjer | I dette afsnit beskriver leverandøren, hvorledes denne sikrer sporbarhed mellem krav og test cases og eventuelt risici, mellem tidsplaner og test fremdrift, mellem forventet resultat og faktisk resultat samt overblik over konstaterede fejl og deres status. Test styring og fejlrapportering Automatiserede tests |
| Prøveafvikling og håndtering af fejl og ændringer | I dette afsnit beskriver leverandøren, hvorledes denne sikrer, at afprøvninger gennemføres inden for de rammer, der er udstukket i beskrivelsen af den enkelte prøvetype. Evt konstaterede og dokumenterede fejl udredes, rettes og gentestes af leverandøren i dennes deklarerede processer og miljøer. De allerede reviewede og godkendte test cases genanvendes, evt suppleret med test cases, der specifikt adresserer de rettede fejl. Leverandøren beskriver sin proces for håndtering af fejl og ændringsanmodninger – både i forbindelse med afvikling af test i forbindelse med leverancer i AU’s anskaffelsesprojekt, men også i forbindelse med den efterfølgende forvaltning. Herunder har leverandøren beskrevet, hvorledes denne, i samarbejde med AU, sikrer, at AU har tid og mulighed for egne nødvendige gentests inden for den afsatte afprøvningsperiode. Fejl fra en given afprøvning skal være udbedret inden næste prøve påbegyndes. Alternativt skal AU have godkendt en plan herfor. Se afsnit Fejlkategorisering. |
| Regressionstests | Når fejl er udbedrede, er det væsentligt at genteste for disse fejl, men det er ligeledes vigtigt at sikre sig, at der ikke er indtruffet nye fejl i forbindelse med fejlretningen. I dette afsnit beskriver leverandøren sin tilgang til regressionstest, herunder hvordan test cases hertil opbygges, beskrives og vedligeholdes. Automatiseringsgraden af regressionstests, deres dækning og fokus skal også beskrives. Endvidere skal leverandøren beskrive, hvorledes denne vil bistå AU med at etablere regressionstestsuiter til AU’s interne brug. |
| Løbende rapportering i prøveforløbet | I forbindelse med afvikling af en prøve rapporterer den part, der har ansvaret for afviklingen (leverandør eller AU), løbende testresultaterne, herunder de fejl og problemer, der identificeres. AU’s rapportering sker i AU’s teststyringsværktøj mhp overblik over prøveresultater og fremdrift på prøveafviklingen, samt overblik over antal fejl, fordeling på fejlkategori og fremdrift på fejlrettelser. Leverandøren beskriver i sin prøvestrategi, hvorledes denne sikrer de samme overblik. Hvis muligt sker dette ligeledes i AU’s teststyringsværktøj. |
| Samlet rapportering af et prøveforløb | Den hovedansvarlige for en prøve (leverandør eller AU) udarbejder en prøverapport, der samlet rapporterer på prøveresultatet med angivelse af eventuelle konstaterede fejl. For så vidt angår driftsprøven, udarbejder AU rapporten i forbindelse med driftsprøvens gennemførelse, medmindre Leverandøren skal varetage driften. I så fald udarbejder Leverandøren rapporten. Se krav til prøverapport. |
| Konfigurationsstyring af testware | I dette afsnit skal leverandøren beskrive sin konfigurationsstyring af testware (testscrips, testcases og testdata, testmiljø), herunder versionsstyring, konfigurationskontrol, sporing og rapportering samt testdokumentation. |
| Release management på testmiljøer | I dette afsnit skal leverandøren beskrive, hvordan leverandøren håndterer release management på testmiljøerne, hvilket inkluderer planlægning af testmiljø-releases, miljøkonfiguration, dokumentation, overvågning og vedligeholdelse |
| Organisation, roller og ansvar | I dette afsnit skal leverandøren beskrive hvilke organisationer (AU, leverandør, eventuelle 3. parts leverandører), som indgår i prøverne. Leverandøren skal tilsvarende beskrive hvilke roller, der skal indgå i prøverne fra hver organisation samt deres ansvar. |
| Risikoanalyse og risikostyring | I dette afsnit skal leverandøren beskrive, hvordan risikoanalyse og risikostyring håndteres, herunder identifikation, vurdering og styring af risici, og hvordan disse processer dokumenteres. |
| Godkendelse af prøver | I dette afsnit beskriver leverandøren, hvorledes denne sikrer grundlaget for og proces omkring godkendelse af en prøve. Resultatet af en prøve kan godkendes, når prøvens acceptkriterier er opfyldt. AU skal give skriftlig meddelelse om, hvorvidt prøven kan godkendes. Kan prøven ikke godkendes, skal AU senest 10 arbejdsdage efter prøvens afslutning give leverandøren skriftlig meddelelse om årsagen til den manglende godkendelse. Såfremt AU ikke giver meddelelse om prøvens godkendelse inden for 10 arbejdsdage, anser leverandøren prøven for godkendt. AU kan godkende prøver, selvom der er kendte fejl i leverancen. Se fejlkategorier. Og håndteringen af disse. |
| Godkendelse af leverandørens prøvestrategi |
For enhver afprøvning skal der udarbejdes en prøveplan. Prøveplanen udarbejdes af den part, der har hovedansvaret for den konkrete afprøvning - leverandøren eller AU. Såfremt andre har ansvaret for den specifikke opgaver under afprøvningen, skal det beskrives i prøveplanen.
Prøveplanen skal adressere de punkter, der er listet herunder i prøveplan-templaten.
Leverandørens prøveplaner skal godkendes af AU. Der er dog ikke krav om, at AU's prøveplaner godkendes af leverandøren - dog skal de koordineres og afstemmes med leverandøren.
AU skal have prøveplanen til godkendelse senest 10 dage før afprøvningens start, og skal senest 5 dage før afprøvningens start godkende prøveplanen skriftligt.
Hvis AU ikke kan godkender prøveplanen: AU skal angive årsagerne hertil skriftligt og om muligt tydeligt angive hvilke forbedringer, der anses nødvendige for Leverandøren til at kunne opnå godkendelse af prøveplanen. Leverandøren skal herefter udarbejde en ny så hurtigt som muligt og genfremsætte til godkendelse ved Kunden.
Krav ID | Beskrivelse |
|---|---|
| Afp 1 | For enhver test i en afprøvning skal der udarbejdes en prøveplan |
| Afp 2 | Prøveplanen udarbejdes af den part, der har hovedansvaret for den konkrete afprøvning - leverandøren eller AU. Såfremt andre har ansvaret for den konkrete afprøvning, fremgår dette af prøveplanen. |
| Afp 3 | Prøveplanen skal godkendes af AU, såfremt den er udarbejdet af leverandøren eller tredjepart. |
Overskrift | Beskrivelse | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Scope | Genstanden for denne prøveplan er [testtype). Testgrundlaget for testen er henvisning til designgrundlag. Afprøvningsplanen adresserer alle aktiviteter i planlægningen, testdesignet, testeksekveringen, opfølgningen og rapporteringen. | ||||||||||||||||||||||||
| Ansvarlig for afprøvningen | Leverandør / tredjepart | ||||||||||||||||||||||||
| Forudsætninger og afhængigheder | Såfremt der er forudsætninger for afprøvningens gennemførelse, skal de anføres. Ligeledes beskrives eventuelle afhængigheder. | ||||||||||||||||||||||||
| Afprøvningstilgang | Afprøvningstilgang er jf. prøvestrategien. Er der afvigelser for den specifikke afprøvning, skal de fremgå her | ||||||||||||||||||||||||
| Ressourcer | Anfør de specifikke ressourcer til denne afprøvning:
| ||||||||||||||||||||||||
| Tidsplan | Detaljeret tidsplan for afprøvningen med angivelse af aktiviteter og start- og sluttidspunkt:
| ||||||||||||||||||||||||
| Testværktøjer | Her beskrives, hvorvidt afprøvningen udføres manuelt eller automatisk og vha hvilke testværktøjer. Ligeledes beskrives værktøjet til test styring, såfremt det adskiller sig fra det, der er anført i prøvestrategien. Nedenstående er et eksempel:
| ||||||||||||||||||||||||
| Testmiljø | Her beskriver leverandøren det/de testmiljø(er), prøven skal afvikles på, dets bestykning, versionering, adgange og andre forhold, som har betydning for prøvens gennemførelse. | ||||||||||||||||||||||||
| Testdata | Her beskriver leverandøren forventet behov for testdata, kilderne til testdataene, herunder AUs eventuelle involvering i levering af testdata, omfanget af testdataene, typer af data, datakvaliteten, datafortrolighed og beskyttelse. Det beskrives desuden, hvorvidt der planlægges med syntetiske, anonymiserede eller pseudonomiserede data samt hvordan testdata bringes til anvendelse i produktet. | ||||||||||||||||||||||||
| Indgangs-, udgangs-, suspensions- og genoptagelseskriterier | Indgangs-, udgangs-, suspensions- og genoptagelseskriterier. Er der særlige forhold om denne prøve, tilføjes de her. | ||||||||||||||||||||||||
| Godkendelseskriterier | Specifikke godkendelseskriterier for den konkrete afprøvning, som afviger fra den generelle kriterier, fremgår her. | ||||||||||||||||||||||||
Testcases til eksekvering | Her henviser leverandøren til de testcases, der er planlagt til afvikling i testen: Indsæt gerne henvisning til filter fra Zephyr/JIRA, der indeholder alle planlagte testcases - eller henvis konkret på anden måde | ||||||||||||||||||||||||
| Drejebog for afprøvning og fejlrapportering | Her beskriver leverandøren meget konkret drejebogen for, hvorledes prøven gribes an, trin-for-trin for selve afprøvningen og for fejlrapportering. | ||||||||||||||||||||||||
| Fejlhåndtering og gentest | Er der særlige forhold om denne test, tilføjes de her. | ||||||||||||||||||||||||
| Risici | Indsæt eventuelle risici og mitigerende handlinger, som er forbundet med denne specifikke test. | ||||||||||||||||||||||||
| Godkendelse | Det anføres, hvem der har godkendt prøveplanen og hvornår. | ||||||||||||||||||||||||
Dette afsnit beskriver AU's tilgang til en drejebog for prøverne og sætter drejebogen ind i AU's test- og kvalitetssikringskontekst.
Leverandøren har til opgave at tilrettelægge og udarbejde drejebog for hver enkelt prøve. Drejebogen beskriver alle de opgaver, som skal gennemføres i forbindelse med afvikling af afprøvningen af leverandørens leverancer. Drejebøgerne skal for hver af de afprøvninger, der er defineret i det specifikke prøveprogram, i detaljer beskrive gennemløbet af prøveafviklingen. Beskrivelsen skal også omfatte de eventuelle forudsætninger, der skal være opfyldt for, at den pågældende afprøvning kan gennemføres, herunder hvilken dokumentation der skal foreligge, og beskrive de godkendelses-/acceptkriterier, der er kontraktligt aftalt mellem leverandør og kunde.
Prøveprocessen ser for enhver instans af enhver prøvetype ud som beskrevet herunder (ISTQB).
| Prøveaktivitet | Hovedansvarlig rolle (Andre roller kan involveres) | Kommentar |
| Prøveplan for det samlede prøveforløb. | Leverandør | Det samlede projekt: Det skal af prøveplanen fremgå, hvilke opgavetyper projektet omfatter. Prøveplanen godkendes af AU |
| Ressourcesikring af afprøvningsorganisation | Leverandør og AU | Det samlede projekt og den enkelte afprøvning Sikring af rollerne test manager, testkoordinatorer, testere, miljøansvarlig, udviklere til test i udviklingsforløbet |
| Gennemførelse af produktrisikoanalyse på de samlede leverancer | Leverandør med input fra AU | Det samlede projekt: |
| Sikring af opfølgning på fremdrift af prøveaktiviteter | Leverandør | Det samlede projekt og den enkelte afprøvning Sikring af dataindsamling på de besluttede metrikker som grundlag for opfølgningen |
| Løbende koordinering mellem projektleder og test manager om status på og planer for prøveaktiviteterne | Leverandør og AU | Det samlede projekt og den enkelte afprøvning Til brug for realistisk planlægning og som grundlag for rapportering til styregruppen om produktkvaliteten og planstatus |
| Planlægning af den enkelte afprøvning (afprøvningsplaner) | Leverandør | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Klargøring til opfølgning på fremdriften af den enkelte afprøvning | Leverandør | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
Prøveaktivitet | Hovedansvarlig rolle | Kommentar |
|---|---|---|
| Analyse af testgrundlag (herunder sikring af acceptkriterier som grundlag for testcase design) | Leverandør | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Identifikation af de overordnede krav til miljøer og data til afprøvningen | Leverandør | Hhv udvikling, integrationsudvikling migrering, konfigurering andet |
| Pr leverancetype: udarbejdelse af det detaljerede testdesign i test cases | Leverandør | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Identifikation og klargøring af data til de udarbejdede test cases | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Sikring af sporbarhed mellem krav, løsning og testcase - herunder sikring af korrekt testdækning | Leverandør | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Review af testcases, der er udviklet af andre (her leverandøren) | AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
Prøveaktivitet | Hovedansvarlig rolle | Kommentar |
|---|---|---|
| Afvikling af prøven, evaluering af resultater og udarbejdelse af fejlrapporter | Se den enkelte prøvetype | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Løbende monitorering af fremdrift og produktkvalitet | Se den enkelte prøvetype | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Sikring af, at alle ressourcer er parate og klædt på til opgaven (tekniske: vha testbarheds-/smoketest, miljøer, data, og personelle, herunder leverandørressourcer) | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Sikring af, at fejlrapportering, -fejlhåndtering og -visitering sker, jf beslutninger dokumenteret i den aftalte afprøvningsstrategi | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Styring og koordinering af processen om den enkelte test | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Tæt og løbende koordinering med interessenter (forretning, leverandør, projektleder, drift) | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Udarbejdelse af testafviklingsplan for den enkelte test (testcase afviklingsrækkefølge, booking af afprøvningsmiljø(er), sikring af testdata, adgange, lokaler, materiale, kompetenceudvikling af testere)* | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
| Evaluering af fejlrapporter og fejlhåndtering | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet
|
| Løbende monitorering og rapportering til projektleder om fremdrift og produktkvalitet | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet |
Prøveaktivitet | Hovedansvarlig rolle | Kommentar |
|---|---|---|
| Evaluering af udgangskriterier og rapportering af den enkelte test | Leverandør og AU | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet
|
| Rapportering af den samlede afprøvning til projektleder | Test manager | Pr afprøvning for hhv udvikling, integrationsudvikling, migrering, konfigurering, andet Den samlede leverance |
| Endelig afrapportering til styregruppen om produktkvaliteten og status på fejl | Projektleder | Til brug for styregruppens stillingtagen til produktionsigangsætning |
Prøveaktivitet | Hovedansvarlig rolle | Kommentar |
|---|---|---|
| Arkivering af testmateriale | AU Test manager | |
| Deltagelse i evaluering af testprocesserne | Leverandør og AU | |
| Evaluering af testprocesserne gennem projektforløbet | Leverandør og AU | |
| Overlevering af testartefakter til forvaltning | AU Test manager | Det samlede projekt Leverandør leverer de aftalte afprøvningsartefakter |
| Sikring af, at alle afprøvningsaktiviteter i projektet er fuldført, og der er en plan (eller beslutning) for enhver åben fejl, der er identificeret | Leverandør og AU |
Som en del af drejebogen udarbejdes en testafviklingsplan, som dels specificerer de testcases der skal afvikles og som dels sikrer, at sammenhængende arbejdsgange testes på tværs af Systemets funktionalitet. På denne måde testes, at flowet i de daglige arbejdsgange og rutiner i systemet er sammenhængende, og at funktionaliteten fungerer fejlfrit. Testafviklingsplane skal således indeholde:
Dette afsnit beskriver AU's krav til prøverapporter.
En prøverapport dokumenterer den enkelte afprøvning, således at det er klart, hvad der er afprøvet, og hvad prøveresultatet var. Prøverapporten laves med udgangspunkt i prøveplanen.
Krav ID | Beskrivelse |
|---|---|
| Afp 1 | For enhver test i en afprøvning skal der udarbejdes en prøverapport |
| Afp 2 | Prøverapporten udarbejdes af den part, der har hovedansvaret for den konkrete afprøvning - leverandøren eller AU. Såfremt andre har ansvaret for den konkrete afprøvning, fremgår dette af prøveplanen. |
| Afp 3 | Prøverapporten skal godkendes af AU, såfremt den er udarbejdet af leverandøren eller tredjepart. |
Overskrift | Beskrivelse |
|---|---|
Overskrift | Beskrivelse |
| Prøve- og testtype | Genstanden for denne afprøvningsplan er [testtype). |
| Prøveresultatet | Kort opsummering af prøveresultatet ift acceptkriterierne for prøven. |
| Ansvarlig for afprøvningen | Leverandør / tredjepart |
| Prøveforløbet | Kort vurdering af prøveforløbet (startkriterier opfyldt, alle ressourcer (personelle og tekniske) tilgængelige og klædt på til opgaven, realistisk tidsplan, ) |
| Testdækning og testresultat | Opsummering af, i hvor høj grad de planlagte testcases er gennemført samt resultatet heraf. |
| Fejl og mangler | Opsummering af, hvor mange fejl og mangler der er fundet i alt og med hvilke kategorier. Opsummering af status på fejl og mangler, herunder hvor mange der er udestående og med hvilke kategorier |
| Afvigelser ift prøveplanen | Opsummering af afvigelser ift prøveplanen, herunder tidsmæssige afvigelser og ressourcemæssige afvigelser. Begrundelser for disse afvigelser. |
| Oversigt over udeståender | Opsummering af eventuelle udeståender ift afprøvningsplanen |
| Konsekvenser ved manglende godkendelse af prøveresultatet | Beskrivelse af konsekvensen af manglende godkendelse af prøven og det forventede videre forløb derfra. |
| Godkendelse | Det anføres, hvem der har godkendt prøverapporten og hvornår. |
Fejlkategorisering
Fejl kan være af forskellige alvorsgrad, og der er brug for en klassificering af disse alvorsgrader for at kunne vurdere og prioritere fejl ift forretningspåvirkning. AU opererer med 5 alvorsgrader, og den enkelte fejl klassificeres derfor i henhold til nedenstående oversigt. Den initielle klassificering foretages af AU.
Klassificering af fejl ift alvorsgrad er et afgørende værktøj til at definere acceptkriterier for en given afprøvning. Acceptkriterier for fejl fremgår af beskrivelsen af den enkelte prøvetype.
En afprøvning afbrydes af AU, hvis der findes blokerende eller kritiske fejl – eller et antal major fejl, der gør, at kritisk funktionalitet er utilgængelig. AU beslutter, om afprøvningen skal stå stille, mens fejlretningen pågår – og om afprøvningen skal starte forfra efter fejlretningen, eller den kan fortsætte fra det punkt, man var nået til.
Fejlenes alvorsgrad udstikker også prioriteringen ift fejlrettelser.
Alvorsgrad | Definition | |
5 | Blokerende | En blokerende fejl forhindrer videre afprøvning, og afprøvningen vil blive suspenderet. Leverandøren skal udbedre den blokerende fejl uden unødig forsinkelse og indenfor prøveperioden. Hvis Leverandøren ikke er i stand til at udbedre den blokerende fejl inden for maksimalt fem arbejdsdage, skal Leverandøren levere bindende planer til AU for, hvorledes den/de kritiske fejl vil blive udbedret og gentestet inden for prøveperioden. |
4 | Kritisk | En mangel, der er kritisk for løsning af AU’s opgaver, og hvor rimelig omgåelse ikke er mulig. Forretningskritiske funktioner kan ikke udføres, og det er ikke muligt at få dem igang. Kritisk ift systemets tilgængelighed, resultater, funktionalitet, ydeevne, sikkerhed eller brugervenlighed. Hvis en sådan fejl identificeres under en prøve, kan AU vælge at stoppe prøven. Hvis AU vælger ikke at stoppe prøven, skal leverandøren rette den kritiske fejl uden unødig forsinkelse og indenfor prøveperioden. Leverandøren skal også levere en bindende plan til AU for, hvordan den/de kritiske fejl bliver udbedret og gentestet indenfor prøveperioden. |
3 | Høj | En mangel, der er væsentlig for løsning af AUs opgaver, men hvor rimelig omgåelse efter leverandørens anvisninger er mulig. Prøven fortsættes så vidt muligt, såfremt fejlen kan afhjælpes ellers omgås. Der skal af leverandøren udarbejdes acceptable workarounds, som muliggør at opgaverne kan udføres på en anden måde. Hvis en høj fejl identificeres under en prøve, kan AU vælge at stoppe prøven. Hvis AU vælger ikke at stoppe prøven, skal leverandøren rette fejlen uden unødig forsinkelse og indenfor prøveperioden. Leverandøren skal også levere en bindende plan til AU for, hvordan den/de high fejl bliver udbedret og gentestet indenfor prøveperioden. |
2 | Medium | En fejl, der ikke er afgørende for at løse AU´s opgaver, men hvor en rimelig omgåelse ikke er mulig. Testen af den funktion/det område, som fejlen påvirker, skal stoppes. Fejlen forhindrer ikke andre tests i at blive udført. AU kan kræve, at leverandøren retter defekten, før testen genoptages |
1 | Lav | En fejl, der ikke er afgørende for at løse brugernes opgaver, og hvor en rimelig omgåelse ifølge leverandørens instruktioner er mulig. Der kan også være tale om en kosmetisk fejl, eller en forkert placering på et billede eller i en rapport. Fejlen medfører intet servicetab. Inden prøven fuldføres, skal fejlen overføres til en backlog. Leverandøren skal give AU bindende tilsagn om og plan for, hvordan fejlen(e) vil blive rettet. |
Dette afsnit beskriver de krav til prøvegodkendelser, som AU har.
Godkendelse af en prøve omfatter to ting:
Det er en forudsætning for godkendelse af en prøve, at prøverapporten er udarbejdet i overensstemmelse med kravene til denne, og at det fremgår tydeligt, at prøven har dækket alle relevante dele af leverancen. Hvis prøverapporten ikke er udarbejdet i overensstemmelse med kravene til denne, kan AU afvise prøverapporten. Leverandøren er herefter forpligtet til at udarbejde en revideret rapport, der hurtigst muligt og inden for fem arbejdsdage skal leveres til AU.
Efter modtagelse af en prøverapport skal AU, i henhold til aftalt tidsplan, skriftligt meddele leverandøren, om prøven kan godkendes.
Leverandøren vedlægger som en del af godkendelsesgrundlaget for prøven en mangelliste, der identificerer de udestående fejl samt en plan for udbedring af de enkelte.
Såfremt AU selv har hovedansvaret for en prøve, skal AU på tilsvarende måde meddele leverandøren, om prøven opfylder acceptkriterierne eller ej. Dette skal som udgangspunkt ske inden xx arbejdsdage efter prøven er afviklet og prøverapporten udarbejdet.
Et prøveresultat kan godkendes, når acceptkriterierne, som de fremgår af den enkelte prøve i prøveprogrammet, er opfyldt.
Med mindre andet er angivet, sker afprøvning af leverancer i model af de generiske prøvetyper, som standardkontrakten for K02, Længerevarende it-projekter, udstikker - og suppleret med Demonstrationsprøve, som er en AU tilretning.
Det drejer sig om nedenstående, og hver af prøvetyperne er udfoldet på links herunder.