En guide til regressionstest for softwarekvalitetssikring

Regressionstestning er en af de vigtigste testtyper i ethvert softwareudviklingsprojekt. På et meget overordnet niveau er målet at bekræfte, at nye udviklinger ikke har introduceret fejl eller mangler i områder, der tidligere fungerede.

Gennem mit arbejde med forskellige projekter inden for forskellige forretningsområder har jeg lært, at hvert team har sine egne processer til udførelse af regressionstestning af software. Der er dog nogle fælles punkter, som alle vellykkede testprojekter deler.

Denne guide giver dig den viden, du skal bruge for at mestre regressionstestning. Den udforsker arsenalet af effektive værktøjer til regressionstestning for at strømline processen og sikre et problemfrit udviklingsworkflow. Jeg deler de erfaringer, jeg gjorde mig undervejs.

Hvad er regressionstestning i softwareudvikling?

Det er relativt normalt, at der opstår nye fejl og/eller dukker tidligere problemer op igen, når software opdateres, ændres eller genbruges på et modificeret mål. 

For at sikre, at disse fejl opdages, før softwareopdateringerne udgives til produktion, bør QA-teamet fokusere på at finde dem i tide – og det er her, regressionstestning kommer ind i billedet.

Regressionstestning er en testtype, hvor funktionaliteten af softwareapplikationens allerede eksisterende funktioner bekræftes. Regressionstestning udføres efter hver ændring eller opdatering af koden for at sikre, at de eksisterende funktionaliteter fungerer som tilsigtet uden revisioner eller tilføjelser. Afhængigt af projektets omfang kan der anvendes enten manuel eller automatiseret regressionstestning.

Hvornår bør du bruge regressionstestning?

Når der tilføjes nye funktioner eller forbedringer til en eksisterende kodebase eller applikation, er regressionstestning nødvendig. Det garanterer, at alle tilføjede funktioner eller opdateringer af en eksisterende applikation fungerer fejlfrit og uden fejl. Der er stor sandsynlighed for problemer med inkompatibel kode, fordi udviklere og testere ofte har svært ved at følge alle kodens tråde. Derfor gør kørsel af regressionstest på deres software (eller applikation) det muligt for dem at finde fejl tidligere og udgive software med færre risici.

Hver gang en implementering tager længere tid end forventet, kan regressionstestning anvendes. I dette scenarie skal testeren udføre regressionstest hver dag. Ved ugentlige udgivelser er det desuden at foretrække at udføre regressionstestning efter funktionel testning.

Automatiseret regressionstestning

Regressionstestbiblioteket udvides, efterhånden som teamet tilføjer softwarefunktioner. Regressionstestpakken kan med tiden vokse til en sådan størrelse, at det bliver umuligt at køre testene manuelt inden for de begrænsede Agile-sprintcyklusser.

Regressionstestning egner sig bedst til automatisering, fordi den skal kunne gentages og udføres tilbagevendende. Før hver udgivelse kan du udføre en grundig regressionstest, og du kan udvikle mindre og hurtigere testpakker med feedback for at kontrollere, om der er opstået regressioner efter kodeændringer (hotfixes). Opdag softwaretestværktøjer, der er særligt effektive til regressionstestscenarier.

Hvornår skal regressionstestning udføres?

Regressionstestning er nødvendig, hver gang der tilføjes nye funktioner eller forbedringer til en eksisterende kodebase eller applikation. Det garanterer, at alle tilføjede funktioner eller opdateringer af en eksisterende applikation fungerer fejlfrit og uden fejl. Der er stor sandsynlighed for problemer med inkompatibel kode, fordi udviklere og testere ofte har svært ved at følge alle kodens tråde. Derfor gør kørsel af regressionstest på deres software (eller applikation) det muligt for dem at finde fejl tidligere og udgive software med færre risici.

Manuel regressionstestning skal udføres, hvis testautomatisering ikke er integreret med byggesystemet, og/eller automatiserede testkørsler ikke er planlagt regelmæssigt. Er det så nødvendigt at gå tilbage og kontrollere enhver kodeændring? Nej, er svaret.

Regressionstestning er kun nødvendig, når en kodeændring påvirker andre dele af produktet. For at fastslå dette skal man undersøge, hvordan det ændrede modul interagerer med andre produktmoduler.

Det meste af tiden er de udviklere, der foretager ændringer, klar over de potentielle effekter på andre moduler og hele produktets adfærd, og de bør anmode om regressionstestning efter behov.

Hvem er ansvarlig for regressionstestning?

Efter at funktionel testning er afsluttet, udføres regressionstestning for at kontrollere, at alle andre funktionaliteter fungerer. Det er normalt QA-teamets ansvar. Nye testere, som ikke har testet funktionen før, men som kan udføre dokumenterede testcases, kan også inddrages i regressionstestprocessen. I disse tilfælde bør regressionstestcasene være skrevet korrekt, så selv en ny person på teamet kan følge dem. 

Testere, som måske ikke tidligere har udført de funktionelle tests, men som har god erfaring med at arbejde med de funktioner, der skal testes, har også gode muligheder for at finde alvorlige fejl, hvis der er blevet introduceret nogen.

Hvordan ved du, hvornår regressionstestningen er afsluttet?

Du skal finde en fin balance mellem det, du har tid og ressourcer til at dække som en del af regressionstestningen, og den risiko, teamet kan påtage sig.

Her er nogle ting, som testteamet kan tage i betragtning, når risikoen estimeres:

• Hvis en funktion bruges intensivt af softwarens brugere, bør den prioriteres i planen for regressionstestning.
• Tekniske områder af produktet, der tidligere har vist sig at være stabile og har været kendt for at generere gode testrapporter, er mindre risikable, så softwaretesterne kan vælge ikke at inkludere dem som en del af regressionstestningen.
• Analyse af tidligere rapporterede fejl fra kunder eller det interne QA-team kan hjælpe med at identificere svagere områder i appen, hvor regressionstestningen bør fokusere.
• Hvis fejl har været åbne i lang tid uden at blive rettet, har de kun lille indvirkning på brugernes arbejdsgange, og brugerne har fundet løsninger på dem.

Teknikker til regressionstestning

De vigtigste teknikker, der bruges ved regressionstestning, er: 

• Fuld regressionstestning, også kaldet gentestning af alt
• Udvælgelse af regressionstest
• Prioritering af testcases

Fuld regressionstestning

Ved denne metode anvendes regressionstestning på alle aktive testsuiter. Selvom denne tilgang kræver meget tid og mange ressourcer, er det den sikreste teknik til at garantere, at alle fejl bliver fundet og rettet, fordi den har den højeste testdækning.

Derfor er der specifikke situationer, hvor strategien med fuld regressionstestning fungerer bedre end andre, f.eks. når applikationen ændres til en ny platform eller et nyt sprog, eller når operativsystemet modtager en større opdatering.

Testudvælgelse (eller delvis regressionstestning)

Denne teknik indebærer, at testcases udvælges fra testsuiten for at blive kørt igen. Udvælgelsen af testcases er baseret på kodeændringerne i modulet.

Prioritering af testcases 

Når du bruger denne tilgang, kan du prioritere testcases med den højeste prioritet, så de udføres først i regressionstestprocessen. Disse er også gode kandidater til automatiseret testning. Testene bør prioriteres baseret på deres fejlfrekvens, forretningsmæssige betydning og anvendte funktionaliteter. 

Testcases, der relaterer sig til scenarier fra det virkelige liv og nye funktionaliteter, bør også tildeles høj prioritet.

Relateret til regressionstestning

Regressionstestning vs. gentestning

I modsætning til regressionstestning, hvor testere validerer, at den eksisterende funktionalitet stadig fungerer, bekræfter gentestning, at en fejl er blevet rettet. Gentestning omhandler kun mislykkede testcases og fokuserer på at verificere, om resultatet af testcasen har ændret sig. 

Agil regressionstestning

Når man arbejder i et agilt miljø, introduceres der nye funktioner i hvert sprint, og regressionstestsuiten bør altid holdes opdateret for at sikre, at alle funktioner fungerer korrekt efter sprintet. I agile miljøer, hvor kodeændringer forekommer hyppigt, kan effektive QA-automatiseringsværktøjer være en stor hjælp til at følge med i regressionstestningen. Regressionstesten bør løbende udvides med testcases, der matcher alle de testede og stabile funktioner, og testcases, der ikke længere er relevante, bør fjernes.

Visuel regressionstestning

Regressionstesttilgangen bruges også ved visuel regressionstestning. Visuel regressionstestning kontrollerer dog kun softwarens visuelle elementer. Med andre ord sikrer den, at ingen komponent i softwarens visuelle grænseflade er blevet ødelagt af kodeændringer.

En visuel regressionstest verificerer, hvad brugeren vil se, efter systemet er blevet ændret, ved at sammenligne øjebliksbilleder taget før og efter ændringerne. 

Enhedstestning vs. regressionstestning

Målet med enhedstestning er at validere, at individuelle kodenheder fungerer som forventet uafhængigt af hinanden. Den udføres, efterhånden som koden udvikles, en enhed ad gangen, tidligt i udviklingscyklussen. 

Til sammenligning udføres regressionstestning senere i udviklingscyklussen, når der er kodeopdateringer eller fejlrettelser. Regressionstestning dækker normalt hele applikationen eller softwaren.

Sundhedstestning vs. regressionstestning

Sundhedstestning udføres for at evaluere, om softwaren fungerer som tilsigtet efter tilføjelsen af et nyt modul eller en ny funktionalitet. Sundhedstestning er en softwaretestmetode, der hurtigt vurderer kvaliteten af en softwareudgivelse for at afgøre, om den er egnet til yderligere testning.

Så evaluerer sanitytest stabiliteten af nyligt tilføjede funktioner eller kodeændringer i det aktuelle build. Regressionstest verificerer, at alle områder, der påvirkes af funktionsændringer eller kodeændringer, er stabile.

Vigtigste pointer 

Brugeroplevelsen og den overordnede produktkvalitet kan forbedres betydeligt gennem regressionstest.

Regressionstest i Agile har også forskellige tekniske og kommercielle fordele. Jo mere din virksomhed investerer i planlægning og gennemførelse af regressionstest, desto mere kontrol får I over produktets budget, processer og fejlhåndtering.

Hvis du vil vide mere om emner inden for kvalitetssikring, så tilmeld dig QA Leads nyhedsbrev!