En guide til regresjonstesting for kvalitetssikring

Regresjonstesting er en av de viktigste testtypene i ethvert programvareutviklingsprosjekt. På et overordnet nivå er målet å bekrefte at nyutvikling ikke har introdusert feil eller mangler i områder som tidligere fungerte.

Gjennom arbeidet mitt med ulike prosjekter innen forskjellige forretningsområder har jeg lært at hvert team har sine egne prosesser for å gjennomføre regresjonstesting av programvare. Det finnes imidlertid noen fellesnevnere som alle vellykkede testprosjekter deler.

Denne veiledningen gir deg kunnskapen du trenger for å mestre regresjonstesting. Den utforsker arsenalet av kraftige verktøy for regresjonstesting for å effektivisere prosessen og sikre en smidig utviklingsarbeidsflyt. Jeg deler erfaringene jeg gjorde meg underveis.

Hva er regresjonstesting i programvareutvikling?

Det er relativt normalt at nye feil oppstår og/eller at problemer dukker opp igjen når programvare oppdateres, endres eller gjenbrukes på et modifisert mål. 

For å sikre at disse feilene avdekkes før programvareoppdateringene lanseres i produksjon, bør QA-teamet fokusere på å finne dem i tide – og det er her regresjonstesting kommer inn.

Regresjonstesting er en testtype der funksjonaliteten til programvarens allerede eksisterende funksjoner bekreftes. Regresjonstesting gjennomføres etter hver endring eller oppdatering av koden for å sikre at den eksisterende funksjonaliteten fungerer som tiltenkt, uten endringer eller tillegg. Avhengig av prosjektets omfang kan man bruke enten manuell eller automatisert regresjonstesting.

Når bør du bruke regresjonstesting?

Når nye funksjoner eller forbedringer legges til i en eksisterende kodebase eller applikasjon, er regresjonstesting nødvendig. Det garanterer at alle nye funksjoner eller oppdateringer i en eksisterende applikasjon fungerer feilfritt og uten feil. Det er stor sannsynlighet for problemer med kodeinkompatibilitet fordi utviklere og testere ofte har problemer med å følge hver enkelt kodeflyt. Derfor gjør kjøring av regresjonstester på programvaren (eller applikasjonen) det mulig å finne feil tidligere og lansere programvare med færre risikoer.

Regresjonstesting kan brukes når en utrulling tar lengre tid enn forventet. I dette scenarioet må testeren gjennomføre regresjonstester hver dag. For ukentlige utgivelser er det dessuten å foretrekke å gjennomføre regresjonstesting etter funksjonell testing.

Automatisert regresjonstesting

Regresjonstestbiblioteket utvides etter hvert som teamet legger til funksjoner i programvaren. Over tid kan regresjonstestpakken bli så omfattende at det blir umulig å kjøre testene manuelt innenfor de begrensede, smidige sprintsyklusene.

Regresjonstesting egner seg best for testautomatisering fordi den må kunne gjentas og gjennomføres regelmessig. Før hver utgivelse kan du gjennomføre en grundig regresjonstest, og du kan utvikle slankere testpakker som gir raskere tilbakemeldinger for å kontrollere om det har oppstått regresjoner etter kodeendringer (hurtigfiksinger). Se nærmere på verktøy for programvaretesting som er spesielt effektive i scenarier for regresjonstesting.

Når skal regresjonstesting gjennomføres?

Regresjonstesting er nødvendig hver gang nye funksjoner eller forbedringer legges til i en eksisterende kodebase eller applikasjon. Det garanterer at alle nye funksjoner eller oppdateringer i en eksisterende applikasjon fungerer feilfritt og uten feil. Det er stor sannsynlighet for problemer med kodeinkompatibilitet fordi utviklere og testere ofte har problemer med å følge hver enkelt kodeflyt. Derfor gjør kjøring av regresjonstester på programvaren (eller applikasjonen) det mulig å finne feil tidligere og lansere programvare med færre risikoer.

Manuell regresjonstesting må gjennomføres hvis testautomatisering ikke er integrert med byggesystemet og/eller automatiserte testkjøringer ikke er planlagt regelmessig. Er det da nødvendig å gå tilbake og kontrollere hver eneste kodeendring? Nei, det er svaret.

Regresjonstesting er bare nødvendig når en kodeendring påvirker andre deler av produktet. For å fastslå dette må man undersøke hvordan den endrede modulen samhandler med andre produktmoduler.

Som oftest kjenner utviklerne som gjør endringene til de mulige konsekvensene for andre moduler og for hele produktets atferd, og de bør be om regresjonstesting etter behov.

Hvem har ansvaret for regresjonstesting?

Etter at funksjonell testing er fullført, gjennomføres regresjonstesting for å kontrollere at all annen funksjonalitet fungerer. Det er vanligvis QA-teamets ansvar. Nye testere som ikke har testet funksjonen tidligere, men som kan kjøre dokumenterte testtilfeller, kan også involveres i regresjonsprosessen. I slike tilfeller bør regresjonstesttilfellene være godt dokumentert, slik at selv en ny person i teamet kan følge dem. 

Testere som kanskje ikke har gjennomført de funksjonelle testene tidligere, men som har god erfaring med å arbeide med funksjonene som skal testes, har også gode muligheter til å finne alvorlige feil dersom noen har blitt introdusert.

Hvordan vet du når regresjonstestingen er fullført?

Du må finne en finstemt balanse mellom det du har tid og ressurser til å dekke som en del av regresjonstestingen, og risikoen teamet kan påta seg.

Her er noen ting testteamet kan ta hensyn til når de estimerer risiko:

• Hvis en funksjon brukes intensivt av programvarens brukere, bør den prioriteres i planen for regresjonstesting.
• Tekniske områder av produktet som tidligere har vist seg å være stabile, og som er kjent for å generere gode testrapporter, innebærer mindre risiko. Derfor kan programvaretesterne velge å ikke inkludere dem som en del av regresjonstestingen.
• Analyse av tidligere rapporterte feil fra kunder eller det interne QA-teamet kan bidra til å identifisere svakere områder i appen der regresjonsinnsatsen bør fokuseres.
• Hvis feil har forblitt åpne lenge uten å bli rettet, har de liten innvirkning på brukernes arbeidsflyter, og de har funnet løsninger for å omgå dem.

Teknikker for regresjonstesting

De viktigste teknikkene som brukes ved regresjonstesting, er: 

• Fullstendig regresjon, også kjent som ny testing av alt
• Utvalg av regresjonstester
• Prioritering av testtilfeller

Fullstendig regresjon

I denne metoden brukes regresjonstesting på alle aktive testserier. Selv om denne tilnærmingen krever mye tid og ressurser, er den den sikreste teknikken for å garantere at alle feil blir funnet og rettet, fordi den har den høyeste testdekningen.

På grunn av dette finnes det spesifikke situasjoner der strategien med fullstendig regresjonstesting fungerer bedre enn andre, for eksempel når applikasjonen endres for en ny plattform eller et nytt språk, eller når operativsystemet mottar en betydelig oppdatering.

Testutvalg (eller delvis regresjonstesting)

Denne teknikken innebærer å velge ut testtilfeller fra testserien som skal kjøres på nytt. Utvalget av testtilfeller baseres på kodeendringene i modulen.

Prioritering av testtilfeller 

Når du bruker denne tilnærmingen, kan du prioritere testtilfellene med høyest prioritet, slik at de utføres først i regresjonstestprosessen. Disse er også gode kandidater for automatisert testing. Testene bør prioriteres basert på feilfrekvens, forretningspåvirkning og funksjonalitetene som brukes. 

Testtilfeller som gjelder virkelige scenarier og ny funksjonalitet, bør også gis høy prioritet.

Relatert til regresjonstesting

Regresjonstesting kontra ny testing

I motsetning til regresjonstesting, der testere validerer at den eksisterende funksjonaliteten fortsatt fungerer, bekrefter ny testing at en feil er rettet. Ny testing omfatter bare mislykkede testtilfeller og fokuserer på å verifisere om resultatet av testtilfellet er endret. 

Smidig regresjonstesting

Når man arbeider i et smidig miljø, introduseres nye funksjoner i hver sprint, og regresjonstestserien bør alltid holdes oppdatert for å sikre at alle funksjonene fungerer som de skal etter sprinten. I smidige miljøer der kodeendringer skjer ofte, kan effektive QA-automatiseringsverktøy være avgjørende for å holde tritt med regresjonstestingen. Regresjonsserien bør kontinuerlig utvides med testtilfeller som samsvarer med alle testede og stabile funksjoner, og testtilfeller som ikke lenger er relevante, bør fjernes.

Visuell regresjonstesting

Tilnærmingen for regresjonstesting brukes også ved visuell regresjonstesting. Visuell regresjonstesting kontrollerer imidlertid bare programvarens visuelle elementer. Med andre ord sikrer den at ingen komponenter i programvarens visuelle grensesnitt blir ødelagt av kodeendringer.

En visuell regresjonstest verifiserer hva brukeren vil se etter at systemet er endret, ved å sammenligne øyeblikksbilder tatt før og etter endringene. 

Enhetstesting kontra regresjonstesting

Målet med enhetstesting er å validere at individuelle kodenheter fungerer som forventet, uavhengig av hverandre. Den gjennomføres mens koden utvikles, en enhet om gangen, tidlig i utviklingssyklusen. 

Til sammenligning utføres regresjonstesting senere i utviklingssyklusen, når det er gjort kodeoppdateringer eller feilrettinger. Regresjonstesting dekker vanligvis hele applikasjonen eller programvaren.

Rimelighetstesting kontra regresjonstesting

Rimelighetstesting utføres for å vurdere om programvaren fungerer som tiltenkt etter at en ny modul eller funksjonalitet er lagt til. Rimelighetstesting er en metode for programvaretesting som raskt vurderer kvaliteten på en programvareutgivelse for å avgjøre om den er egnet for videre testing.

Så en rask stabilitetskontroll evaluerer stabiliteten til nylig tilføyde funksjoner eller kodeendringer i det gjeldende bygget. Regresjonstesting bekrefter at alle områder som påvirkes av funksjonalitetsendringer eller kodeendringer, er stabile.

Viktigste punkter 

Brukeropplevelsen og den overordnede produktkvaliteten kan forbedres betydelig gjennom regresjonstesting.

Regresjonstesting i Agile gir også ulike tekniske og kommersielle fordeler. Jo mer virksomheten investerer i planlegging og gjennomføring av regresjonstesting, desto bedre kontroll får den over produktets budsjett, prosess og feilbegrensning.

Hvis du vil lære mer om emner innen kvalitetssikring, abonner på QA Leads nyhetsbrev!