Hvad er Agile Test? Proces & livscyklus

Hvad er Agile Test?

Agile test er en testpraksis, der følger reglerne og principperne for agil softwareudvikling. I modsætning til Waterfall-metoden kan Agile Testing begynde ved projektets start med kontinuerlig integration mellem udvikling og test. Agile testmetoden er ikke sekventiel (i den forstand, at den kun udføres efter kodningsfasen), men kontinuerlig.

Principper for agil testning

Her er de væsentlige principper for agil test:

• I denne agile testmodel er fungerende software det primære mål for fremskridt.
• Det bedste resultat kan opnås af de selvorganiserende teams.
• At levere værdifuld software tidligt og kontinuerligt er vores højeste prioritet.
• Softwareudviklere skal handle for at samles dagligt gennem hele projektet.
• Forbedring af smidighed gennem løbende tekniske forbedringer og godt design.
• Agile test sikrer, at det endelige produkt lever op til virksomhedens forventninger ved at give løbende feedback.
• I Agile Test-processen skal vi udføre testprocessen under implementeringen, hvilket reducerer udviklingstiden.
• Testprocessen i Agile bør arbejde på det konsekvente udviklingstempo
• Giv regelmæssige overvejelser om, hvordan du bliver mere effektiv.
• De bedste arkitekturer, krav og design kommer fra selvorganiserende teams.
• Hver gang teamet mødes, gennemgår og justerer det sin adfærd for at blive mere effektiv.
• Ansigt til ansigt samtale med udviklingsteamet er den mest effektive og effektive metode til at formidle information inden for teamet.

Agile test omfatter forskellige principper, der hjælper os med at øge softwarens produktivitet.

Agil test livscyklus

Den agile testlivscyklus gennemføres i fem forskellige faser, som vi kan se på følgende billede:

Her er de agile procestesttrin:

Fase 1: Konsekvensanalyse: I denne indledende fase samler vi input fra interessenter og brugere. Denne fase kaldes også feedbackfasen, da den hjælper testingeniørerne med at sætte målene for den næste livscyklus.

Fase 2: Agile testplanlægning: Det er anden fase af den agile testlivscyklus, hvor alle interessenter samles for at planlægge tidsplanen for testprocessen og leverancerne.

Fase 3: Udgivelsesberedskab: På dette stadium gennemgår vi de funktioner, der er blevet udviklet/implementeret, er klar til at gå live eller ej. I denne fase besluttes det også, hvilken der skal tilbage til den tidligere udviklingsfase.

Fase 4: Daglige Scrums: Denne fase inkluderer hvert standup morgenmøde for at indhente status for test og sætte målet for hele dagen.

Fase 5: Test Agility Revse: Den sidste fase af den agile livscyklus er agility Review møde. Det involverer ugentlige møder med interessenter for regelmæssigt at evaluere og vurdere fremskridt i forhold til mål.

Agile testplan

Agile testplan omfatter typer af test udført i den iteration som testdatakrav, infrastruktur, testmiljøerog testresultater. I modsætning til vandfaldsmodellen bliver der i en agil model skrevet og opdateret en testplan for hver udgivelse. Typiske testplaner i agile omfatter

• Testomfang
• Nye funktionaliteter som er ved at blive testet
• Niveau eller typer af test baseret på funktionernes kompleksitet
• Belastnings- og ydeevnetest
• Infrastrukturovervejelse
• Afbødnings- eller risikoplan
• Resourcing
• Leverancer og milepæle

Agile teststrategier

Agil testlivscyklus strækker sig gennem fire faser

Iteration 0

Under den første fase eller iteration 0 udfører du indledende opsætningsopgaver. Det omfatter identifikation af personer til test, installation af testværktøjer, planlægning af ressourcer (brugerbarhedstestlaboratorium) osv. Følgende trin er indstillet til at opnå i iteration 0

• Etablering af en business case for projektet
• Fastlæg grænsebetingelserne og projektets omfang
• Skitsér de vigtigste krav og use cases, der vil drive design-afvejningen
• Skitsér en eller flere kandidatarkitekturer
• Identifikation af risikoen
• Omkostningsvurdering og udarbejde et forprojekt

Konstruktionsgentagelser

Den anden fase af agil testmetodologi er konstruktionsgentagelser, størstedelen af ​​testen finder sted i denne fase. Denne fase observeres som et sæt iterationer for at opbygge en stigning af løsningen. For at gøre det inden for hver iteration, holdet implementerer en hybrid af praksis fra XP, Scrum, Agile modellering og agile data og så videre.

I konstruktionsiteration følger det agile team den prioriterede kravpraksis: Med hver iteration tager de de mest væsentlige krav tilbage fra arbejdsemnestakken og implementerer dem.

Konstruktionsiteration er klassificeret i to, bekræftende test og efterforskningstest. Bekræftende testkoncentrater på at verificere, at systemet opfylder interessenternes hensigt som beskrevet for teamet til dato, og udføres af teamet. Mens den efterforskningsmæssige test opdager det problem, som bekræftende team har sprunget over eller ignoreret. I Undersøgende test bestemmer testeren de potentielle problemer i form af fejlhistorier. Undersøgende test beskæftiger sig med almindelige problemer som integrationstest, belastnings-/stresstest og sikkerhedstest.

Igen for bekræftende test er der to aspekter udviklertest og agil accepttest. Begge to er automatiseret for at muliggøre kontinuerlig regressionstest gennem hele livscyklussen. Bekræftende test er den agile ækvivalent til test i henhold til specifikationen.

Agile accepttest er en kombination af traditionel funktionstest og traditionel accepttest som udviklingsteamet, og interessenter gør det sammen. Mens udviklertest er en blanding af traditionel enhedstest og traditionel serviceintegrationstest. Udviklertest verificerer både applikationskoden og databaseskemaet.

Slip slutspil eller overgangsfase

Målet med "Release, End Game" er at implementere dit system med succes i produktion. Aktiviteterne omfatter i denne fase uddannelse af slutbrugere, støttepersoner og driftsfolk. Det omfatter også markedsføring af produktudgivelsen, backup og gendannelse, færdiggørelse af system- og brugerdokumentation.

Den sidste agile metodetestfase inkluderer fuld systemtest og accepttest. For at afslutte din sidste testfase uden nogen forhindringer, bør du teste produktet mere strengt, mens det er i konstruktionsgentagelser. I løbet af slutspillet vil testere arbejde på deres fejlhistorier.

produktion

Efter udgivelsesstadiet vil produktet flytte til produktionsstadiet.

De agile testkvadranter

De agile testkvadranter adskiller hele processen i fire kvadranter og hjælper med at forstå, hvordan agil testning udføres.

Agile kvadrant I

Den interne kodekvalitet er hovedfokus i denne kvadrant, og den består af testcases som er teknologidrevne og implementeret for at understøtte teamet, det omfatter bl.a.

• Enhedstests
• Komponenttests

Agile kvadrant II

Den indeholder testcases, der er forretningsdrevne og implementeret for at understøtte teamet. Denne kvadrant fokuserer på kravene. Den slags test, der udføres i denne fase, er

• Test af eksempler på mulige scenarier og arbejdsgange
• Test af brugeroplevelse såsom prototyper
• Par test

Agile kvadrant III

Denne kvadrant giver feedback til kvadrant et og to. Testcaserne kan bruges som grundlag for at udføre automatiseringstest. I denne kvadrant udføres mange runder af iterationsgennemgange, som opbygger tillid til produktet. Den slags test udført i denne kvadrant er

• Usability Testing
• Undersøgende test
• Partest med kunder
• Samarbejdstest
• Brugeraccepttest

Agile kvadrant IV

Denne kvadrant koncentrerer sig om de ikke-funktionelle krav såsom ydeevne, sikkerhed, stabilitet osv. Ved hjælp af denne kvadrant er applikationen lavet til at levere de ikke-funktionelle kvaliteter og forventet værdi.

• Ikke-funktionelle tests såsom stress- og præstationstest
• Sikkerhedstest vedr autentificering og hacking
• Infrastruktur test
• Datamigreringstest
• Test af skalerbarhed
• Belastningstest

QA-udfordringer med agil softwareudvikling

• Chancerne for fejl er mere agile, da dokumentation prioriteres mindre, hvilket i sidste ende lægger mere pres på QA-teamet
• Nye funktioner introduceres hurtigt, hvilket reducerer den tilgængelige tid for testteams til at identificere, om de nyeste funktioner er i overensstemmelse med kravet, og omhandler det virkelig forretningsdragten
• Testere er ofte forpligtet til at spille en semi-udviklerrolle
• Testudførelsescyklusser er meget komprimerede
• Meget mindre tid til at udarbejde testplan
• Til regressionstest vil de have minimal timing
• Skift i deres rolle fra at være en gate-keeper af kvalitet til at være en partner i Quality
• Kravændringer og opdateringer er iboende i en agil metode, som bliver den største udfordring for QA

Risiko for automatisering i agil proces

• Automatiseret brugergrænseflade giver et højt niveau af tillid, men de er langsomme at udføre, skrøbelige at vedligeholde og dyre at bygge. Automatisering forbedrer muligvis ikke testproduktiviteten markant, medmindre testerne ved, hvordan de skal teste
• Upålidelige tests er et stort problem i automatiseret test. Reparation af fejlagtige tests og løsning af problemer relateret til sprøde tests bør være en topprioritet for at undgå falske positiver
• Hvis den automatiserede test startes manuelt i stedet for gennem CI (Continuous Integration), er der risiko for, at de ikke kører regelmæssigt og derfor kan forårsage fejl i tests
• Automatiserede tests er ikke en erstatning for en eksplorativ manuel test. For at opnå den forventede kvalitet af produktet kræves en blanding af testtyper og niveauer
• Mange kommercielt tilgængelige automatiseringsværktøjer giver enkle funktioner såsom automatisering af indfangning og genafspilning af manuelle testcases. Et sådant værktøj tilskynder til test gennem brugergrænsefladen og fører til iboende sprøde og vanskelige at vedligeholde tests. Også lagring af testcases uden for versionskontrolsystemet skaber unødvendig kompleksitet
• For at spare tid er automatiseringstestplanen mange gange dårligt planlagt eller uplanlagt, hvilket resulterer i, at testen mislykkes
• En test-opsætning og -nedrivningsprocedure går normalt glip af under testautomatisering, mens manuel test, en testopsætning og -nedrivningsprocedure lyder problemfri
• Produktivitetsmålinger såsom et antal testsager, der oprettes eller udføres om dagen, kan være frygtelig misvisende og kan føre til en stor investering i at køre ubrugelige tests
• Medlemmer af det agile automatiseringsteam skal være effektive konsulenter: imødekommende, samarbejdsvillige og ressourcestærke, ellers vil dette system hurtigt fejle
• Automation kan foreslå og levere testløsninger, der kræver for meget løbende vedligeholdelse i forhold til den leverede værdi
• Automatiseret test kan mangle ekspertise til at udtænke og levere effektive løsninger
• Automatiseret test kan være så vellykket, at de løber tør for vigtige problemer at løse, og dermed bliver til uvæsentlige problemer.

Konklusion

Agile metodologi i softwaretest involverer test så tidligt som muligt i livscyklus til softwareudvikling. Det kræver høj kundeinvolvering og testkode, så snart den bliver tilgængelig. Koden skal være stabil nok til at tage den til systemtest. Omfattende regressionstest kan udføres for at sikre, at fejlene er rettet og testet. Hovedsageligt gør kommunikationen mellem holdene den agile modeltest til succes!!!