Scrum minus testplan tilsvarer POC på steroider.
I dag starter de fleste vellykkede prosjekter med en Proof of Concept (POC), en relativt liten vurdering av en idé, hvor den valgte teknologien og funksjonspakken først vil bli verifisert, evaluert for potensiell innvirkning på forretningsbrukere, og deretter, når den er bevist verdig å investere, er et prosjektteam i full størrelse tildelt til å designe og levere det fullfunksjonsproduktet og distribuere det til produksjon.
Dette er den perfekte saken for et Scrum-team. Teamet kan raskt utvikle prototypen og legge til betydelige nye funksjoner hver sprint, mens forretningsbrukere kan se i sanntid rask fremgang og hvordan ideen bygges fra bunnen av i løpet av omtrent 10 sprints. Det etterlater et sterkt inntrykk (som er hovedmålet for POC uansett), men det har også en betydelig egenskap – minimale eller ingen testaktiviteter, og selv å tenke på testprosessen ville være en ren spøk.
Det er ingen morsom aktivitet i et Scrum-team, og folk vil stort sett like ideen om å utvikle seg uten prosesser for å bremse dem. Dette er i utgangspunktet hva enhver testaktivitet vil gjøre implisitt. Og hvem vil ha unødvendig treghet i den tiden vi trenger for å imponere sluttbrukeren mest?
Tilstanden som skjer hvis prosjektteamet fortsetter på samme måte etter at POC-perioden er ferdig, er noe jeg bruker til å kalle POC på steroider – et produksjonssystem som vokser i størrelse og funksjoner, men som fortsatt oppfører seg som en POC – et wannabee-komplett produkt med skjulte defekter og uutforskede hjørnesaker, bare venter på en alvorlig krasj.
Men før det konverterer der, vil teamet ha en vanskeligere tid fra sprint til sprint med å holde tritt med stabile utgivelser, ettersom å fikse de rullende problemene vil bare bli mer komplisert.
Her er noen teknikker som viste seg å fungere da jeg hadde lignende problemer og som jeg tror kan kalles beste praksis for implementering av solide testprosesser, fortsatt uten å rote utviklingsfremgangen for mye – for det er det vi alle ønsker å være for. et Scrum-team.
Innholdsfortegnelse
Fordel smerten
Hvor skal vi ellers starte når vi skal håndtere unødvendig plager enn å dele smerten :).
Og det jeg mener med dette er å lage en plan som vil kreve liten tilleggsaktivitet fra utviklere her og der, men som vil bidra til det felles målet i stor grad over tid, trinnvis men konsekvent.
#1. Utvikle enhetstestkode for hver opprettet del av ny kode
Hvis du klarer å overbevise scrum-teamene dine om å legge til i sin Definition Of Done-klausul utvikling av enhetstester for hver ny kode som er opprettet innenfor sprinten, vil dette fra et langsiktig perspektiv være en stor prestasjon.
Årsakene er ganske åpenbare:
Det vil tvinge utviklere til å tenke på ulike ikke-standardveier til koden. –
- Slike enhetstester kan kobles til automatiserte DevOps-rørledninger og utføres med hver enkelt distribusjon til dev- eller testmiljøet. Beregninger fra rørledningen kan også enkelt eksporteres og deretter brukes til å demonstrere for forretningsbrukere den prosentvise dekningen av testtilfeller direkte knyttet til kildekoden.
Det viktigste er å starte veldig snart. Jo senere enhetstestene begynner å utvikles, jo mer distraherende vil det bli for utviklere å legge dem til i løpet av en sprint.
- Det vil kreve betydelig innsats å bakoverutvikle enhetstester for allerede eksisterende kode. Noen deler av koden kan være laget av en annen utvikler, og den nøyaktige kunnskapen om hvordan den skal fungere i hver enkelt kodedel er ikke helt klar for den nåværende utvikleren. I noen tilfeller kan det komme så langt at det vil ta mer tid å legge til en enhetstest i den modifiserte koden enn å utvikle funksjonsendringen for sprinten (som er en tilstand som ingen sikkert har beregnet under sprintplanleggingen).
#2. Lag en rutine med å utføre alle deler av enhetstester på utviklingsmiljøet
Selv før du oppretter en pull-forespørsel for å slå sammen den nye koden i Master-grenen, skal det være en standardaktivitet å teste både funksjonskoden og enhetstestkoden på dev-miljøet. Ved å gjøre dette vil det sikres at:
- Enhetstestkoden fungerer faktisk for hver del (til slutt er det bare en annen kode som må verifiseres). Dette trinnet hoppes ofte fullstendig over. Det antas på en eller annen måte at hvis enhetstesten uansett er plugget inn i DevOps-rørledningen, vil den til slutt bli utført og testet et sted som standard. Dette er imidlertid ikke annet enn å skyve problemene inn i de øvre nivåene av sprintaktiviteter, der laget vanligvis har mindre tid og mer stress til å fullføre hver engasjert historie.
- Den nye funksjonskoden er testet av utvikleren for grunnleggende funksjonalitet. Det er klart at det ikke kan forventes fra denne testen at forretningsfunksjonaliteten vil bli fullstendig verifisert, men denne testen vil i det minste bekrefte at koden oppfører seg slik utvikleren hadde tenkt den (for nå ignorerer det faktum at forretningslogikken kan blir feil forstått under utviklingen).
#3. Forvent utførelse av enhetstest etter kodesammenslåing til hovedgrenen
En ting er å ha funksjonell kode på den lokale filialen (der ingen andre enn filialeieren utvikler en ny funksjon), men det er en helt annen ting å ha den samme koden som fungerer etter pull-forespørselen og flettes inn i mastergrenen.
Mastergrenen inneholder endringer fra andre Scrum-teammedlemmer, og selv om konfliktene er løst og alt ser bra ut, er koden etter sammenslåing og konfliktløsning i utgangspunktet fortsatt en uprøvd kodebit, og det er risikabelt å sende den videre uten å verifisere først det fungerer fortsatt bra.
Så det som viste seg å være effektivt her, er ganske enkelt å be om å utføre den samme enhetstesten – allerede gjort tidligere på dev-miljøet – også på miljøet, som er bygget fra hovedgrenkodeversjonen.
For utviklerne kan det være et ekstra skritt de trenger å inkludere i livet, men det er ikke så mye av en innsats siden, i dette tilfellet, må ingenting nytt oppfinnes – bare gjenutfør det som allerede ble gjort en gang.
Nå kan dette trinnet hoppes over i ett spesielt tilfelle:
- De automatiserte enhetstestene i DevOps-rørledningene er så omfattende at de allerede dekker hele den manuelle testingen som er utført på toppen av det.
Selv om det definitivt er mulig å oppnå denne tilstanden, har jeg aldri opplevd en slik tilstand i det virkelige liv. Det vil sannsynligvis til og med være for tidkrevende for utviklere å lage slike dypt detaljerte automatiserte enhetstester. Det kan lett bli uakseptabelt for produkteieren å la teamet dedikere så mye tid til denne aktiviteten, da det ville ha en eksplisitt innvirkning på antall leverte historier i løpet av en sprint.
Imidlertid skal preferansen for sprintinnhold aldri være en unnskyldning for ikke å gjøre enhetstestene, eller til og med minimere dem. Ved å gjøre dette, vil teamet konvertere igjen til en slik tilstand at koden mangler for mye enhetstestdekning, og for en innhenting kan det allerede være for sent (igjen, jo høyere innsats for å fullføre enhetstesten enn den faktiske kodeendring for en sprint).
Av alle disse grunnene vil jeg anbefale å gjenutføre enhetstestene på masterkodeversjonen uten å nøle. Det er en så lav innsats sammenlignet med hvilken verdi det vil gi.
Det vil foreta den siste kontrollen for klarheten til mastergrenen for utgivelsestestfasen. Det vil også hjelpe å finne de fleste tekniske feilene (f.eks. feil som hindrer kildekoden fra å bli vellykket utført til den vellykkede slutten), og forlater neste fase å konsentrere seg utelukkende om verifisering av forretningsfunksjonaliteten.
Forbered deg på funksjonstesting
Alle de tidligere testaktivitetene skal føre til én spesifikk konklusjon – hovedgrenkoden er fri for tekniske feil og kjørbar uten problemer for ende-til-ende funksjonelle flyter.
Dette er en fase som enkelt kan dekkes bare av en enkelt person, og denne personen trenger ikke engang å ha teknisk bakgrunn.
Faktisk er det mye bedre hvis dette utføres av noen som er koblet fra utviklerne, men med funksjonell bevissthet om hvordan forretningsbrukere forventer at koden skal oppføre seg. Det er to hovedaktiviteter som skal fullføres:
#1. Nye sprinthistorier målrettet funksjonstest
Hver sprint skal ideelt sett bringe noen ny funksjonalitet (sprintmåløkning) som tidligere ikke fantes, og dermed skal den verifiseres. Det er viktig å sikre at den nye programvaren fungerer i en slik grad at bedriftsbrukerne er glade for å ha den nå, da de åpenbart så frem til det hele siste sprinten minst :).
Det er en så trist opplevelse når den (lenge) lovede funksjonaliteten endelig kunngjøres for å bli utgitt, bare for å finne ut her om dagen at den faktisk ikke fungerer bra.
Derfor er riktig testing av ny sprintfunksjonalitet avgjørende. For å gjøre dette til en suksess, er det 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 på innsiden. sprinten.
Dette kan se overveldende ut ved første øyekast, men fra min erfaring er det igjen fullstendig håndterbart av en enkelt person. Siden spurtene stort sett er ganske korte (som to ukers korte perioder), blir det nesten aldri for mye nytt innhold uansett, siden spurten også inneholder tilleggsaktiviteter som tekniske gjeldshistorier, dokumentasjon, design/spikehistorier, etc.
Testcases utføres så med det formål først og fremst å verifisere ønsket funksjonalitet. Hvis det oppstår et problem med resultatene, henvender man seg kun til den aktuelle utvikleren (den som eier endringene knyttet til denne spesielle defekten) for å løse problemet forhåpentligvis raskt.
På denne måten vil utviklerne bruke minimum tid knyttet til funksjonell testing og kan fortsatt konsentrere seg om aktivitetene de liker best.
#2. Utførelse av regresjonstester
Den andre delen av funksjonstesting skal være å sikre at alt som har fungert til nå også vil fungere etter neste utgivelse. Det er dette regresjonstester er til for.
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, det er de beste kandidatene for regresjonstesttilfeller.
I noen tilfeller dekker regresjonstester til og med implisitt også nye funksjoner i sprinten, for eksempel hvis den nye historien i spurten endrer en bestemt del av den eksisterende flyten.
Så i de fleste tilfeller er det slett ikke veldig komplisert å gjennomføre regresjonstester sammen med nye sprinthistorier funksjonalitetstester, spesielt hvis dette gjøres regelmessig før hver produksjonsutgivelse, og periodisiteten til produksjonsutgivelser ikke er for liten.
Insister på å utføre kvalitetssikringstester før hver produksjonsutgivelse
Quality Assurance (QA)-testen er det siste trinnet før den slippes ut i produksjon, og ofte hoppes denne testen over som uviktig. Spesielt hvis scrum-teamet styres aggressivt for nytt innhold.
Selv forretningsbrukere vil si at de er interessert i nye funksjoner og ikke så mye i å bevare funksjonaliteten eller holde antallet feil lavt. Men igjen – over tid er dette hovedårsaken til at utviklerteamet må bremse ned etter hvert, og da vil ikke forretningsbrukere få det de ber om uansett.
QA-test skal utføres utelukkende av folk utenfor Scrum-teamet, ideelt sett av forretningsbrukere selv 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 utvikler Scrum-teamet. Den vil presentere et endelig syn på produktet og bli brukt på en måte som muligens ingen fra scrum-teamet hadde forventet (ikke i det hele tatt et ideelt tilfelle, men det kan definitivt skje). Det er fortsatt tid for korrigeringer i siste liten.
Alternativt kan det bli klart at forventningene ikke ble godt forstått av scrum-teamet, og i et slikt tilfelle kan vi i det minste bli enige om en oppfølgingsplan, fortsatt langt før selve produksjonsutgivelsen. Dette er, igjen, ikke et ideelt tilfelle, men likevel mye bedre som å innrømme feilen like etter å ha rapportert en vellykket produksjonsutgivelse.
Hvor skal du gå videre herfra?
Å bruke disse praksisene på daglig scrum-arbeid kan på alvor bringe deg til mer stabiliserte og forutsigbare sprint-utgivelsesvaner, uten å forsinke produksjonsutgivelsene eller bruke hele spurten på å forberede neste utgivelse, eller til og med uten å tvinge alle i scrum-teamet til å gjøre noe de gjør. Jeg liker ikke eller vet ikke hvordan jeg skal gjøre det effektivt for mesteparten av sprinten, altså.
Men du trenger absolutt ikke stoppe her.
Inkludering av ytelsestester er ett tema å nevne her. Disse blir ofte ignorert eller ansett som unødvendige, og skrapes i den første runden med «optimalisering av scrumaktiviteter». Jeg var imidlertid alltid i tvil om hvordan man kan forvente at produksjonssystemet skal utvikle seg over tid hvis det ikke blir jevnlig sjekket for ytelse.
Å gå ett nivå opp betyr også innføring av automatiserte tester.
Jeg har allerede dekket en gruppe automatiserte tester (enhetstester i pipelines). Du kan imidlertid utvikle fullstendige ende-til-ende-regresjonstester fullstendig automatisert og utført av seg selv etter hver distribusjon til testmiljøet. Dette vil frigjøre utviklingsscrum-teamet enda mer, men det krever et dedikert team for å utvikle og vedlikeholde slike automatiserte tester. Det vil bli konstant arbeid, ettersom når produksjonskoden endres, kan noen eksisterende automatiserte tester bli ugyldige, og derfor må de oppdateres for å fortsette å jobbe i rørledningene. Det er en innsats som bare noen få er villige til å betale for, men fordelene for utviklere scrum-teamet ville være store.
Dette er emner som strekker seg langt over denne artikkelens omfang og finner ut riktig tidsplan og timing for hver testtype nevnt her – slik at du kan klare deg innenfor et sprintvindu. Jeg vil gjerne dykke inn neste gang!