Hvorfor vil du automatisere en test?

Hvorfor ville du automatisere en test? Hvilke fordeler får vi med testautomatisering?

Ofte når folk blir involvert i automatisert testing, skifter hovedfokuset fra å designe gode tester til å sikre at den automatiserte koden faktisk kan utføre og kjøre testen.

I løpet av sprinten når teammedlemmer er under press for å levere historiene i en begrenset tidsramme, er det vanligvis ikke nok tid til å teste alle de planlagte scenariene, enn si å skrive automatiserte testskript for å teste den nye funksjonaliteten.


Vi kan sette oss fast i detaljene i arbeidet, koding, gjennomgang, utførelse og glemme hovedårsaken Hvorfor vi automatiserer faktisk en test!



Hvorfor automatiserer vi en test?

Dette er et av spørsmålene jeg stiller når jeg intervjuer kandidater for en testautomatiseringsrolle, og til min overraskelse ser det ut til at mange kandidater savner den viktigste og viktigste grunnen til å automatisere en test. Noen av svarene jeg får fra kandidater er ganske troverdige, men fortsatt ikke svaret jeg leter etter. Noen av svarene jeg får på ovennevnte spørsmål er:


Øk testdekningen

Dette svaret er ganske gyldig, men hvordan definerer vi dekning? Hvis vi har 100 tester, hvordan kan vi måle prosentdekningen?

Med en moden testautomatiseringspraksis på plass, kan du kjøre hundrevis av tester på relativt kort tid.

På grunn av dette kan vi opprette flere testtilfeller, flere testscenarier og teste med mer inndata for en gitt funksjon og dermed få mer tillit til at systemet fungerer som forventet.

Imidlertid, i tester og spesielt testautomatisering, betyr ikke flere tester egentlig bedre kvalitet eller større sjanse for å finne feil.


I et innlegg av Martin Fowler, hvor han diskuterer Test dekning , nevner han

Hvis du gjør et visst dekningsnivå til et mål, vil folk prøve å oppnå det. Problemet er at høye dekningsnumre er for enkle å nå med testing av lav kvalitet. På det mest absurde nivået du har AssertionFreeTesting . Men selv uten det får du mange tester på jakt etter ting som sjelden går galt og distraherer deg fra å teste de tingene som virkelig betyr noe.

Spare tid

Dette svaret stemmer også, ettersom du kan bruke verdifull tid på å gjøre interessante utforskende tester mens de automatiserte testene kjører. For en helt ny funksjon som er utviklet, kan det imidlertid ta lengre tid å skrive automatiserte skript enn å teste funksjonen manuelt i første øyeblikk.

Så det er viktig å merke seg at for å spare tid fra automatiserte tester, krever det en første økt innsats for å skriptere de automatiserte testene, og sørge for at de blir kodevurdert, og at det ikke er noen hikke i utførelsen av automatiserte tester.


Finn flere feil

Dette svaret bekymrer meg noen ganger, siden jeg aldri har sett noen beregninger som antyder at det var flere feil funnet ved automatisering enn manuell / utforskende testing. Automatiske tester sjekker vanligvis for regresjon i systemet etter at ny kode er implementert.

Det er alltid større sjanse for å finne feil i nye funksjoner enn i eksisterende funksjonalitet. Videre er det andre grunner hvorfor automatiserte tester ikke finner feil

Bytt ut manuelle testere

Dette er sannsynligvis det verste svaret jeg har hørt med hensyn til hvorfor vi automatiserer en test. Det er et klart skille mellom hva en manuell tester gjør og hva en automatisk test sjekker. Automatisert testing er ikke testing, det er kontroll av fakta.

For å kunne automatisere en test, må vi vite det forventede resultatet slik at vi kan sjekke om det er gyldig eller ugyldig. Dette er det som gir oss sanne eller falske, positive eller negative, bestå eller mislykkes.


Testing derimot er en etterforskningsøvelse, der vi designer og utfører tester samtidig. Mange ting kan oppføre seg annerledes der bare en observant menneskelig tester kan legge merke til.

Gode ​​manuelle testere vil alltid være nødvendig på grunn av ulik tankegang og evnen til å stille spørsmål ved systemet.



Forbedre kvaliteten

Selv om automatiserte tester er i stand til å gi oss raske tilbakemeldinger og varsle oss om helsen til en applikasjon, slik at vi kan tilbakestille enhver kodeendring som har ødelagt systemet, forbedrer ikke automatisert testing alene kvaliteten. Bare fordi vi har en moden testautomatisering på plass, kan det ikke garantere at ingen feil slipper inn i produksjonen.

Vi kan forbedre kvaliteten ved å sikre at riktig praksis følges fra start til slutt i en utviklingssyklus. Kvalitet er ikke en ettertanke; den skal stekes inn helt fra begynnelsen. Det er ikke nok å stole på automatiserte tester for å få et bilde av produktets kvalitet.




Så hva er hovedårsaken til at vi automatiserer en test?

Det korte svaret er repeterbarhet . Vi automatiserer en test fordi vi trenger å utføre de samme testene om og om igjen. Vil du automatisere en test hvis du bare skulle kjøre den en gang og glemme den? Selvfølgelig ikke! Tid og krefter du bruker på å automatisere testen, kunne du ha utført den manuelt.

Nå per definisjon automatiserer vi repeterbare tester, dvs. regresjonstester, som vi trenger å utføre ofte.

Så neste gang, når du vil automatisere en test, kan du ta et skritt tilbake og tenke hvor ofte er det sannsynlig at du vil utføre denne testen? Er det virkelig verdt innsatsen å automatisere testen?