Når skal du automatisere brukerhistorier?

Hvis du har jobbet i et smidig miljø som en kvalitetssikring, ville du sannsynligvis ha kommet over en slags testautomatisering. Jeg mener ikke enhetstestautomatisering som vanligvis er en utviklingssentrisk aktivitet, men funksjonell akseptautomatiseringstestautomatisering som vanligvis gjøres av QA eller den nye fancy rollen som programvareutvikler i Test.

La oss først se på noen kriterier og grunner til å ha testautomatisering som skal svare på spørsmålet 'Hvorfor tester skal / bør ikke automatiseres'



Repeterbarhet

De automatiserte testene skal kunne repeteres, og utdataene skal være konsistente i hvert løp, slik at utviklere kan stole på resultatet av testene. Dette betyr også at vi normalt ikke automatiserer en test hvis den bare kjøres en gang; det eneste unntaket fra dette er hvis du kjører en test mot et veldig stort antall data, for eksempel å sjekke et lenkeomdirigeringsskript med mange lenker.




Pålitelighet

De automatiserte testene burde virkelig kontrollere verifiseringene riktig og kunne bestemme faktiske resultater mot gyldige forventede resultater. Dette betyr også at hvis resultatene ikke kan bestemmes enkelt eller automatiserte tester er utsatt for miljøproblemer som kan forårsake falske positive i testresultatene, så kan ikke testene være pålitelige.



Tid

De automatiserte testene bør også spare oss for tid. Hvis en enkel test tar 10 minutter å fullføre, men det samme resultatet kan bestemmes på 1 minutt manuelt, er det best å ikke automatisere slike tester.




Sikkerhetsnett

De automatiserte testene skal gi et sikkerhetsnett for utviklere, slik at ethvert avvik fra en god fungerende kode, som et resultat av endringer i kodebasen, raskt blir uthevet og rapportert til utviklerne.



Når skal historier automatiseres?

I en typisk sprint, si at det er 7 historier som er forpliktet til en sprint, hvorav 5 er gode kandidater for å automatiseres basert på kriteriene ovenfor. Men når er den beste tiden å automatisere disse historiene? Bør vi skrive de automatiserte testene etter hvert som funksjonene utvikles? Bør vi vente til en funksjon er utviklet og deretter skrive de automatiserte testene? Skal vi vente til slutten av sprinten og deretter automatisere historiene?

I noen tilfeller når historier er feilrettinger eller liten modifisering eller forbedring av en eksisterende funksjon, er det fornuftig å skrive automatiserte tester ettersom funksjonen blir endret av utviklere. Det kan til og med være en eksisterende automatisert test for funksjonen som endres, der du bare trenger å tilpasse skriptet for å imøtekomme de nye endringene.

I andre tilfeller, når historien handler om å implementere en ny funksjon i applikasjonen, hvordan vet vi hvordan sluttproduktet vil se ut for å kunne skrive tester på forhånd? Her snakker jeg ikke om funksjonsfiler som på forhånd beskriver aksepttestene, men selve inventar eller selen-tester (implementering av tester) som kjører mot den leverte koden.


Poenget er - enhver test som skal gjøres mer enn en gang, bør automatiseres. Og hvilke tester skal vi utføre mer enn en gang? Regresjonstester. Og hva er regresjonstester? Tester som avgjør om applikasjonen har gått tilbake i funksjonalitet som et resultat av de nye modifikasjonene og funksjonene.

Men du kan bare skrive gode automatiserte regresjonstester mot et system som er stabilt, godt forstått og deterministisk når det gjelder oppførsel med kjente innganger og utganger.

Problemet med å prøve å skrive automatiserte tester mot en funksjon mens den utvikles, er at du potensielt kan bruke lang tid og mye krefter på å skrive automatiserte skript mot noe som er ustabilt og gjenstand for konstant endring under sprinten. Dessuten, hvor mange ganger har vi sett en historie være forpliktet til en sprint og deretter senere blitt trukket ut av sprinten? Så har vi kastet bort tid på å skripte noe som ikke kom inn i systemet.

Noen organisasjoner innfører til og med en streng regel om at en historie ikke blir 'ferdig' før den er fullstendig automatisert! Skal vi stoppe en viktig funksjon for å bli utgitt fordi QA ikke eller ikke kunne gi automatisering i tide på grunn av forskjellige grunner? Eller en historie er ikke 'ferdig' fordi vi ikke har et automatisk skript for å kontrollere eksistensen av en knapp på en side. Alvor?


Det beste formålet med automatiseringstesting er regresjonstesting og regresjonstester kjøres alltid mot et kjent tilstand og deterministisk system for å kunne oppdage endringer i grunnlinjen, og for å få et meningsfullt resultat fra en automatisert test, er bare når testen har kjørt og sendes manuelt minst en gang, slik at du kan sammenligne resultatene av den automatiske kjøringen mot manuell kjøring.

Etter denne definisjonen skal historiene automatiseres (implementeringen) innen sprint, og bare når funksjonen er fullstendig bekreftet manuelt. Når historien er fullført og den er bekreftet manuelt først, er det en pålitelig funksjon og et stabilt system som du deretter kan designe og skrive automatiserte tester mot. Når den automatiserte testen er implementert, blir den deretter lagt til regresjonstestpakken for å overvåke og oppdage regresjonsfeil når neste funksjoner blir utviklet.