Testprosess som støttehjul for smidig

Tradisjonelle modeller: fokus på forutsigbarhet

Smidig prosjektgjennomføring er grunnleggende forskjellig fra tradisjonell. Tradisjonelle modeller har fokus på forutsigbarhet, man legger en plan, og styrer etter den. Endringer er ikke av det gode siden de har en stygg tendens til å påvirke de planene man har lagt. Erfaring opparbeidet underveis blir heller ikke tatt hensyn til i stor nok grad, siden erfaringer gjerne vil medføre endringer.

Smidig: Optimalisert for endring

Smidige prosjekter kjøres derimot etter en empirisk modell, optimalisert for å håndtere endring og for å utnytte den kunnskapen man opparbeider seg underveis i et prosjektløp. En ting er sikkert, endringer blir det - i alle prosjekter. Tiden går, verden rundt endrer seg, kravene til systemene endrer seg, og kunnskapen til de involverte i prosjektet endrer seg. For å møte ønskene om endring og å kontinuerlig utnytte kunnskapen på en best mulig måte har smidige prosjekter korte tilbakemeldingsløkker på alle nivåer der man tilstreber å utnytte all den kompetansen og kunnskapen man skaffer seg – kontinuerlig. Endring er altså ønsket!

Å prøve å sykle etter en planlagt rute, helt uten å innhente og styre etter tilbakemeldingene man får underveis på sykkelturen virker ikke som noen god idé

Her spiller test og kvalitetsaktiviteter en veldig viktig rolle for å samle informasjon om produktet under utvikling. Hovedfokus for disse aktivitetene vil være å til enhver tid vite mest mulig om det produktet man bygger – både om det er det riktige produktet og om vi bygger det på riktig måte.

Å prøve å sykle etter en planlagt rute, helt uten å innhente og styre etter tilbakemeldingene man får underveis på sykkelturen virker ikke som noen god idé, og litt sånn er det med IT-prosjekter også. Det er lurt å ha øyne og ører åpne hele tiden for faktorer som påvirker produktet – eller sykkelturen om du vil.

Testrollen i et smidig utviklingsprosjekt

Smidige prosjekter kommer i mange slags varianter, og skal du virkelig klare å utnytte de mulighetene som ligger i smidig tankegang må testaktivitetene foregå på en annen måte enn tidligere. Mens fokus tradisjonelt har vært å finne feil, vil fokus i et smidig prosjekt være å unngå å produsere feil i utgangspunktet, det vil si å bygge et best mulig produkt.

Mens fokus tradisjonelt har vært å finne feil, vil fokus i et smidig prosjekt være å unngå å produsere feil i utgangspunktet

Hovedarbeidsoppgaven vil derfor være å fokusere på å innhente informasjon om tilstanden til produktet. Vi ønsker så tidlig som mulig å samle og bruke kunnskap, både om vi lager riktig “ting”, og om “tingen” har rett kvalitet.

Felles ansvar for sluttproduktet

For å få til dette trenger man en fellesskapsfølelse - og at man legger opp til at alle bidrar med det de kan til enhver tid. Felles ansvar for sluttproduktet er en kjerneverdi for deltakerne i et smidig team.

For en tester kan det for eksempel bety å stille de gode spørsmålene om testbarhet før det bygges noe som helst. Eller ved å avklare hva som skal skje med applikasjonen hvis et bakgrunns-system er nede - når man designer løsningen, ikke når man tester den i etterkant. Da er det ofte for sent til å gjøre omfattende endringer og man ender opp med å bygge seg rundt feilen i stedet, det vil si man opparbeider seg teknisk gjeld.

Test vertikaler fra starten av

Generelt er det lurt med en strategi hvor man prøver ut vertikaler av funksjonaliteten fra starten av for å avdekke om tankegangen/modellen/prosessen/designet er fornuftig, og å avdekke det på et tidligst mulig stadium.

For å få til dette er det nødvendig med et skifte for alle deltakere i slike prosjekter fra å fokusere på sitt bidrag og sin rolle – til å hele tiden fokusere på å bidra til et best mulig sluttprodukt. Hele utviklingsteamet har felles ansvar for å lage et godt produkt.

For oss med test som fagfelt vil dette sannsynligvis gi en mer variert hverdag, vi får utnyttet kompetansen vår bedre, og vi vil ha et mye tettere samarbeid med utviklere og kunde/produkteier.

Testprosess som støttehjul

Dersom man skal jobbe smidig kan det å få på plass en smidig testprosess gi gode “støttehjul” for å få til en helhetlig god leveranseprosess. I smidig er poenget å kontinuerlig levere fungerende software – da må man faktisk teste hele tiden!

En god modell for å planlegge testing i et smidig prosjekt er “Agile testing quadrants” – først foreslått av Brian Marick, og gjort til “allemannseie” i testkretser av Janet Gregory og Lisa Crispin i boka “Agile testing”.

Figur 1: Testing utføres både før og etter at koden skrives, og testingen har ulikt fokus

Figur 1: Testing utføres både før og etter at koden skrives, og testingen har ulikt fokus

Som figuren viser utføres testing både før og etter at koden skrives, og testingen har ulikt fokus. Kan du krysse av de fleste av disse testtypene i ditt prosjekt er du sannsynligvis godt rustet til å kunne snu deg raskt i en smidig verden.

Tegn på at metoden din kan trenge “støttehjul”

Et typisk tegn på at man fremdeles sliter med å få tatt ut de fordelene som smidig gir er at iterasjonene ser ut som dette:

Figur 2: Man har gått over fra lange fasedelte vannfallsprosjekter – til kortere fasedelte vannfallsprosjekter

Figur 2: Man har gått over fra lange fasedelte vannfallsprosjekter – til kortere fasedelte vannfallsprosjekter

Man har gått over fra lange fasedelte vannfallsprosjekter – til kortere fasedelte vannfallsprosjekter. Testing utføres i slutten av en iterasjon, eller utsettes til neste iterasjon. Oppgavene deles i mindre biter, det blir flere leveranser /iterasjoner – men fremdeles er grunnmodellen fasedelt, man har en variant av “code & fix” med overleveringer mellom utvikling og test. Da har man i realiteten kun laget seg et kortere vannfall, man har fremdeles de samme problemene - de opptrer bare litt oftere, og de store fordelene med endringsdyktigheten i smidig blir ikke utnyttet.

For å komme seg ut av dette og virkelig endre måten man tenker på, kan fokus på å endre testprosessen være gode "støttehjul" på veien. Noe testing knyttet spesifikt til leveranser vil vi alltid måtte ha, men prøv å hold det på et minimum for å kunne levere effektivt.

Fokuser på kontinuerlig testing – i hver iterasjon – og få en mer smidig utviklingsprosess som resultat!