Skip to content

Myt #2: Regressionstest hinns inte med

december 19, 2012

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.

Agil Myt 2
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å:

Annonser
5 kommentarer leave one →
  1. johlrogge permalink
    januari 7, 2013 08:24

    Men myten var väl att /regressionstest/ inte hinns med. Inte att /manuell regressionstest/ inte hinns med. Ur den aspekten tycker jag att det är en solklar busted. Hade myten varit ”vi kan inte längre regressionstesta på traditionellt sätt” såsom det argumenteras för väl i artikeln är den däremot bekräftad.
    Väldigt väl illustrerat att man inte kan banka ihop en befintlig process för att få plats i en sprint och väl argumenterat att man /kan/ och /bör/ angripa problemet anorlunda. Jag skulle nog tycka att en långtgående automatisering av regressionstestsvit är det enda hållbara sättet att regressionstesta /oavsett/ om man kör agilt eller inte. En manuell testrunda är enligt min erfarenhet falsk säkerhet och inte praktiskt hållbart att luta sig mot för att garantera kvalité. Manuellt repetetivt arbete är inget mäniskor (ens om de är testare) är bra på.

    En besläktad poäng är att man genom att införa regressionstest som en del av det dagliga (eller nattliga) arbetet kan komma ett steg närmare att få bukt med den allt för vanliga inställningen ”att det är testarna som har missat i testning när man hittar fel i produktion”.

  2. Agila myter permalink*
    januari 7, 2013 11:13

    Hej,

    Tack för en bra synpunkt angående myten. Vi funderade ett tag på formuleringen av myten men ville inte ändra den för mycket utan snarare försöka argumentera för hur vi tänker.
    Ofta brukar folk ha funderingar på hur man ska kunna hinna regressionstesta när man arbetar agilt, och då menar de oftast traditionell (som de gjort tidigare) regressionstestning.
    Manuellt eller automatiserat behöver inte vara en faktor i detta problem, det kan vara lika svårt, om inte svårare, att hinna med automatiserade tester om man arbetar utifrån en befintlig process som är intryckt i en sprint.

    Vi tror som sagt att det största problemet är att man inte ser över sina processer vid en övergång till agilt.

    Fortsätt gärna att kommentera

    /Jagge

  3. januari 16, 2013 21:14

    Jag förstår hur ni tänkte. Och det verkar logiskt givet att ni riktar er mot en viss publik, dock är jag inte en del av den gruppen som blir hjälpt av ”förenklingen” så för mig var det inte hjälpsamt. Det är också förvirrande (i vilket fall för mig) att man bortser från den egentliga betydelsen av ett ord och istället använder en vedertagen uppfattning om hur ordet implementeras.

    För alla oss TLDR-människor stod det: Regressionstest hinns inte med – Bekräftad

    När jag har läst detta och en del kommentarer på föregående inlägg har jag börjat förnimma att den typiska test-konsulten i regel ser en annan verklighet än den typiska programmerar-konsulten. Jag ska fundera lite mer på den och utveckla i detalj någon gång men tills vidare tror jag att det som känns logiskt och ”vanligast” i de sammanhang man själv befinner sig inte nödvändigtvis är vanligast och mest logiskt i någon annans sammanhang.

    Jag skulle föredragit att man istället går till botten med vad det är för behov man vill tillgodose. Tex genom att gå definiera vad man vill uppnå med ett regressionstest. Något den här stilen: ”Syftet med ett regressionstest är att säkerställa att systemet inte försämras över tid med avseende på tex funktion, säkerhet, stabilitet, prestanda eller annat man tycker är viktigt”.
    Jag vet inte om min uppfattning om regressionstestets syfte stämmer med författarens eller övriga läsares (vilket också är intressant att få reda på) men jag var tvungen att hitta på något illustrativt.

    Jag anser att den generella metoden: att lyfta blicken och fråga sig vad det är man vill uppnå är sättet att anamma ett lättrörligt arbetssätt. Det är också något man kan lära sig på en blogg som denna. Att se till det värdet vi önskar skapa och inte vilka ritualer vi oftast ägnar oss åt med passande namn. Och jag tror att det inte bara är jag som är ”programmerare” och följer bloggen med intresse så med syftet att hjälpa alla att ta till sig informationen här tror jag att man nästan bör utgå från att man läsare har olika uppfattningar om begrepp och se till att definiera dem för att sedan adressera dem.

    Det är min uppfattning. Se det som min input med önskan om att ett bra initiativ ska bli ännu bättre för ännu fler och inte som kritik. Som jag skrev i kommentaren innan så argumenterar ni väl för ett vanligt problem men TLDR-varianten blir mer missvisande än jag är bekväm med 🙂

  4. januari 18, 2013 06:47

    Hej,

    Jag är nog också en TL DR-person (Too Long; Didn’t Read) väldigt ofta. Om man snabbläser artikeln och hoppar till domen (busted eller approved) så blir resonemanget av naturliga skäl luddigt. Vi kanske kan försöka skriva kortare artiklar eller inleda med en summering av resonemanget bakom domen. Vi får fundera på detta.

    Vidare vill vi att bloggen ska kunna uppskattas av alla oavsett expertis/roll och oavsett om man jobbar i en tradionell eller agil miljö. Jag ska försöka vara mera vaksam framöver om vi använder oss av begrepp vi behöver förtydliga och definera.

    Tack för feedbacken! Du hjälper oss bli bättre 🙂

    /Jimmy

  5. januari 18, 2013 19:13

    Hmm, jämför vi inte äpplen och päron?

    Låt oss jämföra ytterligheterna: Regressionstest i en traditionell utvecklingsmiljö är ofta en manuell historia som utförs lika sällan som releaser görs (några gånger per år). Huvuddelen av regressions-testerna ligger på systemnivå. Utvecklarna jobbar inte test-drivet.

    I en agil utvecklingsmiljö så har man förstått betydelsen av TDD. Testerna är balanserade så att huvuddelen ligger på enhetsnivå (och är automatiserade – duh!). Det finns inte längre ett behov av stora volymer av systemtester. Regressionstestningen på systemnivå har helt enkelt blivit kraftigt reducerad. Om inga tester på systemnivå är automatiserade så vill jag ändå påstå att huvuddelen (säg 90%) av alla regressionstester är automatiserade (på lägre nivåer).

    Låt säga att vi har 10 äpplen i den traditionella miljön att regressionstesta. I den agila miljön blir detta 1 äpple att regressionera, då dom övriga 9 redan är ”täckta” genom TDD:n.

    Sedan kan man naturligtvis halvera vårt enda äpple med riskbaserad test om man vill. Men den stora vinsten görs med TDD:n.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s

%d bloggare gillar detta: