Så förbereder och testar jag mina releaser
Utgåvor och utgåvehantering är en viktig del av vårt arbete. Att leverera rätt produkt till kunderna gör dem nöjda. Att genomföra en smidig utgåva gör oss som är involverade i utgåvan nöjda.
Hur kan vi uppnå en smidig utgåva?
Efter att ha deltagit i ett stort antal sådana kan jag säga att det finns några viktiga punkter som kan bidra till en framgångsrik utgåvehantering.
Låt mig berätta vilka de är.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
En framgångsrik utgåva börjar under utvecklingen.
Identifiera testfall
God utgåvehantering börjar långt före utgåvedagen, redan när funktionen som ska lanseras befinner sig i utvecklingsfasen. Under den här tiden behöver funktionen godkännas av QA. Det innebär att vi behöver testa alla möjliga scenarier vi kan tänka oss som är relevanta för den aktuella funktionen, för att validera att funktionen fungerar enligt kraven. Vissa av dessa scenarier testas med automatiserade tester, medan det för andra antingen är för svårt eller inte värt besväret att skapa automatisering.
När vi identifierar vilken typ av testning vi behöver utföra för den aktuella funktionen bör vi tänka på följande: första gången funktionen sätts i produktion behöver vi testa den fullständigt. Vi måste säkerställa att kunderna inte hittar några kritiska problem. Vi behöver validera kraven. Och vi måste säkerställa att funktionen har god prestanda.
Förseningar och problem i testningen kan få allvarliga konsekvenser för tidsplanerna när programvaruutgåvor förbereds. Att införa effektiva metoder för utgåvehantering bidrar till att testning och driftsättning förblir tillförlitliga och förutsägbara.
Men när funktionen väl är i produktion behöver vi, såvida den inte kräver vissa uppdateringar, inte testa den lika grundligt vid varje framtida utgåva av samma kodbas. Funktionens beteende förändras endast om den underliggande koden har ändrats eller om en extern förändring har skett i något av de beroenden som den använder. Övrig tid räcker det med en rimlighetskontroll av funktionen, där rimlighetskontrollen självklart omfattar de viktigaste testfallen.
Med detta sagt bör du, när funktionen är under utveckling, utvärdera hur många testfall du behöver testa, hur mycket tid du har tillgänglig för testning, vilka testfall som är kritiska och vilka testfall du skulle köra vid varje utgåva.
På så sätt kan du identifiera vilka testfall du ska automatisera. Fokusera på att åtminstone täcka den kritiska funktionaliteten med automatisering. För resten av testerna bör du skapa skriftliga testfall, antingen i ditt projekthanteringssystem (t.ex. Jira) eller i det testhanteringsverktyg du använder. På så sätt går de inte förlorade eller glöms bort, och de kan köras när en utgåva kräver det.
Köra testerna i CI
När du har de automatiserade testerna bör du börja köra dem via CI i utvecklingsmiljöerna med jämna mellanrum. Eftersom andra funktioner utvecklas innan utgåvan sker är det bra att säkerställa att funktionen du vill lansera fortfarande fungerar korrekt, särskilt om du redan har godkänt den under sprinten. Om du kör testerna för den funktion du är intresserad av, exempelvis dagligen, får du snabb återkoppling om eventuella korrigeringar som behöver göras i funktionen på grund av buggar som orsakas av andra förändringar i systemet.
Tidig upptäckt av potentiella buggar i funktionen som ska lanseras ger gott om tid att genomföra korrigeringarna och testa funktionen igen, utan stressen av att behöva göra detta under den begränsade tid du har i utgåvefasen. Ju större täckning av kraven du har i dina automatiserade tester, desto större är sannolikheten att du bara hittar ett litet antal buggar i utgåvefasen.
Förproduktion är viktig och bör ha en inbyggd tidsmarginal.
Tidsramar
Utgåvefasen består vanligtvis av en period som ägnas åt testning i en integrerad förproduktionsmiljö, utöver dagen eller perioden för produktionssättningen. Som testare som deltar i utgåvan ser jag alltid till att be om lämpliga tidsintervall för utgåvan, så att förproduktionsfasen ger mig möjlighet att testa funktionerna som ska lanseras ordentligt.
Jag räknar också alltid med extra tid, eftersom jag förväntar mig att oförutsedda problem kan uppstå under utgåvehanteringen, oavsett om det rör sig om buggar i funktionerna som ska lanseras eller externa faktorer. För att nämna en sådan faktor är förproduktionsmiljöer testmiljöer, och de har en tendens att inte vara så tillförlitliga som de borde vara. Många gånger fungerar de antingen mycket långsamt eller blir otillgängliga en stund, just när utgåvetestningen pågår.
Att lägga till en bufferttid är alltid en bra idé, och även om du inte använder den extra tiden är det helt okej. Du kan ge ditt godkännande innan den tilldelade testtiden är slut, eftersom du kan ägna resten av tiden åt något annat. Det är värre att inte ha någon bufferttid och behöva den, eftersom du då på något sätt måste få plats med all nödvändig testning på kortare tid. Det kan leda till att vissa testfall inte körs, vilket i sin tur kan leda till att vissa buggar endast upptäcks direkt i produktion.
Omfattning
En annan viktig aspekt av förproduktionsreleasen är, ur mitt perspektiv, att ha en särskild releasehanteringskoordinator. För mig innebär det någon som tar hand om vissa aspekter, där den första är att kontrollera releaseomfattningen. Innan testningen av en release påbörjas behöver testaren veta vad som ska testas. Detta kokar ner till releaseomfattningen.
Produktansvariga, alltså PO:er eller BA:er, förväntar sig att vissa funktioner ska ingå i releasen, och detta kommer man överens om när utvecklingen börjar. Koden som ingår i releasen täcker dock inte alltid exakt den omfattning som produktteamet förväntar sig. Ibland glömmer någon att skicka kod till den gren från vilken releasebygget skapas. Eller ännu värre: de kan skicka kod till den här grenen som inte borde skickas dit. Det kan handla om funktioner som ännu inte är färdiga och inte har godkänts av QA, eller funktioner som inte ingår i den aktuella omfattningen.
För att säkerställa att omfattningen uppnås bör releasekoordinatorn jämföra den förväntade omfattningen med den faktiska. Den förväntade omfattningen bör komma från produktansvariga och tydligt anges i någon form av dokument (och kanske i din kvalitetssäkringsplan). Du kan till exempel ha någon form av planeringsdokument som visar projektets milstolpar och vad som ingår i varje milstolpe.
När det gäller den faktiska omfattningen bör en ändringslogg extraheras från det versionshanteringssystem (VCS, t.ex. Git) som projektet använder. Ändringsloggen återspeglar alla incheckningar som gjorts under utvecklingsfasen till den gren som kommer att generera releasebygget. Förhoppningsvis har varje incheckning, om ni arbetar på ett organiserat sätt, en beskrivning som hänvisar till ett Jira-ärende som koden gäller. På så sätt kan du se vilka Jira-ärenden som har motsvarande kod i releasebygget och vilka av dessa ärenden som inte borde ha inkluderats i bygget. Om du upptäcker att dessa incheckningar gäller nödvändiga buggfixar är det förstås helt okej. Det du inte vill ska hända är att dessa incheckningar representerar ofärdigt funktionsarbete eller arbete som gäller funktioner som inte ska tas i produktion med den aktuella releasen.
När du fördjupar dig i avancerade tekniker för releasehantering kommer du att upptäcka att integrering av dina processer med testhanteringslösningar utformade för Jira kan ge ett mer sammanhängande och effektivt arbetsflöde
När en avvikelse upptäcks mellan den förväntade och den faktiska omfattningen bör releasehanteringskoordinatorn samarbeta med produktteamet och utvecklingsteamens chefer för att identifiera den bästa åtgärden. Om de incheckningar som upptäckts inte ingår i omfattningen representerar ofärdigt funktionsarbete är det bäst att ta bort dem. Detta beror på att ni redan befinner er i förproduktionsreleasefasen och inte vill riskera att låta den återstående koden skrivas och testas i all hast bara för att få med den i releasen. Det är riskabelt, eftersom denna brådska kan leda till att testfall glöms bort och inte körs, samt att kritiska buggar slinker ut i produktion. I det här fallet är det bäst att låta det återstående arbetet med dessa funktioner slutföras ordentligt i en framtida release.
Testningen
När omfattningen är tydlig bör testfasen börja. Under testfasen före produktion behöver du validera hela funktionen som ska lanseras på nytt. Du bör föreställa dig att det här är första gången du tittar på den och testa varje scenario som du testade under utvecklingsfasen. Kör de automatiserade tester du redan har skrivit, men i förproduktionsmiljön, och glöm inte de icke-automatiserade scenarierna. Genomför en fullständig regressionstestning av funktionen, av den enkla anledningen att det, när du befinner dig i denna releasehanteringsfas och i förproduktionsmiljön, förmodligen finns andra team som behöver lansera samtidigt som du. Detta är i princip första gången alla beroenden sammanförs med produktionsklar kod i samma miljö. Och detta är i teorin den konfiguration som kommer att köras i produktion från och med releasen.
Det gäller förstås såvida inga problem upptäcks under testningen och korrigeringar krävs. Om det händer behöver du överväga vad som måste testas på nytt. Oavsett om korrigeringen finns i din kod eller i koden för något externt beroende behöver du överväga ytterligare en testomgång om ändringarna påverkar din funktion på något sätt. Se till att du åtminstone testar funktionens kritiska delar på nytt.
Det kan verka tråkigt, särskilt om många korrigeringar görs under den här fasen. Du kan dock inte exakt förutsäga vilken påverkan korrigeringarna kan ha på olika delar av din funktion.
Små ändringar kan orsaka enorma sidoeffekter, så det är bättre att ha tråkigt men vara trygg i att den kritiska funktionaliteten fortfarande fungerar korrekt än att ångra att man inte testade tillräckligt.
Och naturligtvis, om en bugg som upptäcks under den här testfasen är mindre allvarlig behöver du inte besvära dig med att åtgärda den under denna fas. Återigen vill du inte skynda igenom någon implementering eller testning av en i övrigt perfekt fungerande funktion, så att du riskerar att förstöra den.
Under driftsättningen är kommunikation och testning avgörande.
När funktionen har godkänts i förproduktionsmiljön är den redo att driftsättas i produktionsmiljön.
Kommunikation
När det gäller driftsättningen har samordnaren för driftsättningshanteringen några uppgifter att utföra. Först och främst bör datum och tid för driftsättningen fastställas i god tid och kommuniceras till alla berörda parter. Jag tycker att det är mycket hjälpsamt för driftsättningshanteringen att lägga in datumet och tiden för driftsättningen som ett möte i deltagarnas kalendrar, så att deltagarna kan planera sin dag. Detta är en uppgift som samordnaren kan utföra.
På dagen för driftsättningen bör samordnaren påminna alla som är involverade om tidsplanen för driftsättningen. Helst bör kommunikationen ske i en kanal som alla använder, till exempel Slack. Genom att ha en särskild Slack-kanal där alla viktiga aspekter kommuniceras säkerställer man att alla involverade har samma förståelse för vilket steg i driftsättningen som är klart och när, vad omfattningen är, vilka problem som har upptäckts och vem som kan hjälpa till med dessa problem. En sådan kommunikation säkerställer att den som behöver känna till vissa aspekter av driftsättningen ser denna information, till skillnad från muntlig kommunikation (där personen kanske är frånvarande utan att den som kommunicerar informationen märker att personen saknas).
Samordnaren för driftsättningshanteringen bör hålla reda på och tillkännage milstolparna för driftsättningen i denna kanal, till exempel när driftsättningen börjar och när den har godkänts. Dessutom bör alla parter som är involverade i driftsättningen kommunicera via denna kanal när de utför sina tilldelade steg, så att alla andra känner till driftsättningens status och framsteg. Om någon part som behövs vid något tillfälle under driftsättningen inte är tillgänglig bör samordnaren kontakta rätt personer, så att allt kan fungera smidigt.
Testningen
Under driftsättningen i produktion bör den nya funktionen återigen testas fullständigt. Detta beror på att även om funktionen har godkänts i andra testmiljöer är dessa miljöer inte till 100 % identiska med produktionsmiljöerna när det gäller konfiguration och resurser.
För att förhindra oförutsedda felaktiga beteenden hos den driftsatta funktionen är det viktigt att köra alla tillgängliga automatiserade tester tillsammans med de icke-automatiserade delar som du har skrivit testfall för. Godkänn aldrig en funktion i produktion utan att ha testat den.
Att bara anta att funktionen fungerar i produktion betyder inte att den faktiskt gör det.
Se till att den gör det – testa den.
Efter driftsättningen
Driftsättningen är alltså klar. Men att säkerställa att funktionen fungerar korrekt kräver mer arbete än att bara testa den under driftsättningsfasen.
När du är klar med det bör du se till att dina automatiserade tester körs i CI för produktion. Detta kommer att upptäcka oönskade beteenden som orsakas av externa förändringar som du inte känner till.
Övervaka kontinuerligt funktionens prestanda för att säkerställa att belastningen i produktion och kundernas användning inte orsakar försämrad prestanda. Se också till att hålla koll på eventuella felrapporter från dina kunder. De kan visa på områden som inte fungerar korrekt, så att du snabbt kan planera en framtida uppdatering om det behövs.
Om driftsättningen inte gick som förväntat bör du se till att ha ett retrospektivt möte efter driftsättningen. Där kan du ta upp alla problem som uppstod inom hanteringsprocessen för driftsättningen och tilldela åtgärdspunkter till relevanta personer, så att framtida driftsättningar går smidigt och framgångsrikt.
