BLOG
SOFTWARETEST

Blog: Automatisering på tværs i en agil kontekst

Gitte Ottosens indlæg, om komplekse systemer i en agil kontekst, gav mig anledning til, at tænke lidt mere over automatisering på tværs af teams.

[6. april 2016] Når man, som Gitte beskriver, har flere teams der hver arbejder på deres delkomponenter i et samlet system, er det en stor risiko, at man ikke får gennemført en god nok systemtest i løbet af hvert sprint. Hvert team ender med at betragte deres lille komponent som et system i sig selv.

En af løsningerne Gitte lægger op til, er hardening sprints. Som hun beskriver, kan det dog stadig gå galt, og det er et meget sent tidspunkt at finde simple funktionelle fejl. Den bedste måde at løse det problem er automatisering!

Automatisering på systemtestniveau kan være problematisk af mange årsager, men som udgangspunkt er det ikke anderledes, end det de individuelle teams allerede gør for deres egen komponent - eller burde gøre! De fleste agile teams automatiserer store mængder unittests og unit integrations test, men bør også automatisere tests på systemtestniveau. Storytesten er et godt eksempel. For hvert acceptkriterie på en story, bør der være en automatiseret test samtidig med, at der er en række unittests der tester variationerne omkring storytesten. Et eksempel på de testcases jeg taler om, kunne være på et pensionssystem:

Jeg logger ind, opretter en police med dækning x+y+z, indbetaler i 10 år, sætter policen til udbetaling og ser, at der bliver udbetalt penge.

Ved denne test kan det sagtens være et enkelt team der laver alt softwaren, men det kan også være, at et team laver oprettelse, et laver indbetaling, og et tredje laver udbetaling. Hvis det sidste er tilfældet vil ingen af de tre teams typisk få skrevet testcasen, for slet ikke at tale om at få den automatiseret.

Hvis man er i ovenstående situation, er det vigtigt at have lagt en strategi. Scrum lægger f.eks. op til at holde "scrum-of-scrums", hvilket er et møde hvor hvert team sender en repræsentant, og der tales om, hvordan de enkelte teams arbejde har/vil påvirke de andre. Det er nok ikke nok til at få koordineret automatisering på tværs, men konceptet er godt nok. F.eks. kunne produktejerne mødes (evt. med en tester eller to for support), og definere en række testscenarier der går på tværs af løsningen. Testcasen ovenfor er et eksempel på dette. Herefter skal testcasen automatiseres. De første par gange vil intet team typisk have kompetencerne til dette, men man kan starte ved at sætte repræsentanter for hvert team sammen. De kan så automatisere de første par testcases, og på et eller andet tidspunkt vil der have været nok vidensdeling til, at et team godt kan lave en automatiseret testcase der går på tværs af hele systemet.

Det er et stort, og vigtigt skridt, men der er dog nogle punkter der er værd at overveje:

  • Vedligehold: Automatiske test har det med at gå i stykker, så det er nødvendigt at få defineret, hvilke testcases der vedligeholdes af hvilke teams. 
  • Synkronisering: Automatisering på tværs bliver en del lettere, hvis alle teams sprints starter og stopper samtidig. Det gør i øvrigt også mange andre ting lettere, når man har mange teams. Hvis ikke det er muligt, skal man holde meget skarpt øje med hvornår der kommer nye komponenter, og hvordan de påvirker resten af systemet.
  • Testdata: For at kunne teste på tværs er det pludselig ikke nok, at have testdata der passer til hver komponent. I pensionseksemplet skal man f.eks. sikre, at det samme CPR-nummer eksisterer i alle komponenterne.
  • Løbende udvidelse: Ofte kan man ikke automatisere hele scenariet til at starte med. Noget funktionalitet er ikke færdigt, så man må nøjes med dele af testen, eller simulere dele af den. Det er vigtigt at nogen har overblik over dette, så man ikke glemmer at fjerne simulatoren, når den rigtige funktionalitet er tilgængelig.

Alt i alt er der mange ting man skal tænke over, når man skal automatisere på tværs af teams. Fordelene er dog store, og når man først er kommet over den første hurdle, med at få lavet de første par testcases, er det nogenlunde "business as usual", og samtidig en stor hjælp til at sikre vidensdeling mellem de enkelte teams.

Hans-Henrik Olesen
Hans-Henrik Olesen
Managing Consultant
+45 52189718
todo todo