Hvornår skal man automatisere brugerhistorier?

Hvis du har arbejdet i et smidigt miljø som en kvalitetssikring, ville du sandsynligvis være stødt på en slags testautomatisering. Jeg mener ikke enhedstestautomatisering, som typisk er en udviklercentreret aktivitet, men funktionel accepttestautomatisering, der normalt udføres af QA eller den nye smarte rolle som Softwareudvikler i Test.

Lad os først se på nogle kriterier og grunde til at have testautomatisering, som skal besvare spørgsmålet om 'Hvorfor tests skal / bør ikke automatiseres'

Gentagelighed

De automatiske test skal gentages, og output skal være ensartet i hver kørsel, så udviklere kan stole på resultatet af testene. Dette betyder også, at vi normalt ikke automatiserer en test, hvis den kun køres en gang; den eneste undtagelse herfra er, hvis du kører en test mod et meget stort antal data, såsom at kontrollere et linkomdirigeringsscript med mange links.

Pålidelighed

De automatiske tests burde virkelig kontrollere verifikationer korrekt og kunne bestemme faktiske resultater i forhold til gyldige forventede resultater. Dette betyder også, at hvis resultaterne ikke let kan bestemmes, eller automatiske tests er underlagt miljøproblemer, der kan forårsage falske positive resultater i testresultaterne, så kan testene ikke være pålidelige.

Tid

De automatiserede tests bør også spare os tid. Hvis det tager 10 minutter at gennemføre en simpel test, men det samme resultat kan bestemmes manuelt på 1 minut, er det bedst at ikke automatisere sådanne tests.

Sikkerhedsnet

De automatiske test skal give et sikkerhedsnet til udviklere, så enhver afvigelse fra en god fungerende kode som et resultat af ændringer i kodebasen hurtigt fremhæves og rapporteres til udviklerne.

Hvornår skal historier automatiseres?

I en typisk sprint, sig at der er 7 historier, der er forpligtet til en sprint, hvoraf 5 er gode kandidater til at blive automatiseret baseret på ovenstående kriterier. Men hvornår er det bedste tidspunkt at automatisere disse historier? Skal vi skrive de automatiserede tests, når funktionerne udvikles? Skal vi vente til en funktion er udviklet og derefter skrive de automatiserede tests? Skal vi vente til slutningen af ​​sprinten og derefter automatisere historierne?

I nogle tilfælde når historier er fejlrettelser eller mindre ændringer eller forbedringer af en eksisterende funktion, giver det mening at skrive de automatiserede tests, da funktionen ændres af udviklere. Der kan endda være en eksisterende automatiseret test for den funktion, der ændres, hvor du bare skal tilpasse scriptet for at imødekomme de nye ændringer.

I andre tilfælde, når historien handler om at implementere en ny funktion i applikationen, hvordan ved vi hvordan slutproduktet vil se ud for at kunne skrive tests på forhånd? Her taler jeg ikke om funktionsfiler, der på forhånd beskriver acceptstestene, men de faktiske inventar eller selen-tests (implementering af tests), der kører mod den leverede kode.

Bundlinjen er - enhver test, der skal udføres mere end én gang, skal automatiseres. Og hvilke tests skal vi udføre mere end én gang? Regressionstest. Og hvad er regressionstest? Test, der bestemmer, om applikationen er kommet tilbage i funktionalitet som et resultat af de nye ændringer og funktioner.

Men du kan kun skrive gode automatiserede regressionstest mod et system, der er stabilt, godt forstået og deterministisk med hensyn til adfærd med kendte input og output.

Problemet med at forsøge at skrive automatiserede tests mod en funktion, da den udvikles, er at du potentielt kan bruge lang tid og meget kræfter på at skrive automatiserede scripts mod noget, der er ustabilt og underlagt konstant ændring under sprinten. Desuden, hvor mange gange har vi set en historie blive begået til en sprint og derefter senere trukket ud af sprinten? Så har vi spildt tid på at scripte noget, der ikke kom ind i systemet.

Nogle organisationer indfører endda en streng regel om, at en historie ikke 'færdiggøres', før den er fuldt automatiseret! Skal vi stoppe en vigtig funktion, der frigives, fordi QA ikke eller ikke kunne levere automatisering i tide på grund af forskellige årsager? Eller en historie er ikke 'færdig', fordi vi ikke har et automatisk script til at kontrollere eksistensen af ​​en knap på en side. Helt seriøst?

Det bedste formål med automatiseringstest er regressionstest, og regressionstest køres altid mod et kendt tilstand og deterministisk system for at kunne opdage ændringer i basislinjen og for at få et meningsfuldt resultat af en automatiseret test er kun når testen er kørt og sendes manuelt mindst én gang, så du kan sammenligne resultaterne af den automatiske kørsel med den manuelle udførelse.

Efter denne definition skal historierne automatiseres (implementeringen) inden for sprint og kun når funktionen er fuldstændigt verificeret manuelt. Når historien er færdig, og den først verificeres manuelt, er det en pålidelig funktion og et stabilt system, som du derefter kan designe og skrive automatisere tests mod. Når den automatiske test er implementeret, føjes den derefter til regressionstestpakken for at overvåge og opdage regressionsfejl, når de næste funktioner udvikles.