Meny

Hur man implementerar effektiv testautomation i den smidiga världen

how implement efficient test automation agile world

Prova Vårt Instrument För Att Eliminera Problem

Automation i Agile är mycket kritisk.

Tänk på de många funktionerna som läggs till och levereras i varje Sprint. Det måste finnas ett sätt att se till att den nyligen tillagda funktionen inte påverkar den befintliga funktionaliteten.

På grund av den låga sprintlängden är det praktiskt taget omöjligt att utföra hela kostymen varje gång produkten ökas i Sprint-änden. Att ha en automatiserad testdräkt skulle definitivt spela en större roll här.

Att introducera och mogna i automatisering skulle dock definitivt ta lite tid. Att göra en initialinvestering i planering och utformning av automatiseringsaktiviteten skulle definitivt löna sig på lång sikt.

I den här tredje delen av Agile Testing avancerade serier försöker jag citera några tips att tänka på baserat på min erfarenhet när du tar automatisering till ditt projekt.

Läs också del 1 och del 2 först för att få en bättre förståelse för ämnet.

Vad du kommer att lära dig:

Vad ska man automatisera i Agile?

Närhelst vi planerar att införa automatisering i våra projekt röstar de flesta av oss omedelbart antingen “Smoke Tests suit” eller “regression test suit” för att vara bäst kandidat för automatisering . Naturligtvis är de det, men när vi tänker på automatiseringstestpyramiden kan vi dra slutsatsen att det bara är det översta lagret av pyramiden som vi pratar om.

Förutom ovanstående lager har vi fortfarande servicelager och den enhetsskikt som är viktigare.

databas användargränssnitt och programvara för frågan

Så vilka tester, förutom rökprov och regressionstest, kan vara bra kandidater för automatisering?

# 1) Byggnader och implementeringar

I traditionella miljöer har vi fördefinierade byggnader som kan ske varje vecka, två veckor eller ibland till och med varje månad. En av anledningarna är att dessa implementeringar tar tid. Problemet med detta tillvägagångssätt är att vi måste vänta på de fördefinierade datumen för att få buggarna fixade eller för att få de nya funktionerna implementerade, så det blir en fördröjning.

Den andra anledningen var - när testarna slutade testa och komma med buggar och defekter, har programmerarna gått vidare till olika delar av implementeringen och har mindre intresse av att lösa buggarna i den äldre applikationen. Detta tillvägagångssätt fördröjer också tiden för att göra funktionen tillgänglig i produktionen.

Byggnad och distribution är enheter som är repetitiva och ibland tråkiga. Det kan också ta timmar att distribuera en byggnad, vilket fördröjer testningen och så småningom återkopplingen. Att vara en upprepad uppgift blir implementeringar en bra kandidat för automatisering.

Läs också=> Processen för frigörande och distribution

Några av fördelarna med att ha automatiserad byggdistribution är:

  • Ingen chans att göra distributionsfel (mänskliga fel som att kopiera den felaktiga filen eller kopiera filen till fel plats kan undvikas)
  • Bug / funktioner är tillgängliga för att testa så fort de är fixade
  • Testare får mer tid att testa
  • Funktionen är redo att flyttas till produktion på kortare tid
  • Snabb feedback

# 2) Enhetstest / komponenttest

Jag har redan pratat om vikten av att automatisera enhetsskiktet genom att använda TDD-tillvägagångssätt i min senaste handledning .

Detta utgör det lägsta lagret av pyramiden, därav grunden och alla fundament måste vara stenfasta. Utvecklingsteamet bör samarbeta och arbeta tillsammans för att rymma större delen av testet i detta lager.

# 3) Testning av API / webbtjänst

Webbtjänster är mediet där två applikationer utbyter data eller information i termer av begäran och svar, utan att bry sig om den underliggande arkitekturen eller tekniken. I mer enkla termer - att ge en begäran och verifiera svaret är vad vi normalt gör i webbtjänsttestningen.

Testa webbtjänsterna innebär att man skriver program för att anropa dessa webbtjänstmetoder och validerar värdet / erna som det returnerar. Vi kan även testa tjänsterna för olika permutationer och kombinationer. Ha alla testdata i excelbladet så kan ditt program läsa data och ringa den testbara tjänsten genom att skicka testdata som en parameter och validera resultaten.

Denna speciella testning är en del av pyramidens mittlager. Det mesta av funktionstestningen kan skjutas in i detta lager. Att lösa defekter som uppstår i detta lager blir lätt att åtgärda och de skjuts inte upp förrän gränssnittet är tillgängligt.

# 4) Testar bakom GUI

Att automatisera testningen bakom GUI är relativt enklare än att automatisera den faktiska GUI. En annan fördel är att funktionaliteten förblir intakt oavsett ändringar av användargränssnittet. Även om något av UI-elementet ändras ändras inte funktionens funktion. Denna teknik fokuserar främst på affärslogik och regler.

Testfallet skrivs mestadels i tabellformat eller i ett kalkylblad och fixturer / kodavsnitt skrivs som accepterar inmatningen från dessa tabeller och returnerar resultaten. Resultaten genereras omedelbart och ger en bra plattform för icke-tekniska intressenter att köra dessa tester och få de förväntade resultaten. Ett av verktygen som används för att uppnå denna teknik är Kondition .

# 5) Icke-funktionell testning

Detta icke-funktionell testteknik involverar i princip belastning, prestanda och stresstestning. Det finns olika verktyg som är tillgängliga på marknaden som kan användas för att automatisera dessa tester.

# 6) Datajämförelser

Många av våra test kräver att vi jämför datafiler, inklusive textfiler, CSV- eller Excel-filer

  • Dessa filer kan jämföras med baslinjer för att göra datavalidering
  • Jämförelser kan ha samma data men i ett annat format. Detta händer i princip när vi har två av samma filer genererade från två olika källor

Dessa jämförelser kan vara repetitiva, därför automatiserade.

# 7) Söker

Att söka efter en viss enhet från ett stort gäng filer kan också vara tråkigt och Gud hjälper oss om det är en upprepande uppgift. Ett exempel är att söka igenom loggfiler. Om detta också är en tråkig och repetitiv uppgift än vi borde tänka på att automatisera den.

# 8) Upprepade uppgifter

Varje uppgift som börjar med att interagera med slutanvändare eller skriva berättelser för att utveckla den, om den är repetitiv, bör övervägas i automatisering. Vi bör förstå att automatisering inte betyder att det måste finnas ett sofistikerat verktyg / teknik involverat i det. Det kan vara ett enkelt VB-makro eller ett Java-program med ett Javascript för att lösa syftet.

Var ska man börja?

Det finns inga punkter eller en steg-för-steg-guide som säger var man ska starta automatisering. Att starta automatisering för teamet kräver att du brainstormar och använder djupa tankar om vilka aspekter du vill automatisera, eller vad är det ultimata målet med automatiseringen?

Du kan börja med:

  • Identifiera de repetitiva uppgifterna,
  • Identifiera smärtområdena i applikationen
  • Identifiera testutmaningarna

Om du inte har någon automatisering i turnéprojektet / teamet, kan du förmodligen gå till ett flerskiktat tillvägagångssätt där enhetstesterna kan inriktas först för att automatisera. Detta skulle ge dig den högsta avkastningen.

vad är den bästa spionappen för mobiltelefoner

Samtidigt kan testare börja arbeta med rökprov och sedan regressionen. När teamet har fått färdigheterna och känner sig bekvämt, gå gradvis mot automatisering av de andra repetitiva uppgifterna.

Hoppa inte direkt med att köpa ett nytt verktyg utan att utvärdera dina behov. Som jag sa tidigare kan ett enkelt program eller ett makro lösa ditt syfte att automatisera några av de repetitiva uppgifterna. Så innan du väljer att köpa ett verktyg, gör POC och utvärdera om verktyget skulle vara effektivt att använda.

Vänligen gå igenom dessa dokument där jag har gett mer information om hur man väljer rätt testfall för automatisering och lite insikter om att uppskatta automatiseringsinsatser i följande artiklar manual för automatiseringstestprocessutmaningar och testuppskattning av selen automatiseringsprojekt.

När automatiseringsomfånget och verktyget har slutförts är nästa att utforma ramverket.

Kom ihåg att i Agile utvecklas ramverket. Rikta INTE mot att utforma hela ramverket först och sedan implementera. Designa och implementera för MVP (Minimum Viable Product) och förbättra sedan det befintliga ramverket för att inkludera fler funktioner. Du måste också tillämpa god kodning och utvecklingspraxis om du vill att din automatiseringssvit ska vara robust.

Några bästa metoder

  • Inrikta dig inte på att automatisera 100% på en gång. Börja smått. Kom ihåg att det är en process under utveckling
  • Följ samma Agile-metoder som du följer för all programutveckling. Automation kräver också korrekt planering och design. Du vill inte öka dina tekniska skulder när du automatiserar
  • Skapa din testautomatiseringsbacklog. Denna eftersläpning kan sträcka sig från att implementera en ny funktion till att förbättra en befintlig funktion. Ge berättelsespoäng till dina identifierade objekt och tilldela det därefter. Ta dessa eftersläpningsobjekt till din Sprint och spåra den med ett Kanban-kort
  • Skriv acceptanskriterierna för dina automatiseringsberättelser. Dessa acceptanskriterier kan inkludera:
    • Integration av testsviten med CI
    • Flytta dräkten till en central plats
    • Skicka resultaten via e-post
    • Tillhandahållande av att skicka felloggfilerna när testet misslyckas
    • Alla andra kriterier ...
  • Spendera inte tid på att utvärdera ett nytt verktyg. Du kan skapa en prioriterad checklista över vad du vill ha från det nya verktyget och bestämma en tidslinje för utvärdering av den. Om du inte ser dina resultat under den angivna tiden, gå vidare till nästa
  • Fatta ett klokt beslut om vad du ska automatisera. Inte alla automationsdelar är effektiva och ger en positiv avkastning. Automatisera inte bara för automatiseringens skull
  • Använd rätt utvecklingsmiljö. Förvara inte koden till din lokala. Ha ett arkiv för att behålla din kod och vana dig att kolla in din kod i slutet av dagen
  • På ett liknande sätt, försök att utföra dina automatiserade tester från en central plats. Gör det till personoberoende. Det borde vara att någon från teamet kan utlösa skript från sin maskin och resultat erhålls via e-post

Vilka är agila principer som kan tillämpas på automatisering?

Några mycket enkla tips:

  • Håll saker enkelt. Gör vad som behövs. Jag har sett många fall där vi levererar sockerbelagd implementering vilket gör automatiseringen onödigt komplicerad. Låt oss undvika de saker som inte behövs
  • Att göra enkla saker betyder inte att göra de enklaste sakerna. Det innebär att du tar babysteg för att uppnå dina automatiseringsmål. Du kan ta upp en enkel funktion för att automatisera, men det kan hända att implementeringen av automatisering visar sig vara en komplex
  • Tillämpa hela teamet . Jag tror att alla är testare i ett smidigt team. Låt oss inte begränsa automatiseringsjobbet, vare sig bara med testarna eller bara med utvecklarna. Var och en av disciplinerna måste gå i varandras skor för att uppnå automatisering för projektet. Detta tillvägagångssätt skulle också vara effektivt för att lösa alla tekniska problem som följer med implementeringen
  • Ramverket utvecklas i Agile . Försök inte tillhandahålla för många funktioner som i onödan kan göra automatiseringsdelen komplicerad
  • Ta dig tid att göra det rätt. Ta dig tid att utforma det ordentligt för att undvika tekniska skulder
  • Få frekvent feedback
  • Tillämpa rätt kodningsstandarder och praxis. Designen bör vara enkel, tillämpa OOPS-koncepten och försök att hålla testerna oberoende av varandra. Tänk på faktorer som ”underhållsförmåga” i testdräkten

Ser jag några utmaningar när jag automatiserar i Agile?

Automatisering i den smidiga världen kommer med sina egna utmaningar :

  • Vi måste planera riktigt bra. Att besluta om lämpligt testpaket, verktyg, ramverk och tillvägagångssätt, alla behöver en ordentlig strategi. Vi bör dock komma ihåg att inte planera för mycket. Tänk på MVP (Minimal Viable Product)
  • Att kompromissa med kodens kvalitet för att vi vill leverera snabbt: Vi måste komma ihåg att tekniska skulder håller sig bra i automatisering också
  • Team för det mesta följer lag inte 'Hela team-tillvägagångssättet' och lämnar hela ansvaret för kodning och underhåll av den automatiska sviten för testarna vilket ökar testarnas ansvar
  • Att automatisera funktionstesterna är svårare än att automatisera användargränssnittet

Bland alla dessa utmaningar är den mest kritiska utmaningen att uppgradera testarnas färdigheter.

Att göra och underhålla automatiseringen för ett team är nästan som en programmeringsaktivitet (utvecklings) som programmerarna (utvecklarna) gör. Inte bara implementeringen utan också att integrera den automatiska dräkten till CI är viktigt och kräver att testare lär sig och använder sig av nya färdigheter och lär sig nya verktyg och tekniker.

Några Open Source-verktyg som passar in i Agile

  • Selen WebDriver - För UI
  • Selen Grid - För parallell utförande
  • Gurka - För BDD
  • JMeter - För prestandatestning
  • TVÅL - För webbtjänster
  • WireMock - Webbtjänsttestning när webbtjänsten inte är tillgänglig.
  • Epoker - för mobil

Låt mig avsluta med de berömda Agile testkvadranterna:

Agila testkvadranter

Kvadrant 1 är enheten och komponenttestet som kan automatiseras med TDD-metoden.

Kvadrant 2 talar om funktionstestning, där vi kan tillämpa BDD-metoden.

vilken mp4 video nedladdare är kompatibel med youtube

Kvadrant 3 är den enda kvadranten som omfattar manuell testning.

Kvadrant 4 i princip talar om testning som kan uppnås med vissa verktyg. Detta tar hand om belastningstester, stresstester, volymtester och säkerhetstester.

Slutsats

Det finns mycket automatiseringsomfång förutom rökprov och regressionstest. Därför måste vi bryta oss loss från konceptet att begränsa automatiseringen endast till dessa typer av test, vilket i sin tur innebär att en testares kompetens i Agile kräver mer än att bara hitta buggar och defekter.

Testare måste vara mer samarbetsvilliga och skärpa sina färdigheter i programmering / automatisering. Om fler och fler tester automatiseras skulle det ge testarna mer tid att engagera sig i mer sofistikerade och utmanande uppgifter.

Om författaren: Denna artikel är av STH-teammedlem Shilpa. Hon arbetar inom programvarutestningsområdet de senaste 10+ åren inom domäner som Internetannonsering, Investment Banking och Telecom.

Dela gärna dina kommentarer och tankar nedan.

Rekommenderad läsning

^