Scrum minus testplan er lig med POC på steroider.
I dag starter de fleste succesrige projekter med et Proof of Concept (POC), en relativt lille vurdering af en idé, hvor den valgte teknologi og funktionspakke først vil blive verificeret, evalueret for potentiel indvirkning på forretningsbrugere og derefter, når den er bevist. investeringsværdigt, er et projektteam i fuld størrelse tildelt til at designe og levere det fuldt udstyrede produkt og implementere det til produktion.
Dette er den perfekte sag til et Scrum-team. Holdet kan hurtigt udvikle prototypen og tilføje væsentlige nye funktioner hver sprint, mens forretningsbrugere i realtid kan se hurtige fremskridt, og hvordan ideen bygges fra bunden inden for kun omkring 10 sprints. Det efterlader et stærkt indtryk (som er hovedmålet for POC’en alligevel), men det har også en væsentlig egenskab – minimale eller ingen testaktiviteter, og selv at tænke på testprocessen ville være en ren joke.
Det er ingen sjov aktivitet inde i et Scrum-team, og folk vil for det meste kunne lide ideen om at udvikle uden processer for at bremse dem. Dette er dybest set, hvad enhver testaktivitet vil gøre implicit. Og hvem ønsker unødig langsommelighed i den tid, vi har brug for for at imponere slutbrugeren mest?
Den tilstand, der sker, hvis projektteamet fortsætter på samme måde efter POC-perioden er færdig, er noget, jeg bruger til at kalde POC på steroider – et produktionssystem, der vokser i størrelse og funktioner, men stadig opfører sig som en POC – et wannabee komplet produkt med skjulte defekter og uudforskede hjørnesager, der kun venter på et alvorligt styrt.
Men før det konverterer der, vil holdet have sværere ved fra sprint til sprint at holde trit med stabile udgivelser, da løsningen af de rullende problemer kun bliver mere kompleks.
Her er nogle teknikker, der viste sig at virke, da jeg havde at gøre med lignende problemer, og som jeg mener kan betegnes som bedste praksis for implementering af solide testprocesser, stadig uden at rode for meget i udviklingsfremskridtet – for det er det, vi alle ønsker at være til. et Scrum-team.
Indholdsfortegnelse
Fordel smerten
Hvor skal vi ellers starte, når vi har at gøre med unødvendig gener end med at dele smerten :).
Og det, jeg mener med dette, er at skabe en plan, der vil kræve lille ekstra aktivitet fra udviklere her og der, men som vil bidrage til det fælles mål i høj grad over tid, trinvist men konsekvent.
#1. Udvikl enhedstestkode for hvert oprettet stykke ny kode
Hvis det lykkes dig at overbevise dine scrum-teams om at tilføje udvikling af enhedstests til deres Definition Of Done-klausul for hver ny kode, der er oprettet inden for sprinten, så vil dette fra et langsigtet perspektiv være en stor præstation.
Årsagerne er ret indlysende:
Det vil tvinge udviklere til at tænke på forskellige ikke-standardiserede stier til koden. –
- Sådanne enhedstests kan tilsluttes automatiserede DevOps-pipelines og udføres med hver enkelt implementering til udvikleren eller testmiljøet. Målinger fra pipelinen kan også nemt eksporteres og derefter bruges til at demonstrere for forretningsbrugere den procentuelle dækning af testsager direkte bundet til kildekoden.
Det vigtigste er at starte meget snart. Jo senere enhedstestene begynder at blive udviklet, jo mere distraherende vil det blive for udviklere at tilføje dem inden for en sprint.
- Det vil kræve en betydelig indsats at bagudvikle enhedstests for allerede eksisterende kode. Nogle dele af koden kan være oprettet af en anden udvikler, og den nøjagtige viden om, hvordan den skal fungere i hver enkelt kodedel, er ikke helt klar for den nuværende udvikler. I nogle tilfælde kan det komme så langt, at tilføjelse af en enhedstest til den ændrede kode vil tage mere tid end at udvikle funktionsændringen for spurten (hvilket er en tilstand, som ingen helt sikkert har beregnet under sprintplanlægningen).
#2. Lav en rutine med at udføre alle dele af Unit Tests på udviklingsmiljøet
Selv før der oprettes en pull-anmodning om at flette den nye kode ind i Master-grenen, skal det være en standardaktivitet at teste både funktionskoden og enhedstestkoden på dev-miljøet. Ved at gøre dette vil det sikres, at:
- Enhedstestkoden fungerer faktisk for hver del (i sidste ende er det bare en anden kode, der skal verificeres). Dette trin springes meget ofte helt over. Det antages på en eller anden måde, at hvis enhedstesten alligevel er tilsluttet DevOps-pipelinen, vil den til sidst blive udført og testet et eller andet sted som standard. Dette er dog intet andet end at skubbe problemerne ind på de øverste niveauer af sprintaktiviteter, hvor holdet normalt har mindre tid og mere stress til at afslutte hver engageret historie.
- Den nye funktionskode er testet af udvikleren for grundlæggende funktionalitet. Det kan naturligvis ikke forventes ud fra denne test, at virksomhedsfunktionaliteten vil være fuldt verificeret, men i det mindste vil denne test bekræfte, at koden opfører sig på den måde, udvikleren havde til hensigt (for nu at ignorere det faktum, at forretningslogikken kunne være forkert forstået under udvikling).
#3. Forvent udførelse af enhedstest efter kodefletning i mastergrenen
En ting er at have funktionel kode på den lokale filial (hvor ingen andre end filialejeren udvikler en ny funktion), men det er en helt anden ting at have den samme kode til at fungere efter pull-anmodningen og flette ind i masterfilialen.
Master-grenen indeholder ændringer fra andre Scrum-teammedlemmer, og selvom konflikterne er løst, og alt ser fint ud, er koden efter fletning og konfliktløsning dybest set stadig et utestet stykke kode, og det er risikabelt at sende det videre uden først at bekræfte det fungerer stadig fint.
Så det, der viste sig at være effektivt her, er blot at bede om at udføre den samme enhedstest – allerede udført tidligere på dev-miljøet – også på miljøet, som er bygget fra mastergrenkodeversionen.
For udviklerne kan det være et ekstra trin, de skal have med i deres liv, men det er ikke så meget af en indsats, da der i dette tilfælde ikke skal opfindes noget nyt – bare genudfør det, der allerede blev gjort en gang.
Nu kunne dette trin springes over i et bestemt tilfælde:
- De automatiserede enhedstests i DevOps pipelines er så omfattende, at de allerede dækker hele den manuelle test, der er udført oven i købet.
Selvom det absolut er muligt at opnå denne tilstand, har jeg aldrig oplevet en sådan tilstand i det virkelige liv. Det ville formentlig endda være for tidskrævende for udviklere at lave så dybt detaljerede automatiserede enhedstests. Det kunne nemt blive uacceptabelt for produktejeren at lade teamet dedikere så meget tid til denne aktivitet, da det ville have en eksplicit indvirkning på antallet af leverede historier inden for en sprint.
Præferencen for sprintindhold skal dog aldrig være en undskyldning for ikke at lave enhedstestene eller endda minimere dem. Ved at gøre dette vil holdet konvertere igen til en sådan tilstand, at koden mangler for meget enhedstestdækning, og så for en indhentning kan det allerede være for sent (igen, jo større indsats for at gennemføre enhedstesten end den faktiske kodeændring for en sprint).
Af alle disse grunde vil jeg anbefale genudførelse af enhedstestene på masterkodeversionen uden tøven. Det er så lav en indsats i forhold til hvilken værdi det vil give.
Det vil foretage den sidste kontrol for, om mastergrenen er klar til udgivelsestestfasen. Det vil også hjælpe med at finde de fleste af de tekniske fejl (f.eks. fejl, der forhindrer kildekoden i at blive eksekveret med succes indtil den vellykkede afslutning), hvorefter den næste fase kun koncentreres om verifikation af forretningsfunktionaliteten.
Forbered dig på funktionstest
Alle de tidligere testaktiviteter skal føre til én specifik konklusion – mastergrenkoden er fri for tekniske fejl og kan udføres uden problemer for ende-til-ende funktionelle flows.
Dette er en fase, der nemt kan dækkes af kun en enkelt person, og denne person behøver endda ikke at have en teknisk baggrund.
Faktisk er det meget bedre, hvis dette udføres af nogen, der er afbrudt fra udviklerne, men med funktionel bevidsthed om, hvordan forretningsbrugere forventer, at koden opfører sig. Der er to hovedaktiviteter, der skal gennemføres:
#1. Nye sprinthistorier målrettet funktionstest
Hvert sprint skal ideelt set bringe noget ny funktionalitet (sprintmålstigning), som tidligere var ikke-eksisterende, og dermed skal den verificeres. Det er vigtigt at sikre, at det nye stykke software fungerer i en sådan grad, at erhvervsbrugerne er glade for at have det nu, da de åbenbart havde set frem til det hele den sidste spurt som minimum :).
Det er så trist en oplevelse, når den (længst) lovede funktionalitet endelig bliver annonceret til at blive frigivet, kun for den anden dag at finde ud af, at den faktisk ikke fungerer godt.
Derfor er korrekt test af ny sprintfunktionalitet afgørende. For at gøre dette til en succes, er det 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. spurten.
Dette ser måske overvældende ud ved første øjekast, men fra min erfaring er det igen fuldstændig overskueligt af en enkelt person. Da spurterne for det meste er ret korte (såsom to ugers periode kort), er det alligevel næsten aldrig for meget nyt indhold, da spurten også indeholder yderligere aktiviteter som tekniske gældshistorier, dokumentation, design/spydhistorier osv.
Derefter udføres testcases med det formål først og fremmest at verificere den ønskede funktionalitet. Hvis der opstår et problem med resultaterne, kontaktes kun den relevante udvikler (den, der ejer ændringerne relateret til denne særlige defekt) for at løse problemet forhåbentlig hurtigt.
På denne måde vil udviklerne bruge minimum tid forbundet med funktionel testning og kan stadig koncentrere sig om de aktiviteter, de bedst kan lide.
#2. Udførelse af regressionstestsager
Den anden del af funktionstestning skal være at sikre, at alt, der har fungeret indtil nu, også fungerer efter næste udgivelse. Det er hvad regressionstest er til.
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, det er de bedste kandidater til regressionstestcases.
I nogle tilfælde dækker regressionstest endda implicit også nye funktioner i spurten, for eksempel hvis den nye historie i spurten ændrer en bestemt del af det eksisterende flow.
Så i de fleste tilfælde er det slet ikke særlig komplekst at gennemføre regressionstests sammen med nye sprinthistoriers funktionalitetstest, især hvis dette gøres regelmæssigt før hver produktionsudgivelse, og periodiciteten af produktionsudgivelser ikke er for lille.
Insister på at udføre kvalitetssikringstest før hver produktionsudgivelse
Kvalitetssikrings-testen (QA) er det sidste trin, inden den frigives i produktion, og ofte springes denne test over som uvigtig. Især hvis scrum-teamet styres aggressivt for nyt indhold.
Selv forretningsbrugere vil sige, at de er interesserede i nye funktioner og ikke så meget i at bevare funktionaliteten eller holde antallet af defekter lavt. Men igen – over tid er dette hovedårsagen til, at udviklerteamet til sidst bliver nødt til at sætte farten ned, og så vil forretningsbrugere alligevel ikke få, hvad de beder om.
QA-test skal udelukkende udføres af folk uden for Scrum-teamet, ideelt set af forretningsbrugere selv 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 udvikler Scrum-teamet. Det vil præsentere en endelig visning af produktet og blive brugt på en måde, som muligvis ingen fra scrum-teamet havde forventet (slet ikke et ideelt tilfælde, men det kan helt sikkert ske). Der er stadig tid til rettelser i sidste øjeblik.
Alternativt kan det blive klart, at forventningerne ikke var godt forstået af scrum-teamet, og i så fald kan vi i det mindste blive enige om en opfølgningsplan, stadig langt før den egentlige produktionsudgivelse. Dette er igen ikke et ideelt tilfælde, men stadig meget bedre som at indrømme fejlen lige efter at have rapporteret en vellykket produktionsudgivelse.
Hvor skal man gå videre herfra?
Anvendelse af disse praksisser på det daglige scrum-arbejde kan for alvor bringe dig til mere stabiliserede og forudsigelige sprint-udgivelsesvaner, uden at forsinke produktionsudgivelserne eller bruge hele spurten på bare at forberede den næste udgivelse, eller endda uden at tvinge alle i scrum-teamet til at gøre noget, de gør. Jeg kan ikke rigtig lide eller ved ikke, hvordan man gør det effektivt i størstedelen af spurten, altså.
Men du behøver bestemt ikke stoppe her.
Inklusion af præstationstest er et emne at nævne her. Disse ignoreres ofte eller anses for unødvendige, og skrabes i den første runde af “optimering af scrum-aktiviteter”. Jeg var dog altid i tvivl om, hvordan man kan forvente, at produktionssystemet udvikler sig over tid, hvis det ikke jævnligt bliver tjekket for ydeevne.
At gå et niveau op betyder også indførelsen af automatiserede tests.
Jeg har allerede dækket en gruppe af automatiserede tests (enhedstest i pipelines). Du kan dog udvikle komplette ende-til-ende regressionstests fuldstændigt automatiseret og udført af sig selv efter hver implementering til testmiljøet. Dette ville frigøre udviklings-scrum-teamet endnu mere, men det kræver et dedikeret team til at udvikle og vedligeholde sådanne automatiserede tests. Det ville blive konstant arbejde, da når produktionskoden ændres, kan nogle eksisterende automatiserede test blive ugyldige, og de skal derfor opdateres for at fortsætte med at arbejde i pipelines. Det er en indsats, som kun få er villige til at betale for, men fordelene for udvikler scrum-teamet ville være store.
Det er emner, der rækker langt over denne artikels omfang og finder ud af den rigtige tidsplan og timing for hver testtype, der er nævnt her – så du kan nå det inden for et sprintvindue. Jeg vil med glæde dykke i næste gang!