Er du kjent med begrepet Agil Testlivssyklus (ATLS)? Dette er en prosedyre som benyttes av programvareutviklingsteam for å sikre at deres applikasjoner testes på en korrekt og effektiv måte.
Denne artikkelen vil gi deg en innføring i alt du trenger å vite om ATLS, inkludert dens fordeler, trinnene som inngår i prosessen, planlegging av en praktisk teststrategi, gjennomføring av tester basert på kravinnsamling og feilsporing, brukertester (UAT) samt kontinuerlig integrasjon og testautomatisering.
Etter å ha lest denne guiden, vil du ha en bedre forståelse av hvordan du kan benytte smidig testing som en del av programvareutviklingsprosessen!
Dersom du er en agil utvikler, tester eller produktansvarlig som søker en bedre måte å levere produkter på, vil denne artikkelen forklare de ulike stadiene og de nødvendige tiltakene.
Oversikt over smidig testlivssyklus
Det er allment kjent at testing spiller en stor rolle i en verden av smidig utvikling. Likevel er det en aktivitet som ofte blir undervurdert innenfor smidig levering. Dette skyldes ofte et fokus på kostnader og rask produksjonsleveranse.
Uten grundig testing ville det imidlertid ikke finnes noen garanti for kvalitet eller pålitelighet for produktene som teamet utvikler. Det er derfor avgjørende å forstå smidig testlivssyklus – fra å identifisere arbeidselementer til å forstå hvilke typer tester som skal benyttes i de ulike fasene.
Den smidige testsyklusen forutsetter at utviklere og testere er involvert i hvert enkelt sprint. En god gjennomføring av dette muliggjør testautomatisering på alle trinn, noe som bidrar til å oppdage feil tidligere og oftere, og reduserer tiden som brukes på feilsøking i senere faser.
Smidig testing bidrar også til tidlig validering av krav, og som en sideeffekt øker kundetilfredsheten gjennom levering av et produkt av høy kvalitet.
Hva er smidig testing og dens fordeler
Agil Testing er en innovativ metodikk for programvaretesting som bruker automatisering for å skape en iterativ testprosess. Denne automatiseringsfokuserte tilnærmingen hjelper team med raskt å analysere eventuelle inkonsistenser eller problemer i koden, og deretter teste modifikasjoner basert på tilbakemeldinger.
De viktigste fordelene med denne prosessen er åpenbare:
- sikre at testingen har ønsket effekt,
- fører til mer effektive utviklingstider,
- reduserer tiden det tar å løse feil i det utviklede systemet,
- og øker kundetilfredsheten.
Kvalitet og hastighet er sentrale faktorer, da en sprint er definert som en kort tidsperiode (vanligvis 2 til 4 uker). Jo mer teamet kan stole på kvaliteten av sprinttestingen, jo høyere blir selvtilliten og jo raskere kan utviklingsfremgangen være.
Fokus på automatisering bør være et hovedmål for ethvert agilt team. Dette gjør det mulig for teamene å redusere risikoen for kostbare feil og gi mer tid til å skape nytt innhold fremfor å fikse feil i produksjonsmiljøet.
En annen fordel er bedre estimering av prosjektkostnader og tidslinjer. Ettersom produktet er mer modent og forutsigbart, oppstår det færre situasjoner der teamet må håndtere uventede problemer som dukker opp i sprinten uten at det er tatt høyde for slike komplikasjoner på forhånd.
Smidig testlivssyklus – trinn
Smidig testlivssyklus består av fire distinkte stadier.
Enhetstester
Dette er tester som utføres av utviklere når koden er klar fra et utviklingsperspektiv. Testen utføres isolert i et utviklingsmiljø uten involvering av andre deler av systemet.
Enhetstester utføres for å kontrollere koden, og dette kan gjøres både manuelt og automatisk.
Ved manuell testing kjører utvikleren sine testsaker mot koden. Dette er en rask måte å avdekke feil på, men det stjeler tid fra sprinten som ellers kunne blitt brukt på utvikling, særlig på lang sikt.
Et alternativ er å utvikle automatiserte enhetstester, som i bunn og grunn verifiserer funksjonskoden ved å kjøre den. Dette betyr at utvikleren ikke bare må bruke tid på å utvikle en ny funksjon, men også på å utvikle enhetstestkoden som skal teste denne funksjonen.
Selv om dette kan virke som en større innsats på kort sikt, er det en tidsbesparende fordel for prosjektet som helhet, da slike enhetstester er enkle å gjenbruke også i senere stadier av sprinttestingen. De kan til og med inkluderes i vanlige regresjonstesttilfeller, noe som da sparer enda mer tid.
Jo høyere kodedekning automatiserte enhetstester har, jo bedre kodepålitelighet kan vises til klienten.
Funksjonstester
Funksjonstester er utformet for å fastslå hvor godt en funksjon i en applikasjon fungerer. Denne formen for testing brukes for å sikre at koden har riktig funksjonalitet, heller enn tekniske aspekter (som hovedsakelig var en del av enhetstesten), samt å vurdere om den oppfyller behovene og forventningene til brukerne.
Med andre ord brukes funksjonstester til å verifisere at det som er utviklet, oppfyller kravene fra forretningsbrukerne.
Det anbefales å samle viktige testsaker på forhånd og fra relevante interessenter (enten fra produkteier eller til og med fra sluttbrukerne) og lage en liste over alle slike testsaker som trengs for innholdet i sprinten.
Automatisering av funksjonstester krever mer innsats på utviklingssiden, da det er komplekse prosesser som skal verifiseres, inkludert ulike deler av systemet. Den beste strategien i dette tilfellet er å etablere et eget team kun for å utvikle funksjonstestene, parallelt med hovedutviklingsteamet som utvikler nye funksjoner.
For prosjektet betyr dette økte kostnader ved å opprettholde et eget team, men det har også et stort potensial for å spare prosjektet for penger på sikt. Det er opp til prosjektledere å forklare og spesifikt beregne fordelene og besparelsene for å komme med et solid argument overfor forretningsbrukere, noe som kan føre til en godkjenning av den økte prosjektkostnaden.
På den andre siden, dersom det gjøres manuelt, kan denne aktiviteten utføres av et svært lite team (i enkelte tilfeller til og med en enkelt person). Likevel vil en konstant manuell og gjentatt aktivitet være nødvendig for hver eneste sprint. Over tid, etterhvert som funksjonaliteten i systemet utvides, kan det bli vanskeligere å gjennomføre solid funksjonell testing fra sprint til sprint.
Regresjonstester
Hensikten med regresjonstester er å sørge for at alt som har fungert til nå, også vil fungere etter neste utgivelse. Regresjonstester må utføres for å sikre at det ikke er kompatibilitetsproblemer mellom de ulike modulene.
Testtilfeller for regresjonstester er best om de vedlikeholdes regelmessig og gjennomgås før hver utgivelse. Basert på de konkrete prosjektspesifikasjonene er det best å holde dem enkle, men samtidig dekke de fleste kjernefunksjonene og viktige ende-til-ende-flyter som går gjennom hele systemet.
Vanligvis har hvert system prosesser som berører mange ulike områder, og det er de beste kandidatene for regresjonstesttilfeller.
Dersom det finnes eksisterende automatiserte enhets- og funksjonstester, er det en enkel oppgave å lage automatisering for regresjonstesting. Gjenbruk det du allerede har for de viktigste delene av systemet (f.eks. for prosesser som brukes mest i produksjon).
Brukertester (UAT)
Til slutt validerer UAT at applikasjonen oppfyller de nødvendige kravene for distribusjon til produksjon. Denne tilnærmingen fungerer best når du tester programvare ofte i korte og intensive sykluser.
UAT-testen skal kun utføres av personer utenfor det smidige teamet, ideelt sett av forretningsbrukere i et dedikert miljø som er så likt det fremtidige produksjonsmiljøet som mulig. Alternativt kan produkteier erstatte sluttbrukerne.
Uansett bør dette være en ren, funksjonell test fra sluttbrukerens perspektiv, uten noen tilknytning til utviklerteamet. Resultatene av disse testene avgjør om produktet kan lanseres eller ikke.
Planlegging for en effektiv teststrategi
Planlegging er en viktig del av smidig testing, da det knytter sammen hele strategien. Det må også etableres klare forventninger til tidslinjen for de ulike sprintene.
Ved effektivt å administrere agil testplanlegging, kan team skape en klar retning som fører til effektiv ressursbruk innenfor en sprint. Det er også forventet et større samarbeid mellom testere og utviklere.
Det bør også etableres en omfattende plan for å kartlegge når enhetstesting, funksjonstesting eller brukertesting skal finne sted i hver utviklingssprint. Dette sørger for at alle vet nøyaktig når deres deltakelse er nødvendig for en vellykket smidig lansering.
Hvordan planen settes opp, kan være gjenstand for diskusjon og avtale. Det viktigste er imidlertid å gjøre det til en prosess og holde seg til den. Lag en periodisitet som er pålitelig og forutsigbar.
Unngå å avvike fra prosessen. I motsatt fall blir resultatet det motsatte – kaos og uforutsigbare utgivelser til produksjon.
Utføre tester basert på kravinnsamling
Tester må utføres opp mot kravene i hvert trinn. Billetter opprettes når det oppdages feil eller problemer, og disse tildeles utviklingsteamet. Deretter vil teamet kunne finne ut hva som må rettes eller endres i koden. Når alle feil er rettet, kan den smidige testkjøringen fortsette til alle tester er bestått.
Gjennomgang av resultater og feilsporing
En effektiv gjennomgang av resultater og en solid feilsporingsprosess er avgjørende. Prosessen bør involvere alle relevante interessenter, fra prosjektledere og testere til utviklere, og etter hvert også kundesupportteam og kunder for å innhente tilbakemeldinger.
Gjennomgangen bør være omfattende nok til at problemer raskt kan identifiseres og rettes før den planlagte utgivelsesdatoen er i fare.
Valget av verktøy er opp til teamet. Men når et verktøy er valgt, må enhver testaktivitet inkludere pålitelige feilsporingsprosesser for å overvåke problemer, prioritere dem basert på avhengigheter, rapportere statusoppdateringer fra utviklerne angående løsning eller videresending for videre undersøkelse, og deretter lukke billetter når feilene er løst.
Gjennomgang hjelper agile testere med å forstå systemets oppførsel og identifisere feil ved hvert trinn, fremfor senere i prosessen. Regelmessige gjennomganger gjør det også mulig for agile team å identifisere trender og områder som trenger forbedring, slik at de kontinuerlig kan oppdatere testrammeverket og bygge produkter av bedre kvalitet raskere.
Fullføre produktutgivelsen med produksjonsrøyktest
For å maksimere utgivelsens suksess, er det en fordel å kjøre en røyktest mot produksjonsmiljøet rett etter lansering. Dette gir mer selvtillit.
Denne testen består av en rekke skrivebeskyttede aktiviteter i produksjonssystemet, som ikke vil generere ny eller tilfeldig data, men likevel vil verifisere den grunnleggende funksjonaliteten i systemet fra sluttbrukerens synspunkt.
Å involvere de rette interessentene i prosessen bidrar til å sikre samordning og ansvarlighet samtidig som det øker tilliten til at målene er nådd. Til syvende og sist garanterer disse testene en vellykket utgivelse.
Kontinuerlig integrasjon og automatisering av tester for å forbedre effektiviteten
Kontinuerlig integrasjon og automatisering av tester blir i økende grad tatt i bruk av bedrifter for å løfte agile prosesser til neste nivå.
Dersom teamet kan implementere automatisering i flere stadier som beskrevet ovenfor, kan disse kombineres og kobles til en dedikert testpipeline. Dette er i bunn og grunn en helautomatisert batchprosess som utfører de fleste testaktivitetene uavhengig og uten involvering fra andre teammedlemmer.
Over tid vil en slik omfattende testpipeline forkorte den totale tiden som trengs for alle testfasene. Til slutt kan det føre til raskere, inkrementell utgivelse til produksjon etter slutten av hver sprint. Selv om dette er et ideelt scenario, er det i praksis vanskelig å oppnå med alle de involverte testtrinnene. Automatisering er den eneste måten å komme dit på.
Forskjellen mellom smidig testing og fossefalltesting
Agile teststrategier skiller seg fra tradisjonelle fossefallteststrategier på flere måter, som periodisitet, parallellitet og dedikert tid for hver aktivitet.
Men den mest bemerkelsesverdige forskjellen er fokus for hver tilnærming:
- Smidig testing fokuserer på konstante, raske iterasjoner av utvikling og tilbakemeldingssløyfer for å identifisere problemer og raskt forbedre produktet. En iterativ prosess med fokus på kundesamarbeid, kontinuerlig integrasjon og adaptiv planlegging.
- Tradisjonell fossefalltesting legger derimot vekt på en lineær prosess der hvert trinn løses separat og i sekvensiell rekkefølge. Dette gjør at tilbakemeldinger på hele løsningen først blir samlet inn i den aller siste fasen av prosjektet og svært nærme den endelige produksjonsutgivelsen.
Jo tidligere problemene identifiseres av de viktigste interessentene, jo bedre er situasjonen for prosjektet. I denne sammenheng har smidig metodikk definitivt en bedre sjanse til å lykkes.
Konklusjon
Selv om den smidige testlivssyklusen kan se ut til å være kortere enn fossefall, er den i virkeligheten ikke det. Hele prosessen er kontinuerlig og fortsetter frem til produktets lanseringsdato. Avhengig av budsjett og tilgjengelig tid for hver sprint, må det prioriteres hvilke tester som utføres i den aktuelle sprinten.
En godt planlagt teststrategi hjelper deg med å velge hvilke funksjoner eller moduler som krever mer oppmerksomhet enn andre. Automatisering vil muliggjøre inkludering av flere testtrinn i samme sprint, noe som øker systemets generelle pålitelighet fra sprint til sprint.
Du kan nå se nærmere på noen av de beste fremgangsmåtene innen scrum-testing.