Testaktiviteter

I AU IT har vi en tilgang til test, der er baseret på risici. Det er umuligt at teste alle aspekter af en leverance 100% - derfor må vi have en tilgang, der hjælper med at prioritere testfokus, så vi sikrer, at vi arbejder med det, som er vigtigst. AU IT's testpolitik definerer derfor, at vores testprogram skal være baseret på en risiko-vurdering. Hovedartefakten i risikobaseret test er "Product Risk Analysis" (PRA).

Det er væsentligt at sikre, at relevante interessenter for udvikling og forvaltning af det kommende produkt er med til risikoidentifikationen. Det betyder, at i hvert fald følgende roller skal overvejes:  leverancens aftager, IT arkitekt, udvikler, test manager, den kommende forvaltning. Arbejdes der sammen med en leverandør, skal en repræsentant herfor også overvejes. Flere aspekter end de listede kan være relevante. 

Den risikobaserede test-metode anvendes til at bestemme, hvor testen skal begynde, og hvor der er behov for en særlig høj testdækning (i erkendelse af, at vi netop ikke kan teste alt, vi laver). Vha. risikovurderingen, som er én af de fire aktiviteter associeret med risikobaseret test, får vi retningen på, hvor vi skal teste mest (emner øverst på risikoprioriteringen – høj Risc Priority Number - RPN), og hvor de mindre farlige områder er, der ikke behøver så megen test (emner nederst på risikoprioriteringen – lav RPN).

Herunder ses den tilgang til risikoanalyse, som AU IT anvender.

Risikobaseret test
Term	Beskrivelse
Projektrisici	De risici der kan true selve projektets gennemførsel. Projektrisici udarbejdes for projektet af projektleder og er en del af den generelle projektstyring.
Produktrisici	De risici der kan true kvaliteten af det endelige produkt – f.eks. at slutbruger oplever at systemet er vanskeligt at betjene, funktionaliteten ikke er som forventet osv. Når vi snakker test, kigger vi udelukkende på produktrisici ifm. de ting vi tester.
Aktivitet 1: Risikoidentifikation	Proces, der skal identificere risici ved det arbejde, der skal testes. Kan være aktiviteter så som brainstorming og andre idégenereringsmetoder, men kan også være erfaringsbaseret i form af tjeklister og generel viden fra lignende opgaver.
Aktivitet 2: Risikovurdering	På baggrund af risikoidentifikationen foretages en vurdering af hver af disse. Tilgangen til test er baseret på en systematisk risikovurdering, så det sikres, at områder med høj risiko får høj testdækning. Parametre i risikovurderingen er: Sandsynligheden for at leverancen vil fejle (tekniske overvejelser/graden af kompleksitet, vi kalder det teknisk risiko.) Kompleksitet kan være mange ting, f.eks.: Kompleks kode, stor kodemængde, komplekst forretningsområde, kode der ikke har været rørt længe, graden af ny udvikling. Sandsynligheden omsættes til et tal mellem 1 og 5, hvor 5 er den højeste risiko og 1 er lavest. Konsekvensen for forretningen (vi kalder det den forretningsmæssige risiko), såfremt leverancen fejler. Konsekvensen omsættes til et tal mellem 1 og 5. RPN (Risc Priority Number) fås ved at gange værdien for sandsynligheden for, at en risiko indtræffer, med værdien for alvoren af den konsekvens en fejlende leverance vil have for PO’s forretning.
Aktivitet 3: Risikoreduktion	Som følge af risikoidentifikationen og -vurderingen mitigeres de funde risici ved at tildele flest ressourcer til emnerne med høj RPN og nedprioritere dem med lav RPN.
Aktivitet 4: Risikostyring	Generel styring og opfølgning på risikovurderingen af produktet, der arbejdes på. Over tid kan prioriteringen af risici ændre sig, og risikostyring handler om at sætte processer op, der skal imødekomme dette.

Den agile tilgang til risikobaseret test

I den agile kontekst er prioriteringen af test afhængig af en tilsvarende prioritering af udviklingsopgaverne. Det er derfor afgørende for den risikobaserede test, at ovenstående risikoidentifikation og risikovurdering, der laves på et overordnet niveau, er styrende for prioriteringen af udviklingsopgaver, så opgaver med høj RPN udvikles tidligt. Den bruges desuden til at sætte teststrategien tidligt i projektet/opgaven. Risikovurderingen bruges til at definere de testtyper, der er nødvendige at udføre på baggrund af de identificerede risici.    

Den omtalte risikoidentifikation og risikovurdering foretages på et tidligt tidspunkt og er som sagt på et overordnet niveau (Epics/Features). Når vi begynder at arbejde med opgaverne i det agile setup, vil de brydes ned i mindre opgaver (userstories), som specificeres yderligere. Her sætter vi ind med endnu en risikovurdering, hvor vi vurderer risikoen på den enkelte userstory. Dette sker naturligt i den scrum ceremoni, hvor teamet også estimerer de enkelte userstories - typisk backlog refinement. Inden en userstory estimeres, fastlægges dens risikoprofil. Dette kan evt. gøres med et slag risikopoker, først konsekvens og så sandsynlighed, eller ved at bruge risikokvadranter og placere den enkelte userstory i et koordinatsystem med konsekvens på den ene akse og sandsynlighed på den anden. Når vi har haft en dialog og står med et risikobillede af den aktuelle userstory, er vi klar til at estimere selve opgaven. Det nye RPN på userstory niveau indføres på selve opgaven, så det er tydeligt gennem sprintet hvilke opgaver, der har den højeste risiko og dermed højeste prioritet og kræver højest dækning ift. testcases.  

Det er nødvendigt løbende at konsultere resultatet af den overordnede risikoanalyse og følge op på, om noget har ændret sig, så risikobilledet har ændret sig. 

Dette afsnit er alene en service til de roller i projekter og forvaltninger, der arbejder med behovs- og kravprocesser. 

En kravspecifikation vil være et resultat (sikkert blandt flere resultater) af et analyse- og afklaringsarbejde, der er iværksat for at opfylde forretningsmæssige mål. Det kan være at overholde et bestemt lovgivningskrav, at automatisere en rutinemæssig arbejdsgang (og dermed frigøre ressourcer til mere krævende opgaver), at understøtte en ændret arbejdsgang, som involverer en ny godkendelse inde i en arbejdsgang. Eller det kan være teknisk og organisatorisk implementering af et nyanskaffet system i AU. Arbejdet hen imod en kravspecifikation vil altid starte med en forretningsanalyse. 

Herunder beskriver vi de grundlæggende aktiviteter, som vi anbefaler systemejerorganisationen at gennemføre (lige-præcis-tilstrækkeligt) i arbejdet med at nå frem til en afklaring af, hvad det er for en forandring, som en ny it-løsning skal understøtte for brugerne. Forretningsanalysen er som nævnt første skridt i arbejdet hen imod en kravbeskrivelse. 

Det er fristende at kaste sig over en beskrivelse af det, man gerne vil have udviklet eller indkøbt, i stedet for først at fokusere på det forretningsbehov, som systemet eller funktionaliteten skal understøtte. Men at gøre dette svarer til, at en udvikler kaster sig over koden med det samme - uden at tage højde for den arkitektur, kravspecifikation og driftsikkerhed ved igangsætning, som er helt afgørende for forretningen. 

Der er mange metoder og værktøjer, systemejer kan bruge til at gennemføre forretningsanalysen. Den beskrevne fremgangsmåde er derfor én blandt mange mulige. Vi har valgt formidle den, fordi vi selv har anvendt den med gode resultater. Den er enkel, og den bidrager til den transparens og forståelse af processerne, der gør, at beslutninger om det fremtidige system / ændrede system kan træffes på et fælles og solidt grundlag.

De projekter eller udviklingsopgaver, der skal levere pågældende system, vil være vidt forskellige, hvad angår størrelse, kompleksitet, kommende brugertyper. Det væsentlige budskab er, at en lige-præcis-tilstrækkelig forretningsanalyse under alle omstændigheder er afgørende for, at det system (det udviklingsarbejde), der produceres og leveres, er DET RIGTIGE. Det er nemlig resultatet af en god og tilstrækkelig forretningsanalyse, der skal sikre, at de ressourcer, som AU binder i en sådan leverance, laver det rigtige.  

Det er således en forudsætning for at nå frem til de krav, som en it-leverance skal levere på, at forretningsanalysen har stillet skarpt på den præcise forandring (de behov), der ønskes it-understøttet. Forretningsanalysen vil danne grundlaget for afgrænsning af it-projektet i omfang og ambitionsniveau, og den vil beskrive og sikre ledelsens synlige opbakning til de organisatoriske forhold og det overordnede workflow, der skal gælde, når systemet er organisatorisk implementeret. Ved meget store projekter anskues forretningsanalysen som et selvstændigt projekt, og det er notorisk langt mere omfattende end man umiddelbart tænker det. Erfaringer viser, at det forretningsmæssige afklaringsarbejde i forbindelse med udviklingsopgaver, udgør omkring halvdelen af udviklingsarbejdet.

Ude i verden er det erfaringen, at det er ufuldstændige eller ligefrem manglende forretningsanalyser, der kan være medvirkende årsag til, at it-projekter enten ikke lykkes eller har svære vilkår (Søren Lauesen: Hvorfor går it-projekter ofte galt?).

Derfor anbefaler vi en lige-præcis-tilstrækkelig forretningsanalyse, så arbejdet med kravspecificeringen efterfølgende kommer til at ske på et transparent og godkendt grundlag.

Som alle andre indsatser i projekter og forvaltning skal også testindsatsen estimeres, så projektleder/systemforvalter har et grundlag at sikre ressourcer, kompetencer og tid på. I en hybrid udviklingskontekst er det nødvendigt at skelne mellem niveauer for estimering. Sikring af ressourcer, kompetencer og tid er typisk initielle projekt-aktiviteter, som baseres på initielle high-level estimater, mens teamets commitment i det enkelte sprint baseres på teamets egen estimering af den enkelte user story, udført "just in time" og typisk estimeret i story point og ikke i tid. 

På denne siden beskrives således forskellige vinkler ind i og niveauer af estimering af testindsatsen.

Generelle faktorer i estimering af testindsats

High level estimater

Nedenfor ses en oversigt over elementer, som kan have en betydning for estimatet af den samlede testindsats. Listen er primært tænk til anvendelse ved den initielle high level-estimering - hvor lang tid vil det tage at teste den samlede leverance med den viden, vi har helt initielt (typisk repræsenteret i en kontrakt)?

Elementer i estimatet	Beskrivelse
Omfang af test/teststrategi	Identifikation af testniveauer/testtyper (f.eks. systemtest, integrationstest, performancetest, brugervenlighedstest osv.)
Testartefakter	Udvikling og vedligeholdelse af testplaner, testcases, testrapporter, testdata, testmiljøer, automatiserede testscripts osv.
Testressourcer	Antal nødvendige testressourcer, inklusive testere, test mangers, testkoordinatorer og eventuelle specialister eller underleverandører
Testtid	Estimeret tid til udførelse af testcases, fejlfinding og rapportering af testresultater
Testmiljø	Krav til testmiljøet, herunder hardware, software, databaser osv. samt mulige begrænsninger eller deling af testmiljøet
Risikovurdering	Projekt- og produktrisiko: Vurdering af projektets risikoprofil og identifikation af højrisikoområder, der kræver ekstra testindsats
Test management	Tid brugt på møder, rapportering, fejlhåndtering, kommunikation med interessenter og andre test management opgaver
Iterationer og releases	Estimeret testindsats for hver iteration eller release i projektet samt håndtering af afhængigheder mellem dem, herunder behov for regressionstest
Afgrænsning	Hvilke testniveauer og/eller testaktiviteter er IKKE medtaget i estimatet (eksempelvis udviklertests)
Buffertid	En buffer for uforudsete hændelser, forsinkelser eller ændringer i projektet, der kan påvirke testindsatsen

Bemærk, at denne oversigt giver en generel oversigt over de forskellige elementer, og at flere elementer har overlap i beskrivelserne. I praksis kan specifikke projekter have færre eller yderligere elementer eller specifikke krav, der skal tages i betragtning under testestimeringen.

Det er også vigtigt at huske, at estimater altid er forbundet med usikkerhed, så det er en god idé at inkludere en buffer for uforudsete hændelser eller forsinkelser i estimatet.

Sprint estimater

Nedenfor ses en oversigt over elementer, som kan have en betydning for estimatet af sprintets samlede testindsats. Listen er primært tænkt til anvendelse i agil kontekst på user stories og i forbindelse med sprintplanlægning, men kan i lige så høj grad anvendes til estimering af product backloggen. Det er ikke tanken, at de enkelte elementer estimeres hver for sig, men det er elementer, der bør vurderes for hver enkelt user story (eller feature), og som er med til at definere, hvor kompleks en opgave er rent testmæssigt. Vurderingen af en user story´s testmæssige kompleksitet er input til det samlede estimat for storien, udtrykt i story points. 

Elementer i estimatet før hvert sprint	Beskrivelse
Sprintmål	Forståelse af sprintmålene og de specifikke funktioner eller krav, der skal testes i sprintet
Opdatering af testartefakter	Gennemgang og opdatering af eksisterende testartefakter, herunder testcases, testdata og eventuelle automatiserede testscripts, for at afspejle ændringer i sprintopgaverne
Testanalyse	Testanalyse af den enkelte user story/feature, herunder identifikation og prioritering af testområder baseret på sprintets funktionelle ændringer, risikoprofiler og eventuelle afhængigheder fra tidligere sprint.
Testressourceallokering	Bestemmelse af antallet og typen af testressourcer, der er nødvendige for at udføre testopgaverne i sprintet, herunder testere og eventuelle specialister
Estimeret testtid	Estimering af den nødvendige tid for at udføre testopgaverne i sprintet, herunder forberedelse af testartefakter (testplaner, dashboards, testdesign og testcases), afvikling af testcases og rapportering af testresultater. Bemærk, at unit- og integrationstests er udvikler-aktiviteter. Det skal dog sikres, at aktiviteten er taget i betragtning, når den samlede opgave estimeres.
Testmiljø	Sikring af, at det nødvendige testmiljø er tilgængeligt og konfigureret korrekt til at udføre testene i sprinten, inklusive hardware, software, databaser osv., booking af testmiljø.
Testafhængigheder	Identifikation og håndtering af eventuelle afhængigheder af testressourcer, testmiljø eller eksterne systemer, der kan påvirke testindsatsen i sprinten
Buffertid	Inddragelse af en buffer til uforudsete hændelser, ændringer eller risici, der kan påvirke testindsatsen i sprintet

Metode til sprint- og product backlog-estimering

Planning poker

Planning Poker er en konsensus-baseret teknik til agil og relativ estimering.

Planning poker igangsættes ved, at product owner (eller repræsentant for forretningen) læser en af de user stories/features, som skal estimeres, højt for teamet.

Hver deltager har fået udleveret et sæt estimeringskort. Kortene har typisk værdierne 1, 2, 3, 5, 8, 13, 20, 40 og 100 (modificeret fibonaci-skala). Hver værdi repræsenterer antal story points. Alternativt kan man anvende t-shirtstørrelser til denne del af planning poker.

Deltagerne diskuterer nu user storien/featuren og stiller eventuelt uddybende spørgsmål til product owner.

Når user storien/featuren er forstået af alle deltagere, vælger hver enkelt deltager et kort, som repræsenterer deres estimat. Alle deltagere viser herefter deres kort på samme tid. Hvis alle deltagerne har valgt samme kort, så bliver kortets værdi til estimatet.

Hvis deltagerne har valgt forskellige kort, diskuteres estimaterne med forkus på begrundelse for det højeste og det laveste estimat. Efter yderligere diskussion, vælger hver enkelt deltager påny et kort, som repræsenterer deres estimat og alle viser dernæst deres kort på samme tid igen.

Teamet gentager denne proces, indtil der er konsensus om et estimat. Hvis der mangler informationer for at blive i stand til at blive enige om et estimat, kan teamet afvise den specifikke user story/feature, indtil der er tilføjet det nødvendige informationer. 

(Kilde: https://www.mountaingoatsoftware.com/agile/planning-poker).

Metode til high level estimering

Simpel tjekliste

Vi anbefaler generelt, at de samlede testaktiviteter på systemniveau vurderes til at være 1/3 af udvikingsestimaterne. Dette kan granuleres yderligere ved at anvende nedenstående simple model.

Modellen nedenfor tager delvist udgangspunkt i den grundlæggende testproces, men har i sin udformning herunder lidt flere parametre med.

Testniveauet for denne model er system- og systemintegrationstest af udviklingsopgaver. Det betyder, at følgende testtyper og -niveauer er ikke omfattet af modellen:

• Unit- og kompontintegrationstest, herunder regressionstest af 'omgivelser'. Disse testniveauer skal estimeres af udviklerne som en del af udviklingsestimaterne.
• Opgavestillers tests (system-/accepttest). Disse tests planlægges og estimeres af opgavestiller.
• Prøver. Tilgangen til estimering af eventuelle kontraktuelt bestemte prøver og eventuelle understøttende aktiviteter i den forbindelse håndteres ved siden af estimatet for udviklingsopgaverne - typisk ved at anvende den udvidede tjekliste (se nedenfor) og/eller ved at nedbryde kontraktens testrelaterede leverancer i form af et work breakdown tree, hvor de nedbrudte dele kan estimeres/guestimeres hver for sig.

Område	Delleverance	Guestimat (lavt)	Guestimat (Højt)	Kommentar
		Dage (= 5 timer)
Testvinklen repræsenteret i krav- og specifikationsfaserne	En tester er med i dialogerne mellem forretning og AU IT efter behov.			En sådan konstellation vil skære ned på de specifikke estimater herefter, idet flere forhold vil blive præciseret, udfordret, kommunikeret tidligt
Test management	Hovedtestplan, dækkende  for både statisk og dynamisk test. Detail-/sprinttestplaner efter behov (funktionalitet, integrationer, sikkerhed, performance, usability …) Ressourcesikring internt i AU IT og opgavestillers organisation (hvis ressourcer herfra skal bruges i AU IT's testarbejde) Løbende opfølgning på fremdrift i testdesign og testafvikling Testrapport			Ressourcesikring er i AU IT, men også hos opgavestiller ift testdata, review af testcases, arbejdet med risici samt testeksekvering
Reviews af specifikationer	Sikring af rigtig løsning på baggrund af behov (forretningsmæssigt, teknisk, brugervenlighed, sikkerhed, arktitektur)
Testanalyse og -design	Overordnet testanalyse og testdesign Leverance er:  Test cases klar til eksekvering.			En måde at gribe opgaven an på er, at estimere følgende: Antal testobjekter (userstories + integrationer + non-funktionelle krav + ?) Antal testcases pr testobjekt Antal timer pr testcase Vurderet kompleksitet Formel : Antal testobjekter * antal testcases pr objekt * antal timer pr testcase * kompleksitetsfaktor.
Testklargøring	Testafviklingsplan Reservation og klargøring af miljøer Klargøring af testdata Detailplanlægning af testplanlægning, herunder ressourcer og 'påklædning' af disse Implementering af defect management proces og -board.
Testgennemførelse	Testafvikling Fejlhåndtering Gentest			En måde at gribe opgaven an på er, at estimere følgende: Tidligere i estimeringen har vi estimeret antal testcases. Estimat for testgennemførelse er derfor antal timer til afviking pr testcase * antal testcases.

EXCEL SKABELON  !!!! MANGLER

Udvidet tjekliste

Tjeklisten her er primært tænkt til highlevel-estimering, eksempelvis ved estimering af et projekts samlede testestimat, men anvendt som ren tjekliste kan den desuden fungere som en sikring af, alle relevante elementer er taget med i betragtning, når testindsatsen for mindre områder estimeres. 

Testproces	Element	Parametre	Opgave
Teststrategi	Omfang af test	Teststrategi	Identifikation af opgavetyper
Teststrategi	Omfang af test	Teststrategi	Identifikation af testniveauer
Teststrategi	Omfang af test	Teststrategi	Identifikation af testtyper
Teststrategi	Omfang af test	Prøver	Identifikation af kravsatte prøver
Teststrategi	Artefakter	Teststrategi	Udvikling af teststrategi
Teststrategi	Artefakter	Teststrategi	Review af hovedtestplan
Teststrategi	Artefakter	Teststrategi	Godkendelse af hovedtestplan
Teststrategi	Artefakter	Teststrategi	Vedligehold af teststrategi
Testplanlægning	Artefakter	Hovedtestplan	Udvikling af hovedtestplan
Testplanlægning		Hovedtestplan	Review af hovedtestplan
Testplanlægning	Artefakter	Hovedtestplan	Godkendelse af hovedtestplan
Testplanlægning	Artefakter	Hovedtestplan	Vedligehold af hovedtestplan
Testplanlægning	Artefakter	Niveautestplaner	Udvikling af niveautestplaner, herunder plan for regressionstests
Testplanlægning	Artefakter	Niveautestplaner	Vedligehold af niveautestplaner
Testafvikling	Artefakter	Testrapporter	Udvikling af testrapporter
Testafvikling	Artefakter	Testrapporter	Godkendelse af testrapporter
Testanalyse og testdesign	Artefakter	Testdesign	Udvikling af testdesign
Testanalyse og testdesign	Artefakter	Testdesign	Review af testdesign
Testanalyse og testdesign	Artefakter	Testcases	Udvikling af testcases til udviklingsopgaver (udvikling, migrering, konfigurering)
Testanalyse og testdesign	Artefakter	Testcases	Review  af testcases
Testanalyse og testdesign	Artefakter	Testcases	Vedligehold af testcases (regressionstest, versioneringer)
Testimplementering	Artefakter	Testdata	Udvikling af testdata (identifikation)
Testimplementering	Artefakter	Testdata	Vedligehold af testdata (load/indlæsning, oprydning m.m.)
Testimplementering	Artefakter	Testmiljøer	Udvikling af testmiljøer
Testimplementering	Artefakter	Testmiljøer	Vedligehold af testmiljøer
Testimplementering	Artefakter	Testscripts	Udvikling af automatiserede testscripts
Testimplementering	Artefakter	Testscripts	Vedligehold af automatiserede testscripts
Testplanlægning	Artefakter	Testafviklingsplan	Udvikling af test afviklingsplan
Testplanlægning	Testressourcer	Testere	Estimat for allokering af testere (håndteres typisk af PL)
Testplanlægning	Testressourcer	Test manager	Estimat for allokering af test manager (håndteres typisk af PL)
Testplanlægning	Testressourcer	Testkoordinatorer	Estimat for allokering af testkoordinator (håndteres typisk af PL)
Testplanlægning	Testressourcer	Testspecialister	Estimat for allokering af testspecialister (håndteres typisk af PL)
Testplanlægning	Testressourcer	Andre faglige specialister	Estimat for allokering af andre faglige specialister (håndteres typisk af PL)
Testafvikling	Testafvikling	Afvikling af testcases	Afvikling af testcases
Testafvikling	Testafvikling	Afvikling af testcases	Fejlregistrering
Testafvikling	Testafvikling	Afvikling af testcases	Fejlhåndtering
Testafvikling	Testafvikling	Afvikling af testcases	Gentest
Testafvikling	Testafvikling	Afvikling af testcases	Afvikling af regressionstest
Testplanlægning	Risikovurdering	PRA	Etablering af Product Risk Analyses på high-level niveau (epic/feature-niveau)
Testplanlægning	Risikovurdering	PRA	Identifikation af højrisikoområder og deraf områder, som kræver ekstra test
Testplanlægning	Risikovurdering	PRA	Risikovurdering af user stories i det enkelte sprint
Testovervågning og kontrol	Test management	Test management	Møder
Testovervågning og kontrol	Test management	Test management	Testrapportering
Testovervågning og kontrol	Test management	Test management	Kommunikation med interessenter
Testplanlægning	Iterationer og releases	Prøver	Testindsats for hver prøve
Testplanlægning	Iterationer og releases	Releases	Testindsats ved nye releases, herunder regressionstest
Testplanlægning	Iterationer og releases	Afhængigheder	Håndtering af afhængigheder mellem sprint, releases og prøver
Teststrategi	Afgræsning	Out of scope	Identifikation af testopgaver, som ikke er med i det samlede estimat (eks. udvikler test)
Testplanlægning	Buffer	-	Uforudsette hændelser
Testplanlægning	Buffer	-	Forsinkelser
Testplanlægning	Buffer	-	Ændringer

For at anvende tjeklisten til konkret estimering, anbefales det at bruge en kopi af denne Excel-skabelon:

EXCEL SKABELON  !!!! MANGLER

Trepunktsestimering

Excel-skabelonen benytter estimeringsmetoden trepunktsestimering, hvor der vurderes et realistisk estimat, et best case- og et worst-case estimat.

For alle tre estimater vurderes det, hvor sandsynlige de er, og de gives en tilsvarende procentsats.

Estimaterne angives i timer, og sandsynligheden i procent (de tre estimater udgør i alt 100%).

Det realistiske estimat vil i sagens natur have en større sandsynlighed end best- og worstcase-estimaterne.

Det risikojusterede estimat udtrykker et vægtet gennemsnit af de tre estimater og deres sandsynligheder.

Risikopuljen er forskellen mellem det realistiske estimat og det risikojusterede estimat. 

For at sikre den rette rækkefølge for afvikling af testcases, kan der med fordel udarbejdes en testafviklingsplan. Formålet med testafviklingsplanen er, at testafviklingen bliver så effektiv som muligt.

Testafviklingsplanen specificerer de testcases, der skal afvikles og sikrer, at eksempelvis arbejdsgange testes sammenhængende på tværs af Systemets funktionalitet.

Den skal desuden sikre, at forskellige afhængigheder (mellem eksempvelvis testcases, tidsmæssige afhængigheder, datamæssige afhængigheder) afspejles i den rækkefølge, testcases afvikles på.

Testafviklingsplanen skal således indeholde:

• En  oversigt over testcases, inkl. henvisning til, hvilke krav, der bliver testet (med angivlese af user story-/kravnummer).
• Angivelse af afviklingsrækkefølgen af testcases
• Angivelse af, hvem der afvikler hvilke testcases
• Forudsætninger for og tidsmæssige forhold i testafviklingen.
• Beskrivelse af hvilke testdata, der skal etableres, hvordan og af hvem
• Beskrivelse af, hvor testen foregår, tidsrummet for test, medvirkende ressourcer under test - eventuelt blot med henvisning til test- eller prøveplanen.

Review er en statisk testaktivitet, hvilket betyder, at der ikke afvikles kørende kode. Med statisk test undersøges læsbarheden af produktet. Fuldstændighed, korrekthed, testbarhed og konsistens vurderes. Produktet er her typisk dokumenter (artefakter) eller kode (enten kodereview eller statisk analyse), som dog ikke afvikles.

Den statiske test finder fejl, mangler, misforståelser i dokumentationen i forhold til standarder, forretningsmæssig/teknisk viden, compliance og testbarhed. Statisk test kan ydermere bidrage til en fælles forståelse af opgave og/eller løsning - og dermed sikring af, at det er rette løsning, vi har gang i at lave.

Der findes flere typer review med forskellige grader af formalisme. Reviewtyperne retter sig mod forskellige formål, så den enkelte reviewtype skal anvendes, så det konkrete behov tilgodeses. 

Når reviews gennemføres ordentligt, er de den største og mest omkostningseffektive bidragyder til den samlede leverede kvalitet. 

Reviews kan initieres af alle involverede i softwareudviklingen/implementeringen, enten ved behov eller ved faste gates. Her er nogle eksempler på oplagte tidspunkter at gennemføre reviews:

• I forbindelse med udbud og indgåelse af kontrakter
• Af kravspecifikationen - både funktionelle og non-funktionelle krav
• Af udviklingsartefakterne (eksempelvis løsningsarkitekturbeskrivelse og kode)
• Af testdokumentationen (eksempelvis testplaner, testbetingelser og testcases)

Reviews bør planlægges, således at de finder sted på naturlige tidspunkter eller ved milepæle i projektforløb.

En fejlhåndteringsproces (Defect Management process) er nødvendig for at kunne håndtere fejl på en struktureret, prioriteret og konsistent måde. Processen skal tydeligt beskrive, hvem der er ansvarlig for de forskellige stadier i en fejls livscyklus. Fejlhåndteringsprocessen er en generisk proces fælles for alle testaktiviteter på system-niveau, medmindre andet er angivet i de specifikke testplaner.

Fejl fundet af udviklerne under softwareudvikling (på unittest- og komponentintegrationstest-niveauerrne) er ikke håndteret af en formel fejlhåndteringsproces. Ud fra en "lige præcis tilstrækkeligt"-tilgang bliver disse fejl løst løbende som en del af udviklingen.

Større eller mere komplekse fejl og fejl, som er observeret i forbindelse med en testafvikling håndteres i Azure Test Plans . Observationer rappporteres med issuetype "Bug". Azure Test Plans tilbyder en template til fejlrapportering, hvilket sikrer, at alle nødvendige informationer vedrørende observationen registreres. Dette inkluderer:

Overskrift	Kort beskrivelse
Bug ID	Nummer (blot fortløbende - tildeles automatisk i Jira)
Overskrift på bug (Summary)	Sigende navn på fejlrapporten (Ved oprettelse angives titel i feltet Summary)
Beskrivelse	Beskriv observationen så grundig, som muligt Beskriv det testdata, der er anvendt for at fremprovokere fejlen- vær dog obs på ikke at indtaste personhenførbare data jf. GDPR. Tilføj steps-to-reproduce med forventet versus faktisk resultat. Tilføj miljø, som fejlen er fundet i.  Tilføj den testfase/testniveau, som fejlen er fundet i. Andre relevante parametre.
Komponent	Hvis der er oprettet komponenter til løsningen, så kan den relevante komponent, som fejlen vedrører, vælges fra dropdown.
Label	Forskellige labels kan sættes på de enkelte fejlrapporter fx for at kunne udtrække data til metrikker.
Prioritet	Angiv prioritet fra dropdown: Trivial, Minor, Normal, Major, Critical, Blocker
Attachement	Vedhæft relevante skærmbilleder, så det er tydeligt, hvor fejlen er - og andet relevant, eksempelvis dokumentation/specifikation
Epic link	Reference til Epic angives i Epic link.
Issue links	Reference til den aktuelle Userstory laves via issue links. Der kan evt. også linkes til andre relaterede bugs eller til testcases.
Affects version	Vælg den produktversion, som fejlen er fundet i
Fix version	Vælg den produktversion, som fejlen er rettet i (gøres i forbindelse med fejlrettelse, gentest og deployment).
Meta data om test casen	Hvem har oprettet fejlrapporten, hvornår er den oprettet/opdateret? Angives automatisk i Jira.

Proces

Det første skridt i en fejls livscyklus er at evaluere, hvorvidt observationen er en fejl eller ej. En observation kan skyldes forkerte testdata, fejl i testdata, vildledende eller forkert testcase, miljømæssige forhold eller simpelthen misforståelser. Inden der oprettes en fejlrapport i JIRA, har testeren typisk undersøgt og udelukket disse mulige årsager, og antagelsen er derfor, at det faktisk er en fejl.

Den, der indrapporterer fejlen, sætter initielt en prioritet på buggen, men det er Product Owners ansvar (eventuelt i samarbejde med Test Manager/test koordinator) at beslutte hvorvidt en fejl skal rettes og med hvilken prioritet. 

Test Manager (eller testkoordinator) er ansvarlig for initiel visitering af fejlrapporter, så der ikke oprettes dubletter, for tilstrækkelig beskrivelse samt kommunikation med udviklerne. Hvis det vurderes nødvendigt, kan Test Manager (eller testkoordinator) involvere et fejlhåndteringsudvalg, som nedsættes for effektivt at kunne evaluere, prioritere, estimere og tildele fejlrapporternt. Dette er særligt relevant, hvis der er flere leverandører involveret. Udvalget består af Test Manager, Product Owner og relevante repræsentanter fra leverandører,  udvikling, test og forretning. Det skal overvejes, om der tilsvarende er behov for interne fejlhåndteringsudvalg for at diskutere, afklare og prioritere findings og fejl. 

Resultatet af Test Managers (eller testkoordinators) eller udvalgets visitering er et af følgende tre: 

• Fejlhåndteringsrapporten afvises og fejlen skal ikke rettes. 
• Fejlen er klar til at blive rettet og er prioriteret.
• Der er behov for yderligere information/analyse for at kunne vurdere den rigtige prioritet.

Afviste fejlrapporter returneres til den person, der har oprettet rapporten med kommentar med begrundelse for afvisning. Fejl, som er klar til at blive rettet, og fejl, som kræver yderligere informationer og/eller analyse, tildeles enten til AUs udviklingsteam eller til leverandøren. AUs Test Manager er ansvarlig for at sikre tildeling af fejlrapporten til leverandøren. 

Udviklingsteamet kan herefter:

• Foretage en teknisk undersøgelse og analyse for at blive i stand til at identificere og estimere de nødvendige rettelser og derefter returnere fejlrapporten til Product Owner, som kan lave en ny prioritering (gælder større/komplekse fejl)
• Implementere de nødvendige rettelser jf. planen (nu eller på et senere tidspunkt) (gælder simple fejl)

Når en fejl er blevet rettet og rettelsen er blevet deployed til det aftale miljø (typisk testmiljøet), tildeles fejlrapporten - via Test Manager eller testkoordinator - til den, der rapporterede fejlen, som foretager verifikation af, at fejlen ikke længere kan reproduceres. Såfremt fejlen er rapporteret på baggrund af afvikling af en testcase, skal denne testcase genafvikles i forbindelse med gentesten. Hvis fejlen ikke kan reproduceres, lukkes fejlrapporten i JIRA, og testcasen sættes til "passed". Hvis fejlrettelsen ikke kan verificeres, returneres fejlrapporten til udviklingsteamet - via Test Manager eller testkoordinator - med en beskrivelse af den forsøgte verifikation, og testcasen failes. Såfremt fejlen ikke er rapporteret i forbindelse med afvikling af en testcase, skal det overvejes, om der skal oprettes en ny regressions-testcase, der tester for fejlen fremadrettet.

Testprocessen har i alle opgavetyper særligt fokus på princippet om, at teste så tidligt, som muligt, selvom det omgivende systemlandskab endnu ikke er etableret eller færdigudviklet, således at så megen test som muligt kan forberedes og gennemføres tidligt og isoleret – afkoblet fra andre, senere og mere integrerede tests. Afhængigheder kan mockes.

Det er et strategisk mål for at sikre, at omfanget af komponent- og komponentintegrationstest i antal testcases er væsentligt større, end omfanget af systemtesten – og tilsvarende skal systemtesten i omfang og antal testcases være større end omfanget af accepttesten. Derved indikeres, at kompleksiteten i testcases bliver gradvist større, jo højere testniveau testen afvikles på – og derved sikres, at test på de højere niveauer bygger på et solidt fundament af mindre systemdele med allerede afprøvet og tilstrækkelig kvalitet.

1.1  Udvikling / Integrationsudvikling

Herunder ses det generiske paradigme, som det enkelte projekt tager udgangspunkt i og definerer sine testtyper ud fra, for så vidt angår udvikling eller integrationsudvikling. Det fremgår af hovedtestplanen, hvilke testtyper, projektet – med udgangspunkt i risikovurderinger - gør brug af. Såfremt en given testtype på et givet testniveau fravælges, begrundes dette kort i hovedtestplanen.

1.1.1   Statisk test

Test Type	Niveau	Testens formål
Review	Komponent	Specifikation:    Reviewet modtagekontrollerer, at detailspecifikationen er fyldestgørende, testbar og klar til realisering.  Testcases:          Review sikrer, at testcases til dynamisk test er dækkende og korrekte. Kode:                 Kodereview kvalitetssikrer koden. Anvendes ved høj risiko.
Review	Komponent-integration	Specifikation:    Review modtagekontrollerer, at den specificerede løsningsarkitektur er fyldestgørende, testbar og klar til realisering.  Testcases:          Review sikrer, at testcases til dynamisk test er dækkende og korrekte. Kode:                Kodereview, f.eks. i form af walkthrough, kvalitetssikrer koden. Anvendes ved høj risiko.
Review	System	Specifikation:    Review 1 validerer systemspecifikationen op mod kravspecifikationen og sikrer, at den realiserer de beskrevne behov/krav til IT-løsning. Specifikation:    Review 2 modtagekontrollerer, at den specificerede systemarkitektur er fyldestgørende, testbar og klar til realisering. Testcases:         Review sikrer, at testcases for den enkelte testtype til dynamisk test er dækkende for specifikationen og korrekte.
Review	Accept	Specifikation:    Review validerer kravspecifikation op mod de identificerede og beskrevne behov og sikrer, at kravene til nyt/ændret IT-system vil imødekomme behovene. Testcases:         Review sikrer, at testcases for den enkelte testtype til dynamisk test er dækkende for specifikationen og korrekte.

1.1.2   Dynamisk test

Bemærk, at ved udvikling / integrationsudvikling gennemføres mindst én testtype pr niveau. 

Test Type	Niveau	Testens formål	Fokus
Unit test (også kaldet Komponent test)	Komponent	Testen skal finde fejl og verificere, at en unit (komponent), som er den mindste testbare enhed i en applikation, virker efter hensigten og som specificeret i detailspecfikationen. Automatiseres i videst mulige omfang. Whitebox-test.	Funktionalitet Non-funktionalitet Integration
Komponent integrationstest	Komponent-integration	Testen skal finde fejl og verificere, at grænseflader (snitflader) og samspil mellem de godkendte units (komponenter) virker efter hensigten og som specificeret i detailspecifikationen. Automatiseres i videst mulige omfang. Whitebox-test.	Funktionalitet Non-funktionalitet Integration
Simuleret system test (SST)	System	Testen skal finde fejl og verificere, at de godkendte og integrerede komponenter virker samlet efter hensigten, dvs. som specificeret i løsningsbeskrivelsen. Dele af det enkelte system eller af systemets omgivelser er stubbet, og indgående data kan håndteres via drivere. Blackbox-test.	Funktionalitet Non-funktionalitet
System test (ST)	System	Testen skal finde fejl og er en verifikation af, at det samlede system virker efter hensigten, dvs. som specificeret i løsningsbeskrivelsen. Blackbox-test.	Funktionalitet Non-funktionalitet
Simuleret System Integrations Test (SSIT)	System	Integrationsudvikling:  Testen skal finde fejl og verificere, at integrationerne virker efter hensigten, dvs. som specificeret ibehovs-/kravspecifikation og løsningsbeskrivelse. Dele af integrationen er stubbet og data kan håndteres via drivere. Blackbox-test.	Integrationer / data
System Integrations Test (SIT)	System	Testen skal finde fejl og er en verifikation af, at de samlede integrationer virker efter hensigten, dvs. som specificeret i løsningsbeskrivelsen. Blackbox-test.	Integrationer / data
Funktionstest (End2End)	System	Testen skal finde fejl og verificere, at arbejdsgange kan gennemføres efter hensigten, dvs. som specificeret i behovs-/kravspecifikationen og løsningsbeskrivelsen. Blackbox-test.	Funktionalitet Data
User Acceptance Test (UAT)	Acceptance	Testen skal verificere brugen af ​​systemet i produktionslignende miljø. Hovedmålet er, at brugerne verificerer, at brug af systemet opfylder deres behov, og at de kan udføre deres forretningsarbejdsprocesser med et minimum af udfordringer, omkostninger og risici. Fejl kan blive opdaget under UAT, men denne test har ikke som hovedformål at finde fejl. At afdække et stort antal fejl på dette tidspunkt kan have alvorlige konsekvenser for projektets succes.	Funktionalitet Data
Regressionstest	Alle niveauer	Testen skal afdække evt. utilsigtede konsekvenser i ikke-berørte dele af det samlede system.	Funktionalitet Non-funktionalitet Integrationer

1.2    Migrering

Herunder ses det generiske paradigme, som det enkelte projekt tager udgangspunkt i og definerer sine testtyper ud fra, for så vidt angår migrering. Det fremgår af hovedtestplanen, hvilke testtyper, projektet - med udgangspunkt i risikovurderinger - gør brug af. Såfremt en given testtype på et givet testniveau fravælges, begrundes dette kort i hovedtestplanen.

1.2.1   Statisk test

Test Type	Niveau	Testens formål
Review	Komponent	Specifikation:    Reviewet modtagekontrollerer, at detailspecifikationen er fyldestgørende, testbar og klar til realisering.  Testcases:          Review sikrer, at testcases til dynamisk test af den enkelte komponent er dækkende og korrekte.
Review	System	Specifikation:    Review 1 validerer migreringens systemspecifikation op mod kravspecifikationen og sikrer, at den realiserer de beskrevne behov/krav til migrering Specifikation:    Review 2 modtagekontroller, at den specificerede systemspecificikation (f.eks. mapningsdokumentet) for migrering er fyldestgørende, testbar og klar til realisering. Testcases:         Review sikrer, at testcases til dynamisk test af migreringen er dækkende for specifikationen og korrekte. Fokus er på korrekt migrering.
Review	Accept	Specifikation:   Review validerer kravspecifikation op mod de beskrevne behov og sikrer, at kravene til migreringen vil imødekomme behovet for migrerede data. Testcases:         Review sikrer, at testcases for accepttesten til dynamisk test er dækkende for specifikationen og korrekte. Fokus er på brugen at de migrerede data i modtagesystemet.

1.2.2   Dynamisk test

Test Type	Niveau	Testens formål	Fokus
Migreringstest	Komponent	Testen skal finde fejl og verificere, at en komponent migrerer efter hensigten og som specificeret i detailspecifikationen. Whitebox-test.	Data
Migreringstest	System	Testen skal finde fejl og verificere, at de godkendte og integrerede komponenter migreres samlet efter hensigten, dvs. som løsningsbeskrivelsen, og at data er migreret korrekt.  Blackbox-test.	Data
User Acceptance Test	Accept	Testen sikrer, at de migrerede data kan anvendes jvf behovsbeskrivelsen.  Fokus er på brugen at de migrerede data i modtagesystemet.	Data og brugen af data

1.3    Konfigurering (funktionelt og non-funktionelt)

Er opgavetypen konfigurering, kan komponenttyperne være fra nedenstående liste. Når konfigureringen af de enkelte komponenttyper er godkendt hver for sig, kan man begynde at kombinere dem for at sikre, at de virker sammen. Dermed bygges gradvist op til den samlede test på systemniveau.

Begrebet , og det kan eksempelvis være set-up af:

• Login
• Organisationsstruktur
• Roller og tilladelser
• Konfigurering af mail
• Konfigurering af notifikationer
• Ikke-funktionelle parametre

Komponenttyperne og de anvendte testtyper defineres i projektets hovedtestplan.

Herunder ses det generiske paradigme, som det enkelte projekt tager udgangspunkt i og definerer sine testtyper ud fra, for så vidt angår konfigurering. Det fremgår af hovedtestplanen, hvilke testtyper, projektet - med udgangspunkt i risikovurderinger - gør brug af. Såfremt en given testtype på et givet testniveau fravælges, begrundes dette kort i hovedtestplanen.

1.3.1   Statisk test

Test Type	Niveau	Testens formål
Review	Komponent	Specifikation:    Reviewet modtagekontrollerer, at detailspecifikationen er fyldestgørende, testbar og klar til realisering.  Testcases:          Review sikrer, at testcases til dynamisk test af den enkelte komponent er dækkende og korrekte.
Review	System	Specifikation:    Review 1 validerer konfigureringens systemspecifikation op mod kravspecifikationen og sikrer, at den realiserer de beskrevne behov/krav til konfigurering. Specifikation:    Review 2 modtagekontroller, at den specificerede systemspecifiikation for konfigurering er fyldestgørende, testbar og klar til realisering. Testcases:         Review sikrer, at testcases til dynamisk test af konfigureringen er dækkende for specifikationen og korrekte.
Review	Accept	Specifikation:   Review validerer kravspecifikation op mod de beskrevne behov og sikrer, at kravene til konfigureringen vil imødekomme behovene. Testcases:         Review sikrer, at testcases for accepttesten til dynamisk test er dækkende for specifikationen og korrekte.

1.3.2   Dynamisk test

Test Type	Niveau	Testens formål	Fokus
Konfigureringstest	Komponent	Testen skal finde fejl og verificere, at en komponent virker efter hensigten og som specificeret i detailspecifikationen. Whitebox-test.	Funktionalitet Non-funktionalitet
Konfigureringstest	System	Testen skal finde fejl og verificere, at de godkendte og integrerede komponenter virker samlet efter hensigten, dvs som løsningsbeskrivelsen. Blackbox-test.	Funktionalitet Non-funktionalitet
User Acceptance Test	Accept	Testen sikrer, at konfigurationen kan anvendes jvf behovs- og kravspecifikationen.	Funktionalitet Non-funktionalitet
Operations Acceptance Test	Accept	Testen sikrer, at konfigurationen kan anvendes, jvf behovs- og kravspecifikationen.	Funktionalitet Non-funktionalitet

For hver testtype tages der udgangspunkt i analysen af den specifikation, som testen skal designes og verificeres op imod. Herudfra defineres en række testbetingelser (overordnede forhold, der skal adresseres inden for den givne test), og disse testbetingelser nedbrydes og konkretiseres til test cases.

Der findes en række testteknikker, som bør bringes i anvendelse, afhængig af den konkrete kontekst og vurderede risiko.

Test på unit- og komponentintegrationstest-niveau

På unit-/komponentintegrationstestniveau anvendes en erfaringsbaseret tjekliste, som sikrer, at udvikling og test tager hånd om relevante aspekter af følgende:

• CRUD
• Ækvivalensklasser
• Grænseværdianalyse (også for invalide inputs)
• Positive og negative scenarier
• Beslutninger
• Testdata
• Review
• Risiko
• Fejlhåndtering

Test på systemtestniveau

På systemtestniveau anvendes overvejende følgende blackbox testteknikker, både enkeltvis og i kombination, alt efter behov og RPN:

Ækvivalenspartitionering
Anvendes som teknik, hvor vi kan identificere grupper af data, som forventes at være generelt repræsentative (ækvivalenspartitioner) for en komponents eller et systems opførsel. 'Gælder det for A, gælder det også for alle andre værdier'. Ækvivalenspartitionering kan anvendes for både positive og negative udfaldsrum. 

Grænseværdianalyse
Anvendes, hvor grænserne mellem ækvivalenspartitioner forventes at være i risiko for fejl, og der derfor skal være fokus på disse. Eksempelvis -1, 0 og 1, eller ved specifikke datoer:  før 1/1, på 1/1 og efter 1/1.

Beslutningstabeller
Anvendes, hvor specifikationen indeholder logiske betingelser, som kan omsættes til en tabel. Forretningsbetingelserne opstilles struktureret, og systemets forventede reaktion på disse betingelser tilføjes.

Tilstandsovergangstest
Anvendes, hvor specifikationen indeholder systemreaktioner på baggrund af klassers specifikke tilstande eller ændringer mellem tilstande. Denne teknik fokuserer på tilstande og overgange mellem tilstande.

Use case baseret test
Testdesign på baggrund af use cases, der definerer arbejdsprocesserne. Både hovedvejen og alternative veje danner grundlag for testdesignet.

Processcyklustest
En black-box testteknik, hvor testcases udvikles til at eksekvere forretningsprocedurer og processer.

Pairwise
Anvendes, når man tester software, hvori flere inputparametre (hver med flere mulige værdier) skal testes i kombination, og som leder til flere kombinationsmuligheder, end det giver mening at teste inden for den mulige tidsramme. 

Klassifikationstræ
Anvendes til at generere testcases til vigtige kombinationer (anvendes gerne sammen med ækvivalenspartitionering) uden at generere redundante eller umulige testcases. 

Test på accepttestniveau

Test på accepttestniveau er målrettet sikringen af, at de specificerede arbejdsgange for alle brugerroller kan gennemføres med det eller de nye IT-systemer. Derfor vil accepttests ofte være use case-baserede. På accepttestniveau skal løsningen desuden verificeres op imod kontraktens krav og vil derfor i sagens natur være kravsbaseret.

Use case baseret test
Testdesign på baggrund af use cases, der definerer arbejdsprocesserne. Både hovedvejen og alternative veje danner grundlag for test designet.

Der hersker ofte forvirring omkring begreberne tests og prøver, for hvad er i grunden forskellen. Det vil vi forsøge at forkare her. 

Kort forklaret er prøver kontraktuelle og ofte forbundet med en milepæl og betaling. En prøve skal sikre, at Leverandørens Leverancer og efterfølgende ydelser er uden fejl og mangler og opfylder de fastlagte Servicemål.

En prøve vil bestå af en eller flere tests/testtyper. En ”prøve” vil typisk være forbundet med en verificering af levering af en aftalt ydelse, altså typisk en afslutning på en afgrænset leverance. 

En test vil have til formål at finde eventuelle fejl i produktet.

På AU har vi beskrevet følgende relevante prøvetyper:

• Demonstrationsprøve
• Fabriksprøve
• Installationsprøve
• Installationsprøve (SaaS)
• Delleveranceprøve
• Overtagelsesprøve
• Driftsprøve

Alle eller en delmængde af disse sammensættes for en givet leverance i et prøveprogram. 

For at forstå forskellen på og sammenhængen imellem prøver og tests kan vi kigge på eksempelvis overtagelsesprøven, som typisk kan bestå af disse testtyper:

• User Acceptance Test (UAT)
• Brugervenlighedstest
• Systemintegrationstest
• Dokumentationstest
• Test af driftsparathed og non-funktionelle tests
• Test af migrering
• Evt. regressionstest hvis der har været tidligere leverancer

Mere om de forskellige prøvetyper og tilhørende testtyper

Linket herunder henviser til en powerpoint præsentation for et minikursus om test. 

Slides til minikursus om test

Begreberne i nedenstående liste er gengivet fra den internationale ISTQB’s terminologiliste (International Software Testing Qualifications Board). Er der tilføjet præciseringer i definitionsbeskrivelsen eller i eksempelbeskrivelsen, vil dette tydeligt fremgå.

Se i øvrigt DSTB´s side her for en samlet begrebsoversigt samt øvrige relevante materialer. 

Begreb (da)	Parent	Begreb (en)	Definition	Eksempler
Black box test		Black box test	En testmetode, hvor selve kildekoden ikke er kendt af tester. Der testes udelukkende efter inputs og outputs, da vi er ligeglade med, hvordan applikationen er bygget op. Bliver typisk brugt ved de højere testniveauer: accepttests og systemtests
Dynamisk test		Dynamic test	Ved en dynamisk test eksekveres selve koden, og der testes for et eller flere ønskede outputs i en række testcases. Dette kan både foregå manuelt eller automatisk.  Hovedfokus for en dynamisk test er at verificere, at softwaren virker i overensstemmelse med de opstillede krav. Dynamisk test handler om at finde og løse fejl	Dynamisk test teknikker: Unit testing Integrations testing System testing
Funktionel test		Functional test	Der testes for funktionaliteten – tit ud fra specifikationen af komponenten eller systemet
Ikke-funktionel test		Non-functional test	Test af egenskaber for en komponent eller system, der ikke direkte relaterer til funktionaliteten	Pålidelighed Effektivitet Brugervenlighed Sikkerhed
Integration		Integration	Den proces, det er, at kombinere komponenter eller systemer til større samlede enheder
Integrationstest	Testniveau	Integration testing	Test, der skal afsløre defekter (fejl) i grænsefladerne og samspillet mellem integrerede komponenter eller systemer	Komponentintegrationstest Systemintegrationstest
Komponent		Component	Den mindste softwareenhed, der kan testes i isolation
Komponent- integrationstest	Testniveau	Component integration testing	Test udført for at afsløre defekter i grænseflader og samspil mellem integrerede komponenter
Komponenttest	Testniveau	Component testing	Test af individuelle softwarekomponenter
Metrik		Metric	Metode og skala til måling [ISO 14598]
Regressionstest	Testniveau	Regression testing	Test af et tidligere testet program efter modificering for at sikre, at defekter (fejl) ikke er introduceret eller afdækket i uændrede dele af softwaren som følge af de gennemførte ændringer. Testen foretages, når software eller softwaremiljø er ændret
Review		Review	En evaluering af et produkt eller dokument der har til formål at klarlægge uoverensstemmelser fra det planlagte resultat, og derigennem anbefale forbedringer. Der findes flere forskellige former for reviews, der hver især har et specifikt formål
Risikoanalyse		Risk analysis	En analyse der foretages for at klarlægge risici i forbindelse med projektet, og vurdere deres effekt og sandsynlighed for at de forekommer
Statisk test		Static test	Test hvor selve koden undgås at eksekveres. Man søger derimod at finde fejl i dokumentation og kode ved hjælp af reviews og generel inspektion – man checker altså manuelt efter fejl (i både kode, men i den grad også indledende dokumentation, så som kravspecifikationer, designdokumenter osv.). Idéen med statisk test er at man meget hurtigt og tidligt i udviklingen kan forbedre kvaliteten af produktet. Statisk test handler om at forebygge fejl	Statisk test teknikker: Uformelle Reviews Tekniske Reviews Walkthrough Inspektion Static code review
System		System	En række komponenter, der er samlet for at udføre en specifik funktion eller sæt af funktioner [IEEE 610]
System-integrationstest	Testniveau	System integration testing	Test af integration af systemer og pakker, test af grænseflader til eksterne organisationer
Systemtest	Testniveau	System testing	Processen at teste et integreret system for at verificere, at det overholder specificerede krav
Test ansvarlig	Rolle	Test manager	Den person, der er ansvarlig for projektstyring af testaktiviteter og –ressourcer og evalueringen af et testobjekt. Den testansvarlig har ansvaret for at lede, kontrollere, administrere, planlægge og styre evalueringen af testobjektet
Testbase			Ses ikke
Testbetingelse	Test design	Test condition	Et objekt eller en hændelse i en komponent eller et system, der kan verificeres af en eller flere testcases	En funktion, transaktion, attribut
Testcase	Test design	Test case	Et sæt inputværdier, startbetingelser for afvikling, forventede resultater samt postbetingelser for afvikling, der er designet og beskrevet mhp et bestemt mål eller en bestemt testbetingelse	Testcase for aktivering af en bestemt programsti Testcase for verificering af overensstemmelse med et specifikt krav
Test design	Test design	Test design	Den proces, det er, at omdanne/nedbryde generelle testformål til konkrete testbetingelser og testcases
Testdesignteknik	Test design	Test design technique	Procedure anvendt til at udlede/vælge testcases i det rigtige omfang	Specifikationsbaseret Strukturbaseret Erfaringsbaseret
Testdækning
Testelement Bruger vi dette?		Test item	Det enkelte element, der er under test. Der er ofte et testobjekt, der består af flere testelementer
Testfase		Test phase	Se Testniveau
Testniveau	Testniveau	Test level	En gruppe af testaktiviteter, der er organiseret og styret samlet. Et testniveau har direkte forbindelse til et ansvarsområde i et projekt	Komponent test, integrationstest, systemtest, accepttest
Testproces		Test proces	Den grundlæggende testproces består af testplanlægning og –kontrol, testanalyse og –design, testimplementering og –afvikling, evaluering af slutkriterier og testlukning
Testprogram
Teststrategi	Testniveau	Test strategy	Høj-niveau beskrivelse af de testniveauer, der skal gennemføres, og test inden for disse niveauer	Kan være på flere niveauer (med nedarvning): På organisationsniveau På programniveau På projektniveau (På delprojektniveau?)
Teststyring		Test management	Planlægning, estimering, overvågning og kontrol af testaktiviteter, typisk udført af en testansvarlig
Testteknik			Se Test design teknik
Testtype	Test design	Test type	En samling testaktiviteter, der sigter mod at teste en komponent eller et system med fokus på et specifikt testformål. En testtype kan anvendes på et eller flere testniveauer/en eller flere testfaser	Funktionel test Non-funktionel test Brugervenlighedstest Gentest Regressionstest
White box test		White box test	Omvendt black box testing, er kildekoden ved white box testing kendt af tester. White box testing bliver som regel brugt til at verificere flowet af inputs og outputs i applikationen, og til at optimere programmet generelt. White box testing bliver typisk brugt ved de lavere testniveauer: unit tests og integrationstests.