Meny

Hvordan implementere effektiv testautomatisering i den smidige verdenen

  • Hoved
  • Agile Testing
  • Hvordan implementere effektiv testautomatisering i den smidige verdenen

how implement efficient test automation agile world

Prøv Instrumentet Vårt For Å Eliminere Problemer

Automatisering i Agile er veldig kritisk.

Tenk på de mange funksjonene som blir lagt til og levert i hver Sprint. Det må være en måte å sikre at den nylig tilføyde funksjonen ikke påvirker den eksisterende funksjonaliteten.

På grunn av den lave sprintvarigheten er det praktisk talt umulig å utføre hele drakten hver gang produktet økes i Sprint-enden. Å ha en automatisert testdrakt ville definitivt spille en større rolle her.

Imidlertid vil innføring og modning i automatisering definitivt ta litt tid. Å gjøre en innledende investering i planlegging og utforming av automatiseringsaktiviteten vil definitivt lønne seg i det lange løp.

I denne tredje delen av Agile Testing avanserte serier prøver jeg å sitere noen tips som kan vurderes basert på min erfaring når du gir automatisering til prosjektet ditt.

Les også del 1 og del 2 først for å få bedre forståelse av temaet.

Hva du vil lære:

Hva skal jeg automatisere i smidig?

Når vi planlegger å introdusere automatisering i prosjektene våre, stemmer de fleste av oss umiddelbart for at enten 'Smoke Tests dress' eller 'regression test suit' skal være den beste kandidat for automatisering . Selvfølgelig er de det, men når vi tenker på automatiseringstestpyramiden, kan vi konkludere med at det bare er det øverste laget av pyramiden vi snakker om.

Bortsett fra ovennevnte lag har vi fortsatt tjenestelag og enhetslag som er viktigere.

hvordan åpne en apk-fil på android

Så hvilke tester, bortsett fra røykprøver og regresjonstester, kan være gode kandidater for automatisering?

# 1) Bygg og distribusjoner

I tradisjonelle miljøer har vi forhåndsdefinerte bygg som kan være ukentlig, hver fjortende dag eller noen ganger til og med månedlig. En av årsakene er at disse distribusjonene tar tid. Problemet med denne tilnærmingen er at vi må vente på de forhåndsdefinerte datoene for å fikse feilene eller få de nye funksjonene implementert, så det er en forsinkelse.

Den andre grunnen var - da testere var ferdige med testingen og kom med feil og mangler, har programmørene gått videre til forskjellige deler av implementeringen og har mindre interesse for å løse feilene i den eldre applikasjonen. Denne tilnærmingen forsinker også tiden for å gjøre funksjonen tilgjengelig i produksjonen.

Bygging og distribusjon er enhetene som er repeterende og noen ganger kjedelige. Det kan også ta timer å distribuere en build, som forsinker testingen og til slutt tilbakemeldingen. Å være en repeterende oppgave, blir distribusjoner en god kandidat for automatisering.

Les også=> Prosessen for styring av frigjøring og distribusjon

Noen av fordelene ved å ha automatisert byggedistribusjon er:

  • Ingen sjanse for å gjøre distribusjonsfeil (menneskelige feil som å kopiere feil fil eller kopiere fil til feil plassering kan unngås)
  • Feil / funksjoner er tilgjengelige for å teste så snart de er løst
  • Testere får mer tid til å teste
  • Funksjonen er klar til å flyttes til produksjon på kortere tid
  • Rask tilbakemelding

# 2) Enhetstester / Komponenttester

Jeg har allerede snakket om viktigheten av å automatisere enhetslaget ved å bruke TDD-tilnærming i min siste opplæring .

Dette danner det laveste laget av pyramiden, derav fundamentet og ethvert fundament må være bunnsolid. Utviklingsteamet skal samarbeide og samarbeide for å tilpasse det meste av testen i dette laget.

# 3) API / Web Service Testing

Webtjenester er mediet der to applikasjoner utveksler data eller informasjon når det gjelder forespørsel og svar, uten å bry seg med den underliggende arkitekturen eller teknologien. I mer enkle termer - å gi en forespørsel og validere svaret er det vi vanligvis gjør i nettjenestetesten.

Testing av nettjenestene innebærer å skrive programmer for å ringe til disse nettjenestemetodene og validere verdien / ene som den returnerer. Vi kan til og med teste tjenestene for forskjellige permutasjoner og kombinasjoner. Ha alle testdataene i excel-arket, og programmet ditt kan lese dataene og ringe den testbare tjenesten ved å sende testdataene som en parameter og validere resultatene.

Denne spesielle testen er en del av det midterste laget av pyramiden. Det meste av funksjonstestingen kan skyves inn i dette laget. Å løse feil som oppstår i dette laget blir enkelt å fikse, og de blir ikke utsatt til brukergrensesnittet er tilgjengelig.

# 4) Testing bak GUI

Å automatisere testingen bak GUI er relativt enklere enn å automatisere den faktiske GUI. En annen fordel er at funksjonaliteten uavhengig av UI-endringene forblir intakt. Selv om noe av UI-elementet endres, endres ikke funksjonaliteten til funksjonen. Denne teknikken fokuserer hovedsakelig på forretningslogikken og reglene.

Testtilfellene er for det meste skrevet i tabellformat eller i et regneark, og inventar / kodebiter skrives som godtar innspill fra disse tabellene og returnerer resultatene. Resultatene genereres umiddelbart og gir en flott plattform for ikke-tekniske interessenter å kjøre disse testene og få de forventede resultatene. Et av verktøyene som brukes for å oppnå denne teknikken er Fitness .

# 5) Ikke-funksjonell testing

Dette ikke-funksjonell testteknikk innebærer i utgangspunktet belastning, ytelse og stresstesting. Det finnes forskjellige verktøy som er lett tilgjengelige i markedet som kan brukes til å automatisere disse testene.

# 6) Datasammenligning

Mange av testene våre krever at vi sammenligner datafiler, inkludert tekstfiler, CSV- eller Excel-filer

best safe youtube to mp3 converter
  • Disse filene kan sammenlignes med grunnlinjene for å utføre datavalidering
  • Sammenligninger kan ha samme data, men i et annet format. Dette skjer i utgangspunktet når vi har to av de samme filene generert fra to forskjellige kilder

Disse sammenligningene kan være repeterende, derfor automatiserte.

# 7) Søker

Å søke etter en bestemt enhet fra en stor haug med filer kan også være kjedelig, og Gud hjelper oss hvis det er en gjentatt oppgave. Et eksempel er å søke i loggfiler. Hvis dette også er en kjedelig og repeterende oppgave enn vi burde tenke på å automatisere den.

# 8) Gjentatte oppgaver

Enhver oppgave som begynner med å kommunisere med sluttbrukere eller skrive historier for å utvikle den, hvis den er repeterende, bør vurderes i automatisering. Vi bør forstå at å gjøre automatisering ikke betyr at det må være et sofistikert verktøy / teknologi involvert i det. Det kan være en enkel VB-makro eller et Java-program med et Javascript for å løse formålet.

Hvor skal jeg starte?

Det er ingen punkter eller en trinnvis guide som sier hvor du skal starte automatisering. For å starte automatisering for teamet, må du brainstorme og bruke dype tanker om hvilke aspekter du ønsker å automatisere, eller hva er det endelige målet med automatiseringen?

Du kan starte med:

  • Identifisere repetitive oppgaver,
  • Identifisere smerteområdene i applikasjonen
  • Identifisere testutfordringene

Hvis du ikke har noen automatisering i turprosjektet / teamet, kan du sannsynligvis gå for en flerlags tilnærming der enhetstestene kan målrettes først for å automatisere. Dette vil gi deg den høyeste avkastningen.

Samtidig kan testere begynne å jobbe med røykprøvedrakt og deretter regresjonen. Når teamet har fått ferdighetene og føler seg komfortabel, kan du gå gradvis mot automatisering av de andre repeterende oppgavene.

Ikke hopp direkte inn i å kjøpe et nytt verktøy uten å vurdere behovene dine. Som jeg sa tidligere, kan et enkelt program eller en makro løse formålet ditt med å automatisere noen av de repeterende oppgavene. Så før du bestemmer deg for å kjøpe et verktøy, gjør POC og vurdere om verktøyet vil være effektivt å bruke.

Vennligst gå gjennom disse dokumentene der jeg har gitt mer informasjon om hvordan du velger riktige testtilfeller for automatisering og litt innsikt i estimering av automatiseringsarbeid i følgende artikler manual for automatiseringstestprosessutfordringer og testestimering av selen automatiseringsprosjekt.

Når omfanget av automatisering og verktøy er ferdig, er det neste å designe rammeverket.

Husk at i Agile utvikles rammeverket. MÅ IKKE målrette design hele rammeverket først og deretter implementere. Design og implementer for MVP (Minimum Viable Product), og forbedr deretter det eksisterende rammeverket for å inkludere flere funksjoner. Du må også bruke god koding og utviklingspraksis hvis du vil at automatiseringsserien din skal være robust.

Noen gode fremgangsmåter

  • Ikke mål å automatisere 100% på en gang. Begynn i det små. Husk at det er en prosess under utvikling
  • Følg de samme smidige rutinene som du følger for programvareutvikling. Automatisering krever også riktig planlegging og design. Du ønsker ikke å øke den tekniske gjelden din når du automatiserer
  • Lag et testautomatiseringsetterslep. Dette etterslepet kan variere fra implementering av en ny funksjon til forbedring av en eksisterende funksjon. Gi historiepoeng til de identifiserte elementene dine, og tildel det deretter. Ta disse etterslagselementene til Sprint og følg den med et Kanban-brett
  • Skriv akseptkriteriene for automatiseringshistoriene dine. Disse akseptkriteriene kan omfatte:
    • Integrasjon av testsuiten med CI
    • Portering av drakten til et sentralisert sted
    • Send resultatene via e-post
    • Levering av sending av feilloggfilene når testen mislykkes
    • Eventuelle andre kriterier ...
  • Ikke bruk tid på å evaluere et nytt verktøy. Du kan lage en prioritert sjekkliste over hva du vil ha fra det nye verktøyet og bestemme en tidslinje for evaluering av den. Hvis du ikke ser resultatene dine i den angitte tiden, kan du gå videre til neste
  • Ta en klok beslutning om hva du skal automatisere. Ikke alle deler av automatisering er effektive og gir en positiv avkastning. Ikke automatiser bare for automatiserings skyld
  • Benytt deg av riktig utviklingsmiljø. Ikke hold koden til din lokale. Ha et depot for å beholde koden din og gjør det til en vane å sjekke koden din på slutten av dagen
  • På en lignende måte kan du prøve å utføre automatiserte tester fra et sentralisert sted. Gjør det til personuavhengig. Det burde være at noen fra teamet kan utløse manusene fra maskinen sin, og resultatene oppnås via e-post

Hva er smidige prinsipper som kan brukes på automatisering?

Noen veldig enkle tips:

  • Hold ting enkelt. Gjør det som trengs. Jeg har sett mange tilfeller der vi leverer sukkerbelagt implementering, noe som gjør automatiseringen unødvendig komplisert. La oss unngå ting som ikke er nødvendig
  • Å gjøre enkle ting betyr ikke å gjøre de enkleste tingene. Dette betyr å ta skritt for babyen for å oppnå automatiseringsmålene dine. Du kan ta opp en enkel funksjon for å automatisere, men det kan hende at implementeringen av automatisering viser seg å være en komplisert
  • Bruk hele teamtilnærmingen . Jeg tror alle er testere i et smidig team. La oss ikke begrense automatiseringsjobben, enten bare med testerne eller bare med utviklerne. Hver av fagene må gå i hverandres sko for å oppnå automatisering for prosjektet. Denne tilnærmingen vil også være effektiv for å løse noen av de tekniske problemene som følger med implementeringen
  • Rammeverket er utviklet i Agile . Ikke prøv å tilby for mange funksjoner som unødvendig kan gjøre automatiseringsstykket komplisert
  • Ta deg tid til å gjøre det riktig. Bruk litt tid på å utforme den ordentlig for å unngå teknisk gjeld
  • Få hyppige tilbakemeldinger
  • Bruk riktige kodestandarder og praksis. Design skal være enkelt, bruk OOPS-konseptene og prøv å holde testene uavhengige av hverandre. Tenk på faktorer som 'vedlikeholdsevne' i testdrakten

Ser jeg noen utfordringer mens jeg automatiserer i Agile?

Automatisering i den smidige verden følger med sine egne utfordringer :

  • Vi må planlegge veldig bra. Å bestemme riktig testpakke, verktøy, rammeverk og tilnærming, trenger alle en skikkelig strategi. Vi bør imidlertid huske å IKKE overplanere. Husk MVP (Minimal Viable Product)
  • Kompromiss med kvaliteten på koden fordi vi ønsker å levere raskt: Vi må huske at teknisk gjeld holder godt i automatisering også
  • Lag mesteparten av tiden lagene følger ikke “Hele teamtilnærmingen” og overlater hele ansvaret for koding og vedlikehold av den automatiserte suiten for testerne, noe som legger til testernes ansvar
  • Å automatisere funksjonstestene er tøffere enn å automatisere brukergrensesnittet

Blant alle disse utfordringene er den mest kritiske utfordringen å oppgradere testernes ferdigheter.

Å gjøre og vedlikeholde automatiseringen for et team er nesten som en programmeringsaktivitet (utviklingsaktivitet) som programmererne (utviklerne) gjør. Ikke bare bare implementeringen, men også å integrere den automatiserte drakten til CI er viktig og krever at testere lærer og vedtar nye ferdigheter og lærer nye verktøy og teknologier.

Noen Open Source-verktøy som passer inn i Agile

  • Selen WebDriver – For UI
  • Selenett - For parallell utførelse
  • Agurk - For BDD
  • JMeter - For ytelsestesting
  • SÅPE - For webtjenester
  • WireMock - Testing av nettjeneste når nettjenesten ikke er tilgjengelig.
  • Epoker - for mobil

La meg avslutte med de berømte Agile testkvadrantene:

forskjell mellom systemtesting og brukertest

Agile testkvadranter

Kvadrant 1 er enheten og komponenttesten som kan automatiseres med TDD-tilnærmingen.

Kvadrant 2 snakker om funksjonstesting, der vi kan bruke BDD-tilnærmingen.

Kvadrant 3 er den eneste kvadranten som har omfanget av manuell testing.

Kvadrant 4 snakker i utgangspunktet om testingen som kan oppnås med noen verktøy. Dette tar vare på belastningstester, stresstester, volumtester og sikkerhetstester.

Konklusjon

Det er mye automatiseringsomfang bortsett fra røykprøver og regresjonstester. Derfor må vi løsrive oss fra konseptet med å begrense automatisering bare til denne typen testing, noe som igjen betyr at ferdighetssettet til en tester i Agile krever mer enn bare å finne feil og mangler.

Testere må være mer samarbeidsvillige og skjerpe sine programmerings- / automatiseringsferdigheter. Hvis flere og flere tester automatiseres, vil det gi testerne mer tid til å engasjere seg i mer sofistikerte og utfordrende oppgaver.

Om forfatteren: Denne artikkelen er av STH-teammedlem Shilpa. Hun jobber i programvaretestingsfeltet de siste 10+ årene innen domener som Internett-annonsering, Investment Banking og Telecom.

Del dine kommentarer og tanker nedenfor.

Anbefalt lesing

^