Hvis du noen gang har sittet i et møte med utviklere, eller fulgt diskusjoner i teknologimiljøer, kan du fort få inntrykk av at de snakker mer om testing enn om selve utviklingen. Samtalen dreier seg om testdekning, automatiserte tester, regresjonstester, pipelines og kvalitetssikring, mens selve funksjonaliteten, altså det produktet faktisk skal gjøre, nesten kan virke som en bisetning. Burde ikke utviklere først og fremst være opptatt av å utvikle?
Testing er egentlig bare utvikling satt i system
For mange utenfor teknologibransjen kan ordet testing høres ut som noe som skjer etter at utviklerne er ferdige med jobben sin. Litt som en kontroll på slutten før noe sendes ut til kunder eller brukere. Men slik fungerer det sjelden i praksis.
Før kunne en utvikler lage en funksjon, trykke på en knapp og se om det fungerte. Hvis noe gikk galt, rettet man feilen og prøvde igjen. I små systemer fungerer dette fortsatt ganske godt.
Problemet oppstår når løsningene blir store, består av mange integrasjoner og brukes av tusenvis eller millioner av mennesker samtidig. Da holder det ikke lenger å teste litt tilfeldig og håpe at alt fungerer. En liten endring ett sted kan plutselig påvirke noe helt annet, og ofte oppdages ikke feilen før brukerne begynner å klage.
Når utviklere snakker mye om testing, handler det i praksis om å håndtere kompleksitet. Jo større et system blir, desto vanskeligere blir det å holde oversikt over alle sammenhenger og avhengigheter.
Tester fungerer derfor som en slags sikkerhetsmekanisme som gir utviklere en måte å kontrollere at systemet fortsatt oppfører seg som forventet etter at noe er endret.
En god teststrategi kan blant annet bidra til å sikre at
- nye funksjoner ikke ødelegger eksisterende funksjonalitet
- feil oppdages tidlig i utviklingsprosessen
- flere utviklere kan jobbe parallelt uten å skape uforutsigbare konsekvenser
- systemet kan videreutvikles over tid uten at stabiliteten forsvinner
Testing er selve utviklingen
I moderne utviklingsmetoder har testing i stor grad flyttet seg fra slutten av prosessen til å bli en integrert del av selve utviklingsarbeidet. I noen tilfeller skriver utviklere til og med testene før de skriver funksjonen.
Prinsippet bak denne tilnærmingen er enkelt. Først beskriver man hvordan systemet skal oppføre seg gjennom en test, deretter skriver man koden som får testen til å bestå, og til slutt forbedrer man løsningen uten å bryte den oppførselen som testen beskriver.
Dermed får testene en dobbelt rolle. De fungerer både som kontrollmekanisme og som en slags levende dokumentasjon på hvordan systemet faktisk er ment å fungere.
Når nye utviklere kommer inn i et prosjekt, kan de ofte forstå systemet raskere ved å lese testene enn ved å lese selve koden.
Den skjulte gevinsten: Mindre feilsøking
Mange utviklere har opplevd prosjekter hvor små endringer plutselig skaper nye feil i helt andre deler av systemet, og hvor timer eller dager går med til å finne årsaken.
En av de mest undervurderte effektene av gode tester er at de reduserer behovet for feilsøking senere. Når et system har gode tester, vil mange av disse feilene bli oppdaget automatisk lenge før de når brukerne. Dermed kan utviklere jobbe raskere, selv om det kan virke som de bruker mer tid på testing.
I gode utviklingsmiljøer er testing ikke bare en teknisk praksis, men en del av kulturen. Det handler om en felles forståelse av at kvalitet ikke oppstår tilfeldig, men må bygges inn i systemet fra starten av.
Dette betyr ikke at alle er enige om hvor mye testing som er riktig. Noen miljøer kan bli så opptatt av testdekning at utviklingen nesten stopper opp, mens andre tar større sjanser og prioriterer fart fremfor kontroll.
Når testing sier noe om modenheten i et fagfelt
Hvis vi løfter blikket litt, ser vi at dette ikke bare gjelder programvareutvikling. Mange fagfelt følger samme mønster. Jo større konsekvensene av feil er, desto mer tid brukes på kvalitetssikring.
I luftfarten brukes enorme ressurser på testing, simulering og sikkerhetsrutiner før et fly settes i drift. I medisinsk teknologi kan det ta år å dokumentere og validere en løsning før den tas i bruk.
Den samme tankegangen har etter hvert også spredd seg til mange andre bransjer.
I moderne bilproduksjon testes alt fra kollisjonssikkerhet til programvaren som styrer bremsesystemer og sensorer. Innen netthandel brukes kontinuerlig testing for å analysere hvordan små endringer påvirker kundeopplevelse, salg og brukeradferd. Banker og betalingstjenester simulerer enorme mengder trafikk og feilscenarier for å sikre at systemene tåler belastning og angrep.
Selv utenfor teknologi ser vi lignende mønstre. Store organisasjoner tester nye arbeidsprosesser i mindre skala før de rulles ut bredt. Markedsførere A/B-tester budskap og design for å redusere risiko og forstå hva som faktisk fungerer. Produktutvikling handler i stadig større grad om å validere antakelser tidlig, før man investerer for mye tid og penger i feil løsning.
På mange måter handler dette om det samme overalt: Å gjøre små kontrollerte feil tidlig er billigere enn store ukontrollerte feil senere.
Når utviklere diskuterer testing mer enn funksjonalitet, er det derfor ikke nødvendigvis et tegn på at de har mistet fokus. Det kan like gjerne være et tegn på at faget har blitt mer profesjonelt.
Eksempel: Hvordan en test egentlig fungerer
Tenk deg at du skal forklare et datasystem hva en bil er.
For oss mennesker virker svaret åpenbart. Vi vet intuitivt at en bil normalt har fire hjul, motor og er laget for å frakte mennesker eller varer. Men et datasystem vet ingenting før reglene er definert. Derfor må systemet testes:
- Hva skjer hvis bilen bare har ett hjul?
- Hva hvis den mangler motor?
- Hva hvis noen prøver å registrere en sykkel som bil?
- Hva hvis bilen har fem hjul?
- Hva hvis informasjon mangler helt?
Gjennom slike tester kontrollerer utviklerne at systemet reagerer riktig både når alt er korrekt, og når noe er uventet eller feil.
På mange måter er dette kjernen i moderne testing. Det handler ikke bare om å bekrefte at noe fungerer, men om å bygge trygghet rundt hvordan systemet oppfører seg i ulike situasjoner.
En ekstra pirkete utvikler vil kanskje påpeke at en bil ikke nødvendigvis må ha fire hjul, at det finnes trehjulinger eller elektriske kjøretøy uten tradisjonell motor. Men det er egentlig bare et tegn på at eksempelet fungerer. For da begynner man automatisk å tenke:
- Hvilke regler gjelder?
- Hvilke unntak finnes?
- Hvordan definerer vi grensene?
Og det er jo nettopp slik testing fungerer i praksis.
Hvordan testing skaper tryggere systemer og bedre samarbeid
Bak alle tekniske diskusjoner om testdekning, automatiserte tester og kvalitetssikring ligger det egentlig et ganske enkelt spørsmål: Kan vi stole på systemet vårt?
- Kan vi gjøre endringer uten at noe uventet skjer.
- Kan flere mennesker jobbe på samme kode uten at alt bryter sammen.
- Kan vi bygge videre på det vi allerede har laget.
Når utviklere bruker mye tid på testing, handler det derfor ikke bare om kode. Det handler om å skape tillit, både til systemet, til teamet og til at det som bygges i dag fortsatt fungerer i morgen.
Jo mer komplekse systemer og organisasjoner blir, desto viktigere blir det at fagmiljøer forstår hverandre. Når utviklere er åpne om hvordan de jobber, hvorfor testing er viktig og hvilke metodikker som brukes, blir det lettere for mennesker uten teknisk bakgrunn å ta bedre beslutninger.
En leder som forstår hvordan ulike fagfelt faktisk arbeider, vil lettere kunne lage realistiske planer, prioritere riktig og skape bedre samarbeid mellom teamene. Mange konflikter i prosjekter handler nemlig ikke om manglende vilje, men om manglende forståelse for kompleksiteten de ulike fagområdene jobber med.
Jeg tror testing har blitt en så stor del av moderne utvikling, fordi kompleksiteten i dagens systemer gjør struktur, kvalitet og samarbeid viktigere enn noen gang, I en verden hvor stadig mer av samfunnet vårt styres av programvare.
