Regression — vad är det, varför uppstår det och hur man testar

Vad är regression inom utveckling

Regression — är en situation där funktionalitet som fungerade i den tidigare versionen slutar fungera efter att ändringar har gjorts. Ändringen kan vara vad som helst: buggfix, tillägg av ny funktion, omfaktorisering, uppdatering av bibliotek eller till och med en konfigurationsändring. Regression är stabilitetens främsta fiende: varje ändring riskerar att förstöra något som redan har kontrollerats och släppts.

Termen kommer från testning: regressionstestning — är att köra om befintliga tester efter varje ändring. Om ett tidigare godkänt test misslyckas — har en regression inträffat. I vidare bemärkelse är regression inte bara ett testmisslyckande, utan även varje försämring av beteendet som observeras av användaren eller QA. Enligt Tricentis State of Testing 2023 utgör regressioner 35–45% av alla buggar som hittas i produktion.

Regression skiljer sig från en vanlig bugg genom tidsmässig kontext: en bugg kan ha funnits alltid, medan regression alltid är resultatet av en ändring. Detta är en viktig skillnad eftersom sökandet efter orsaken till en regression börjar med analys av ändringar: vad ändrades mellan “fungerade” och “slutade fungera”. Git bisect — standardverktyget för att hitta commiten som orsakade regressionen.

Typer av regressioner och exempel

Lokal regression — en ändring i modul A förstör funktionalitet i samma modul A. Exempel: utvecklaren skriver om sorteringsfunktionen och den slutar att korrekt bearbeta en tom array. Lokal regression är enklast att upptäcka och åtgärda eftersom orsak och verkan är nära varandra.

Avlägsen regression — en ändring i modul A förstör funktionalitet i modul B, som inte är direkt kopplad via kod, men är kopplad via data eller tid. Exempel: en ändring av databasschemat i modulen “Användare” förstör en rapport i modulen “Analys” som använder samma tabell. Avlägsna regressioner är de mest lömska: utvecklaren misstänker inte att hans ändring kommer att påverka en annan modul.

Biverkningsregression — en ändring av en biverkning (loggning, cachning, skicka notifieringar) förstör det förväntade beteendet. Exempel: utvecklaren lade till cachning för att snabba upp arbetet, men på grund av föråldrad cache ser användarna inaktuella data. Biverkningsregressioner är svåra att fånga med automatiska tester eftersom biverkningar ofta inte täcks av tester.

Prestandaregression — koden fortsätter att fungera korrekt funktionellt, men långsammare än tidigare. Exempel: den nya krypteringsalgoritmen ger samma resultat, men exekveringstiden ökade från 2 ms till 200 ms. Prestandaregressioner upptäcks inte av vanliga enhetstester — benchmarkning och profilering krävs.

Varför uppstår regressioner

Första orsaken — kodkoppling (coupling). Ju starkare moduler är beroende av varandra, desto högre är sannolikheten att en ändring i en orsakar regression i en annan. Klassiska antipatterns: God Object (objekt som gör allt), Shotgun Surgery (ändring av en kräver justeringar på dussintals platser), Circular Dependency. Att minska coupling — en uppgift för arkitekturen: SOLID-principer, Dependency Injection, hexagonal arkitektur.

Andra orsaken — brist på tester för den ändrade funktionaliteten. Om koden inte täcks av tester får utvecklaren veta om regressionen först från QA eller användare. Enligt Google Testing Blog har projekt med testtäckning >75% 5 gånger färre regressioner än projekt med täckning <25%. TDD (Test-Driven Development) garanterar att testerna skrivs före koden, inte “när det finns tid”.

Tredje orsaken — mänsklig faktor. Utvecklaren känner inte till förekomsten av angränsande funktionalitet, förstår inte alla beroenden eller har helt enkelt bråttom. Orsak — otillräckligt kunskapsutbyte om kodbasen. Lösningar: code review med utvecklare från andra moduler, pair programming, arkitekturdokumentation. Projektets Bus factor är omvänt proportionell mot antalet dokumenterade arkitekturbeslut.

Regressionstestning och dess roll

Regressionstestning — är processen att köra om befintliga tester efter varje ändring för att kontrollera att gammal funktionalitet inte har förstörts. Det är det enda sättet att garantera att en ny ändring inte har stört funktionen av befintlig kod. Utan regressionstestning är varje release ett lotteri: utvecklaren hoppas att han inte har förstört något, men kan inte bekräfta det.

Manuell regressionstestning — det dyraste och mest ineffektiva tillvägagångssättet. När projektet växer ökar antalet regressionstestscenarier linjärt och tiden för manuell körning exponentiellt. Efter 2–3 års utveckling kan manuell regression ta 2–3 veckor, vilket gör frekventa releaser omöjliga. Den enda utvägen är automatisering.

Automatiserad regressionstestning delas in i nivåer enligt testpyramiden:

• Enhetstester — snabba, isolerade, täcker enskilda funktioner och metoder
• Integrationstester — kontrollerar interaktion mellan moduler, DB, externa tjänster
• E2E-tester — kontrollerar fullständiga användarscenarier via UI eller API
• Snapshot-tester — jämför aktuell utdata från en komponent med en referens

Enligt Google Testing Blog är det optimala förhållandet: 70% enhetstester, 20% integrationstester, 10% E2E. Avvikelse från detta förhållande minskar effektiviteten av regressionstestning: överskott av E2E-tester saktar ner pipelinen, brist på enhetstester lämnar mikrofel obemärkta.

Automatiseringsstrategier för regressionstestning

Första strategin — Full Regression. Alla tester i projektet körs. Den mest pålitliga, men också den långsammaste metoden. Tillämplig för små projekt (upp till 10 000 tester, körtid <30 minuter). För stora projekt kan full regression ta timmar, vilket gör CI/CD-pipelinen opraktisk.

Andra strategin — Selective Regression. Endast tester som är relaterade till den ändrade koden körs. För att bestämma samband används kodens beroendegraf. Verktyg: Bazel (Google), Nx (JavaScript), sbt (Scala). Selective regression sparar 60–80% av körtiden men kräver noggrann konstruktion av beroendegrafen — fel leder till missade regressioner.

Tredje strategin — Prioritized Regression. Alla tester rangordnas efter prioritet: critical path (viktigaste användarscenarierna), high risk (kod med felhistorik), changed code (kod som påverkas av ändringen). Först körs de mest prioriterade testerna — om de klarar sig får utvecklaren snabb feedback. Tidsbegränsad körning: inom 10 minuter kontrolleras kritiska tester, resten — i bakgrunden.

Hur man förebygger regressioner i projektet

Första och viktigaste steget — kultur av att skriva tester. Varje ändring bör åtföljas av ett test som kontrollerar att ändringen fungerar och ett test som kontrollerar att inget har förstörts. TDD (Test-Driven Development) ger bäst resultat: utvecklaren skriver först ett misslyckat test, sedan koden som klarar det. Detta garanterar att testet finns före koden.

Andra steget — CI/CD-pipeline med obligatorisk testkörning. En pull request kan inte slås samman förrän alla tester har godkänts. Tester kan inte “hoppas över” på grund av brådska — brådskande ändringar går igenom en accelererad men obligatorisk testuppsättning. Enligt Google DevOps Research har team med obligatorisk CI/CD 3 gånger färre regressioner i produktion.

Tredje steget — övervakning i produktion. Även de bästa testerna garanterar inte 100% skydd mot regressioner. Verktyg för observability (Sentry, Datadog, New Relic) bör övervaka nyckelmetrik efter varje driftsättning: felfrekvens, latens, genomströmning. Automatisk återställning (rollback) vid överskridande av trösklar — en säkerhetsbuffert om regressionen ändå når produktion.

Fjärde steget — code review med regressionstänkande. Granskaren bör ställa frågan: “Vilka andra moduler kan förstöras av denna ändring?”. Det räcker inte att kontrollera att koden är korrekt — man måste kontrollera att den inte stör angränsande funktionalitet. Checklistan för code review bör innehålla punkten “kontroll av regressioner i angränsande moduler”.