Utfordrer tradisjonell testing

Utfordrer tradisjonell testing

Effektiv smidig utvikling forutsetter kontinuerlig testing. Prosessen går tregere, men det kan lønne seg på sikt.

Testing er en utfordring i all programvareutvikling. I klassisk programvareutvikling etter fossefallsmetoden er det et kjent ankepunkt at testing kommer for sent. Først når utviklerprosjektet er nesten ferdig, kommer testfasen. Dette kan bli marerittaktig ressurskrevende, og ofte også tidkrevende.

Det er ikke få gode leveringsfrister som er blåst i testfasen. Og det står ikke til å nekte at det har skjedd at testeprosedyrene er blitt tatt litt lett på når en hel organisasjon er rettet inn mot en leveringsdato. Med kostbare konsekvenser som mye brukerstøtte, akutt feilretting og fare for at prosjektresultatet ikke kan brukes til å støtte forretningene det er laget for.

Tregere, men raskere.

Under smidige utviklerprosjektet endres testeregimet drastisk. Kvalitet skal etterstrebes hele tiden, og er en grunnleggende filosofi bak metodene. I utgangspunktet starter hvert trinn i utviklerprosessen med å lage en enhetstest for å teste det som utvikles i gjeldende modul. Tanken er at dette gir en bedre planlegging av selve utviklingsprosessen.

En annen fordel som framheves i utviklermiljøet, er at det å utvikle testprosedyrer blir mindre og mindre tidkrevende. Grunnen er at mye av kodene i testerutinene lar seg gjenbruke med større og mindre modifikasjoner på alle trinn i prosjektet. Og også i andre prosjekter.

- I utgangspunktet skal man ha noe å teste allerede fra dag 1 av utviklingsprosjektet, understreker Geir Hansen, teknologidirektør i Geodata. Geodata tar mer og mer i bruk smidig programmering og Scrum-metodikk.

Større risiko for problemer

Hansen viser til at problemet med klassisk fossfallsutvikling er at man kontinuerlig aggregerer risiko for hver dag man legger til kode. Kodebasen i prosjektet utvikles hele tiden, og utvikleren legger ikke opp til å aktivt sjekke stabiliteten i den koden som er skrevet før helt til slutt.

- Jo mindre av koden man har testet, jo større risiko for at problemer kommer i slutten, forteller Hansen.

- Man er gjerne 95 prosent ferdig, men når testingen starter, viser det seg at de siste fem prosentene er enormt tidkrevende.

Det er denne fasen, som først kommer i gang når all koden er ferdig og all funksjonalitet er på plass at kostnadene i prosjektet virkelig begynner å løpe. Det er her smidige prosesser kommer inn, siden tidsbruken reduseres og usikkerheten går drastisk ned.

Fortsetter neste side

Les om:

Utvikling