Er du kjent med Agile Testing Life Cycle (ATLC)? Det er en prosess som brukes av programvareutviklingsteam for å sikre at applikasjonene deres testes riktig og effektivt.
Dette innlegget vil lede deg gjennom alt du trenger å vite om ATLC, inkludert fordelene, trinnene involvert i prosessen, planlegging for en praktisk teststrategi, utførelse av tester basert på kravinnsamling og feilsporing, brukerakseptetester (UAT) og kontinuerlig integrasjon og automatisering av tester.
Etter å ha lest denne veiledningen, vil du bedre forstå hvordan du bruker smidig testing som en del av livssyklusen for programvareutvikling!
Hvis du er en smidig utvikler, tester eller produktsjef som leter etter en bedre måte å levere produktene dine på, så vil denne artikkelen forklare stadiene som er involvert sammen med de nødvendige tiltakene.
Innholdsfortegnelse
Oversikt over livssyklus for smidig testing
Det er ingen hemmelighet at testing er enormt viktig i en verden av smidig utvikling. Men til tross for det er det ofte undervurdert aktivitet innen smidig levering. Årsaken er selvfølgelig pengene i forhold til tid til produksjonslevering.
Men uten detaljert testing ville det ikke vært noen garanti for kvalitet eller pålitelighet for noe produkt teamet ditt utvikler. Derfor er det avgjørende å forstå livssyklusen for smidig testing – fra å identifisere arbeidselementer til å forstå hvilken type test som skal brukes i hver fase.
Den smidige testsyklusen krever at utviklere og testere er involvert i hver eneste sprint. Å gjøre det godt muliggjør testautomatisering på alle trinn, noe som hjelper til med å oppdage feil tidligere og oftere, og reduserer feilsøkingstiden senere.
Smidig testing hjelper også med tidlig validering av krav og, som en bieffekt, forbedrer kundetilfredsheten ved å levere et kvalitetsprodukt.
Hva er smidig testing og dens fordeler
Agile Testing er en innovativ programvaretestmetodikk som utnytter automatisering for å lage en iterativ testprosess. Denne automatiseringssentriske tilnærmingen hjelper teamene raskt å analysere eventuelle inkonsekvenser eller problemer i koden og deretter teste modifikasjoner basert på denne tilbakemeldingen.
Så hovedfordelene med denne prosessen ser ut til å være åpenbare:
- sikre at testingen har nødvendig effekt,
- det fører til mer effektive utviklingstider,
- det utviklede systemet har generelt raskere feilløsningshastigheter,
- og kundetilfredsheten er forbedret.
Kvalitet og hastighet er avgjørende faktorer her, da sprinten defineres som en liten tidsperiode (typisk 2 til 4 uker). Jo mer teamet kan stole på kvalitet inkludert i sprinttestingen, jo høyere selvtillit og raskere utviklingsfremgang kan teamet produsere.
Fokus på automatisering bør være hovedmålet for ethvert smidig team. Dette lar teamene redusere risikoen for kostbare feil og gir mer tid dedikert til å lage nytt innhold i stedet for å fikse det som allerede er i produksjon.
En annen sidegevinst er en bedre estimering av prosjektkostnad og tidslinje. Siden produktet er langt mer modent og forutsigbart, er det færre situasjoner der teamet må håndtere uventede problemer som er reist i sprinten uten å beregne slike komplikasjoner på forhånd.
Smidig testing av livssyklustrinn
Livssyklusen for smidig testing består av fire forskjellige stadier.
Enhetstester
Dette er testene som utføres av utviklere når koden er klar fra et utviklingssynspunkt. Den utføres isolert i et utviklingsmiljø uten å involvere andre deler av systemet.
Enhetstester utføres for å teste koden og kan gjøres manuelt og automatisk.
Hvis den utføres manuelt, kjører utvikleren testsakene sine mot koden. Dette er raskt å finne ut av, men det tar mer tid fra sprinten dedikert til utviklingen, spesielt fra et langsiktig perspektiv.
Et alternativ til dette er å lage en automatisert enhetstestkode, som i utgangspunktet vil verifisere funksjonskoden bare ved å utføre den. Dette betyr at utvikleren ikke bare må bruke tid på å utvikle den nye funksjonen, men også på å utvikle enhetstestkoden som skal teste den funksjonen.
Og selv om dette kan se ut som en større innsats fra et kortsiktig perspektiv, er det en tidsbesparelse for prosjektet som helhet fordi slike enhetstester er enkle å gjenbruke også i senere stadier av sprinttestingen. De kan til og med inkluderes i vanlige regresjonstesttilfeller, som da sparer enda mer tid.
Til slutt, jo høyere kodedekning av automatiserte enhetstester, desto bedre kodepålitelighetsverdier kan vises til klienten.
Funksjonstester
Funksjonstester er utformet for å bestemme hvor godt en funksjon i en applikasjon fungerer. Denne typen testing brukes for å sikre riktig funksjonalitet til koden fremfor tekniske aspekter (som hovedsakelig var en del av enhetstesten), samt vurdere om den oppfyller behovene og forventningene til brukerne eller ikke.
Med andre ord brukes funksjonstester for å verifisere at det som ble utviklet oppfyller kravene gitt av bedriftsbrukerne.
Det er god praksis å samle viktige testcaser på forhånd og fra relevante interessenter (enten fra produktets eier eller til og med fra sluttbrukerne) og lage en liste over alle slike testcaser som trengs for innholdet inne i sprinten.
Automatisering av funksjonstester innebærer mer innsats på testutviklingssiden, siden det er komplekse prosesser som skal verifiseres, inkludert ulike deler av systemet sammen. Den beste strategien, i dette tilfellet, er å etablere et dedikert team bare for å utvikle funksjonstestene langs linjen som hovedutviklingsteamet utvikler nye funksjoner.
Visst, for prosjektet betyr dette økte kostnader for å opprettholde et eget team, men det har også et stort potensial for å spare prosjektet penger på sikt. Det er kun opp til prosjektledere å forklare og spesifikt beregne fordelene og besparelsene for å komme med et solid argument foran forretningsbrukere som vil føre til en slik økning i prosjektkostnadsgodkjenningen.
På den andre siden, hvis den gjøres manuelt, kan denne aktiviteten utføres av et veldig lite team (i noen tilfeller til og med en enkelt person). Imidlertid vil en konstant manuell og gjentatt aktivitet hver eneste sprint være nødvendig. Over tid, ettersom funksjonssettet til systemet utvides, kan det være vanskeligere å ta igjen solid funksjonell testing sprint for sprint.
Regresjonstester
Hensikten med regresjonstesten skal være å sikre 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 ulike moduler.
Testtilfeller for regresjonstester er best hvis de regelmessig vedlikeholdes og tas opp igjen før hver utgivelse. Basert på de konkrete prosjektspesifikasjonene, er det best å holde dem enkle, men likevel dekke de fleste av kjernefunksjonene og viktige ende-til-ende-flyter som går gjennom hele systemet.
Vanligvis har hvert system slike prosesser som berører mange forskjellige områder, og det er de beste kandidatene for regresjonstesttilfeller.
Hvis det er eksisterende automatiserte enhetstester og funksjonstester, er det en veldig enkel oppgave å lage automatisering i regresjonstesting. Bare gjenbruk det du allerede har til den viktigste delen av systemet (f.eks. for prosesser som brukes mest i produksjonen).
User Acceptance Tests (UAT)
Sist, men ikke minst, validerer UAT at applikasjonen oppfyller de nødvendige kravene for produksjonsdistribusjon. Denne tilnærmingen fungerer best når du tester et stykke programvare ofte i korte og intense sykluser.
UAT-testen skal kun utføres av personer utenfor det smidige teamet, ideelt sett av forretningsbrukere i et dedikert miljø, som er så nær fremtidig produksjon som mulig. Alternativt kan produktets eier erstatte sluttbrukerne her.
Uansett bør dette være en ren, funksjonell test fra sluttbrukerens perspektiv, uten noen tilknytning til utviklerteamet. Resultatene av disse testene er her for å ta den viktige go/no go-avgjørelsen for produksjonsutgivelse.
Planlegging for en effektiv teststrategi
Planlegging er en viktig del av smidig testing, da den binder sammen hele strategien. Den må også sette klare forventninger til tidslinjen i forbindelse med spurtene.
Ved å effektivt administrere smidig testplanlegging, kan team skape en klar retning som fører til effektiv ressursbruk innenfor en sprint. Det er åpenbart forventet større samarbeid mellom testere og utviklere.
Det bør også etableres en omfattende plan for å kartlegge når enhetstesting, funksjonstesting eller brukeraksepttesting skjer innenfor hver utviklingssprint. Derfor vet alle nøyaktig når deres deltakelse er nødvendig for en vellykket smidig lansering.
Hvordan sette opp planen kan være etter nærmere diskusjon og avtale. Det viktigste er imidlertid å gjøre det til en prosess og holde seg til det. Lag en periodisitet som vil være pålitelig og forutsigbar.
Ikke flyt bort fra prosessen. Ellers blir virkeligheten direkte motsatt – kaos og uforutsigbare utgivelser til produksjon.
Utføre tester basert på kravsamling
Tester må utføres mot kravene i hvert trinn. Billetter åpnes deretter når en feil eller et problem blir funnet og tilordnet utviklingsteamet, som da vil kunne finne ut hva som må fikses eller endres for koden. Når alle feilene er fikset, kan den smidige testkjøringen fortsette til alle testene 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 støtteteam, men også kunder for innhenting av tilbakemeldinger.
Dette bør være omfattende aktivitet nok til at problemer kan identifiseres raskt og utbedres før den allerede planlagte utgivelsesdatoen er i fare.
Valget verktøy er igjen opp til teamet. Men når den først er valgt, må enhver testaktivitet inkludere pålitelige feilsporingsprosesser for å overvåke problemer, prioritere dem i henhold til avhengigheter, rapportere tilbake statusoppdateringer fra utviklere om løsning eller overføring for videre undersøkelse, og deretter lukke billetter når de er løst.
Gjennomgang hjelper smidige testere å forstå systemets oppførsel, og identifiserer feil ved hvert trinn i stedet for senere i prosessen. Regelmessige gjennomganger lar også smidige 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 en røyktest som kjøres mot produksjon (rett etter utgivelsen) en måte å få mer selvtillit på.
Denne testen består av et sett med skrivebeskyttede aktiviteter inne i produksjonssystemet, som ikke vil skape noen nye tilfeldige data, men vil fortsatt verifisere den grunnleggende funksjonaliteten til systemet fra sluttbrukernes syn.
Å 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 å drive smidige prosesser til neste nivå.
Hvis teamet kan implementere automatisering i flere stadier som beskrevet ovenfor, kan disse kombineres og kobles til en dedikert testpipeline, som i utgangspunktet er en helautomatisert batchprosess som utfører mesteparten av testaktivitetene uavhengig og uten involvering av noe annet team medlem.
Over tid vil en slik omfattende testpipeline forkorte den totale tiden som trengs for alle testfasene. Til slutt kan det føre til en veldig rask inkrementell produksjonsutgivelse etter slutten av hver sprint. Selv om dette er et ideelt case-scenario, er det i virkeligheten vanskelig å oppnå med alle testtrinnene som er involvert. Automatisering er den eneste måten å komme dit på.
Forskjellen mellom smidig testing og fossetesting
Agile teststrategier skiller seg fra tradisjonelle fossefallsteststrategier på flere måter, som periodisitet, parallellitet eller dedikert tid for hver aktivitet.
Men den mest bemerkelsesverdige forskjellen er fokuset for hver tilnærming:
- Smidig testing fokuserer på konstante, raske gjentakelser av utvikling og tilbakemeldingssløyfer for å identifisere problemer og raskt forbedre produktet. En iterativ prosess fokusert på kundesamarbeid, kontinuerlig integrasjon og adaptiv planlegging.
- På den annen side legger tradisjonell fossefallstesting vekt på en lineær prosess der hvert trinn løses separat og i sekvensiell rekkefølge, slik at tilbakemeldingene fra hele løsningen bare forlates for den aller siste fasen av prosjektet og svært nær den endelige produksjonsutgivelsesdatoen.
Jo tidligere problemene blir identifisert av hovedinteressenter, jo bedre er situasjonen for prosjektet. I denne forbindelse har smidig metodikk definitivt en bedre sjanse for å lykkes.
Konklusjon
Selv om den smidige testlivssyklusen kan se ut til å være kortere enn fossen, er den i virkeligheten ikke det. Hele prosessen er kontinuerlig og fortsetter frem til produktutgivelsesdatoen. Avhengig av budsjett og tilgjengelig tid for hver sprint, må du prioritere hvilke tester som utføres i løpet av den aktuelle spurten.
En godt planlagt teststrategi hjelper deg å velge hvilke funksjoner eller moduler som krever mer oppmerksomhet enn andre. Automatisering vil muliggjøre inkludering av flere testetrinn i samme sprint, noe som øker systemets generelle pålitelighet fra sprint til sprint.
Du kan nå se på noen av de beste praksisene innen scrum-testing.