thought-catalog-214785
>

Automatiserte tester - hva og hvorfor

Stian Sjoli 
24. feb. 2019

Når Programvare brukes kan uventet oppførsel medføre tap av verdier, noe som koster mer jo seinere det oppdages [1]. Slike feil kan ofte spores tilbake til designfeil eller antagelser gjort i kildekoden til varen. Det er derfor viktig å avdekke feil og mangler så tidlig som mulig i utviklingsprosessen, noe som har ført til metodikk, f.eks test-dreven utvikling, der tester til og med skal skrives før kildekoden. Dette innlegget vil presentere hva automatiserte tester er og litt om nytteverdien til slike tester.

Hva er automatiserte tester?

Testing er ofte omtalt som prosessen der man evaluerer kvaliteten til en programvare, og her er det blant annet viktig å avdekke feil og mangler. Automatiserte tester er programvare skrevet for å bekrefte at annen programvare (her omtalt som kildekode) fungerer slik som ønsket. Disse kan skrives enten før, samtidig eller etter at kildekoden er ferdig, og fungerer da som et virkemiddel for å oppdage uventet oppførsel og mangler. 

 

Testpyramiden

Tester kan deles inn i tre typer; enhets,  integrasjon eller ende-til-ende. Ende-til-ende tester, eller funksjonelle tester, innebærer å teste funksjonalitet i kildekoden som helhet, noe som innebærer at de er langsomme og av mange grunner ofte kostbare. Enhetstester forsøker på den andre siden å teste enkeltkomponenter i kildekoden i isolasjon, og er derfor gjerne raskere og mindre kostbare. Integrasjonstester ligger i det midterste laget da disse tester interaksjonen mellom to eller flere komponenter i kildekoden. Det er ønskelig at disse danner en pyramide for å skape et balansert forhold mellom testlagene, et konsept beskrevet av Mike Cohn i Succeeding with Agile [2]. 

 

Hvorfor automatiserte tester? 

En manuell tester er god til å avdekke uante feil og mangler, f.eks igjennom utforskende testing, som krever menneskelig kreativitet og oppfinnsomhet, men vil samtidig bruke lengre tid på regressjonstesting. Regressjonstesting er verifisering av at kildekoden fortsatt har ivaretatt all funksjonalitet ved kodeendringer. Dette er repetitivt arbeid, som kan utføres raskt av automatiserte tester.  

Slik brukertesting tester gjerne i det øverste laget i testpyramiden, ende-til-ende, og er ikke en fullverdig erstatning for automatiserte tester, blant annet fordi de ikke klarer å penetrere dypt nok ned i kildekoden slik at veien mellom årsak og symptom for feilen er lengre enn for automatiserte tester plassert på riktig nivå i testpyramiden. 

Skrives tester parallelt med kildekoden, og kjøres jevnlig vil man på et tidlig tidspunkt belyse når kodeendringer har introdusert feil i kildekoden. Da har testene fungert som en barriere for å forhindre regresjon av funksjonalitet, man har vunnet en trygghet på at kildekoden er intakt og perioden tester undersøker kildekoden overlapper med når kildekode utvikles. Alle disse faktorene gjør at automatiserte tester er en viktig faktor i kontinuerlig levering av programvarefunksjonalitet.  

Det er også slik at utviklere bruker mesteparten av tiden sin til å lese kode (side 5 [3]), og skrevne tester er et eksempel på god kodedokumentasjon i den forstand at de forklarer og tester forventet oppførsel. Noe som blant annet gjør det lettere for en utvikler å forholde seg til andres kode. De samme testene tilfører også en trygghet under omskrivning av kildekoden.  

 

Referanser

[1] Herb Krasner. "The Cost of Poor Quality Software in the US: A 2018 Report". 2018. 

[2] Mike Cohn. "Succeeding with Agile:Software Development Using Scrum". 2009. ISBN-13: 978-0-321-579-362.

[3] Steve Freeman & Nat Pryce. "Growing Object-Oriented Software, Guided by Tests". 2010. ISBN-13: 978-0-321-50362-6.