I denne artikel vil jeg præsentere tre principper du bør følge, for at undgå en dyr og ineffektiv test-automatisering.
Når udviklingsteams vil arbejde agilt, er det typisk en udfordring for dem at levere velfungerende software hyppigt, da omkostningen ved manuelle tests er for stor.
Som team-coach med fokus på netop agil test, har jeg ofte set, at det er de manuelle regressions-, integrations- og end-2-end-tests, der tager lang tid at eksekvere. Som tidligere udvikler ved jeg også, at de manuelle tests desuden kan mindske arbejdsglæden og motivationen.
Mange udviklingsorganisationer og teams ser automatisering som en oplagt mulighed, for at nedbringe tiden på denne test-aktivitet. Der findes da også et utal af værktøjer, som kan automatisere manuelle test. Det kan dog let ende med at blive en dyr og ineffektiv portefølje af automatiserede tests.
Jeg vil derfor her give tre vigtige principper, som din strategi for test-automatisering bør følge.
3 principper til din testautomatisering
For automatiserede test er det vigtigere, at
- Vedligeholde og identificere årsag til fejl, frem for let og simpelt at kunne automatisere
- Forstå hvilket krav der testes, fremfor at kunne eksekvere testene hurtigt
- Test-automatisering implementeres ude i teamet, fremfor effektiviseres gennem centralisering
Disse principper er lettere at skrive end at følge. Jeg vil derfor i det følgende uddybe dem en efter en, så du får hjælp til at komme godt i gang med din testautomatisering.
Princip 1: Vedligeholde og identificere årsag til fejl, fremfor let og simpelt at kunne automatisere
Automatiseringsværktøjer fokuserer på, at det er hurtigt og simpelt at implementere en automatiseret test, med en meget flad læringskurve.
Det er en god egenskab, men skal ikke være det primære fokus. Automatiserede test skal ligesom softwarekode være lettere at vedligeholde, end at skrive. Testene skal nemlig være lette at læse og det skal være let at forstå hvordan de er opbygget, også flere år efter de er skrevet. Hvis de fejler, skal det være hurtigt at lokalisere hvor fejlen er opstået og hvilket krav der testes.
Når der er 10 test, er det let at overskue. Men når der er over 500 test, bliver værdien af at have et godt overblik mere værdifuldt, end hurtigt at kunne tilføje nye tests.
Den bedste måde at opbygge en automatiseret test er med en tredeling af testen. Der findes forskellige skabeloner og værktøjer til dette, eksempelvis Given-When-Then eller Arrange-Act-Assert.
Hvis ikke det er let at forstå, hvad en fejlende automatiseret test skyldes, er testen værdiløs.
Det skal være let at identificere, hvilket område af systemet fejlen kan være opstået i. Dette kan sikres ved at afvikle testen før implementeringen er lavet (test-drevet udvikling) og vurdere hvor sigende beskrivelsen er fra den fejlene test.
Princip 2: Forstå, hvilket krav der testes, frem for at kunne eksekvere testene hurtigt
Når en regressionstest skal afvikles manuelt, tager det lang tid at afviklingstiden. Derfor testes flere krav på en gang.
For automatiseret test er eksekveringshastigheden væsentligt hurtigere end ved manuelle test og testen kan desuden køre uden overvågning. De enkelte funktionelle krav kan derfor have separate automatiseret test, uden det går ud over eksekveringshastigheden.
Et eksempel kan f.eks. være at teste at et beløb vises korrekt. Tallet vises med rødt, når det er negativt og sort når det er positivt. For automatiserede test, ville et sådan krav ofte deles op i 2 separate testgrupper. En testgruppe hvor visningen er korrekt for positive og negative tal, og en anden gruppe hvor tallet er korrekt beregnet.
Det betyder selvfølgelig flere test, så derfor er grupperingen og navngivningen af de enkelte test yderst vigtigt. Der findes mange forskellige måder at navngive og strukture test på. Som team og organisation skal I derfor fastlægge en struktur og navngivningsprincipper som skal følges, for lettere at kunne søge og koble test og krav.
Princip 3: Test-automatisering decentraliseres ude i teams fremfor effektiviseres gennem centralisering
Den primære årsag til at eksekvere automatiseret test, er at de enkelte udviklingsteams får en hurtig feedback på, om systemet funktionelt fungerer, de får tillid til og de forstår feedback fra testen. Når automatiseret test oprettes og vedligeholdes uden for teamet, mistes forståelsen, den hurtige feedback og tilliden til resultatet fra testen.
Når en test ikke er konstrueret i teamet, vil den første respons typisk være, at det er testen, der er forkert og ikke systemet. Når viden om hvordan testen er implementeret og viden om hvordan systemet fungerer, er adskilt, er det en langsommelig proces at finde årsagen til fejlen.
Resultatet kan være at testen slettes fordi den ikke længere fejler eller at resultatet ignoreres. Hermed forsvinder tilliden til de automatiserede test og udviklingsteamet får ikke nogen reel værdi fra dem.
Hvis man ønsker en platform, der kan bruges til test-automatisering af mange teams, kan den bygges op centralt, men selve testene skal teamet selv definere, implementere og integrere i udviklingen.
Sådan kommer du i gang
Hvis du følger disse tre principper, er du kommet godt i gang med at skabe grundlaget for en effektiv og agil testautomatisering. Men hvor starter du? Har I de nødvendige faglige kompetencer i jeres teams? Har I den nødvendige kultur, så jeres teams er klar til at påtage sig ansvaret – og en evt. central gruppe klar til at uddelegere den?
Der kan være mange forhindringer for at komme i gang, som alle gør det svært at efterleve disse tre principper. Jeg vil derfor anbefale, at I starter så enkelt som muligt. Sikrer synlig opbakning fra lederne og synliggør de enkelte automatiserede test i teamet. Hjælp softwareudviklerne med at få kompetencerne til at lave automatiserede test. Det kan f.eks. være ved at lave nogle simple kode-opgaver, der skal løses med teknikken Test Driven Development (TDD).
Jeg har hjulpet mange teams igennem denne proces, og har derfor set mange eksempler på, hvad der virker, og absolut ikke virker. På den baggrund kan vi i Ugilic tilbyde at tage jer igennem en velafprøvet proces, hvor vi hjælper jer med at fastlægge en teststrategi, der tager udgangspunkt i den eksisterende udviklingsproces i teamet. Det skaber sammenhæng mellem de forskellige testaktiviteter og teamets øvrige udviklingsaktiviteter. Derved kommer I helt sikkert godt fra start, i jeres rejse mod en mere automatiseret testproces.
