De fleste testere kjenner vel godt til spørsmålet: «Hvor lang tid vil det ta å teste denne saken?» Ofte er det gjerne litt nøling når vi begynner å svare. Vi er ikke alene. Estimering er en utfordring for hele teamet.
Det som gjør estimering så vanskelig er at det er mange variabler og faktorer som kan påvirke.
Hvilke variabler du velger å ta med og innholdet i dem vil avhenge av situasjonen du er i. Dermed kan vi heller ikke gi en magisk formel for hvordan vi kan estimere test. Hva kjennetegner da estimering av test?
Testing fører til mer testing
Utfordringen med å estimere for test er at tidsbruken avhenger av hva som faktisk utvikles og leveres til test. Når vi estimerer i forkant, altså før vi har tilgang til testobjektet, så er det gjerne basert på en løsningsbeskrivelse, en liste med krav eller akseptansekriterier. Vi har kanskje også en mer eller mindre bevisst tidligere erfaring som kan veilede oss. Tross dette vet vi ikke hvor mye tid vi trenger når selve leveransen står foran oss. Det vi trodde vi skulle teste og fremgangsmåten vi hadde valgt kan vise seg å ikke være den beste likevel. Vi kan rett og slett ikke vite på forhånd om hvilke avklaringer, endringer og retester som må gjøres etter at selve testingen har startet.
Testing fører til behov for mer testing
La oss se på eksempel. Før testingen starter anslår at vi trenger 6 timer på en oppgave. Etter 4 timers testing avdekkes at kravene ikke har tatt høyde for noe og det krever en endring. I utgangspunktet har vi da 2 timer igjen til å avslutte de planlagte testene og teste endringen. Noen ganger vil vi også ønske tid til å regresjonsteste som følge av endringen. I tillegg til tiden som vil gå med til selve testen, vil vi også måtte bruke tid på å avklare nye prioriteringer og avveininger mot andre oppgaver i sprinten. Noe som tar tid i seg selv.
For å ta høyde for ting som vi ikke har tenkt på, er det innen test ofte behov for utforskende test. Utforskende test har de samme utfordringene som de planlagte scenariene når det kommer til det som kan dukke opp av avklaringer eller mangler underveis. Selve den utforskende testen er det vanlig å dele inn i faste tidsrammer, for eksempel at man fokuserer på et gitt risikofelt i 30 minutter.
Testimering
Så når en tester estimerer kan man med fordel legge til tid som følge av at vi kommer til å stadig avdekke ny funksjonalitet og må gjøre avklaringer. Hva kan vi gjøre for å hindre at dette stjeler av tiden tiltenkt de andre planlagte testene som fortsatt kan være relevante å kjøre?
Det er her «testimering» kommer inn i bildet. Testimering er ikke et etablert fagutrykk, kun et ordspill på den kontinuerlige vurderingen av tidsbruk som en tester gjør av hvilke tester som MÅ, BØR eller KAN kjøres. Vi må sjonglere mellom å være smidige i tilnærmelsen samtidig som vi tenker risiko. Testobjektet og risikoen endrer seg hele tiden. Vi må slå følge og alltid kjøre de mest relevante testene, altså MÅ-testene. Hvilke tester som er i denne kategorien er altså flytende. Hvor mye tid vil vi bruke på å planlegge og gjennomføre kjøringen av disse testene? Det er fort gjort å glemme tiden det tar til forberedelser. Avklaringer om verktøy, eksterne avhengigheter, testmiljø og forberedelse av testdata er gjengangere som fort kan bli tidstyver.
Alt dette må vi se opp mot tiden vi har til rådighet. Mange bruker jo ulike Definitions of Done av typen at alle MÅ-testene skal ha blitt kjørt uten åpne alvorlige feil før vi produksjonssetter. Men ikke før vi har kjørt alle MÅ-testene vil det fort kunne dukke opp andre tester som kan gi informasjon om produktrisiko og «må» kjøres. Testimering er på mange måter en evighetsmaskin, og det er ofte opp til oss testere å stanse den slik at vi får gått i produksjon. Tiden kommer til å renne ut, og da er vi over i en annen diskusjon om gjenstående risiko. Det vil alltid være mulig å kjøre en test til, men avveiningen må gjøres opp mot en forventning om nytten av det.
Hvor lang tid tar det å lære å estimere?
Som vi har sett er estimering komplekst. De vanlige rådene gjelder også for oss testere:
- Bruk egne erfaringer som ledesnor. Jo bedre man kjenner en kontekst, jo lettere vet man utfordringer og løsninger. Dette kan gjerne kreve en strukturert datainnsamling fra tidligere prosjekter som likner.
- Ikke vær redd for å argumentere for hvordan du kom fram til estimatet. Si også gjerne hvor sikker du er på dette tallet: 90%, 60% eller 50%?
- Samarbeid og diskusjoner innad i teamet ser ut til å gjøre oss mer treffsikre. Er du i tvil, spør en venn eller bruk en av de mange teknikkene som hjelper oss til å se ting fra nye perspektiver.
- Bruk flere teknikker samtidig for å fange opp flere relevante aspekter.
- Legg til noen timer til det du ikke har tenkt på.
| Estimeringsteknikker Det finnes dessverre ikke noen 100% sikre estimeringsteknikker, men det finnes sikkert over 100 ulike teknikker. Her er bare noen få utvalgte. Story Points Smidige metoder benytter gjerne «story points», og da for å kunne forutsi hvor mye arbeid som vil kreves i en sprint. Det er gjerne teamet selv som definerer disse måleenhetene. Planning Poker Teknikken Planning Poker gir forretningssiden og IT-siden en mulighet til å diskutere ulike oppfatninger om hva som er prioritet og verdien av en sak ut fra tallverdiene på kortene. Sannsynlighet For team som ikke liker å spille poker, kan man for eksempel kun hente inn anslag og deretter diskutere det mest optimistiske, det mest pessimistiske og det som flest forventer. Her finnes det ulike måter å regne ut på, for eksempel Three-point estimation. Ekspertvurderinger Man kan ta det hele enda lengre og kun se på ekspertenes vurderinger, altså de som kjenner oppgavens tekniske sider best. Denne metoden kalles gjerne Delphi eller ETE. |
