Myt #2: Regressionstest hinns inte med

Att regressionstesterna inte hinns med är en vanlig oro bland testare när en transformation mot att arbeta agilt inleds. Fokus på att leverera ett färdigt och levererbart inkrement av produkten/systemet gör att teamet ofta vill köra genom hela sin regressionstestsvit för att känna sig trygg i sin leverans. Som vanligt föder oro myt.

– Om det ska levereras till produktion så ska väl allt vara testat och eventuellt godkänt av kunden. Eller?

Mytens ursprung

I ett försök att anpassa sig och arbeta iterativt trycker teamet helt enkelt ihop sin nuvarande process för att passa  i en kortare tidsplan – “iteration”. Istället för att ändra vilka aktiviteter som måste genomföras, och hur de utförs för att säkerställa kvaliteten inför leverans, utgår teamet från befintliga rutiner. De befintliga rutinerna är troligtvis skapade utifrån en annan kontext än den agila och då kommer det att uppstå problem i arbetet.

Försök att banka ihop befintliga testprocesser till dess att de får plats i en sprint är dömt att misslyckas.

En annan vanlig orsak till mytens uppkomst är att regressionstest traditionellt är en aktivitet som utförts efter att kodfrys har inträffat. Det blir därför naturligt för teamet att utföra regressionstestning i slutet av sprinten. Eftersom en iteration aldrig är längre än 4 veckor, blir det väldigt mycket arbetsuppgifter att genomföra om allt (d.v.s. hela systemet/produkten) skall regressionstestas varje gång.

Detta tror vi är de två starkaste orsakerna till myten om att regressionstest inte hinns med.

För att lösa problemet är det många team som lägger på en “releasesprint” precis innan en produktionssättning där regressionstestning sker.

Så vad är då syftet med regressionstest?

När man pratar om regressionstest syftar det på en aktivitet som utförs för att säkerställa att systemet/produkten fungerar i sin helhet efter att ny funktionalitet har introducerats eller befintlig ändrats. Traditionellt har denna aktivitet utförts i ett slutskede innan skeppning eller produktionssättning har skett. Det ger teamet och intressenterna en känsla av förtroende för att systemet fungerar som det är tänkt och att en ändring inte förstört någon befintlig funktionalitet.

Men vad är egentligen orsaken till att vi vill regressionstesta?

Om syftet med regressionstest är att vi vill känna oss säkra efter att vi infört ändringar, så är det enklaste sättet att sluta göra ändringar i systemet över huvud taget. Detta skulle inte vara speciellt utvecklande eller hållbart i längden. Vi kommer behöva ändra i systemet och då måste det finnas något som gör att vi känner oss osäkra och behöver regressionstesta inför varje leverans.

Denna osäkerhet kan bero på väldigt många faktorer, och några skulle kunna vara:

• Att systemet skört och har många beroenden
• Att teamet har batchat ihop väldigt många nya features som skall släppas på en och samma gång
• Att teamet har svårt att göra en bedömning av hur ändringarna har påverkat systemet

Så hur angriper vi detta istället?

Några tips på hur man kan minska behovet av regressionstestning:

• Mindre feature-batcher – Releasa oftare, men färre features i varje release. Det gör att en mindre del av systemet troligtvis är påverkat av releasen och regressionstestning kan minskas till att bara beröra den del som ändrats.
• Riskbaserad testning – Gör en riskbedömning av systemet. I vilka delar är risken störst att något har gått sönder? Är dessa delar affärskritiska? Om inte, kanske vi inte behöver lägga så mycket tid på regressionstest där.
• Lite regressionstest i taget – Regressionstestning är inte en aktivitet som måste göras på slutet utan teamet kan regressionstesta allt eftersom utveckling sker i iterationen.
• Automatisera regressionstesterna – Genom att automatisera regressionstesterna där det är möjligt och gynnsamt kan tiden för manuella regressionstester minskas. Det gör det också möjligt att kontinuerligt köra sina regressionstester, d.v.s. inte bara i slutet av iterationen.
• Modularisera/komponentifiera systemet – Beroende på hur systemet eller produkten ser ut ger det också bättre förutsättningar för att regressionstesta enskilda komponenter eller moduler. Det behöver inte vara så att hela systemet måste regressionstestas bara för att vi ändrat i en del eller modul. Med en god design, arkitektur och tydliga API:er kan komponenter isoleras och regressionstestas var för sig.
• Gemensamt test- och releaseansvar – Om alla i teamet hjälps åt (utvecklare, testare, PO e.t.c.) kommer regressionstesterna garanterat gå fortare än om bara testarna engagerar sig i denna aktivitet. Detta medför också en ökad kunskap i teamet om systemet och hur det testas.

Alltså…

Myten är faktiskt sann. Om du och ditt team försöker trycka ihop er befintliga process för att passa i den agila formen utan att först försöka ändra befintligt arbetssätt kommer det med stor sannolikhet att misslyckas. Passar det inte att arbeta agilt så ska ni inte göra det, men försök inte att blanda ihop två olika världar.

Om visionen istället är en process där ni inte längre behöver regressionstesta allt manuellt varje leverans och kontinuerligt jobbar med förbättringar i den riktningen, så behöver inte regressionstestning vara ett hinder för att arbeta agilt.

Myten i sin presenterade form, d.v. s. “Regressionstest hinns inte med” är alltså: