Generisk teststrategi
Denne teststrategi er målrettet test i IT-implementeringsprojekter. Dvs et projekt, der skal realisere det ønskede IT-system.
Teststrategien har afhængigheder til og skal tilrettes efter AUs testpolitik og den test- og prøvestrategi, som er kontraktuelt aftalt med en leverandør i fbm systemanskaffelsen.
Teststrategien anvendes for alle udviklingsmodeller, både agilt orienterede, demand/supply-hybrid-modellen og de rene vandfaldsorienterede. Projektets konkrete tilgang vil fremgå af hovedtestplanen.
I strategiens afsnit vil der være henvisninger til konkrete modeller, metoder og guides.
Opgavetyper, testniveauer og testtyper
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 stubbes.
Opgavetyper
Afhængigt af kontekst kan en leverance bestå af en eller flere af følgende opgavetyper:
- Udvikling
- Integrationsudvikling
- Konfigurering
- Migrering
Da vi har et princip om at købe standardprodukter, er mængden af egenudvikling begrænset, så vægten ligger på de øvrige opgavetyper.
ISTQB testniveauer
Følgende testniveauer er beskrevet i ISTQB:
- Komponenttest (også kendt som unittest) fokuserer på isolerede testkomponenter. Det kræver ofte specifik understøttelse som f.eks. testharness eller bestemte framework for unittest. Komponenttest udføres af udviklerne i deres udviklingsmiljøer og og afvikles ideelt set, når kode flyttes fra et miljø til et andet.
- Komponentintegrationstest (også kendt som unitintegrationstest) fokuserer på test af brugergrænseflader og interaktioner mellem komponenter. Komponentintegrationstest udføres af udviklerne i deres udviklingsmiljøer og afvikles ideelt set, når kode flyttes fra et miljø til et andet.
- Systemtest fokuserer på hele systemet eller produktets overordnede adfærd og evner, ofte inkluderer det funktionelle test af end-to-end opgaver og den ikke-funktionelle test af kvalitetsegenskaber. Systemtest relaterer sig til systemets specifikationer og kan eventuelt udføres af et uafhængigt Testteam.
- Systemintegrationstest fokuserer på at teste systemets grænseflader og andre systemer og eksterne tjenester. Systemintegrationstest kræver passende testmiljøer, der helst skal minde om driftsmiljøet
- Accepttest fokuserer på validering og på at demonstrere klarhed til udrulning, hvilket betyder, at systemet lever op til brugernes forretningsbehov. Ideelt set bør accepttest udføres af de brugere, som systemet er beregnet til. De primære former for accepttest er: brugeraccepttest (UAT) og driftsmæssig accepttest.
ISTQB testtyper
ISTQB skelner mellem statiske og dynamiske testtyper. Disse er beskrevet herunder. Statisk test er test uden afvikling af kode, mens dynamisk test er test med afvikling af kode.
Statisk test
Der skelnes mellem disse to typer af statisk test i ISTQB:
Review tager udgangspunkt iikke-kørende kode , specifikation af proces, specifikation af systemarkitektur og andre arbejdsprodukter, som evalueres via manuel undersøgelse.
Statisk analyse kan identificere problemer tidligere end dynamisk test og kræver ofte en mindre indsats, da det ikke er nødvendigt med testcases. I stedet anvender man typisk værktøjer, som er indbygget i udvuklingsværktøjet. Statisk analyse kan både anvendes til at spore specifikke fejl i koden og til at evaluere vedligeholdelsesegnethed og sikkerhed.
Dynamisk test
Følgende dynamiske testtyper beskrives i ISTQB.
Funktionel test evaluerer de funktioner, som en komponent eller et system bør kunne udføre. Funktionerne henviser til de "ting”, som testobjektet skal kunne gøre. En funktionel test hovedmålsætning er at undersøge, om der er funktionel fuldstændighed, funktionel korrekthed og funktionel hensigtsmæssighed.
Ikke-funktionel test evaluerer andre attributter end en komponents eller systems funktionelle egenskaber. Ikke-funktionelle test tester, ”hvor godt et system opfører sig”. En ikke-funktionel test hovedmålsætning er at undersøge de ikke-funktionelle softwarekvalitetsegenskaber:
- Performanceeffektivitet
- Kompatibilitet
- Brugervenlighed
- Pålidelighed
- Sikkerhed
- Vedligeholdelsesegnethed
- Flytbarhed
De to testtyper kan anvendes på alle testniveauer, selvom fokus bliver forskelligt for hvert niveau. Forskellige testteknikker kan anvendes til at udlede testbetingelser og testcases for alle de nævnte testtyper.
Dertil kommer gentest, regressionstest og vedligeholdelsestest.
Testprocessen
Testprocessen omfatter alle aktiviteter i relation til test, altså både planlægnings- og styringsaktiviteter og aktiviteter som testanalyse og -design og testafvikling. I diagrammet nedenfor er testprocessen indplaceret i AU's projektmodel (de to øverste baner) og tilsvarende mappet til en hybrid udviklingsmodel (Hybrid/Scrum-boblerne). Den dokumentation, der laves i de enkelte dele af processen, ses i den nederste bane. Planen for testprocessen planlægges og vedligeholdes helt parallelt med projektplanen.
De enkelte dele af testprocessen gennemføres løbende for enhver testtype på ethvert testniveau - jvf den konkrete testplan - eller som en del af en agil udviklingsproces og dermed hovedsageligt iterativt i løbet af sprints.
Eventuelle afvigelser fra denne generiske testproces angives i projektets hovedtestplan.
Det er generelt god testpraksis og dermed ønskværdigt at efterstræbe en høj uafhængighed for testen. Der er dog visse forbehold, som gør, at det ikke altid er muligt på AU.
Agil kontekst
I en agil udviklingsproces er det svært at opnå samme høje uafhængighed, da de agile mindset netop insisterer på høj grad af inddragelse og dialog udvikler og tester imellem. Testen er en del af Scrum-teamets opgaver, og det er Scrum-temaet, der er ansvarlig for kvaliteten. Testeren er altså i tæt dialog med udvikleren og indgår i øvrigt i de samme afklarings- og planlægningsmøder, som det øvrige team. Testeren er i denne sammenhæng altså ”belastet af viden” om produktet, der skal testes. Dette er et vilkår, som accepteres, men som til gengæld har andre positive effekter: Testeren er med til at sikre, at krav er forståelige, klare, entydige, sammenhængende og testbare, inden udviklingsarbejdet starter op, fejl kan findes og korrigeres tidligt, og validering af produktet kan tilsvarende foretages så tidligt som muligt.
Komponent- og komponentintegrationstest
Testcases til komponent- og kompontentintegrationstestniveauerne designes og gennemføres overvejende som en del af udviklingsprocessen. På disse niveauer kan anvendes uformelle reviews af testobjekt og testresultat, men en udvikler vil ofte teste sin egen kode. Det betyder, at der på disse niveauer er en lav eller ingen adskillelse af ansvar mellem den, der har fremstillet testobjektet, og den, der tester testobjektet. Med udgangspunkt i vores risikobaserede tilgang til test, bør der derfor på risikofyldte områder foretages reviews af de unit- og integrationstest, som udviklerne laver. På den måde sikres høj kvalitet på de lavere testniveauer, hvilket giver det bedste grundlag for test på de højere niveauer (systemtest, accepttest).
Systemtest
Ved inddragelse af udpegede og uafhængige testere til test på systemniveau sikres en høj grad af adskillelse af ansvar. Heraf følger også en høj grad af objektivitet i testen. Der skal dog bemærkes, at det langt fra altid er en mulighed. Ofte vil systemtesten foretages af indenfor projektteamet. I så fald bør det afprøves, om AU forretning/AU brugere kan inddrages – enten i selve testafviklingen eller som reviewere af systemtestens testbetingelser og testcases.
Testorganisering, roller og ansvar
Den konkrete udmøntning af ressourcesikringen af nedenstående roller i projektet sker gennem hovedtestplanen og videre ud i de enkelte niveautestplaner.
I forbindelse med beskrivelsen af ansvar herunder er begrebet 'Sikring af' nævnt flere steder. Med begrebet menes, at den udpegede rolle har ansvaret for, at den udpegede aktivitet gennemføres, men vedkommende kan involvere andre roller eller ressourcepersoner i selve gennemførelsen.
| Rolle | Ansvar |
| Styregruppe | I forbindelse med det samlede projekt: Godkendelse af teststrategi Godkendelse af acceptkriterier for godkendelsen af det kommende produkts kvalitet Godkendelse af / iværksættelse af korrigerende handlinger på baggrund af testrapporteringer Godkendelse til produktion af det kommende produkt |
| Projektejer | I forbindelse med det samlede projekt: Sikring af, at behovs-/kravspecfikationen er review'et og godkendt af projektets interessenter Sikring af, at behovs-/kravspecfikationen er testbar og med definerede acceptkriterier Sikring af ressourcer til forretningsafklaringer og reviews af løsningsspecifikationer samt dynamisk test på alle testniveauer |
| Projektleder | I forbindelse med det samlede projekt: Projektlederen leder projektet og har derfor også ansvaret for at sikre test management i projektet. Sikring af acceptkriterier for godkendelsen af det kommende produkts kvalitet. Sikring af ressourcer til rollebesættelsen af testprocessens aktiviteter gennem projektforløbet. Sikring af kommunikationskanaler i projektet. Håndtering af problemer indenfor og udenfor projektet, som konstateres i forbindelse med testen, og som har afhængigheder til og indflydelse på testen (eksempelvis andre systemer eller processer). Sikre rapportering af test fremdrift, status, indstillinger og fejl til projektejer og styregruppe. Rettidig sikring af nødvendige testmiljøer og testdata. |
| Product Owner | I forbindelse med det samlede projekt/i sprint: Definition af, hvilke krav der skal opfyldes for at opnå produktets ønskede kvalitet, typisk i form af formulering af acceptkriterier for hvert PBI. Hjælpe med at prioritere testopgaverne ved at deltage i risikovurderingen af hvert enkelt PBI og med særligt fokus på den forretningsmæssige risiko. Besvare spørgsmål og sikre afklaringer fra Scrum teamet (herunder testeren), både under Backlog Refinement og undervejs i sprints. |
| Scrummaster | I forbindelse med sprint: Fjerne forhindringer - Scrum Master skal hjælpe med at fjerne eventuelle forhindringer, der kan hindre Scrum teamet (inkl. testeren) i at udføre deres testopgaver effektivt, herunder sørge for, at de har de nødvendige ressourcer og adgang til det nødvendige udstyr og software. Sikring af, at test og eventuelt tester er involveret i backlog refinement, sprint planning, sprint review og retrospektivmøder. |
| Scrum team | I forbindelse med sprint: Teamet er ansvarlige for at nå det sprintmål, der er sat i hvert sprint. Planlægning af testaktiviteter i sprintet og identifikation af de vigtigste testscenarier. Testafvikling og rapportering på testresultaterne - manuel test, automatiseret test eller en kombination. Planlægning og afvikling af test på tværs af teams, såfremt der er afhængigheder mellem teams leverancer. |
| Test manager | I forbindelse med det samlede projekt: Sikre fyldestgørende og tilstrækkelig test planlægges, designes og gennemføres. Sikre fyldestgørende og tilstrækkelig test på tværs af teams og på tværs af sprints i en agil kontekst, herunder regressionstest. Overordnet er det test managers opgave at planlægge, overvåge og kontrollere det samlede projekts test og testaktiviteter. Dette indbefatter følgende: Implementering af indeværende / udarbejdelse af projektspecifik teststrategi, dækkende såvel statisk som dynamisk test. Risikoanalyse af produkt med henblik på planlægning af testindsatsen. Testplaner Opfølgning på testaktiviteter, såvel statiske som dynamiske. Sikring af sporbarhed. Sikring af testdækning af krav, epics, userstories og risici. Sikring af sammenhæng mellem test strategien og øvrige testartefakter. Koordinering med evt. andre test managers i projektet (opgavestillers organisation og evt. leverandør). Koordinering med projektejer og forretning. Rapportering af test fremdrift, status og fejl til projektleder. Oprettelse, vedligehold, konfigurationsstyring og kontrol af den testrelaterede dokumentation for projektet. Testkoordinatoropgaver (hvis testkoordinatorrollen ikke er besat af en anden person - se rollebeskrivelse nedenfor). |
| Test koordinator | I forbindelse med den enkelte testtype: Styring og koordinering af de enkelte test gennemløb. Koordinering mellem involverede parter i den konkrete test (opgavestillers organisation, leverandør, afdelinger i AU IT, testere). Sikring af, at testere er godt forberedt på opgaven. Sikring af, at testdata er til rådighed. Sikring af, at testmiljøer er reserveret. Sikring af og opfølgning på fremdriften i de enkelte test gennemløb. Opsamling, screening og kommunikation af testobservation. |
| Tester | I forbindelse med den enkelte testtype/i sprints: Laver analyse af testgrundlag. Laver test case design. Angiver krav til testdata (typer og mængde). Afvikler tests, evaluerer resultater og laver hændelsesrapporter. Reviewer testcases, der er udviklet af andre. Holder en tæt dialog med test manager/test koordinator. |
| Teknisk tester | I forbindelse med den enkelte testtype/i sprints: Samme opgaver som Tester. Testautomatisering. |
Risikovurdering som grundlag for testplanlægning og -prioritering
Projektets samlede test planlægges, designes og prioriteres med udgangspunkt i produktrisikoanalyser (PRA). Det skal sikres, at i områder med størst risiko startes test så tidligt som muligt, og her testes med størst intensitet. Dette fordrer dog, at udviklingen af det mest risikofyldte starter tilsvarende tidligt, og risikoanalysen vil derfor i agilt setup være input til product owners prioritering.
Den risikobaserede test-tilgang anvendes altså til at bestemme hvor testen skal begynde, og hvor der er behov for en særlig høj testdækning. Der beregnes et risikotal for enhver risiko, og dette tal er afgørende for, hvor dybt og hvor højt prioriteret den tilhørende test skal være. De testmæssige konsekvenser af et givet risikotal er forhåndsdefineret og ses nedenfor. Styringsmæssige valg, der afviger fra dette, vil fremgå af projektets testplaner.
Vi arbejder med to niveauer af risikoanalyser i projekterne:
- Først gennemføres en overordnet PRA på epic-/feature-niveau - typisk en workshop med deltagelse af forretningsrepræsentanter, udviklere, testere, arkitekt og testmanager. Denne kan give input til den overordnede prioritering af epics. Dialogen omkring risici kan desuden bidrage til at skabe et fælles billede af opgaven.
- Løbende i sprints - typisk ved sprintplanning - gennemføres en letvægts risikoanalyse på de enkelte userstories i form af risikopoker (først konsekvens så sandsynlighed) eller ved hjælp af risikokvadranter, hvor en userstory placeres i kvadranter med konsekvens på den ene akse og sandsynlighed på den anden. Formålet er at planlægge og styre testindsatsen i løbet af sprintet - hvad er vigtigst at teste, hvad er mest kritisk.
Det er væsentligt, at risikovurderingen laves på alle de kvalitetsegenskaber, som projektets leverancer adresserer. Dvs. både de funktionelle og de non-funktionelle områder.
Herunder ses en matrix over risikoprofiler, som er tilføjet farvekoder for omfanget og dybden af den test, der skal planlægges i forlængelse heraf. 1 er lavest konsekvens/sandsynlighed, 5 er højest.
Risikoprofil matrix
Risk Priority Number (RPN)
| Konsekvens (effekt) | |||||
|---|---|---|---|---|---|
| Sandsynlighed | 1 | 2 | 3 | 4 | 5 |
| 2 | 4 | 6 | 8 | 10 | |
| 3 | 6 | 9 | 12 | 15 | |
| 4 | 8 | 12 | 16 | 20 | |
| 5 | 10 | 15 | 20 | 25 | |
RPN og testdybde
| RPN | Testdybde | Udmøntning af testdybde |
|---|---|---|---|
Højt RPN (15-25) ELLER Sandsynlighed = 5 ELLER | Testdybde *** |
| |
Middel RPN (8-12) ELLER | Testdybde ** |
| |
Lille RPN (1-6) | Testdybde * |
|
Test dokumentation
Den test dokumentation (artefakter), som produceres i et IT-projekt tjener flere formål. Der er således dokumenter til:
- styring af projektets testaktiviteter (strategi og planer)
- fyldestgørende test case design (test management tool)
- fyldestgørende fejlrapportering i fbm test afvikling
- testrapportering
Herunder ses dokumentationsartefakterne fra diagrammet ovenfor - men henført til det styringsniveau, de hører hjemme på. Indeværende teststrategi er hjemhørende på strategisk niveau for IT-projekter.
Forvaltningssporet er tilføjet i oversigten. Det skyldes, at IT-projektet i forbindelse med projektafslutning overdrager det nye produkt til den forvaltning, der skal bære det videre.
Beslutninger om den kommende forvaltning er dokumenteret i en godkendt systemforvaltningsaftale. Det er således også i systemforvaltningsaftalen, at beslutninger om, hvorledes test af systemændringer skal foregå. En sådan beskrivelse udmøntes i en generisk teststrategi, som vil ligge til grund for planlægningen og design af den enkelte test i forbindelse med kommende ændringer af det nye produkt.
Projektets teststrategi
Ansvar for udarbejdelse: Test manager
Ansvar for godkendelse: Projektets styregruppe
Skabelon for Teststrategi for projekter
Projektets teststrategi beskriver den generelle ramme for testen inden for projektet. Det udgør det fælles grundlag og giver en fælles forståelse af test hos projektets interessenter.
Indeværende teststrategi er generisk på organisationsniveau og er målrettet alle IT-projekter. Det betyder, at den udmønter organisationens tilgang til test i IT-projekter. Denne teststrategi kan umiddelbart anvendes af IT-projekter og danne grundlag for udarbejdelsen af testplaner.
Projektets hovedtestplan
Ansvar for udarbejdelse: Test manager
Ansvar for godkendelse: Projektleder
Hovedtestplanen har til formål at udmønte projektets teststrategi i det konkrete projekt. Den konkretiserer således fremgangsmåden, aktiviteterne inklusive deres relationer og afhængigheder og de arbejdsprodukter, som processen skal levere. Der er en klar, rød tråd fra teststrategien til de niveauer af tests, der specificeres og afvikles. Den videre uddybning af aktiviteter og arbejdsprodukter sker i et antal niveautestplaner, som alle er i overensstemmelse med hovedtestplanen.
Hovedtestplanens indhold afhænger selvfølgelig helt af det konkrete projekt, og derfor vil ikke alle elementer i skabelonen være relevante altid, ligesom der også vil kunne være behov for specifikke tilføjelser. Det er derfor Test Managers ansvar at lave en målrettet hovedtestplan til projektet.
Er der afvigelser fra hovedtestplanen til den eller de enkelte niveautestplaner, fremgår dette klart af niveautestplanerne.
Projektets niveautestplaner
Ansvar for udarbejdelse: Test manager
En niveautestplan beskriver og udgør planlægnings- og styringsgrundlaget for de specifikke aktiviteter, der skal udføres inden for den konkrete testtype på et konkret testniveau. Den udvider således hovedtestplanen, hvor det er nødvendigt, ved at udfolde detaljerede informationer om planlægning, opgaver og milepæle, eller behov for miljøer og data, der ikke nødvendigvis er dækket af hovedtestplanen.
Det skal anføres, at scopet for en niveautestplan kan have andre typer af afgrænsninger end specifikt testniveau. Dette vil afhænge af det konkrete projekt/den konkrete udviklingsopgave. Består opgaven i at udvikle tre integrationsservices, giver det god mening at lave en specifik testplan pr service.
Ved mindre udviklingsopgaver i forvaltningen kan det tænkes, at niveautestplanen er den eneste, der udarbejdes, og at denne vil være fuldt tilstrækkelig til styring af testforløbet.
Projektets test cases
Ansvar for udarbejdelse: Tester
Skabelon for Testcase
En testcase er en formaliseret og helt konkret beskrivelse af, hvorledes en specifik og afgrænset testaktivitet planlægges gennemført. Testcasen indeholder som minimum:
- Testcase-titel
- Testcase ID
- Metadata om testcasen (udarbejdet af, oprettelsesdato, status, etc.)
- Formål
- Forudsætninger for at kunne afvikle testcasen
- Reference til testgrundlag
- Reference til testbetingelse (hvis den findes)
- Prioritet
- Sammenhæng til andre testcases
- Nødvendigt testdata
- Trin i testcasen: Input og forventet resultat
Testcases oprettes til både manuelle og automatiserede tests.
Projektets fejlrapporter
Ansvar for udarbejdelse: Tester
Skabelon for Fejlrapport
Når det forventede og det faktiske resultat i afviklingen af en test case ikke stemmer overens, er det nødvendigt at undersøge afvigelsen for at afgøre, om der er tale om en fejl eller ej. En sådan hændelse kan bunde i misforståelser under testafvikling, misforståelse i test casen eller i testdata.
Når der er konstateret en afvigelse, som forventeligt skyldes en fejl i kode, oprettes en fejlrapport som klart beskriver den konstaterede afvigelse. Man kan også vælge at rapportere alle afvigelser, fundet under testen, for først derefter at foretage de nødvendige undersøgelser. Det er en afvejning i det enkelte projekt/den enkelte udviklingsopgave og i den enkelte test.
Testrapporter pr test
Ansvar for udarbejdelse: Test manager
Skabelon for testrapport
I forbindelse med afviklingen af enhver test type på et ethvert test niveau rapporteres på testens resultater. I agil kontekst kan testrapportering i løbet af sprintet med fordel laves via dashboards. På baggrund af testrapporten kan der træffes beslutning om GO/NOGO til "next step" på oplyst og kvalificeret baggrund. Hvis testen har påvist kvalitetsproblemer, vil det afspejles i testrapporten, og der kan iværksættes de nødvendige tiltag for at højne kvaliteten og dermed mindske risikoen for fejl i produktion. Hvis testen omvendt ikke har påvist kvalitetsproblemer, kan der gives GO til at gå videre til næste testniveau (eller til release til produktionsklargøring). Testrapporten samler op på den afviklede test og skal ses i sammenhæng med den samhørende testplan. Testrapporten dokumenterer således resultatet af den planlagte og afviklede test.
Testrapportering er langt overvejende maskinelt funderet, visuel og baseret på metrikker, der er besluttet og indarbejdet fra start i testprojektet.
Projektets afsluttende testrapport
Ansvar for udarbejdelse: Test manager
Skabelon for Testafslutningsrapport
I forbindelse med projektafslutningen eller afslutningen af testprojektet rapporteres på den samlede tests resultater. På baggrund af testrapporten kan der træffes beslutning om GO/NOGO til produktionsigangsætning på oplyst og kvalificeret baggrund. Hvis testen har påvist kvalitetsproblemer vil der være objektiv vidnesbyrd for at træffe korrigerende/mitigerende handlinger og dermed mindske risikoen for fejl i produktion. Testrapporten samler op på den afviklede test og skal ses i sammenhæng med den samhørende testplan. Testrapporten dokumenterer således resultatet af den planlagte og afviklede test.
En stor del af den afsluttende testrapport maskinelt funderet, visuel og baseret på metrikker, der er besluttet og indarbejdet fra start i testprojektet.
Konfigurationsstyring af testdokumentation
Test manager har ansvaret for at oprette, vedligeholde og kontrollere den testrelaterede dokumentation for projektet. Dokumentationen opbevares centralt og tilgængeligt for hele projektet.
Testteknikker
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å komponent- og komponentintegrationstest-niveau
- CRUD
- Ækvivalensklasser
- Grænseværdianalyse (også for invalide inputs)
- Positive og negative scenarier
- Beslutninger
- Testdata
- Review
- Risiko
- Fejlhåndtering
Test på systemtestniveau
- Ækvivalenspartitionering
- Grænseværdianalyse
- Beslutningstabeller
- Tilstandsovergangstest
- Use case baseret test
- Processcyklustest
- Pairwise
- Klassifikationstræ
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
- Kravbaseret test
Testmiljøer og testdata
Nedenstående beskrivelse adresserer den strategiske tilgang til testmiljøer og testdata. Den skal betragtes som værende generisk. Beslutninger om faktisk nødvendige testmiljøer og testdata til de identificerede testtyper vil fremgå af projektets hovedtestplan.
Testmiljøer
Afkoblede og isolerede tests bruges i videst mulige omfang. Det er afgørende, at testprojektet definerer og beskriver hver eneste anvendte testtype og angiver lige-præcis-tilstrækkeligt behov for miljøer og data til at gennemføre pågældende testtype. Oversigt over testtyper, deres behov for miljøer og data, testmiljøets bestykning samt tidspunkt for, hvornår testmiljø og testdata skal være tilgængeligt, skal fremgå af projekts hovedtestplan.
I forbindelse med testaktiviteter generelt er der identificeret behov for flere sammenhængende testmiljøer, der spejler/repræsenterer systemer og integreret data i produktion. Behovet er, at disse miljøer er stabile og drives på en måde, der sikrer, at testdata og systemer ikke forstyrres eller ødelægges under testprocessen for samtidige og parallelle tests.
Det er endnu ikke teknisk muligt at udvikle og implementere så omfattende testmiljøer i AU..Store tværgående og sammenhængende tests på systemniveau og derover, afvikles i det ene fælles integrationstestmiljø, som AU for indeværende råder over. Teststrategien angiver derfor, at projekter alene anvender de relevante dele af dette store, integrerede testmiljø til test på systemniveau. Dette giver mulighed for, at andre projekter eller opgaver kan arbejde i andre dele af testmiljøet. Projektet udpeger derfor de berørte systemer og anvender drivers, stubbe og mocks så langt som muligt.
Specielt om det integrerede testmiljø
Reservation af det integrerede testmiljø og testdata til specifikke tests på systemniveau koordineres for indeværende med andre projekter og systemer og registreres i testkalendere efter retningslinjerne beskrevet i Reservation af testmiljøer.
Vellykket koordinering med andre projekter og produkter kræver streng tids- og testdatastyring med det enkelte projekts leveringsplan og testplan.
Adgang til testmiljøer og dermed til personoplysninger og følsomme testdata styres i henhold til samme praksis som adgang til produktionsmiljø og produktionsdata. Denne praksis er AUs sikkerhedspolitik.
Om testniveauer og miljøer
KomponenttestDenne test køres af udviklere i det lokale udviklingsmiljø. Drivere / stubs / mocks bruges til udskiftning af kaldte komponenter. Eventuelle data fra andre systemer indlæses fra kopitabeller.
Komponentintegrationstest
Denne sammenhængende test af integrerede komponenter/units køres af udviklere i udviklingsmiljøet. Drivere/stubbe bruges fortsat til simulering af endnu ikke udviklede/klargjorte komponenter.
Systemtest
Dette testniveau dækker den fuldt integrerede test (alle komponenter, alle systemer og grænseflader). Der kan være mange testtyper på dette niveau, nogle af dem kan anvende drivere, stubs/mocks. Testtyper på dette testniveau afvikles i det integrerede testmiljø, såfremt der testes med integrationer til andre AU-systemer.
Accepttest
Accepttests afvikles i det integrerede testmiljø, såfremt der testes med integrationer til andre AU-systemer.
Testdata
Testdata i det integrerede testmiljø er et spejl af produktionsdata fra en given repopuleringsdato. De enkelte systemers testmiljøer er sammenkoblet, det kan dog være opgraderet asynkront og efter aftale. Kompleksiteten af disse opgraderinger er meget forskellig. Fuld datasammenhæng om personer kræver den mest komplekse og tidskrævende opgradering, og denne har brug for tre ugers kalendertid og tildeling af ressourcer.
Pr. december 2023 fandt seneste repopulering sted i februar 2019.
For at imødekomme de underliggende grundlæggende krav til testdata inden for den tidsramme, der er nødvendig for at teste projekter, indtil infrastrukturen kan imødekomme behovet for flere integrerede testmiljøer / testdata, der kan rulles tilbage eller blive indlæst på ny, vil de eksisterende testmiljøer derfor blive opgraderet til produktionsversion af funktioner og repopuleret med data fra produktionsmiljøet, når og hvor det er nødvendigt, finansieret og aftalt med systemejerne. Systemejere kræver data til systemtest, som er realistiske og tilstrækkelige og så tæt på de daglige aktiviteter som muligt i kvalitet og kvantitet.
Det er for indeværende ikke muligt at tilbageføre testdata til gentest, hvor det er nødvendigt. Den taktiske løsning på dette er at identificere et større antal forekomster af testdata end nødvendigt for en enkelt testafvikling, så nye forekomster allerede er identificeret til gentest.
Fremgangsmåden til identifikation af testdata består af to trin: For det første en beskrivelse af testdataprincipper (typer og egenskaber, der skal dækkes), og for det andet (baseret på disse principper) identifikation og registrering af de konkrete testdata.
Principper for identifikation af testdata opbevares efter projektets afslutning for at blive brugt i den efterfølgende forvaltning.
Værktøjer til test og testmanagement
Projekter anvender værktøjer til både testafvikling (automatisering) og til styring af testen.
Azure Test Plans anvendes til test management på systemtestniveau og derover. Her oprettes og styres test cases, og her registreres resultatet af eksekveringen af den enkelte test case. Evt tilhørende fejlrapporter oprettes i Azure Devops med workitem-typen Bug. I værktøjet sikrer fremgangsmåden forbindelsen fra test casen til den eller de tilknyttede fejlrapporter - bl.a. til brug for måling af produktkvaliteten.
Azure Test Plans giver mulighed for sikre forbindelsen mellem eksempelvis krav/user story, test objekt, test type og test case. Dette giver input til metrikker, der anvendes til måling af bl.a. testdækning.
Bugs håndteres på samme måde som øvrige issues/work items i projektet - de kan eksempelvis kvalificeres bl.a. med en prioritet, tildeles en ansvarlig og ændre status til brug for opfølgning.
Testautomatisering
Testautomatisering sikres i videst muligt omfang og er en integreret del af testplanlægningen for alle projekter med nyudvikling, uanset den valgte udviklingsmodel. Dette for at sikre opbygningen af en effektiv og nyttig regressionstest, og projektet skal således oprette og vedligeholde en automatiseret regressionstestsuite og ved projektafslutning overdrage denne til forvaltning.
Ikke al test i alle testtyper og på alle testniveauer skal og kan automatiseres. Det er således de testtyper, som udviklerne gennemfører, som er målet for testautomatiseringen. Er der mulighed for implementering af testautomatisering for andre testtyper og på andre testniveauer, fremgår dette af projektets hovedtestplan.
Testautomatisering implementeres således på unit- og komponentintegrationsniveauerne i fbm med al nyudvikling, og det tilstræbes implementeret ved ændringer og videreudvikling. Det betyder, at projektleder og test manager skal sikre, at tid til udvikling, løbende opfølgning og vedligehold af testautomatisering inkluderes i udviklings- og testestimater.
AU IT råder over en række testautomatiseringsværktøjer, som hver især retter sig mod bestemte teknologier og udviklingsplatforme.
De konkrete værktøjer, som det enkelte projekt anvender, udpeges i projektets hovedtestplan.
Testmetrikker og testrapportering
For at sikre korrekt og tilstrækkelig indsigt i kvaliteten af både testprocessen og produktet under test samt i projektets testfremdrift, aftales de metrikker, der opsamler relevante målinger. Metrikkerne er et redskab til både test manager og projektleder.
Det afklares i projektet, hvilke af nedenstående metrikker eller evt. andre, der skal iværksættes, og hvorledes målingerne foretages. Det afklares ligeledes, hvordan resultatet af målingerne rapporteres. Der rapporteres på den enkelte test, på den enkelte release (hvis anvendelig) og på projektniveau. De anvendte metrikker angives i projektets hovedtestplan.
Nedenstående metrikker er mulige, og test manager udvælger og implementerer dem, der understøtter den testrapportering, der er aftalt med hhv. projektleder og styregruppe.
HVILKE METRIKKER KAN SYSTEMUNDERSTØTTES I AZURE!
- Antal testcases
- Testcase design fremdrift
- Testafviklingsstatus (antal planlagte/ikke-afviklede/passed/failed/skipped/blocked testcases)
- Testafviklingsfremdrift pr. testtype
- Testdækning pr. test objekt
- Testdækning pr. produktrisiko
- Kapacitet - testplanlægning og opfølgning
- Kapacitet - testafvikling
- Antal fejl
- Antal fejl over tid
- Antal fejl pr. alvorsgrad og pr. status
- Antal fejl i hver testfase (faseomslutning)
- Antal afviste fejl
- Antal fejl fundet under AU ITs interne statiske test (review)
- Antal fejl fundet under AU ITs interne dynamiske test i udviklingsprocessen
- Antal fejl pr. komponent/test objekt
- Gennemsnitslig alder for fejl
Proces for fejlhåndtering
Fejlhåndteringsprocessen sikrer, at fejl håndteres struktureret, prioriteret og konsistent. Processen angiver, hvem der er ansvarlig for de forskellige faser i fejlens livscyklus. Der er tale om en generisk proces, der er fælles for alle testaktiviteter på systemtest-, systemintegrationstest- og accepttestniveau, medmindre andet er angivet i specifikke testplaner.
Fejl, der konstateres af udviklerne under softwareudvikling (unit- og komponentintegrationsniveauerne), håndteres ikke inden for denne formelle proces. Disse fejl løses undervejs i udviklingen.
Større eller mere komplekse fejl og mangler på systemtest-, systemintegrationstest- og accepttestniveau håndteres i Azure Devops/Azure Test Plans. Observationerne rapporteres i Azure Devops med workitem-typen ”Bug”. Der er udarbejdet en skabelon i Azure Devops til registrering af fejl for at sikre, at alle nødvendige data rapporteres. Dette inkluderer:
- Test objekt
- Fejlkategori
- Detaljeret beskrivelse af fejlen
- Skridt til at reproducere fejlen
- Test miljø
- Testtype
- Produktversion
- Opdaget af
- Opdaget hvornår
- Skærmbilleder, hvis relevant
- Andre parametre, om nødvendigt.
Processen
Det første trin i fejlens livscyklus er at evaluere, om den konstaterede fejl faktisk er en fejl eller ej. En fejl kan være forårsaget af fejlagtige testdata, vildledende eller fejlagtig testcase, fejl i testmiljøet eller simpelthen misforståelser. Inden oprettelsen af fejlrapport, vil testeren typisk have undersøgt og udelukket disse mulige årsager, og antagelsen er derfor, at der faktisk er tale om en fejl.
Testeren sætter som udgangspunkt en prioritet, men det er testmanager ansvar at sikre (evt. sammen med systemejers repræsentant/PO), at der tages beslutning om, hvorvidt fejlen skal afhjælpes og med hvilken prioritet.
Test manager er ansvarlig for den første screening af fejlrapporter for dubletter og for tilstrækkelig beskrivelse samt for kommunikationen med udviklerne. Test manageren sikrer prioritering samt beslutning om fejlretning ved systemejer eller PO. Om nødvendigt kan test manager involvere et fejlhåndterings-udvalg, der er oprettet til en testafvikling til at evaluere, prioritere, estimere og dispatche fejlrapporterne. Dette udvalg vil bestå af systemejer/PO og relevante repræsentanter fra udvikling og test. Under end-to-end test vil tekniske repræsentanter fra en eventuel leverandør også være relevante deltagere i dette udvalg. Ved fejl fundet i sprint kan prioritering antages at følge user storyens prioritering.
Resultatet af test managerens eller udvalgets screening er et af tre:
- Fejlrapporten afvises, og fejlen bør ikke rettes
- Fejlen er klar til at blive rettet, og den prioriteres
- Det er nødvendigt med flere oplysninger/analyser for at beslutte den rigtige prioritet.
Afviste fejlrapporter returneres til tester med en kommentar, der forklarer, hvorfor fejlen er blevet afvist. Man skal anvende JIRA-feltet Resolution (not a bug, wont fix, dublicate, obsolette mm) eller Azure Devops-feltet Reason (As Designed, Cannot Reproduce, Deferred, Duplicate, Obsolete, Will not Fix). Derved sikres, at man nemt kan lave opsamling på afviste fejl. Fejl, der skal rettes, og fejlrapporter, der kræver mere analyse, tildeles enten AU-udviklingsteamet eller en eventuel leverandør. Projektleder eller test manager er ansvarlig for at tildele fejl til leverandøren.
Udviklingsteams'ene (AU eller leverandør) kan derefter:
- Gennemføre den tekniske analyse for at kunne estimere rettelsen og derefter returnere fejlen til systemejer (via test manager) til ny prioritering (ved komplekse fejl)
- Gennemføre rettelsen efter planen (nu eller senere) (ved simple fejl).
Når en fejl er rettet, og rettelsen er blevet lagt på det aftalte miljø, tildeler test manger eller udvikleren den rettede fejlrapport til tester, så denne kan verificere, at fejlen ikke længere kan reproduceres. Hvis dette er tilfældet, lukkes fejlrapporten. Hvis verifikationen ikke bekræfter rettelsen, returneres fejlrapporten til udvikling - eventuelt via test manager - med en ny kommentar.
Fejls alvorsgrad
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.
Vi har 5 alvorsgrader. Hver fejl klassificeres i henhold til nedenstående oversigt. Den initielle klassificering foretages af testen, der rapporterer fejl - og den kan ændres i løbet af fejlhåndteringsprocessen, da fejlanalysen vil gøre os klogere.
Klassificering af fejl ift alvorsgrad kan også være et nyttigt værktøj til at definere acceptkriterier for en given test. F.eks. kan ét blandt flere acceptkriterier ift produktionsigangsætning være, at "der ikke må være udestående blokerende eller kritiske fejl". I forhold til prøver vil fejlkategorisering og SLA være defineret i kontrakten.
Alvorsgrad | Definition | |
|---|---|---|
| 5 | Blokerende | En blokerende fejl forhindrer videre test, og testen vil blive suspenderet. |
| 4 | Kritisk | En kritisk fejl forårsager, at systemet går ned og ikke kan bruges. Forretningskritiske funktioner kan ikke udføres, og det er ikke muligt at få dem igang. Kritisk ift systemets tilgængelighed, testresultater, funktionalitet, ydeevne, sikkerhed eller brugervenlighed. |
| 3 | Major | En major fejl sætter en kritisk funktion i systemet ud af spillet og forårsager alvorligt tab af service. Det kunne være en fejl i en beregning. Fejlen kan ikke afhjælpes ved en work-around, og brugeren kan ikke komme videre med sin konkrete opgave |
| 2 | Normal | En normal fejl sætter en mindre kritisk funktion i systemet ud af spillet og forårsager mindre servicetab, men der kan laves en work-around på den korte bane. En fejl med mellemstore forretningspåvirkninger, men den kan godt påvirke mange brugere. |
| 1 | Minor | En minor fejl har lille eller ingen praktisk indvirkning, og der er en simpel work-around, hvis nødvendigt. 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. |
Klassificering af fejl
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. Klassificeringen skal altid følge kontraktens definitioner.
Alvorsgrad og acceptkriterier
Klassificering af fejl ift alvorsgrad kan være et nyttigt værktøj til at definere acceptkriterier for en given test. F.eks. kan ét blandt flere acceptkriterier ift produktionsigangsætning være, at "der ikke må være udestående blokerende eller kritiske fejl". I forhold til prøver vil fejlkategorisering og SLA være defineret i kontrakten.
Regressionstest og gentest
Der skal løbende afvikles regressionstest undervejs i projektet, så det sikres, at det, der tidligere er meldt klar, fortsat virker, når der tilføjes, ændres eller fjernes funktionalitet eller andre komponenter i softwaren. Regressionstesten bør på de laveste testniveauer så vidt muligt automatiseres, så de nemt og hurtigt kan afvikles og skabe sikkerhed for produktets grundlæggende stabilitet.
Regressionstesten på systemtestniveau bør om muligt også automatiseres. Det er vigtigt at gøre sig klart, at selv om en automatiseret regressionstest sparer tid til afvikling af testcases, så skal der omvendt bruges tid til både opfølgning og vedligehold. Der bør derfor sikres ressourcer i form af de rette kompetencer, tid og økonomi til dette arbejde i projektet.
Hovedtestplanen skal udfolde de specifikke kriterier i det konkrete projekts behov for regressionstest, og dette bør indgå som en del af projektets testproces.
Gentest anvendes efter fejlrettelse for at sikre, at den identificerede fejl er udbedret. Det er vigtig hver gang at vurdere behovet for regressionstest efter fejlrettelser for at sikre, at den nye/ændrede kode ikke har afstedkommet nye fejl i ikke-berørte dele af systemet.
Hovedtestplanen skal udfolde det konkrete projekts specifikke proces for gentest, herunder hvem, der udfører gentesten, og hvornår en gentest udføres.
Godkendelse af projektets strategi
Som beskrevet indledningsvist, er strategien her generisk og danner grundlag for testplanlægning i det enkelte implementeringsprojekt. Der er ikke tale om en generel og gældende AU-teststrategi, og det betyder, at godkendelse af teststrategien skal ske på det enkelte projekt.
Det er således projektets Test Managers ansvar at sikre, at projektets teststrategi formelt godkendes af både styregruppe og projektleder.