Vad är Agile Testing? Metodik, process & Livscykel

Innehållsförteckning:

Anonim

Vad är Agile Testing?

AGILE TESTING är en testpraxis som följer reglerna och principerna för smidig mjukvaruutveckling. Till skillnad från Waterfall-metoden kan Agile Testing börja i början av projektet med kontinuerlig integration mellan utveckling och testning. Agile Testing-metodiken är inte sekventiell (i den meningen att den körs först efter kodningsfasen) utan kontinuerlig.

I den här artikeln kommer vi att diskutera

  • Agil testplan.
  • Agila teststrategier.
  • The Agile Testing Quadrant.
  • QA-utmaningar med smidig mjukvaruutveckling.
  • Risk för automatisering i smidig process.

Agil testplan

Agil testplan inkluderar typer av test som utförts genom att iteration som testdatakrav, infrastruktur, testmiljöer och testresultat. Till skillnad från vattenfallsmodellen, i en smidig modell, skrivs en testplan och uppdateras för varje släpp. Typiska testplaner i agile inkluderar

  1. Testomfång
  2. Nya funktioner som testas
  3. Nivå eller typer av tester baserat på funktionernas komplexitet
  4. Last- och prestandatestning
  5. Infrastrukturöverväganden
  6. Lättgörande eller riskplan
  7. Resursing
  8. Leveranser och milstolpar

Agila teststrategier

Agil testning livscykel spänner över fyra steg

(a) Iteration 0

Under det första steget eller iteration 0 utför du initiala installationsuppgifter. Det inkluderar att identifiera personer för testning, installera testverktyg, schemaläggningsresurser (användbarhetstestlaboratorium) etc. Följande steg är inställda för att uppnå i Iteration 0

a) Upprätta ett affärsfall för projektet

b) Fastställ gränsvillkoren och projektets omfattning

c) Skissera de viktigaste kraven och användningsfall som kommer att driva konstruktionsavvägningarna

d) Skissera en eller flera kandidatarkitekturer

e) Identifiera risken

f) Kostnadsberäkning och förbereda ett förprojekt

(b) Konstruktionsinteraktioner

Den andra fasen av agil testmetodik är konstruktionsinteraktioner, majoriteten av testningen sker under denna fas. Denna fas observeras som en uppsättning iterationer för att bygga en ökning av lösningen. För att göra det, inom varje iteration, implementerar teamet en hybrid av övningar från XP, Scrum, Agile modellering, och smidig data och så vidare.

I konstruktion iteration följer det agila teamet den prioriterade kravpraxis: För varje iteration tar de de viktigaste kraven som finns kvar från arbetsobjektet och implementerar dem.

Konstruktion iteration klassificeras i två, bekräftande testning och undersökande testning. Bekräftande testning koncentrerar sig på att verifiera att systemet uppfyller de intressenters avsikt som beskrivs till laget hittills och utförs av teamet. Medan undersökningen upptäcker problemet som bekräftande team har hoppat över eller ignorerat. I undersökande testning bestämmer testaren de potentiella problemen i form av defektberättelser. Undersökande tester handlar om vanliga frågor som integrationstest, belastning / stresstest och säkerhetstestning.

Återigen för, bekräftande testning finns det två aspekter av utvecklartestning och smidig acceptansprovning . Båda är automatiserade för att möjliggöra kontinuerlig regressionstestning under hela livscykeln. Bekräftande testning är den smidiga motsvarigheten till testning till specifikationen.

Agile acceptans testning är en kombination av traditionell funktionell testning och traditionell acceptans testning som utvecklingsteamet, och intressenter gör det tillsammans. Medan utvecklartestning är en blandning av traditionell enhetstestning och traditionell serviceintegrationstestning. Utvecklare testar verifierar både applikationskoden och databasschemat.

(c) Släpp slutspel eller övergångsfas

Målet med "Release, End Game" är att distribuera ditt system framgångsrikt i produktion. Aktiviteterna inkluderar i denna fas utbildning av slutanvändare, supportpersoner och operativa personer. Det inkluderar också marknadsföring av produktutgåvan, säkerhetskopiering och återställning, slutförande av system- och användardokumentation.

Det slutliga testfasen för smidig metod inkluderar fullständig systemtestning och acceptansprovning. För att avsluta ditt slutgiltiga testfas utan några hinder, måste du testa produkten mer noggrant medan den är i konstruktionsupprepningar. Under slutspelet kommer testare att arbeta med sina defekthistorier.

(d) Produktion

Efter släppfasen flyttas produkten till produktionsfasen.

The Agile Testing Quadrants

De smidiga testkvadranten separerar hela processen i fyra kvadranter och hjälper till att förstå hur smidig testning utförs.

a) Agile Quadrant I - Den interna kodkvaliteten är huvudfokus i denna kvadrant, och den består av testfall som är teknologidrivna och implementeras för att stödja teamet, det inkluderar

1. Enhetstester

2. Komponenttester

b) Agile Quadrant II - Den innehåller testfall som är affärsdrivna och implementeras för att stödja teamet. Denna kvadrant fokuserar på kraven. Den typ av test som utförs i denna fas är

1. Testning av exempel på möjliga scenarier och arbetsflöden

2. Test av användarupplevelse som prototyper

3. Parprovning

c) Agile Quadrant III - Denna kvadrant ger feedback till kvadranterna en och två. Testfallet kan användas som bas för att utföra automatiseringstester. I denna kvadrant genomförs många omgångar av iterationsgranskningar som bygger förtroende för produkten. Den typ av testning som görs i denna kvadrant är

1. Testning av användbarhet

2. Exploratory Testing

3. Koppla ihop test med kunder

4. Samarbetestestning

5. Test av användaraccept

d) Agile Quadrant IV - Denna kvadrant koncentrerar sig på de icke-funktionella kraven som prestanda, säkerhet, stabilitet etc. Med hjälp av denna kvadrant görs applikationen för att leverera de icke-funktionella egenskaperna och det förväntade värdet.

1. Icke-funktionella tester som stress- och prestandatest

2. Säkerhetstest med avseende på autentisering och hacking

3. Infrastrukturprovning

4. Test av datamigrering

5. Skalbarhetsprovning

6. Lasttestning

QA-utmaningar med smidig mjukvaruutveckling

a) Risken för fel är mer smidig, eftersom dokumentation ges mindre prioritet, så småningom lägger mer tryck på QA-teamet

b) Nya funktioner introduceras snabbt, vilket minskar den tillgängliga tiden för testteam för att identifiera om de senaste funktionerna uppfyller kraven och riktar det sig verkligen till affärsdräkterna

c) Testare är ofta skyldiga att spela en semi-utvecklare

d) Testkörningscykler är mycket komprimerade

e) Mycket kortare tid att förbereda testplanen

f) För regressionstestning kommer de att ha minimal timing

g) Förändring av sin roll från att vara en grindvakt av kvalitet till att vara en partner i kvalitet

h) Kravsändringar och uppdateringar är inneboende i en smidig metod, vilket blir den största utmaningen för QA

Risk för automatisering i smidig process

  • Automatiserat användargränssnitt ger en hög nivå av självförtroende, men de är långsamma att utföra, ömtåliga att underhålla och dyra att bygga. Automation kanske inte förbättrar testproduktiviteten avsevärt om inte testarna vet hur de ska testa
  • Otillförlitliga tester är ett stort problem vid automatiserad testning. Att lösa misslyckade tester och lösa problem relaterade till sköra tester bör vara högsta prioritet för att undvika falska positiva resultat
  • Om det automatiska testet initieras manuellt snarare än genom CI (kontinuerlig integration), finns det en risk att de inte körs regelbundet och därför kan orsaka misslyckande av tester
  • Automatiserade tester är inte en ersättning för en utforskande manuell testning. För att uppnå den förväntade kvaliteten på produkten krävs en blandning av testtyper och nivåer
  • Många kommersiellt tillgängliga automatiseringsverktyg erbjuder enkla funktioner som automatisering av inspelning och uppspelning av manuella testfall. Ett sådant verktyg uppmuntrar testning genom användargränssnittet och leder till en iboende spröd och svår att underhålla tester. Lagring av testfall utanför versionskontrollsystemet skapar också onödig komplexitet
  • För att spara tid är automatiseringstestplanen dåligt planerad eller oplanerad, vilket resulterar i att testet misslyckas
  • En testuppsättning och nedrivningsprocedurer missas vanligtvis under testautomatisering, medan man utför test manuellt, en testuppsättning och nedrivningsprocedurer låter sömlöst
  • Produktivitetsmätvärden som ett antal testfall som skapas eller utförs per dag kan vara väldigt vilseledande och kan leda till en stor investering i att köra värdelösa tester
  • Medlemmar i det agila automatiseringsteamet måste vara effektiva konsulter: tillgänglig, samarbetsvillig och resursfull, annars kommer systemet snabbt att misslyckas
  • Automation kan föreslå och leverera testlösningar som kräver för mycket kontinuerligt underhåll i förhållande till det angivna värdet
  • Automatiserad testning kan sakna expertis för att bli gravid och leverera effektiva lösningar
  • Automatiserad testning kan vara så framgångsrik att de har slut på viktiga problem att lösa och därmed vänder sig till obetydliga problem.

Slutsats

Agil metodik i programvarutestning innebär att testa så tidigt som möjligt i livscykeln för programvaruutveckling. Det kräver hög kundinvolvering och testkod så snart den blir tillgänglig. Koden ska vara tillräckligt stabil för att ta den till systemtestning. Omfattande regressionstestning kan göras för att säkerställa att buggarna fixas och testas. Kommunikation mellan lagen gör främst smidig modelltest framgång !!!