Är du bekant med Agile Testing Life Cycle (ATLC)? Det är en process som används av mjukvaruutvecklingsteam för att säkerställa att deras applikationer testas korrekt och effektivt.
Det här inlägget går igenom allt du behöver veta om ATLC, inklusive dess fördelar, steg involverade i processen, planering för en praktisk teststrategi, exekvering av tester baserade på kravinsamling och buggspårning, tester för användaracceptans (UAT) och kontinuerliga tester. integration & automatisering av tester.
Efter att ha läst den här guiden kommer du att bättre förstå hur du använder agilt testning som en del av din mjukvaruutvecklingslivscykel!
Om du är en smidig utvecklare, testare eller produktchef som letar efter ett bättre sätt att leverera dina produkter, kommer den här artikeln att förklara de inblandade stegen tillsammans med nödvändiga åtgärder.
Innehållsförteckning
Översikt över livscykeln för agila tester
Det är ingen hemlighet att testning är oerhört viktigt i en värld av agil utveckling. Men trots det är det ofta underskattad aktivitet inom agila leveranser. Anledningen är naturligtvis pengarna i förhållande till tiden till produktionsleverans.
Men utan detaljerade tester skulle det inte finnas någon garanti för kvalitet eller tillförlitlighet för någon produkt som ditt team utvecklar. Det är därför det är avgörande att förstå den agila testlivscykeln – från att identifiera arbetsobjekt till att förstå vilken typ av test som ska användas inom varje fas.
Den agila testcykeln kräver att utvecklare och testare är involverade i varje enskild sprint. Att göra det bra möjliggör testautomatisering i varje steg, vilket hjälper till att upptäcka buggar tidigare och oftare, vilket minskar felsökningstiden senare.
Agil testning hjälper också till med tidig validering av krav och som en bieffekt förbättrar kundnöjdheten genom att leverera en kvalitetsprodukt.
Vad är Agile Testing och dess fördelar
Agile Testing är en innovativ mjukvarutestmetod som utnyttjar automatisering för att skapa en iterativ testprocess. Detta automationscentrerade tillvägagångssätt hjälper team att snabbt analysera eventuella inkonsekvenser eller problem i koden och sedan testa ändringar baserat på denna feedback.
Så de viktigaste fördelarna med denna process verkar vara uppenbara:
- säkerställa att testningen har den nödvändiga effekten,
- det leder till effektivare utvecklingstider,
- det utvecklade systemet har överlag snabbare fellösningshastigheter,
- och kundnöjdheten förbättras.
Kvalitet och snabbhet är avgörande faktorer här, eftersom spurten definieras som en kort tidsperiod (vanligtvis 2 till 4 veckor). Ju mer teamet kan lita på kvalitet som ingår i sprinttestningen, desto högre självförtroende och snabbare utvecklingsframsteg kan teamet producera.
Fokus på automatisering bör vara det primära målet för alla agila team. Detta gör det möjligt för team att minska risken för kostsamma misslyckanden och möjliggör mer tid som ägnas åt att skapa nytt innehåll snarare än att fixa det som redan är i produktion.
En annan sidofördel är en bättre uppskattning av projektkostnad och tidslinje. Eftersom produkten är mycket mer mogen och förutsägbar, finns det färre situationer där teamet måste hantera oväntade problem som tagits upp under sprinten utan att tidigare beräkna sådana komplikationer.
Agilt testande livscykelsteg
Den agila testlivscykeln består av fyra distinkta stadier.
Enhetstest
Det här är tester som utförs av utvecklare när koden är klar ur utvecklingssynpunkt. Det exekveras isolerat i en utvecklingsmiljö utan att involvera andra delar av systemet.
Enhetstester utförs för att testa koden och kan göras manuellt och automatiskt.
Om det körs manuellt, kör utvecklaren sina testfall mot koden. Detta går snabbt att reda ut, men det tar mer tid från sprinten som ägnas åt utvecklingen, särskilt ur ett långsiktigt perspektiv.
Ett alternativ till detta är att skapa en automatiserad enhetstestkod, som i princip kommer att verifiera funktionskoden bara genom att exekvera den. Detta innebär att utvecklaren måste lägga tid på att inte bara utveckla den nya funktionen utan också utveckla enhetstestkoden som ska testa den funktionen.
Och även om detta kan se ut som en större insats ur ett kortsiktigt perspektiv, är det en tidsbesparande för projektet som helhet eftersom sådana enhetstester är lätta att återanvända även i senare skeden av sprinttestningen. De kan till och med ingå i vanliga regressionstestfall, vilket då sparar ännu mer tid.
Slutligen, ju högre kodtäckning av automatiserade enhetstester, desto bättre kodtillförlitlighetsmått kan visas upp för kunden.
Funktionstester
Funktionstester är utformade för att avgöra hur väl en funktion i en applikation fungerar. Denna typ av testning används för att säkerställa korrekt funktionalitet hos koden snarare än tekniska aspekter (som huvudsakligen var en del av enhetstestet), samt för att bedöma om den uppfyller användarnas behov och förväntningar.
Funktionstester används med andra ord för att verifiera att det som utvecklats uppfyller de krav som företagsanvändarna ställer.
Det är god praxis att samla in viktiga testfall i förväg och från relevanta intressenter (antingen från produktägaren eller till och med från slutanvändarna) och göra en lista över alla sådana testfall som behövs för innehållet i sprinten.
Att automatisera funktionstester kräver mer ansträngning på testutvecklingssidan, eftersom det är komplexa processer som ska verifieras, inklusive olika delar av systemet tillsammans. Den bästa strategin, i det här fallet, är att etablera ett dedikerat team endast för att utveckla funktionstesterna i samma linje som huvudutvecklingsteamet utvecklar nya funktioner.
Visst, för projektet innebär detta ökade kostnader för att upprätthålla ett separat team, men det har också stor potential att spara projektet pengar på sikt. Det är bara upp till projektledare att förklara och specifikt beräkna fördelarna och besparingarna för att föra ett solidt argument inför affärsanvändare som kommer att leda till en sådan ökning av projektkostnadsgodkännandet.
Å andra sidan, om den görs manuellt, kan denna aktivitet utföras av ett mycket litet team (i vissa fall till och med en enda person). Det kommer dock att krävas en konstant manuell och upprepad aktivitet varje enskild sprint. Med tiden, när funktionerna i systemet expanderar, kan det bli svårare att komma ikapp med solida funktionella tester sprint för sprint.
Regressionstest
Syftet med regressionstestet ska vara att säkerställa att allt som fungerat fram till nu fungerar även efter nästa release. Regressionstester måste utföras för att säkerställa att det inte finns kompatibilitetsproblem mellan olika moduler.
Testfall för regressionstester är bäst om de regelbundet underhålls och ses över före varje release. Baserat på de konkreta projektspecifikationerna är det bäst att hålla dem enkla men ändå täcka majoriteten av de centrala funktionerna och viktiga flöden från slut till slut som löper genom hela systemet.
Vanligtvis har varje system sådana processer som berör många olika områden, och det är de bästa kandidaterna för regressionstestfall.
Om det finns befintliga automatiserade enhetstester och funktionstester är det en mycket enkel uppgift att skapa automatisering i regressionstestning. Återanvänd bara det du redan har för den viktigaste delen av systemet (t.ex. för processer som används mest i produktionen).
Användaracceptanstest (UAT)
Sist men inte minst validerar UAT att applikationen uppfyller de nödvändiga kraven för produktionsinstallation. Detta tillvägagångssätt fungerar bäst när du testar en mjukvara ofta i korta och intensiva cykler.
UAT-test ska enbart utföras av personer utanför det agila teamet, helst av affärsanvändare i en dedikerad miljö, som är så nära framtida produktion som möjligt. Alternativt kan produktägaren här ersätta slutanvändarna.
I vilket fall som helst bör detta vara ett rent, funktionellt test ur slutanvändarens perspektiv, utan någon koppling till utvecklarteamet. Resultaten av dessa tester är här för att fatta det avgörande beslutet att gå / inte gå för produktionen.
Planera för en effektiv teststrategi
Planering är en viktig del av agilt testning, eftersom det binder samman hela strategin. Det måste också ställa tydliga förväntningar på tidslinjen i samband med sprintarna.
Genom att effektivt hantera agil testplanering kan team skapa en tydlig riktning som leder till effektiv användning av resurser inom en sprint. Uppenbarligen förväntas ett större samarbete mellan testare och utvecklare.
En övergripande plan bör också upprättas för att kartlägga när enhetstestning, funktionstestning eller användaracceptanstestning sker inom varje utvecklingssprint. Därför vet alla exakt när deras deltagande krävs för en framgångsrik agil lansering.
Hur man lägger upp planen kan vara efter ytterligare diskussion och överenskommelse. Det viktigaste är dock att göra det till en process och hålla fast vid den. Skapa en periodicitet som kommer att vara pålitlig och förutsägbar.
Flytta inte bort från processen. Annars blir verkligheten direkt tvärtom – kaos och oförutsägbara releaser till produktion.
Utföra tester baserat på kravinsamling
Tester måste utföras mot kraven för varje steg. Biljetter öppnas sedan när en bugg eller ett problem hittas och tilldelas utvecklingsteamet, som sedan kommer att kunna ta reda på vad som behöver fixas eller ändras för koden. När alla buggar har åtgärdats kan exekvering av agil testning fortsätta tills alla tester har godkänts.
Granskning av resultat och felspårning
En effektiv granskning av resultaten och en stabil buggspårningsprocess är avgörande. Processen bör involvera alla relevanta intressenter, från projektledare och testare till utvecklare, och så småningom supportteam, men även kunder för insamling av feedback.
Detta bör vara tillräckligt omfattande så att problem kan identifieras snabbt och åtgärdas innan det redan planerade releasedatumet är i riskzonen.
Valet av verktyg är återigen upp till laget. Men när den väl har valts måste alla testaktiviteter inkludera tillförlitliga buggspårningsprocesser för att övervaka problem, prioritera dem enligt beroenden, rapportera tillbaka statusuppdateringar från utvecklare om upplösning eller överföring för vidare undersökning och sedan stänga ärenden när de är lösta.
Granskning hjälper agila testare att förstå deras systembeteende och identifierar buggar vid varje steg snarare än senare i processen. Regelbundna granskningar gör det också möjligt för agila team att identifiera trender och områden som behöver förbättras, vilket gör att de kontinuerligt kan uppdatera sitt testramverk och bygga produkter av bättre kvalitet snabbare.
Slutför produktsläppet med produktionsröktest
För att maximera releasens framgång är ett röktest som körs mot produktion (strax efter release) ett sätt att få mer självförtroende.
Detta test består av en uppsättning skrivskyddade aktiviteter inuti produktionssystemet, som inte kommer att skapa några nya slumpmässiga data men ändå verifiera systemets grundläggande funktionalitet från slutanvändarnas synvinkel.
Att involvera rätt intressenter i processen hjälper till att säkerställa anpassning och ansvarsskyldighet samtidigt som man ökar förtroendet för att målen har uppnåtts. I slutändan garanterar dessa tester en framgångsrik release.
Kontinuerlig integration och automatisering av tester för att förbättra effektiviteten
Kontinuerlig integration och automatisering av tester anammas alltmer av företag för att driva agila processer till nästa nivå.
Om teamet kan implementera automatisering i flera steg enligt beskrivningen ovan, kan dessa kombineras och kopplas till en dedikerad testpipeline, som i grunden är en helautomatiserad batchprocess som gör majoriteten av testaktiviteterna självständigt och utan inblandning av något annat team medlem.
Med tiden kommer en sådan omfattande testpipeline att förkorta den totala tiden som behövs för alla testfaser. Så småningom kan det leda till en riktigt snabb inkrementell produktion efter slutet av varje sprint. Även om detta är ett idealiskt scenario, är det i verkligheten svårt att uppnå med alla teststeg som ingår. Automatisering är det enda sättet att komma dit.
Skillnaden mellan agilt testning och vattenfallstestning
Agila teststrategier skiljer sig från traditionella vattenfallsteststrategier på flera sätt, som periodicitet, parallellitet eller dedikerad tid för varje aktivitet.
Men den mest anmärkningsvärda skillnaden är fokus för varje tillvägagångssätt:
- Agila tester fokuserar på ständiga, snabba iterationer av utveckling och återkopplingsslingor för att identifiera problem och snabbt förbättra produkten. En iterativ process fokuserad på kundsamarbete, kontinuerlig integration och adaptiv planering.
- Å andra sidan betonar traditionell vattenfallstestning en linjär process där varje steg löses separat och i sekventiell ordning, vilket lämnar feedback från hela lösningen endast för det allra sista steget av projektet och mycket nära det slutliga produktionssläppningsdatumet.
Uppenbarligen, ju tidigare problemen identifieras av de viktigaste intressenterna, desto bättre situation för projektet. I detta avseende har agil metodik definitivt en bättre chans att lyckas.
Slutsats
Även om den smidiga testlivscykeln kan tyckas vara kortare än vattenfallet, är det i själva verket inte det. Hela processen är kontinuerlig och pågår fram till produktens releasedatum. Beroende på budget och tid tillgänglig för varje sprint kommer du att behöva prioritera vilka tester som utförs under just den sprinten.
En välplanerad teststrategi hjälper dig att välja vilka funktioner eller moduler som kräver mer uppmärksamhet än andra. Automatisering kommer att möjliggöra inkludering av flera teststeg i samma sprint, vilket ökar systemets övergripande tillförlitlighet från sprint till sprint.
Du kan nu titta på några av de bästa metoderna för scrumtestning.