Å skrive tester for å spare tid og penger

Vi har alle vært der. Prosjektet er forsinka, lista over bugs vokser, og hver gang man fikser en feil dukker en gammel en opp igjen!

En frustrerende situasjon, og en mange prosjektledere kan kjenne seg igjen i. Å lede et utviklingsprosjekt er ikke bare en komplisert administrativ utfordring. Det er ikke uten grunn man sier «å lede utviklere er som å gjete katter». Men det er også en teknisk utfordring. Hvordan vet du hvor du skal fokusere? Skal man prioritere fremdrift og akseptere at man påtar seg større og større teknisk gjeld? Eller skal man gå tilbake, re-evaluere tidligere kode, og risikere å havne ennå lengre bak skjema? Det er et dilemma.

Men det trenger ikke å være sånn. Med riktig styring fra dag 1 kan man oppdage feil tidligere, og som mange har opplevd blir det vanskeligere og mer tidkrevende å fikse en feil som har vært en del av kodebasen lenge.

Det er her kontinuerlig testing av kode kommer inn! Testdreven utvikling sikrer ikke bare kvaliteten på leveransen, men det gjør også prosjektet billigere i lengden.

Jeg kan høre deg si: «Hvordan kan prosjektet bli billigere av å skrive mer kode?»

Først av alt må man slutte å tenke på et prosjekt som en leveranse av et produkt, og mer som en pågående prosess med levetid langt utover dagen der versjon 1.0 er «ferdig». Man vet ikke før programvaren avvikles hva den komplette kostnaden blir, og det kan bli katastrofalt hvis man har signert en SLA avtale på support og feilretting. Konsulenten som står opp kl 4 natt til søndag for å fikse en feil telles ikke som en del av prosjektkostnaden, men det er absolutt en kostnad påført din bedrift som en konsekvens av hvordan prosjektet ble drevet. Alle bugs kan ikke unngås, men med riktig testing kan man iallefall fange opp de fleste før de når skjermen til kunden.

«Ok, jeg skjønner. Så hva gjør vi?»

Vel, det er den vanskelige delen. Et hvert prosjekt har sine unike sider, og man må ta høyde for både kompleksitet, forventet levetid og valgt teknologi for å finne svaret. Men det finnes noen fellesnevnere:

  1. Funksjonalitet som ikke har automatiske tester er en kilde til usikkerhet. Det er vanskelig å vite om en annen endring vil påvirke denne koden, og det gjør hele prosjektet utsatt for feil som er vanskelig å finne.
  2. Ett-klikks utrulling er målet, både i testmiljøet og produksjonsmiljøet. Å manuelt flytte filer, oppdatere konfigurasjonsfiler og sette opp databasen er en vanlig kilde til feil som er et mareritt å rette opp igjen. Et verktøy jeg anbefaler er OctopusDeploy, som tar versjonerte pakker og setter de opp på serverene med full støtte for tilbakerulling.
  3. All kode testes når en endring sjekkes inn i versjonshåndteringssystemet, hver gang. Minst en gang i døgnet kjøres en full utrullings- og integreringstest i et lukket miljø. Dette luker ut evt. følgefeil som er vanskelige å se, og hindrer situasjoner der en komponent ikke blir riktig satt opp på den store dagen. Min anbefaling er TeamCity.

Har man automatisk testing og utrulling på plass, og gode rutiner for testing via brukergrensesnittet, vil man for det meste unngå at prosjektet blir en endeløs syklus av feilretting og dårlige tilbakemeldinger fra kunder.

Man må også skrive testene riktig for at dette skal gi full uttelling, men forskjellige måter å gjøre dette på tar vi en annen gang.