Agil testning: Metodologi og livscyklus

Hvad er Agile Test?

Agile test er en testpraksis, der følger reglerne og principperne for agil softwareudvikling. I modsætning til vandfaldsmetoden begynder agil testning ved projektets start og kører kontinuerligt sideløbende med udviklingen. Den er ikke sekventiel – udføres først efter kodningsfasen – men vævet ind i hver iteration, så feedback når teamet i det øjeblik, fejl opstår.

Principper for agil testning

De væsentlige principper for agil testning er:

• Arbejdssoftware er det primære mål for fremskridt.
• De bedste resultater kommer fra selvorganiserende teams.
• Tidlig og kontinuerlig levering af værdifuld software er den højeste prioritet.
• Udviklere og testere samarbejder dagligt gennem hele projektet.
• Agilitet forbedres gennem løbende teknisk forbedring og godt design.
• Løbende feedback sikrer, at det endelige produkt lever op til virksomhedens forventninger.
• Testning kører under implementeringen, hvilket reducerer den samlede udviklingstid.
• Testprocessen opretholder et ensartet og bæredygtigt tempo.
• Teams holder regelmæssige pauser for at reflektere og justere for at blive mere effektive.
• De bedste arkitekturer, krav og designs opstår fra selvorganiserende teams.
• Ansigt-til-ansigt samtale er den mest effektive og virkningsfulde form for kommunikation i teamet.

Anvendt tilsammen øger disse principper softwareproduktiviteten og forkorter vejen fra idé til fungerende funktion.

Agil test livscyklus

Den agile testcyklus gennemføres i fem faser, som vist nedenfor.

Faserne er:

• Fase 1: Konsekvensanalyse. Indsaml input fra interessenter og brugere. Dette kaldes også feedbackfasen, fordi den hjælper testingeniører med at sætte mål for den næste livscyklus.
• Fase 2: Planlægning af agil testning. Alle interessenter mødes for at planlægge testplanen, omfanget og leverancerne.
• Fase 3: Udgivelsesberedskab. Revse de funktioner, der er blevet implementeret, og beslut, hvilke der er klar til at gå live, og hvilke der skal vende tilbage til udvikling.
• Fase 4: Daglige scrums. Morgenens stående møde, hvor teamet indhenter status på test og sætter mål for dagen.
• Fase 5: Test Agility Review. Ugentlige møder med interessenter for at evaluere fremskridt i forhold til mål og justere strategien.

Agile testplan

An agil testplan beskriver de typer test, der udføres i en iteration, de nødvendige data og infrastruktur, testmiljøerog testresultaterne. I modsætning til vandfaldsmodellen skrives og opdateres en agil testplan for hver udgivelse. En typisk plan inkluderer:

• Testomfang.
• Ny funktionalitet testes.
• Testniveau eller -type baseret på funktionens kompleksitet.
• Belastnings- og ydeevnetest.
• Overvejelser vedrørende infrastruktur.
• Risiko- og afbødningsplan.
• Ressourceindsamling.
• Leverancer og milepæle.

Agile teststrategier

Den agile testlivscyklus strækker sig over fire strategiske faser.

Iteration 0

I den første fase udfører du de indledende opsætningsopgaver. Disse omfatter at identificere personer til test, installere testværktøjer og planlægge ressourcer såsom et laboratorium for brugervenlighedstestning. Målene med Iteration 0 er at:

• Udarbejd en business case for projektet.
• Definer randbetingelser og projektets omfang.
• Skitser de vigtigste krav og use cases, der vil føre til designafvejninger.
• Skitsér en eller flere kandidatarkitekturer.
• Identificer risici.
• Estimer omkostninger og udarbejde en foreløbig projektplan.

Konstruktionsgentagelser

Den anden fase af agil testning er konstruktionsiterationer, hvor størstedelen af ​​testningen finder sted. Denne fase er et sæt iterationer, der bygger løsningen trinvis. Inden for hver iteration anvender teamet en hybrid af praksisser fra XP, Scrum, agil modellering og agile data.

Teams følger praksis for prioriterede krav: Ved hver iteration trækker de de vigtigste elementer fra backloggen og implementerer dem. Konstruktionsiterationer er opdelt i to komplementære testvarianter:

• Bekræftende testning verificerer, at systemet opfylder interessenternes intentioner. Det udføres af teamet selv.
• Undersøgelsestestning søger efter problemer, som bekræftende testning muligvis har overset. Testere rejser potentielle problemer som defekthistorier. Undersøgende testning dækker integration, belastning og stress samt sikkerhedstestning.

Bekræftende testning har yderligere to aspekter — udviklertest og agil accepttest — og begge er automatiserede for at muliggøre kontinuerlig regressionstestning gennem hele livscyklussen. Bekræftende testning er den agile ækvivalent til testning i henhold til specifikationen.

Agil accepttest kombinerer traditionel funktionel test og accepttest, fordi udviklingsteamet og interessenterne udfører det sammen. Udviklertest kombinerer traditionel enhedstest med serviceintegrationstest og verificerer både applikationskode og databaseskema.

Udgivelse, slutspil eller overgangsfase

Målet med udgivelsesfasen er at implementere systemet i produktion med succes. Aktiviteterne omfatter træning af slutbrugere, supportpersonale og driftsteams; markedsføring af produktudgivelsen; backup- og gendannelsesøvelser; og færdiggørelse af system- og brugerdokumentation.

Den sidste fase af den agile test omfatter fuld systemtest og accepttest. For at afslutte uden forhindringer skal produktet testes grundigt under konstruktionsiterationer. I slutfasen fokuserer testerne på at løse defekthistorier, der er blevet rejst tidligere i cyklussen.

Produktion

Efter frigivelsesfasen går produktet i produktion, hvor det overvåges for live-adfærd, og eventuelle problemer føres tilbage til den næste planlægningscyklus.

De agile testkvadranter

De agile testkvadranter opdeler hele processen i fire områder og hjælper teams med at forstå, hvordan agil testning udføres.

Agile kvadrant I

Kvadrant I fokuserer på intern kodekvalitet med teknologidrevne tests, der understøtter teamet:

• Enhedstests.
• Komponenttests.

Agile kvadrant II

Kvadrant II indeholder forretningsdrevne tests, der understøtter teamet og fokuserer på krav. Typisk arbejde i denne kvadrant omfatter:

• Test af eksempler på mulige scenarier og arbejdsgange.
• Test af brugeroplevelsesartefakter såsom prototyper.
• Partestning.

Agile kvadrant III

Kvadrant III giver feedback til kvadranter I og II. Testcases her danner ofte grundlag for automatisering, og flere iterationsgennemgange opbygger tillid til produktet. Typisk arbejde omfatter:

• Brugervenlighedstestning.
• Udforskende testning.
• Partest med kunder.
• Samarbejdstestning.
• Brugeraccepttestning.

Agile kvadrant IV

Kvadrant IV fokuserer på ikke-funktionelle krav såsom ydeevne, sikkerhed og stabilitet. Denne kvadrant sikrer, at applikationen leverer de forventede ikke-funktionelle kvaliteter. Typisk arbejde omfatter:

• Ikke-funktionelle tests såsom stress- og performancetest.
• Sikkerhedstest, der dækker autentificering og indtrængningsforsøg.
• Infrastrukturtestning.
• Test af datamigrering.
• Skalerbarhedstestning.
• Belastningstestning.

QA-udfordringer med agil softwareudvikling

Agil levering giver reelle fordele, men det skaber også nye udfordringer for QA-teams:

• Dokumentation prioriteres lavere, så risikoen for fejl stiger, og presset flyttes til QA-teamet.
• Nye funktioner ankommer hurtigt, hvilket giver testere mindre tid til at verificere de nyeste funktioner i forhold til krav og forretningsintentioner.
• Testere spiller ofte en semi-udviklerrolle.
• Testudførelsescyklusser er meget komprimerede.
• Der er begrænset tid til rådighed til at udarbejde testplanen.
• Budgetterne for regressionstest bliver stramme.
• Testere går fra at være kvalitetsvogtere til at være partnere inden for kvalitet.
• Hyppige kravændringer er en uundværlig del af agile løsninger, hvilket er en af ​​QA's største udfordringer.

Risiko for automatisering i den agile proces

Automatisering er essentielt i agile aktiviteter, men det indebærer risici, som teams aktivt skal håndtere:

• Automatiserede UI-tests tilbyder høj sikkerhed, men er langsomme, skrøbelige og dyre at vedligeholde. Produktivitetsgevinster ses kun, når testere ved, hvordan man designer gode tests.
• Upålidelige tests er en stor bekymring. At rette op på skrøbelige tests og falsk positive resultater skal fortsat være en topprioritet.
• Automatiserede tests, der kører manuelt i stedet for via CI, risikerer at drive lydløst hen og producere forældede resultater.
• Automatisering erstatter ikke udforskende manuel testning. En blanding af testtyper og -niveauer er nødvendig for at opnå den forventede kvalitet.
• Værktøjer til optagelse og afspilning fremmer brugergrænsefladebaserede scripts, der er skrøbelige og svære at vedligeholde. Tests, der er gemt uden for versionskontrol, tilføjer unødvendig kompleksitet.
• Dårligt planlagt automatisering, der udføres for at "spare tid", mislykkes ofte fuldstændigt.
• Testopsætnings- og nedtagningsprocedurer er lette at overse ved automatisering, mens manuel testning håndterer dem naturligt.
• Produktivitetsmålinger som "testcases pr. dag" kan vildlede teams til at køre unyttige tests.
• Automatiseringsteamet skal være effektive konsulenter – imødekommende, samarbejdsvillige og ressourcefulde – ellers vil praksissen mislykkes.
• Løsninger, der kræver omfattende løbende vedligeholdelse, kan opveje den værdi, de leverer.
• Automatiserede tests mangler muligvis den nødvendige ekspertise til at levere effektive løsninger.
• Succesfuld automatisering kan løbe tør for vigtige problemer at løse og føre til mindre værdifuldt arbejde.

De bedste fremgangsmåder for effektiv agil testning

Følgende fremgangsmåder sikrer, at agil testning er hurtig, pålidelig og værdifuld for teamet:

• Shift venstre: Start testningen på kravtidspunktet, ikke ved slutningen af ​​iterationen.
• Par med udviklere: Gennemgå acceptkriterierne sammen, så defekter designes udefra og ikke indkodes.
• Lagautomatisering: Byg en sund pyramide af enheds-, service- og UI-tests.
• Hold testene uafhængige: Isoler hver test, så fejl peger på en enkelt grundlæggende årsag.
• Track flaky tests: karantæne og rette ustabile tests hurtigt for at forhindre underminering af tilliden i pakken.
• Brug AI-assisteret analyse: Lad værktøjer markere påvirkede tests, gruppere fejl og foreslå stabile lokatorer efter hver fletning.

Ofte Stillede Spørgsmål