Denne ganger var frokostseminaret delt, med to ulike innlegg om testautomatisering. Audun Urke fra prosjektgruppen TestInnsikt introduserte SOCOs nye plattform for analyser av testfaget, testinnsikt.no. Cecilie Haugstvedt delte av sine erfaringer og ga gode praktiske råd for å både unngå utfordringene og løse problemene.
Sannheter i søkelyset
Hva vet vi egentlig om testautomatisering i Norge? Etter å ha sendt ut spørreundersøkelser og analysert resultatene, kunne testinnsikt.no lanseres tidligere i år. I sin presentasjon beskrev Audun hvordan prosjektgruppen jobbet med å finne frem til tilsynelatende sannheter om testautomatisering, som de så satte seg fore å undersøke.
Hypotesene om hvordan vi velger å automatisere skulle vise seg vanskelige å bruke til bastante konklusjoner.
«Valg av verktøy styres av tilgjengelige utviklingsspråk og plattformer»?
– Nja, egentlig kan vi bare si at det ville vært riktig for enhetstester.
«De som har høy utrullingsgrad har mye testautomatisering»
– Vel, det er mange som produksjonsetter minst en gang i uken som ikke har mye automatisering.
«Har du først investert mye i testautomatisering, så har du det på alle testnivåene»
– Kanskje, men det er ikke mange med mye automatisering som har det på alle tre testnivåene.
«Testerne skriver mer tester på lavere nivåer»
– Ikke alene, men de bidrar.
Det er altså vanskelig å konkludere bastant, men Audun lanserte en ny hypotese om at dette er tegn på at vi er blitt flinke til å bli bevisste egne behov og forutsetninger. Jo bedre vi kjenner vår egen situasjon og rammer, jo lettere blir det å vite hvilke råd og erfaringer vi bør lytte til.
Og det fikk publikum i del to av frokostseminaret!
Behov og problemer
Cecilie Haugstvedt pekte på flere fallgruver som gjerne oppstår med testautomatisering. Mange av dem hadde som fellesnevner vilkårlige målsetninger som ikke tar hensyn til konteksten. Du bør ikke sette mål for testdekning bare for å sette mål, og det er lurt å tenke gjenbruk når manuelle regresjonstester skal automatiseres.
Da er det heller å anbefale å fokusere på hva som er behovene dine, og hvor problemene oppstår under utviklingsløpet.
- Det er vanlig at det oppstår problemer med mye feil i testautomatiseringen, så her bør du finne rotårsaken.
- Ikke vær dogmatisk med valg av verktøy. Ta heller vare på folkene som ønsker å forbedre testene.
- Områder som krever mye utvikling er gode kandidarer til flere enhetstester.
- Tester som er utdaterte, trege eller ustabile kan forbedres gjennom kontinuerlig forbedring, parprogrammering eller gruppeprogrammering.
- Testdata kan bli mangelvare for enkelte testscenarier. Unngå bruk av produksjonsdata!
Som de to innleggene viste, er testautomatisering altså komplekst og veldig situasjonsbetinget. Selv om vi nok er et stykke fra å kartlegge det store bildet, så kjenner vi til vante fallgruver og tiltak som virker.
