Softwareteams har mere frihed end nogensinde. De har adgang til en lang række værktøjer, og mange af dem er gratis. Der findes et væld af open source-byggesten, som kan bruges til at skabe applikationer. Og bedst af alt opfordrer mange arbejdsgivere teams til selv at etablere deres udviklingssystemer og metoder samt lade teammedlemmerne medbringe deres egne værktøjer.
Friheden til at bruge de værktøjer, metoder og teknologier, du bedst kan lide og kender, vil sandsynligvis bidrage positivt til dit teams produktivitet – indtil det punkt, hvor du rammer grænserne for teamets selvstændighed.
Undgå en flaskehals i testningen
Min ven Jan ledede et meget kompetent softwareteam hos en virksomhed, der udvikler skræddersyet software. De forstod virkelig, hvordan man arbejder agilt. Og de havde et kvalitetsproblem. De havde accelereret deres releasecyklus så effektivt, at testningen var blevet en flaskehals.
Og de løste flaskehalsen ved at springe testningen over. Jan forstod naturligvis, hvad der skulle gøres. Han downloadede Robot Framework, brugte det til at bygge en skræddersyet ramme til testautomatisering for teamet og integrerede den i deres pipeline til kontinuerlig integration. Gradvist tilføjede han flere og flere tests og udvidede rammen med et stort antal nøgleord på højt niveau for at gøre testskripting nemt.
I mellemtiden oplevede de andre teams – og der var mange af dem – lignende udfordringer og løste dem på deres egne måder med Selenium eller et andet værktøj efter eget valg.
Teams har brug for en automatiseringsramme til alle
Pessimister siger, at enhver løsning indeholder kimen til et nyt problem. Jan fandt snart ud af, at han var blevet fuldtidsingeniør inden for testautomatisering. Hans biblioteker var ganske vist nemme at bruge – for ham, og hans testarkitektur var nem at forstå – for ham. I alle andre teams var der en kollega i samme situation. En af dem skiftede job. Udvikleren, der overtog, besluttede at omskrive det hele, fordi hun ikke kunne lide den måde, automatiseringen var blevet bygget på, og syntes, at den var svær at forstå. Da mange teams begyndte at rapportere disse udfordringer til deres ledere, opstod det oplagte spørgsmål: Hvorfor er der ingen ensartethed på tværs af teams?
Der måtte gøres noget. Løsningen var oplagt: Lad os etablere et centraliseret testautomatiseringsteam, som kan betjene udviklingsteamene ved at levere én automatiseringsramme til alle. I praksis bestod teamet af Jan og en anden udvikler. Det var her, kampen for alvor begyndte.
Del metodikken, ikke kun værktøjerne
Tests gik ofte i stykker. Det gjorde rammen også. Udviklingsteamene havde svært ved at ændre deres arbejdsmetoder, så de passede til værktøjerne, og værktøjsteamet havde svært ved at imødekomme alle de forskellige behov. Rammens kompleksitet blev ved med at vokse. Flaskehalsen i testningen var blevet omdannet til en flaskehals i værktøjerne til testautomatisering.
Delte interne værktøjer er en smuk idé, men det er svært at få dem til at fungere. For at lykkes skal værktøjet håndteres som et rigtigt produkt, og det skal testes grundigt. Paradoksalt nok er interne rammer til testautomatisering ofte fejlbehæftede. Men der er en endnu større udfordring. Hvis du vil drage fordel af delte værktøjer i stor skala, har du også brug for en fælles metode.
Historien om Jan er typisk – og den er ikke slut endnu. De overvejer nu deres næste skridt: at vende tilbage til autonome teams og acceptere omkostningen, investere mere i de delte værktøjer og etablere en ensartet metode eller vælge et kommercielt værktøj og kun fokusere på metoden. Ingen af disse valg er forkerte, men hvert af dem vil få forskellige konsekvenser.
