Programvareteam har større frihet enn noen gang. De har tilgang til et bredt utvalg verktøy, og mange av dem er gratis. Det finnes en overflod av byggesteiner med åpen kildekode som kan brukes til å lage applikasjoner. Og best av alt: Mange arbeidsgivere oppmuntrer teamene til å sette opp sine egne utviklingssystemer og metoder, og til at teammedlemmene tar med sine egne verktøy.
Friheten til å bruke verktøyene, metodene og teknologiene du liker best og kjenner best, vil sannsynligvis bidra positivt til teamets produktivitet – helt til dere når grensene for teamets selvtilstrekkelighet.
Unngå en flaskehals i testingen
Vennen min, Jan, ledet et svært kompetent programvareteam i et selskap som utvikler spesialtilpasset programvare. De forsto virkelig hvordan de skulle jobbe smidig. Og de hadde et kvalitetsproblem. De fremskyndet utrullingssyklusen så effektivt at testingen hadde blitt en flaskehals.
Og de løste flaskehalsen ved å hoppe over testingen. Jan forsto selvfølgelig hva som måtte gjøres. Han lastet ned Robot Framework, brukte det til å bygge et tilpasset rammeverk for testautomatisering for teamet og koblet det til pipelinen for kontinuerlig integrasjon. Gradvis la han til flere og flere tester og utvidet rammeverket med et stort antall nøkkelord på høyt nivå for å gjøre det enkelt å skrive testskript.
I mellomtiden opplevde de andre teamene – og det var mange av dem – lignende utfordringer og løste dem på sine egne måter, med Selenium eller et annet verktøy etter eget valg.
Team trenger et rammeverk for testautomatisering for alle
Pessimister sier at enhver løsning inneholder kimen til et nytt problem. Jan oppdaget snart at han hadde blitt testautomatiseringsingeniør på heltid. Joda, bibliotekene hans var enkle å bruke – for ham – og testarkitekturen hans var enkel å forstå – for ham. I alle andre team var det en kollega i samme situasjon. En av dem byttet jobb. Utvikleren som overtok, bestemte seg for å skrive om alt fordi hun ikke likte måten automatiseringen var bygget på, og syntes det var vanskelig å forstå. Da mange team begynte å rapportere disse utfordringene til lederne sine, oppsto det åpenbare spørsmålet: Hvorfor er det ingen konsistens på tvers av teamene?
Noe måtte gjøres. Løsningen var åpenbar: La oss etablere et sentralisert team for testautomatisering som skal betjene utviklingsteamene ved å tilby ett rammeverk for testautomatisering for alle. I praksis besto teamet av Jan og en annen utvikler. Det var da kampen virkelig begynte.
Del metodikk, ikke bare verktøy
Testene sluttet ofte å fungere. Det gjorde også rammeverket. Utviklingsteamene hadde problemer med å endre praksisen sin for å tilpasse seg verktøyene, og verktøyteamet hadde problemer med å imøtekomme alle disse ulike behovene. Rammeverkets kompleksitet fortsatte å øke. Flaskehalsen i testingen var blitt omdannet til en flaskehals i verktøyene for testautomatisering.
Delte interne verktøy er en god idé, men det er vanskelig å få dem til å fungere. For å lykkes må verktøyet forvaltes som et ekte produkt, og det må testes grundig. Paradoksalt nok er interne rammeverk for testautomatisering ofte fulle av feil. Men det finnes en enda større utfordring. For å dra nytte av delte verktøy i stor skala trenger du også en felles metodikk.
Historien om Jan er typisk – og den er ikke over ennå. Nå vurderer de sitt neste trekk: gå tilbake til autonome team og akseptere kostnaden, investere mer i de delte verktøyene og etablere en konsistent metodikk, eller velge et kommersielt verktøy og kun fokusere på metodikken. Ingen av disse valgene er feil, men hvert av dem vil få ulike konsekvenser.
