BLOG
SOFTWARETEST

Blog: Agil test af komplekse systemer

Så er det tid til næste kapitel om den agile bageform. Disse blogposts er skrevet ud fra en testers perspektiv, men mange af de problemstillinger vi oplever, vil være relevante på tværs af roller.

[17. marts 2016] Denne gang er fokus på de komplekse systemer: Kan man passe dem ind i en agil bageform? Det umiddelbare svar er JA! Nok forholdsvis hurtigt fulgt af et "men så....". Når jeg taler om komplekse systemer, kunne det f.eks være elektroniske patientjournaler eller andre lignende sundhedsfaglige systemer. Men også de komplekse CMS systemer der benyttes indenfor pension og bank, eller måske kommando- og kontrolsystemer til forsvaret. Her er ofte tale om systemer med integrationer til eksterne systemer, komplicerede arbejdsgange og sikkerhedsmæssige aspekter der skal dækkes. Og så er de ofte større end at de kan rummes i et enkelt agilt team (7 deltagere plus minus 2 personer). 

Første gang jeg var med til at teste i en agil kontekst, var vi fuldt fokuseret på de enkelte userstories – det var måden krav blev defineret på i projektet, grundlaget for både udvikling og test. Vi var måske 4 eller 5 forskellige teams i projektet, der arbejdede på det samme system. Hver på vores del af backloggen. Da vi var under transition fra vandfald til agile havde vi valgt ikke at nedlægge systemtestfasen, og skulle heller ikke sætte i drift i slutningen af hvert sprint. Så efter en række sprint (måske 5-6 stykker) var det tid til systemtest. Bygget blev installeret på testmiljøet, og vi var klar med vores testcases. Det skulle jo bare være regressionstest af systemet, for vi havde jo testet stories løbende.... Det blev en meget interessant oplevelse, for vi havde siddet 4-5 teams med tunnelsyn! Alle havde vi fokuseret på hvad vi var i gang med at lave - havde fokuseret på de enkelte userstories, vi havde ansvaret for at udvikle. Ingen var på noget tidspunkt stoppet op, trådt et skridt tilbage og sagt ”gad vide om det vi laver påvirker de andre teams?”. Eller ”gad vide om det eksisterende system stadig har det godt?”. Vi havde ikke en stor automatiseret regressionstest suite der kørte hver nat, så regressionstesten var manuel – og den havde vi jo ikke tid til løbende mens sprintene kørte.

Intet virkede, bygget kunne knapt nok starte, og da det kom i gang væltede det ind med fejl – primært relateret til den manglende fokus på systemet som helhed.

Det var dyre lærepenge, men i vores retrospektive på den systemtest, identificerede vi en række problemer:

  • Vi havde ikke tilstrækkelig fokus på, om en story kunne kompromitere de forrige stories.
  • Vi tænkte ikke på featuren, altså samlingen af userstories, der samlet set gav ny værdi for slutbrugeren.
  • Vi havde ikke tilstrækkelig fokus på afhængigheder til andre userstories eller features, der skulle udvikles af andre teams. Og det var, vel at mærke, ikke kun test der var ramt her.
  • Fordi vi ingen automatiseret regressionstest havde, opdagede vi på intet tidspunkt, at vi ødelagde noget for de andre teams – ikke før til allersidst.
  • Fordi vi kørte en række sprints i forlængelse af hinanden, inden vi var klar til at gå i produktion med en release, kunne ”hyldevaren” fra de tidligere sprints godt degenerere pga senere udvikling, og det opdagede vi ikke. Især ikke hvis den senere udvikling blev lavet af et andet team.
  • Generelt var det et manglende helhedssyn. For meget tunnelsyn i de enkelte teams.

Når man arbejder med udvikling af et system fordelt på flere teams, så er der et meget større behov for koordinering og fokus på afhængigheder. Man kan ikke udelukkende forvente, at den slags håndteres af den direkte kommunikation mellem deltagerne – via stand up og den slags – for det gjorde vi jo alt sammen pr. team. Der måtte mere til, mere fokus på at koordinere mellem teams på mange niveauer: Når vi planlagde, når vi designede og udviklede (genbrug, afhængigheder osv.) og selvfølgelig også når vi skulle teste.

Men ét var den løbende koordination, afklaring af afhængigheder og kommunikation på tværs – noget andet var, hvad der var praktisk muligt.

Som udgangspunkt så forventes det, at alt test i et agilt projekt foregår i teamet - og i sprintet. Uanset om det er unittest, systemtest, integrationstest, accepttest eller måske nogen af de nonfunktionelle ting som performance, brugevenlighed og så videre. Selv i projekter med kun et team og mere overskuelige systemer, stiller det store krav til teamet (ja du læste rigtigt... teamet, ikke testeren :)). Dels kræver det, at man har stor fokus på løbende automatisering af sin test, så mest muligt regressionstest kan køres automatisk og som en del af den kontinuerlige integration (se tidligere blogpost om regressionstest), dels kræver det, at man i teamet har plads i slutningen af sprintet til at få lavet supplerende test (udover den storyfokuserede), og rette eventuelle fejl der måtte være dukket op. Når projekterne bliver større og systemerne mere komplekse, så bliver denne udfordring også større. Vi skal dels have fokus på test af systemet som helhed, måske teste end-to-end scenarier der kræver, at det komplette system er til rådighed. Vi skal have adgang til et miljø med integrationer løbende i sprintet, og naturligvis også kompetencer og værktøjer til at kunne gennemføre større performance og skalerbarhedsscenarier. Og så er der jo useraccepttesten. Hvis man har en ekstern kunde, så er der i kontrakten ofte fastlagt rammer omkring afleveringsforretningen, der ligger udover, at man laver demo i hvert sprint af afsluttede user storys, og man har brug for en egentlig aktivitet for dette, for at få sign-of på leverancen.

Defor bliver det sværere og sværere at holde alt indenfor sprintet, og have ”potentially shipable software” i slutningen af hvert sprint. Det kan blive nødvendigt med end-games eller hardening sprints (kært barn har mange navne :)). Dels for at få de ovennævnte testaktiviteter gennemført, men også for at sikre, at andre tværgående aktiviteter er på plads, herunder brugerdokumentation, review af diverse blivende dokumenter, rettelser af fejl man ikke har nået i sprints osv. Dette er lidt kontroversielt – mange agilister mener, at det er et markant brud med de agile principper, men det kan være et nødvendigt brud. Vælger man denne tilgang er det vigtigt at holde fokus! Hvad er formålet med dette hardening sprint? Det skal ikke blive en undskyldning for at skyde fejlrettelser og refactoring i sprintet. Vi skal undgå at skabe en pukkel af teknisk gæld vi skubber foran os til hardening sprintet, det er alt for risikabelt. Så en klar formulering af formål og rammer - og de overholdes.

Det er derfor nødvendigt med en klar formulering af formål og rammer for hardening sprintet, og der skal i alle teams være fokus på, at de rammer bliver overholdt!

Gitte Ottosen
Gitte Ottosen
Managing Consultant
+45 39778711
todo todo