Test automatiseringstips og beste praksis

Automated Testing er en viktig testaktivitet i løpet av programvarens utviklingslivssyklus fordi den kan gi rask tilbakemelding til teamet når en ny funksjon er utviklet.

Det fjerner også byrden fra QA for gjentatte ganger å kjøre regresjonstester, noe som sparer tid for QA å fokusere på andre testaktiviteter.

Testautomatisering, når det er gjort riktig, kan være veldig fordelaktig for teamet. Tipsene nedenfor hjelper deg med å få mest mulig ut av din automatiserte testprosess og aktivitet og fremhever fallgruver som skal unngås når du begynner å automatisere testene.




Manual vs Automated - Testing vs Checking

Unngå sammenligning mellom manuell og automatisert testing. De trengs begge ettersom hver tjener et annet formål. Automatiserte tester er et sett med instruksjoner skrevet av en person for å gjøre en bestemt oppgave. Hver gang en automatisert test kjøres, vil den følge nøyaktig de samme trinnene som instruert, og bare se etter ting som blir bedt om å sjekke.

På den annen side, under manuell testing, er testers hjerne engasjert og kan oppdage andre feil i systemet. Teststrinnene er ikke nødvendigvis de samme hver gang, da testeren kan endre strømningene under testingen. dette gjelder spesielt i tilfelle utforskende testing.




Automatiser regresjonstester

Hovedårsaken til at du vil automatisere en test er at du vil utføre testen gjentatte ganger på hver nye utgivelse. Hvis det kreves at testen bare utføres en gang, kan innsatsen for å automatisere testen oppveie fordelene.

Det kreves at regresjonstester utføres gjentatte ganger etter hvert som programvaren som testes utvikler seg. Dette kan være veldig tidkrevende og en kjedelig oppgave for QA å måtte kjøre regresjonstester hver dag. Regresjonstester er gode kandidater for testautomatisering.



Design tester før du automatiserer dem

Det er alltid en god praksis å lage testsaker og scenarier før du begynner å automatisere testene. Det er den gode testdesignen som kan hjelpe til med å identifisere feil, automatiserte tester utfører bare testdesignet.

Faren ved å hoppe rett til automatisering er at du bare er interessert i å få skriptet til å fungere og vanligvis bare automatiserer positive og lykkelige flyt-scenarier i stedet for å tenke på de andre mulige scenariene som kan testes.


Du må heller ikke redusere testomfanget bare for å få testen til å fungere eller bestå.



Fjern usikkerhet fra automatiserte tester

Et av nøkkelpunktene for automatisert testing er muligheten til å gi konsekvente resultater slik at vi kan være sikre på at noe faktisk har gått galt når en test mislykkes.

Hvis en automatisert test går i en kjøring og mislykkes i neste løp, uten noen endringer i programvaren som testes, kan vi ikke være sikre på om feilen skyldes applikasjonen eller på grunn av andre faktorer, for eksempel problemer med testmiljøet eller problemer i selve testkoden.

Når det er feil, må vi analysere resultatene for å se hva som hadde gått galt, og når vi har mange inkonsekvente eller falske positive resultater, øker det analysetiden.


Ikke vær redd for å fjerne ustabile tester fra regresjonspakker; i stedet sikte på jevne, rene resultater som du kan stole på.



Gjennomgå automatiserte tester for gyldighet

Du vil bli skremt av det store antallet automatiserte tester som er utdaterte, bare ikke sjekk for noe eller ikke sjekker de viktigste bekreftelsene!

Dette kan være et symptom på å hoppe rett til automatisering uten å bruke nok tid på forhånd til å planlegge hva som må gjøres og utforme gode testscenarier.

Ha alltid en kollega til å gjennomgå de automatiserte testene for gyldighet og sunn fornuft. Forsikre deg om at testene er oppdaterte.




Ikke automatiser ustabil funksjonalitet

Etter hvert som en ny funksjon eller funksjonalitet blir utviklet, kan mange ting gå galt, og til og med funksjonen kan ikke lenger være aktuelt fordi virksomheten har ombestemt seg.

Hvis du begynte å automatisere tester mens funksjonen ble utviklet, må testene oppdateres mange ganger etter hvert som funksjonen utvikler seg, og kan være ganske skremmende å prøve å holde tritt med alle endringene. Og hvis funksjonen ikke lenger er anvendelig, blir alt det arbeidet med testautomatisering bortkastet.

Derfor er det alltid best å automatisere en funksjon når den er stabilisert og mindre endret.



Ikke forvent magi fra testautomatisering

Den primære årsaken til testautomatisering er å frigjøre QA-tid til interessante utforskende tester og å gi teamet tillit til at applikasjonen fortsatt er i orden etter hvert som nye endringer blir levert.


Ikke forvent at automatisering finner mange feil . Antall feil funnet av automatisering er faktisk alltid mye mindre enn manuell og utforskende testing.



Ikke stol utelukkende på automatisering - Pass på å bestå tester

Automatiserte regresjonstester kan gi en følelse av selvtillit for teamet fordi regresjonstester fortsatt skal bestå ettersom ny funksjonalitet blir levert. Teamet begynner å stole på testene og å ha et godt sett med regresjonstester kan fungere som et sikkerhetsnett.

Vær imidlertid oppmerksom på at ikke alle tester er automatiserte eller kan automatiseres, følg derfor alltid automatiserte tester med utforskende testing.

Noen ganger kan en endring i programvaren mislykkes i en test; Imidlertid, hvis alle testene er bestått, betyr det at mangelen blir savnet, og fordi det ikke var noen oppfordring til handling, ble mangelen ubemerket.



Målet for rask tilbakemelding

Rask tilbakemelding er et av målene med automatiserte tester fordi utviklere er opptatt av å vite om det de har utviklet fungerer og ikke har brutt nåværende funksjonalitet.

For å få denne raske tilbakemeldingssløyfen, må testene automatiseres i komponent- eller API-laget uten å stole på brukergrensesnittet.

Tester som kjøres på brukergrensesnittet er mye tregere og utsatt for feil på grunn av GUI-endringer. Med andre ord fungerer funksjonaliteten fortsatt som forventet, men testene mislykkes på grunn av endringer i brukergrensesnittet. Derfor kan testene bli upålitelige.



Forstå sammenhengen

Tester kan automatiseres på hvilket som helst lag, enhet, API, service, GUI. Hvert lag tjener et annet formål for testing.
Enhetstester sørger for at koden fungerer på klassenivå, at den kompilerer og at logikken er som forventet. Tester på dette laget er mer bekreftelse enn validering.

API-tester eller integrasjonstester sikrer at et sett med funksjoner og klasser kan fungere sammen, og data kan overføres fra en klasse til en annen.

GUI-tester tester derimot brukerstrømmer og reiser. Generelt vil vi ikke teste for funksjonalitet fra brukergrensesnittet. Dette bør gjøres på lavere lag.

Hovedformålet med UI-tester er å sikre at hele systemet fungerer i henhold til noen vanlige brukerscenarier og brukssaker. Testing på dette laget er mer validering i stedet for bekreftelse

På brukergrensesnittnivå automatiserer vi scenarier i stedet for historier.



Ikke automatiser hver test

100% testdekning er ikke mulig siden det kan være millioner av kombinasjoner. Vi utfører alltid en delmengde av mulige tester. Det samme prinsippet gjelder automatisert testing.

For å lage et automatisert skript krever det tid og krefter, og med sikte på 'Automatisering av hver test' krever vi mye ressurs og tid, noe som i mange tilfeller ikke er mulig.

Bruk i stedet en risikobasert tilnærming for å bestemme hvilke tester som skal automatiseres. For å få mest mulig ut av automatiseringen, bare automatiser de viktigste forretningssakene og scenariene.

Dessuten gir et høyt antall automatiserte tester vedlikeholdskostnader og er vanskelige å vedlikeholde.

En annen merknad å huske på er at ikke alle tester kan automatiseres. Noen tester er veldig kompliserte og krever mange nedstrøms systemkontroller og kan være inkonsekvente. I disse tilfellene er det best å legge igjen disse kontrollene for manuell testing.



Bruk testteknikker i testautomatisering

Testteknikkene du lærte i ISTQB, er ikke bare for manuell testing. De gjelder også for automatisert testing. Teknikker som grenseverdianalyse, ekvivalenspartisjonering, statlig overgangstesting, parvis testing kan gi mange fordeler ved automatisert testing.



Ikke automatiser kaos

For å få mest mulig ut av den automatiserte testen din, bør en god QA-prosess være på plass. Hvis QA-prosessen er kaotisk og vi legger til automatisert testing i det kaoset, er alt vi får raskere kaos.

Prøv å svare på spørsmål som, Hva skal du automatisere, Når skal man automatisere , Når skal du utføre automatiserte tester, Hvem skal automatisere testene, Hvilke verktøy skal brukes til testautomatisering, osv ...

Disse tipsene er samlet hovedsakelig av erfaring som en automatiseringstester og noen gode fremgangsmåter fulgt av andre.

Har du noen tips om testautomatisering som skal legges til i denne listen?