BLOG
SOFTWARETEST

Blog: Passer dit projekt ned i den agile 'bageform'?

Er du nogensinde stødt ind i agile evangelister der prædiker Agile ”by the book”, som ikke vil erkende at der faktisk er situationer hvor man IKKE kan køre 100% efter bogen? Som forsøger at presse kørende projekter ned i en agil ”bageform”, uden skelen til projektets alder eller tilstand?

[18. februar 2016] Hvis man starter på en tom side; et helt nyt projekt uden bagage fra tidligere releases, med en kunde der er helt klar på at sætte releases i drift hver 3. eller 4. uge, så er jeg ikke på nogen måde i tvivl om, at det for mange er muligt at implementere agile helt efter bogen. Men har man bagage med fra tidligere, kan man støde på forhindringer der er nødt til at blive adresseret; ting der gør at man er nødt til at klippe en tå, og hakke en hæl hist og her, for at få virkeligheden til at passe... Eller måske ændre faconen på bageformen lidt. Over de næste par uger vil jeg prøve at illustrere et par eksempler på hvad der kan påvirke mulighederne for at være DONE i sprintet, og kunne gå i drift umiddelbart efter sprintafslutningen – alle set med en testers briller.

Det første emne jeg vil tage fat i er regressionstesten. I følge bageformen skal den jo “blot” være fuldt automatiseret – evt. suppleret af lidt exploratory testing, men er man i et projekt med mange eksisterende funktionaliteter, er det bare ikke altid en mulighed. I et af mine tidligere projekter har vi kørt i et års tid, al test udover unit og unit integration test er specificeret og afviklet som manuel test. Det gælder både vores test af ny funktionalitet og regressionstesten. Som udgangspunkt kan vi godt køre videre med manuelle tests langt hen ad vejen, men her bliver det vigtigt at erkende, at regressionstestbyrden vil påvirke velocity for teamet. Der vil uvægerligt komme en større og større mængde af regressionstests, der skal gennemkøres i løbet af hvert sprint, efterhånden som systemet vokser – og skal vi gå i drift umiddelbart efter hvert sprint, må det køres i sprintet. Et af de hårdest ramte projekter jeg har oplevet, stod til sidst med en regressionstestbyrde der tog flere timer end selve udviklingen i hvert sprint; en situation som selvsagt ingen kan være tilfredse med.

Der er flere løsninger på problemet, afhængigt af hvad du har mulighed for at ændre – et par kunne være:

  1. Releaseforløb der køres i forlængelse af sprintet
  2. Begrænsning af scope for regressionstest
  3. Implementering af automatisk regressionstest

I erkendelse af at regressionstesten efterhånden fylder for meget inde i sprintet, hvilket medfører at scope i hvert sprint giver mere og mere begrænset forretningsværdi, kan man tage beslutningen at køre den endelige regressionstest som en del af et ”end game”, i forlængelse af sprintet. Det betyder en forsinkelse af releasen, men gør at man har plads til mere funktionalitet i selve sprintet. Bemærk at jeg siger ENDELIG regressionstest - der skal stadig testes løbende i sprintet. Alt ny funktionalitet skal være testet som en del af definition of done, lige som en vis mængde løbende regressionstest kan gennemføres som exploratory test i teamet. Den endelige kan man altså forskyde, så den kører i parallel med at næste sprint opstartes. Det er der naturligvis også ulemper ved, dels fordi man skubber risici for at finde kritiske fejl ud af sprintet, der således vil kunne påvirke næste sprint, da man er nødsaget til at trække ressourcer ud af teamet til at løse det mest kritiske inden man går i drift. Samtidig vil teamets testere være fokuseret på at teste det afsluttede sprint, og ikke kunne følge med i planlægning og afvikling af det næste sprint sideløbende. For fejl der ikke er kritiske, vil man ofte vælge bare at registrere dem og ikke løse dem med det samme, hvilket så medfører at mængden af teknisk gæld øges.

Man kan naturligvis vælge at skære i regressionstesten, for eksempel ved at vælge kun at teste de områder der har højest risikoklasse. Det vil sige at man kun adresserer de områder hvor både sandsynligheden og konsekvensen for fejl er højest. Dette er naturligvis ikke en beslutning som hverken team eller tester kan tage; den bør ligge hos Product Owner. Hvilke risici er man klar til at løbe i forhold til fejl i produktionen? Kan man acceptere at der findes en eller flere fejl produktionen umiddelbart efter idriftsættelse? For overhovedet at kunne tage denne diskussion kræves det naturligvis ligeledes at team og Product Owner, sammen med test manageren, har gennemført en produktrisikoanalyse, så man har et konkret grundlag at vurdere ud fra. Set fra et kvalitetsmæssigt synspunkt er det ikke en tilgang jeg kan anbefale, men der kan naturligvis være situationer hvor time-to-market vejer højere end kvaliteten af leverancen.

Sidst men ikke mindst er der løsningen med at implementere en automatisk regressionstest. Der er ingen tvivl om at dette er en af de grundlæggende dele af en agil teststrategi, og at det bør være i fokus i et hvert agilt team, for at kunne teste tidligt og teste tit. Og for nye projekter er det helt essentielt at man får taget stilling til en automatiseringsstrategi fra starten af, så dette bliver en integreret del af måden teamet arbejder på. Men for kørende projekter er det en lidt større opgave; her har man allerede en backlog af eksisterende manuel regressionstest, og er derved nødt til at have en strategi for hvordan man får denne med i forløbet. Skal man slå en streg i sandet og sige ”fra nu af laver vi vores regressionstest automatisk, men vi accepterer at den eksisterende er manuel”? Eller skal man lave et projekt der fokuserer på at få tygget sig igennem den manuelle suite sideløbende med, at der udvikles nyt? Eller skal man vælge en tilgang hvor man gennemgår den eksisterende manuelle suite, sorterer og rydder op, og prioriterer hvad der skal automatiseres og hvad man fortsat vil lade være manuelt? Det er alt sammen spørgsmål teamet er nødt til at tage stilling til, som en del af strategien. Samtidig skal man naturligvis sikre, at rammerne for automatiseringen er på plads: Et framework der sikrer genbrug og let vedligeholdelse, der sikrer at den automatiske test kan blive en integreret del af den kontinuerlige integration, og således kører som en integreret del af byggeprocessen i teamet.

Det var lidt om regressionstesten, men hvad med:

-        Komplekse/store systemer udviklet af flere teams?

-        Projekter med formelle kontrakter omkring afleveringsforretning?

-        Teams uden testere?

Dem vender vi tilbage til i de kommende uger.

Gitte Ottosen
Gitte Ottosen
Management Consultant & Agile Evangelist
+45 39778711
todo todo