Er du bekendt med Agile Testing Life Cycle (ATLC)? Det er en proces, der bruges af softwareudviklingsteams til at sikre, at deres applikationer testes korrekt og effektivt.
Dette indlæg vil lede dig gennem alt, hvad du har brug for at vide om ATLC, inklusive dets fordele, trin involveret i processen, planlægning af en praktisk teststrategi, udførelse af test baseret på kravindsamling og fejlsporing, brugeraccepttest (UAT) og kontinuerlig integration & automatisering af tests.
Efter at have læst denne vejledning, vil du bedre forstå, hvordan du bruger agile test som en del af din softwareudviklings livscyklus!
Hvis du er en agil udvikler, tester eller produktchef, der leder efter en bedre måde at levere dine produkter på, så vil denne artikel forklare de involverede stadier sammen med den nødvendige handling.
Indholdsfortegnelse
Oversigt over Agile Testing Livscyklus
Det er ingen hemmelighed, at test er enormt vigtigt i verden af agil udvikling. Men på trods af det er det ofte undervurderet aktivitet indenfor agile levering. Årsagen er naturligvis pengene i forhold til leveringstidspunktet.
Men uden detaljerede tests ville der ikke være nogen garanti for kvalitet eller pålidelighed for noget produkt, dit team udvikler. Derfor er det afgørende at forstå den agile testlivscyklus – fra at identificere arbejdsemner til at forstå, hvilken type test der skal bruges inden for hver fase.
Den agile testcyklus kræver, at udviklere og testere er involveret i hver eneste sprint. At gøre det godt giver mulighed for testautomatisering på alle trin, hvilket hjælper med at opdage fejl tidligere og hyppigere, hvilket reducerer fejlfindingstiden senere.
Agile test hjælper også med den tidlige validering af krav og forbedrer som en bivirkning kundetilfredsheden ved at levere et kvalitetsprodukt.
Hvad er Agile Test og dets fordele
Agile Testing er en innovativ softwaretestmetode, der udnytter automatisering til at skabe en iterativ testproces. Denne automatiseringscentrerede tilgang hjælper teams med hurtigt at analysere eventuelle uoverensstemmelser eller problemer i koden og derefter teste ændringer baseret på denne feedback.
Så de vigtigste fordele ved denne proces ser ud til at være indlysende:
- sikre, at testen har den nødvendige effekt,
- det fører til mere effektive udviklingstider,
- det udviklede system har generelt hurtigere fejlløsningshastigheder,
- og kundetilfredsheden er forbedret.
Kvalitet og hurtighed er her afgørende faktorer, da spurten er defineret som en lille periode (typisk 2 til 4 uger). Jo mere holdet kan stole på kvalitet inkluderet i sprinttestningen, jo højere selvtillid og hurtigere udviklingsfremskridt kan holdet producere.
Fokus på automatisering bør være det primære mål for ethvert agilt team. Dette giver teams mulighed for at sænke risikoen for dyre fiaskoer og muliggør mere tid dedikeret til nyt indhold frem for at rette op på det, der allerede er i produktion.
En anden sidegevinst er en bedre vurdering af projektomkostninger og tidslinje. Da produktet er langt mere modent og forudsigeligt, er der færre situationer, hvor teamet skal håndtere uventede problemer, der er rejst inden for sprinten uden forudgående at beregne sådanne komplikationer.
Agil test af livscyklustrin
Den agile testlivscyklus består af fire adskilte stadier.
Enhedstests
Dette er de test, der udføres af udviklere, når koden er klar fra et udviklingssynspunkt. Det udføres isoleret i et udviklingsmiljø uden at involvere andre dele af systemet.
Enhedstest udføres for at teste koden og kan udføres manuelt og automatisk.
Hvis det udføres manuelt, kører udvikleren sine testcases mod koden. Dette er hurtigt at finde ud af, men det tager mere tid fra spurten dedikeret til udviklingen, især set fra et langsigtet perspektiv.
Et alternativ til dette er at oprette en automatiseret enhedstestkode, som grundlæggende vil verificere funktionskoden blot ved at udføre den. Dette betyder, at udvikleren skal bruge tid på ikke kun at udvikle den nye funktion, men også på at udvikle den enhedstestkode, der tester denne funktion.
Og selvom dette kan ligne en større indsats fra et kortsigtet perspektiv, er det en tidsbesparelse for projektet som helhed, fordi sådanne enhedstests er nemme at genbruge også i senere faser af sprinttestningen. De kan endda indgå i almindelige regressionstestsager, hvilket så sparer endnu mere tid.
Endelig, jo højere kodedækning ved automatiserede enhedstests, jo bedre kodepålidelighedsmetrikker kan fremvises for klienten.
Funktionelle tests
Funktionelle tests er designet til at bestemme, hvor godt en funktion i en applikation fungerer. Denne type test bruges til at sikre den korrekte funktionalitet af koden frem for tekniske aspekter (som hovedsageligt var en del af enhedstesten), samt vurdere hvorvidt den opfylder brugernes behov og forventninger.
Med andre ord bruges funktionelle tests til at verificere, at det udviklede lever op til de krav, som erhvervsbrugerne stiller.
Det er god praksis at samle vigtige testcases på forhånd og fra relevante interessenter (enten fra produktejeren eller endda fra slutbrugerne) og lave en liste over alle sådanne testcases, der er nødvendige for indholdet inde i sprinten.
Automatisering af funktionelle test kræver mere indsats på testudviklingssiden, da det er komplekse processer, der skal verificeres, herunder forskellige dele af systemet sammen. Den bedste strategi, i dette tilfælde, er at etablere et dedikeret team kun til at udvikle de funktionelle tests langs den linje, hovedudviklingsteamet udvikler nye funktioner.
Nok betyder det for projektet øgede omkostninger til at opretholde et separat team, men det har også et stort potentiale for at spare projektet penge på sigt. Det er kun op til projektledere at forklare og specifikt beregne fordelene og besparelserne for at fremføre et solidt argument foran forretningsbrugere, der vil føre til en sådan stigning i projektomkostningsgodkendelsen.
På den anden side, hvis den udføres manuelt, kan denne aktivitet udføres af et meget lille team (i nogle tilfælde endda en enkelt person). Dog vil en konstant manuel og gentagen aktivitet hver eneste sprint være påkrævet. Over tid, efterhånden som systemets funktionssæt udvides, kan det være sværere at hamle op med solide funktionelle test sprint for sprint.
Regressionstest
Formålet med regressionstesten skal være at sikre, at alt, der har fungeret indtil nu, også fungerer efter næste udgivelse. Der skal udføres regressionstest for at sikre, at der ikke er kompatibilitetsproblemer mellem forskellige moduler.
Testcases for regressionstest er bedst, hvis de regelmæssigt vedligeholdes og genbesøges før hver udgivelse. Baseret på de konkrete projektspecifikationer er det bedst at holde dem enkle og alligevel dække størstedelen af de helt kernefunktioner og vigtige ende-til-ende-flows, der løber gennem hele systemet.
Normalt har hvert system sådanne processer, der berører mange forskellige områder, og det er de bedste kandidater til regressionstestcases.
Hvis der er eksisterende automatiserede enhedstests og funktionelle tests, er det en meget nem opgave at skabe automatisering i regressionstest. Bare genbrug det, du allerede har, til den vigtigste del af systemet (f.eks. til processer, der bruges mest i produktionen).
Brugeraccepttest (UAT)
Sidst men ikke mindst validerer UAT, at applikationen opfylder de nødvendige krav til produktionsimplementering. Denne tilgang fungerer bedst, når du tester et stykke software ofte i korte og intense cyklusser.
UAT-testen skal udelukkende udføres af folk uden for det agile team, ideelt set af forretningsbrugere i et dedikeret miljø, som er så tæt på fremtidig produktion som muligt. Alternativt kan produktejeren her erstatte slutbrugerne.
Under alle omstændigheder bør dette være en ren, funktionel test fra slutbrugerens perspektiv uden nogen forbindelse til udviklerteamet. Resultaterne af disse test er her for at træffe den altafgørende go/no go-beslutning for produktionsudgivelse.
Planlægning af en effektiv teststrategi
Planlægning er en vigtig del af agile test, da det binder hele strategien sammen. Det skal også opstille klare forventninger til tidslinjen i forbindelse med spurterne.
Ved effektivt at styre agil testplanlægning kan teams skabe en klar retning, der fører til effektiv brug af ressourcer inden for en sprint. Det er klart, at der forventes et større samarbejde mellem testere og udviklere.
Der bør også etableres en omfattende plan for at kortlægge, hvornår enhedstest, funktionel test eller brugeraccepttest finder sted inden for hver udviklingssprint. Derfor ved alle præcis, hvornår deres deltagelse er nødvendig for en vellykket agil lancering.
Hvordan planen sættes op, kan ske efter nærmere drøftelse og aftale. Det vigtigste er dog at gøre det til en proces og holde fast i den. Skab en periodicitet, der vil være pålidelig og forudsigelig.
Flyt ikke væk fra processen. Ellers vil det stik modsatte være virkeligheden – kaos og uforudsigelige udgivelser til produktion.
Udførelse af test baseret på kravindsamling
Tests skal udføres i forhold til kravene på hvert trin. Billetter åbnes derefter, når en fejl eller et problem er fundet og tildelt udviklingsteamet, som så vil være i stand til at finde ud af, hvad der skal rettes eller ændres for koden. Når alle fejl er blevet rettet, kan eksekvering af agil test fortsætte, indtil alle test er bestået.
Gennemgang af resultater og fejlsporing
En effektiv gennemgang af resultater og en solid fejlsporingsproces er afgørende. Processen bør involvere alle relevante interessenter, fra projektledere og testere til udviklere, og i sidste ende supportteams, men også kunder til indsamling af feedback.
Dette bør være omfattende aktivitet nok til, at problemer kan identificeres hurtigt og afhjælpes, før den allerede planlagte udgivelsesdato er i fare.
Det valgte værktøj er igen op til holdet. Men når den først er valgt, skal enhver testaktivitet omfatte pålidelige fejlsporingsprocesser for at overvåge problemer, prioritere dem i henhold til afhængigheder, rapportere statusopdateringer fra udviklere om løsning eller overførsel til yderligere undersøgelse og derefter lukke billetter, når de er løst.
Gennemgang hjælper agile testere med at forstå deres systems adfærd og identificerer fejl ved hvert trin i stedet for senere i processen. Regelmæssige anmeldelser giver også agile teams mulighed for at identificere trends og områder, der skal forbedres, hvilket giver dem mulighed for løbende at opdatere deres testramme og hurtigere bygge produkter af bedre kvalitet.
Afslutning af produktudgivelsen med produktionsrøgtest
For at maksimere udgivelsens succes er en røgtest, der køres mod produktion (lige efter udgivelsen), en måde at få mere selvtillid på.
Denne test består af et sæt skrivebeskyttede aktiviteter inde i produktionssystemet, som ikke vil skabe nye tilfældige data, men som stadig vil verificere systemets grundlæggende funktionalitet fra slutbrugernes syn.
Inddragelse af de rigtige interessenter i processen hjælper med at sikre tilpasning og ansvarlighed, samtidig med at tilliden til, at målene er nået, øges. I sidste ende garanterer disse test en vellykket udgivelse.
Kontinuerlig integration og automatisering af tests for at forbedre effektiviteten
Kontinuerlig integration og automatisering af tests bliver i stigende grad taget i brug af virksomheder for at drive agile processer til det næste niveau.
Hvis teamet kan implementere automatisering i flere faser som beskrevet ovenfor, så kan disse kombineres og forbindes til en dedikeret testpipeline, som dybest set er en fuldautomatiseret batchproces, der udfører størstedelen af testaktiviteterne uafhængigt og uden involvering af noget andet team medlem.
Over tid vil en sådan omfattende testpipeline forkorte den samlede tid, der er nødvendig for alle testfaserne. Til sidst kan det føre til en virkelig hurtig trinvis produktionsfrigivelse efter afslutningen af hver sprint. Selvom dette er et ideelt case-scenarie, er det i virkeligheden svært at opnå med alle de involverede testtrin. Automatisering er den eneste måde at komme dertil.
Forskellen mellem agil test og vandfaldstest
Agile teststrategier adskiller sig fra traditionelle vandfaldsteststrategier på flere måder, såsom periodicitet, parallelitet eller dedikeret tid til hver aktivitet.
Men den mest bemærkelsesværdige forskel er fokus for hver tilgang:
- Agile test fokuserer på konstante, hurtige gentagelser af udvikling og feedback-loops for at identificere problemer og hurtigt forbedre produktet. En iterativ proces med fokus på kundesamarbejde, kontinuerlig integration og adaptiv planlægning.
- På den anden side lægger traditionel vandfaldstest vægt på en lineær proces, hvor hvert trin løses separat og i sekventiel rækkefølge, hvilket efterlader feedback fra hele løsningen kun for den allersidste fase af projektet og meget tæt på den endelige produktionsudgivelsesdato.
Det er klart, at jo hurtigere problemerne identificeres af de vigtigste interessenter, jo bedre er situationen for projektet. I denne henseende har agil metodologi absolut en bedre chance for succes.
Konklusion
Selvom den agile testlivscyklus kan se ud til at være kortere end vandfaldet, er den i virkeligheden ikke det. Hele processen er kontinuerlig og fortsætter indtil produktudgivelsesdatoen. Afhængigt af budgettet og den tid, der er til rådighed for hver sprint, bliver du nødt til at prioritere, hvilke tests der udføres i den pågældende sprint.
En veltilrettelagt teststrategi hjælper dig med at vælge, hvilke funktioner eller moduler der kræver mere opmærksomhed end andre. Automatisering vil muliggøre inklusion af flere testfaser i samme sprint, hvilket øger systemets overordnede pålidelighed fra sprint til sprint.
Du kan nu se på nogle af de bedste praksisser inden for scrum-test.