Från POC till Produkt: Vikten av Testning i Scrum
Ett Proof of Concept (POC) kan ses som en katalysator för innovativa projekt. Vanligtvis börjar framgångsrika satsningar med en sådan utvärdering, där teknikens potential och funktionsuppsättning granskas. Efter en lyckad POC, där affärsnyttan bekräftas, tilldelas ett dedikerat team uppdraget att utveckla och implementera en fullständig produkt.
Scrum-team är väl lämpade för detta. De kan snabbt skapa prototyper och utöka funktionaliteten i varje sprint. Affärsanvändare får realtidsuppdateringar och ser produktens utveckling på bara några sprintar. Det ger ett starkt intryck, vilket ofta är målet med en POC. Men det finns en nackdel – testning är sällan prioriterat, vilket ibland till och med kan anses vara kontraproduktivt i detta skede.
Inom ett Scrum-team kan testning ibland ses som en bromsande aktivitet. Fokuset ligger på snabb utveckling, och det finns en ovilja att införa processer som kan sakta ner framstegen. Det är förståeligt, särskilt när målet är att imponera på användarna.
Om ett team fortsätter i samma stil efter POC-perioden kan det leda till det jag kallar ”POC på steroider” – ett produktionssystem som växer i omfång men fortfarande beter sig som en POC, med dolda fel och otestade fall. Detta kan leda till allvarliga problem.
Med tiden blir det svårare att upprätthålla stabila releaser, eftersom problemen blir allt mer komplexa. Här är några tekniker som jag har funnit användbara och som jag anser vara bästa praxis för att införa robusta testprocesser, utan att hindra utvecklingsteamets framsteg.
Dela upp Arbetet
När man ska hantera ett potentiellt besvär är det ofta klokt att dela upp ansvaret. Det innebär att implementera en plan som kräver lite extra ansträngning av utvecklarna, men som kollektivt bidrar stort till målet över tid.
#1. Utveckla Enhetstester för Ny Kod
Om du lyckas få med enhetstester i definitionen av ”Klart” för varje sprint, kommer det att vara en stor framgång. Anledningarna är flera:
- Utvecklare tvingas tänka på olika, icke-standardiserade vägar för koden.
- Enhetstester kan integreras i DevOps-pipelines och utföras vid varje distribution. Mätvärden kan användas för att visualisera testtäckningen för affärsanvändare.
Det är viktigt att börja tidigt. Ju senare man börjar med enhetstester, desto svårare blir det att lägga till dem i en sprint.
- Att utveckla enhetstester i efterhand tar mycket tid. Viss kod kan vara skriven av andra, och den exakta logiken kan vara svår att förstå. I värsta fall tar det längre tid att lägga till ett enhetstest än att utveckla själva funktionsändringen, vilket kan leda till problem i sprintplaneringen.
#2. Utför Enhetstester i Utvecklingsmiljön
Innan koden slås samman till huvudgrenen bör både funktions- och enhetstester köras i utvecklingsmiljön. Detta säkerställer att:
- Enhetstestkoden fungerar korrekt. Det här steget hoppas ofta över, men det är viktigt att bekräfta att testerna själva är korrekta.
- Den nya funktionskoden testas av utvecklaren. Detta bekräftar att koden beter sig som avsett, även om affärslogiken kan vara felaktig.
#3. Kör Enhetstester Efter Sammanslagning i Huvudgrenen
Kod kan fungera bra i en lokal gren, men det är inte säkert att den fortsätter att fungera efter sammanslagning i huvudgrenen. Andra teammedlemmars ändringar kan orsaka oväntade problem.
Därför är det viktigt att köra enhetstesterna igen, även i den miljö som byggts från huvudgrenskoden. Detta säkerställer att koden fortsätter att fungera som avsett.
Detta kan verka som ett extra steg för utvecklarna, men det kräver ingen ny ansträngning eftersom det är samma tester som kördes tidigare.
Det här steget kan hoppas över i följande fall:
- Automatiska enhetstester i DevOps-pipelines täcker all manuell testning.
Även om detta är möjligt, är det ovanligt att automatiska tester är så omfattande. Att skapa så detaljerade tester skulle vara tidskrävande och kan leda till att produktägaren motsätter sig, eftersom det påverkar sprintens leveranser.
Prioriteringen av sprintinnehåll får dock aldrig vara en ursäkt för att undvika enhetstester. Genom att göra detta kommer teamet att hamna i ett läge där det finns en brist på testtäckning, och det kan bli svårt att åtgärda i efterhand.
Därför rekommenderar jag att enhetstesterna körs om på huvudgrenskoden. Det är en liten ansträngning jämfört med det värde det ger. Det fungerar som en sista kontroll av att huvudgrenen är redo för release. Det hjälper också till att upptäcka tekniska fel, så att nästa fas kan fokusera på affärsfunktionalitet.
Förbered för Funktionstestning
Alla tidigare tester ska säkerställa att koden i huvudgrenen är fri från tekniska fel och kan köras utan problem.
Denna fas kan hanteras av en enda person, som inte nödvändigtvis behöver ha en teknisk bakgrund. Det är fördelaktigt om personen är oberoende av utvecklarna men har en bra förståelse för hur affärsanvändarna förväntar sig att koden ska fungera. Det finns två huvudaktiviteter som ska utföras:
#1. Funktionstester av Nya Sprintberättelser
Varje sprint ska helst introducera ny funktionalitet som behöver testas. Det är viktigt att säkerställa att den nya programvaran fungerar som förväntat och att användarna är nöjda. Det är en besvikelse när en efterlängtad funktion inte fungerar korrekt.
Därför är det viktigt att testa ny funktionalitet noggrant. Samla in viktiga testfall från relevanta intressenter, antingen produktägare eller slutanvändare. Detta hjälper till att skapa en lista över testfall för sprintens innehåll.
Det kan verka mycket i början, men min erfarenhet är att det går bra att hantera av en enda person. Sprintarna är oftast korta, och sprinten innehåller andra aktiviteter som teknisk skuld, dokumentation etc.
Testfallen utförs sedan för att verifiera den önskade funktionaliteten. Om problem uppstår kontaktas den utvecklare som är ansvarig för den specifika defekten för att åtgärda den. På så sätt spenderar utvecklarna minimalt med tid på funktionstestning och kan fokusera på utvecklingsarbetet.
#2. Utför Regressionstester
Den andra delen av funktionstestningen är att säkerställa att allt som fungerade tidigare fortfarande fungerar efter nästa release. Regressionstester är viktiga för att uppnå detta.
Testfall för regressionstester bör underhållas och ses över regelbundet. De ska vara enkla men ändå täcka de centrala funktionerna och viktiga flöden som går genom hela systemet.
Ofta påverkar sådana processer flera olika delar av systemet, vilket gör dem till idealiska kandidater för regressionstestfall. Ibland täcker regressionstester även implicit ny funktionalitet, till exempel om den nya funktionen i en sprint ändrar en del av ett befintligt flöde.
I de flesta fall är det inte särskilt svårt att utföra regressionstester tillsammans med funktionstester av nya sprintberättelser, särskilt om detta görs regelbundet innan varje produktionssläpp.
Kräv Kvalitetssäkringstester Före Varje Produktionssläpp
Kvalitetssäkringstestet (QA) är det sista steget innan release, och det hoppas ofta över, särskilt om scrum-teamet fokuserar på ny funktionalitet. Affärsanvändare kan också säga att de är mer intresserade av nya funktioner än att bevara funktionalitet eller hålla antalet fel lågt. Men i längden leder detta till att utvecklingstakten saktar ner, och affärsanvändare får inte vad de vill ha.
QA-test ska utföras av personer utanför Scrum-teamet, helst av affärsanvändare själva i en miljö som liknar produktion. Alternativt kan produktägaren ersätta slutanvändarna.
Detta bör vara ett funktionellt test från användarens perspektiv, utan någon koppling till utvecklingsteamet. Det ger en sista översyn av produkten och kan avslöja problem som scrum-teamet inte hade förutsett. Det finns fortfarande tid för korrigeringar i sista minuten. Det kan också avslöja missförstånd av användarens förväntningar, vilket kan leda till uppföljningsplaner, vilket är bättre än att erkänna ett misslyckande efter release.
Vart Ska Vi Gå Härnäst?
Genom att använda dessa rutiner kan du stabilisera era sprintreleaser utan att fördröja produktion eller tvinga scrum-teamet att göra saker de inte gillar. Men du kan ta det ännu längre.
Prestandatestning är ett område som ofta förbises eller anses onödigt. Det är dock viktigt att regelbundet kontrollera systemets prestanda för att säkerställa att det utvecklas på ett bra sätt.
Nästa steg är automatisering av tester. Vi har redan berört enhetstester i pipelines. Man kan utveckla helt automatiserade regressionstester som körs efter varje distribution till testmiljön. Detta skulle frigöra utvecklingsteamet ytterligare, men det kräver ett dedikerat team för att utveckla och underhålla dessa tester. Det är ett kontinuerligt arbete, eftersom testerna måste uppdateras när koden ändras. Det är en investering som få är villiga att göra, men fördelarna är stora.
Det är ämnen som går utöver den här artikelns omfattning, liksom att bestämma rätt schema och tidpunkt för varje testtyp, så att du ryms inom en sprint. Jag hoppas kunna återkomma till detta vid ett annat tillfälle.