Menu

Sådan implementeres effektiv testautomatisering i den agile verden

how implement efficient test automation agile world

Prøv Vores Instrument Til At Fjerne Problemer

Automatisering i Agile er meget kritisk.

Tænk på de mange funktioner, der tilføjes og leveres i hver Sprint. Der skal være en måde at sikre, at den nyligt tilføjede funktion ikke påvirker den eksisterende funktionalitet.

På grund af den lave Sprint-varighed er det praktisk talt umuligt at udføre hele dragten hver gang produktet øges i Sprint-enden. At have en automatiseret testdragt ville helt sikkert spille en større rolle her.

Imidlertid vil introduktion og modning til automatisering bestemt tage noget tid. At foretage en indledende investering i planlægning og design af automatiseringsaktiviteten ville helt sikkert betale sig i det lange løb.

I denne 3. del af Agile Testing avanceret serie forsøger jeg at citere et par tip til at overveje baseret på min erfaring, når du bringer automatisering til dit projekt.

Læs også del 1 og del 2 først for at få en bedre forståelse af emnet.

Hvad du lærer:

Hvad skal man automatisere i Agile?

Når vi planlægger at indføre automatisering i vores projekter, stemmer de fleste af os straks for enten 'Smoke Tests suit' eller 'regression test suit' for at være den bedste kandidat til automatisering . Selvfølgelig er de det, men når vi tænker på automatiseringstestpyramiden, kan vi konkludere, at det bare er det øverste lag af pyramiden, vi taler om.

Bortset fra ovenstående lag har vi stadig servicelag og enhedslag der er vigtigere.

bedste software til oprydning af pc

Så hvilke tests, bortset fra røgtest og regressionstest, kan være gode kandidater til automatisering?

# 1) Bygninger og implementeringer

I traditionelle miljøer har vi foruddefinerede builds, der kan være ugentlige, hver uge eller nogle gange endda månedlige. En af grundene er, at disse implementeringer tager tid. Problemet med denne tilgang er, at vi bliver nødt til at vente på de foruddefinerede datoer for at få bugs løst eller få de nye funktioner implementeret, så der er en forsinkelse.

Den anden grund var - da testere afsluttede testen og kom med fejl og mangler, er programmørerne gået videre til forskellige implementeringsstykker og har mindre interesse i at løse fejlene i den ældre applikation. Denne tilgang forsinker også tiden til at gøre funktionen tilgængelig i produktionen.

Bygning og implementering er de enheder, der er gentagne og til tider kedelige. Det kan også tage timer at implementere en build, som forsinker testningen og til sidst feedbacken. At være en gentagen opgave bliver implementeringer en god kandidat til automatisering.

Læs også=> Processen til frigivelse og implementeringsstyring

bedste wow-server til nye spillere 2017

Et par af fordelene ved at have automatisk build-implementering er:

  • Ingen chance for at lave installationsfejl (menneskelige fejl som kopiering af den forkerte fil eller kopiering af fil til den forkerte placering kan undgås)
  • Fejl / funktioner er tilgængelige for test, så snart de er rettet
  • Testere får mere tid til at teste
  • Funktionen er klar til at blive flyttet til produktion på kortere tid
  • Hurtig feedback

# 2) Enhedstest / komponenttest

Jeg har allerede talt om vigtigheden af ​​at automatisere enhedslaget ved hjælp af TDD tilgang i min sidste vejledning .

Dette danner det laveste lag af pyramiden, hvorfor fundamentet og ethvert fundament skal være bundsolid. Udviklingsteamet skal samarbejde og arbejde sammen for at rumme det meste af testen i dette lag.

# 3) API / Web Service Testing

Webtjenester er mediet, hvor to applikationer udveksler data eller information med hensyn til anmodning og svar uden at forstyrre den underliggende arkitektur eller teknologien. I mere enkle vendinger - at give en anmodning og validere svaret er, hvad vi normalt gør i webservicetesten.

Test af webservices indebærer at skrive programmer for at kalde disse webservicemetoder og validere den værdi / værdier, den returnerer. Vi kan endda teste tjenesterne for forskellige permutationer og kombinationer. Har alle testdata i excelarket, så kan dit program læse dataene og ringe til den testbare service ved at videregive testdataene som en parameter og validere resultaterne.

Denne særlige test er en del af det midterste lag i pyramiden. De fleste af de funktionelle test kan skubbes ind i dette lag. Det er let at rette op på fejl, der opstår i dette lag, og de udsættes ikke, indtil brugergrænsefladen er tilgængelig.

# 4) Test bag GUI

Automatisering af testen bag GUI er forholdsvis lettere end automatisering af den faktiske GUI. En anden fordel er, at funktionalitet forbliver intakt uanset UI-ændringer. Selvom noget af UI-elementet ændres, ændres funktionens funktion ikke. Denne teknik fokuserer primært på forretningslogik og regler.

Testcases er for det meste skrevet i tabelformat eller i et regneark, og der er skrevet inventar / kodestykker, der accepterer input fra disse tabeller og returnerer resultaterne. Resultaterne genereres med det samme og giver en god platform for ikke-tekniske interessenter til at køre disse tests og få de forventede resultater. Et af de værktøjer, der bruges til at opnå denne teknik er Fitnesse .

# 5) Ikke-funktionel test

Det her ikke-funktionel testteknik dybest set involverer belastning, ydeevne og stresstest. Der er forskellige værktøjer, der er let tilgængelige på markedet, som kan bruges til at automatisere disse tests.

# 6) Datasammenligning

Mange af vores test kræver, at vi sammenligner datafiler, herunder tekstfiler, CSV eller excel-filer

  • Disse filer kan sammenlignes med basislinjer til udførelse af datavalidering
  • Sammenligninger kan have samme data, men i et andet format. Dette sker grundlæggende, når vi har to af de samme filer genereret fra to forskellige kilder

Disse sammenligninger kan være gentagne, derfor automatiserede.

# 7) Søgning

At søge efter en bestemt enhed fra en stor flok filer kan også være kedelig, og Gud hjælper os, hvis det er en gentagende opgave. Et eksempel er søgning gennem logfiler. Hvis dette også er en kedelig og gentagen opgave, end vi skulle tænke på at automatisere den.

# 8) Gentagne opgaver

Enhver opgave, der starter med at interagere med slutbrugere eller skrive historier for at udvikle den, hvis den gentager sig, bør overvejes i automatisering. Vi skal forstå, at automatisering ikke betyder, at der skal være et sofistikeret værktøj / teknologi involveret i det. Det kan være en simpel VB-makro eller et Java-program med et Javascript for at løse formålet.

Hvor skal man starte?

Der er ingen punkter eller en trinvis vejledning, der siger, hvor man skal starte automatisering. At starte automatisering for teamet kræver, at du brainstormer og anvender dybe tanker om, hvilke aspekter du søger at automatisere, eller hvad er det ultimative mål med automatiseringen?

Du kan starte med:

  • Identificering af de gentagne opgaver
  • Identificering af smerteområderne i applikationen
  • Identificering af testudfordringerne

Hvis du ikke har nogen automatisering i tour-projektet / teamet, kan du sandsynligvis gå til en flerlags tilgang, hvor enhedstestene først kan målrettes for at automatisere. Dette giver dig den højeste ROI.

Samtidig kan testere begynde at arbejde på røgtestdragt og derefter regression. Når holdet har fået færdighederne og føler sig godt tilpas, skal du gradvist bevæge dig mod automatisering af de andre gentagne opgaver.

Gå ikke direkte ind i at købe et nyt værktøj uden at vurdere dine behov. Som jeg sagde tidligere, kan et simpelt program eller en makro løse dit formål med at automatisere nogle af de gentagne opgaver. Så før du beslutter dig for at købe et værktøj, gør POC og vurdere, om værktøjet ville være effektivt at bruge.

Gå igennem disse dokumenter, hvor jeg har givet flere detaljer om, hvordan man vælger korrekte testsager til automatisering og nogle indsigter i estimering af automatiseringsindsatsen i de følgende artikler manual til automatisering test proces udfordringer og testestimering af selen automatiseringsprojekt.

Når omfanget af automatisering og værktøj er afsluttet, er det næste at designe rammen.

Husk, i Agile udvikles rammen. MÅ IKKE målrette mod at designe hele rammen først og derefter implementere. Design og implementer til MVP (Minimum Viable Product) og forbedr derefter den eksisterende ramme til at omfatte flere funktioner. Du skal også anvende god kodning og udviklingspraksis, hvis du vil have din automatiseringspakke til at være robust.

gratis shell script editor til windows

Nogle bedste fremgangsmåder

  • Mål ikke mod at automatisere 100% på én gang. Start lille. Husk, at det er en proces under udvikling
  • Følg de samme Agile-fremgangsmåder, som du følger for enhver softwareudvikling. Automatisering kræver også korrekt planlægning og design. Du ønsker ikke at øge din tekniske gæld, når du automatiserer
  • Opret din testautomatiseringsforsinkelse. Dette efterslæb kan variere fra implementering af en ny funktion til forbedring af en eksisterende funktion. Giv historien point til dine identificerede emner, og tildel den i overensstemmelse hermed. Tag disse efterslæbte poster til din Sprint, og følg den ved hjælp af et Kanban-kort
  • Skriv acceptkriterierne for dine automatiseringshistorier. Disse acceptkriterier kan omfatte:
    • Integration af testpakken med CI
    • Aflevering af dragt til en central placering
    • Send resultaterne via e-mail
    • Levering af afsendelse af fejllogfilerne, når testen mislykkes
    • Eventuelle andre kriterier ....
  • Brug ikke for meget tid på at evaluere et nyt værktøj. Du kan oprette en prioriteret tjekliste over alt, hvad du vil have fra det nye værktøj, og beslutte en tidslinje til evaluering af den. Hvis du ikke kan se dine resultater inden for den fastsatte tid, skal du gå videre til det næste
  • Lav en fornuftig beslutning om, hvad du skal automatisere. Ikke hvert stykke automatisering er effektivt og giver et positivt investeringsafkast. Automatiser ikke kun for automatiserings skyld
  • Brug det rette udviklingsmiljø. Opbevar ikke koden til din lokale. Har et lager for at beholde din kode og gøre det til en vane at kontrollere din kode i slutningen af ​​dagen
  • På samme måde kan du prøve at udføre dine automatiserede tests fra et centralt sted. Gør det personuafhængigt. Det burde være, at alle fra holdet kan udløse scripts fra deres maskine, og resultater opnås via e-mail

Hvad er Agile-principper, der kan anvendes til automatisering?

Nogle meget enkle tip:

  • Hold tingene enkle. Gør hvad der er nødvendigt. Jeg har set mange tilfælde, hvor vi leverer sukkerbelagt implementering, hvilket gør automatiseringen unødigt kompliceret. Lad os undgå de ting, der ikke er nødvendige
  • At gøre enkle ting betyder ikke at gøre de nemmeste ting. Dette betyder at tage babyens skridt for at nå dine automatiseringsmål. Du kan muligvis tage en enkel funktion til at automatisere, men det kan ske, at implementeringen af ​​automatisering viser sig at være en kompleks
  • Anvend hele holdmetoden . Jeg tror, ​​at alle er testere i et smidigt hold. Lad os ikke begrænse automatiseringsjobbet hverken kun med testere eller kun med udviklerne. Hver af disciplinerne skal træde ind i hinandens sko for at opnå automatisering til projektet. Denne tilgang ville også være effektiv til at løse ethvert af de tekniske problemer, der følger med implementeringen
  • Rammen udvikles i Agile . Forsøg ikke at give for mange funktioner, der unødigt kan gøre automatiseringsstykket kompliceret
  • Tag dig tid til at gøre det rigtigt. Brug lidt tid på at designe det ordentligt for at undgå den tekniske gæld
  • Få hyppig feedback
  • Anvend korrekte kodningsstandarder og praksis. Designet skal være simpelt, anvende OOPS-koncepterne og prøve at holde testene uafhængige af hinanden. Overvej faktorer som 'vedligeholdelsesevne' i testdragt

Ser jeg nogen udfordringer, mens jeg automatiserer i Agile?

Automatisering i den agile verden kommer med sine egne udfordringer :

  • Vi er nødt til at planlægge rigtig godt. Beslutningen om den passende testpakke, værktøj, ramme og tilgang har alle brug for en ordentlig strategi. Vi skal dog huske IKKE at overplanlægge. Husk MVP (minimalt levedygtigt produkt)
  • Kompromitterer kvaliteten af ​​koden, fordi vi ønsker at levere hurtigt: Vi skal huske, at teknisk gæld også holder i automatisering
  • Hold det meste af tiden hold følger ikke 'Hele team-tilgangen' og overlader hele ansvaret for kodning og vedligeholdelse af den automatiserede suite til testere, hvilket øger testernes ansvar
  • At automatisere funktionstestene er hårdere end at automatisere brugergrænsefladen

Blandt alle disse udfordringer er den mest kritiske udfordring at opgradere testernes færdigheder.

At udføre og vedligeholde automatiseringen for et team er næsten som en programmeringsaktivitet (udviklingsaktivitet), som programmørerne (udviklerne) udfører. Ikke kun implementeringen, men også integration af den automatiserede dragt til CI er vigtig og kræver, at testere lærer og vedtager nye færdigheder og lærer nye værktøjer og teknologier.

Nogle Open Source-værktøjer, der passer ind i Agile

  • Selen WebDriver - Til UI
  • Selenet - Til parallel udførelse
  • Agurk - til BDD
  • JMeter - Til ydelsestest
  • SÆBE - Til webservices
  • WireMock - Webtjenestetest, når webservicen ikke er tilgængelig.
  • Epoker - til mobil

Lad mig afslutte med de berømte Agile testkvadranter:

Agile testkvadranter

Kvadrant 1 er enheden og komponenttesten, der kan automatiseres med TDD-tilgangen.

Kvadrant 2 taler om funktionstest, hvor vi kan anvende BDD-tilgangen.

Kvadrant 3 er den eneste kvadrant, der har omfanget af manuel test.

Kvadrant 4 dybest set taler om den test, der kan opnås med nogle værktøjer. Dette tager sig af belastningstest, stresstest, volumintest og sikkerhedstest.

Konklusion

Der er et stort omfang af automatisering bortset fra røgtestene og regressionstestene. Derfor er vi nødt til at slippe fri fra konceptet med at begrænse automatisering til kun disse typer af test, hvilket igen betyder, at dygtighedssættet til en tester i Agile kræver mere end bare at finde fejl og mangler.

Testere skal være mere samarbejdsvillige og skærpe deres programmerings- / automatiseringsevner. Hvis flere og flere tests automatiseres, vil det give testerne mere tid til at engagere sig i mere sofistikerede og udfordrende opgaver.

Om forfatteren: Denne artikel er af STH-teammedlem Shilpa. Hun arbejder inden for softwaretestfeltet i de sidste 10+ år inden for domæner som internetannoncering, Investment Banking og Telecom.

Del dine kommentarer og tanker nedenfor.

Anbefalet læsning

^