Meny

Vad QA-testare borde veta om hanteringsprocessen för frigöring och distribution

  • Huvud
  • Testa Begrepp
  • Vad QA-testare borde veta om hanteringsprocessen för frigöring och distribution

what qa tester should know about release

Prova Vårt Instrument För Att Eliminera Problem

I vårt teammöte idag kontrollerade chefen med alla på deras beredskap för testutförande . Han nämnde att 'koden kommer att vara redo för QA i morgon morgon'. Vad menade han när han sa 'kod kommer att vara redo', betyder det att utvecklarna kommer att skriva koden i QA-miljö ikväll?

Han menade faktiskt att utplaceringen är planerad att göras på natten och den nya koden kommer att distribueras till QA-miljön för testning.

Många av er kanske nu frågar vad distribution är och vad gör de egentligen i den?

frigörings- och distributionshanteringsprocess för qa

Vad du kommer att lära dig:

Övergripande frigörings- och implementeringshanteringsprocess och betydelse för QA-teamet

  • Varför upprätthåller vi verkligen olika miljöer?
  • Hur migreras koden från en miljö till en annan?

Jag kommer att täcka följande ämnen i den här artikeln

  1. Varför är det viktigt för testare att vara medvetna om utgivnings- och distributionsprocessen?
  2. Olika miljöer
  3. Vad menar du med Build and Deployment?
  4. Planerad kontra nödsituation
  5. QA-checklista - före och efter distribution

# 1. Varför är det viktigt för testare att vara medvetna om distributionsprocessen?

Vårt huvudsakliga jobb med testkörning beror på hur framgångsrik implementeringen var. Om distributionsteamet mötte utmaningar och stött på flera problem och inte kunde distribuera koden ordentligt, kommer det säkert att indikera att QA-teamet kommer att identifiera många buggar som kan knytas till miljön eller distributionsprocessen.

  • Om testare är medvetna om distributionsprocessen kommer de att förstå vikten av att slutföra sina uppgifter inom den planerade tidsramen.
  • Testare får en uppfattning om problemet verkligen är ett funktionsfel eller något som orsakas under distributionen säger att en testare är tilldelad för att testa rapportfunktionen men när han försöker logga in på webbplatsen ser han ett fel som innebär att miljön är nere , sådana frågor kan inte betraktas som funktionella frågor utan som miljömässiga. Om testaren är medveten om distributionen kan han relatera problemet till ett distributionsproblem.
  • Många icke-problem kan undvikas om testarna verkligen är medvetna om listan som har distribuerats. Ibland händer det att du testar och rapporterar ett problem för områden som aldrig har använts.

# 2. Olika miljöer

Olika miljöer

I ovanstående klassificering har jag täckt de fyra viktigaste miljöerna som de flesta organisationer följer, men många klienter upprätthåller mycket mer miljöer som iscenesättning, förinstallering etc. Dessutom kan namngivningskonventionen skilja sig.

  • DEV - Dev-miljö är den som skapats och underhålls av utvecklingsteamet för att skriva koden. Tillgången till denna miljö ges endast till utvecklingsteamet. Vanligtvis har QA-teamet inte tillgång till den här miljön. Denna miljö används mest av Dev-teamet för deras enhetstestning.
  • QA - QA-miljö är den där testningen faktiskt äger rum. Denna miljö ägs av QA-teamet. DEV-teamet har inte tillgång till den här miljön. Efter avslutad design och kodning flyttas koden till QA-miljö för att QA-teamet ska kunna genomföra testkörning.
  • UAT - Test av användaraccept är en miljö där testningen utförs av företagsanvändarna. Detta görs efter att systemtestningen har slutförts. Den huvudsakliga avsikten är att testa systemet ur affärssynpunkt. Tillgång till denna miljö ges endast till företagsanvändarna. Men vid vissa tillfällen söker de QA-hjälp, under sådana omständigheter får QA-teamet tillfällig tillgång till miljön.
  • DRIVA - PROD-miljön är den faktiska livemiljön som exponeras för riktiga användare och inget av DEV- och QA-team har läs- / skrivåtkomst till denna miljö. Prod support support team underhålls för att lösa problem relaterade till produktionsmiljön.

Läs också=> Hur man effektivt förbereder 'testbädd' och minimerar testmiljöfel

vad är skillnaden mellan java och c ++

# 3. Vad menar du med Build and Deployment

En byggnad innehåller huvudsakligen det kompilerade paketet som kan innehålla den körbara bat, exe, biblioteken som dll, lib och arkiv som zip-filer. Utvecklingsteam skapar byggnaden och tillhandahåller den till distributionsteamet för installation.

Sammanställningen av källkoden sköts huvudsakligen av utvecklingsteamet och efter att de har genererat byggandet placerar de den på någon specifik plats som är tillgänglig för distributionsteamet för distribution till en annan miljö.

När byggnaden har distribuerats meddelas QA-teamet att de ska göra det byggverifieringstestning (BVT) och om det är framgångsrikt utför laget resten av funktionstestning .

I någon organisation där de inte upprätthåller ett separat distributionsteam tillhandahåller utvecklingsteamet byggnaden till QA och QA-teamet själva slutför distributionen. Det finns en stor risk, i sådana fall bör QA-resurser vara tekniskt sunda för att förstå den övergripande processen för byggdistribution och bör också veta hur man kan åtgärda om ett problem uppstår.

Byggnader upprätthålls med siffrorna 1.0.01 eller 1.0.03. Så det är möjligt att build 1.0.01 kan köra DLL v0.2 och build 1.0.03 kan köra DLL v0.5. Det blir viktigt för QA-teamet att se till att rätt uppbyggnad distribueras i miljön innan testningen startar. Det är alltid en bra idé att hålla reda på de förändringar som tillhandahålls som en del av varje byggnad.

Att upprätthålla ett separat distributionsteam är alltid en bra metod eftersom det hjälper till att smidigt flytta koden från en miljö till en annan.

Distribution är en process genom vilken koden / byggnaden flyttas från en miljö till en annan. De flesta av organisationen följer idag en ordentlig kanal för distributionen och har ett separat team som tar hand om alla dessa.

Bygg och distribution

fas av programvaruutvecklingens livscykel

Före utplaceringsdagen träffas ett team bestående av utvecklare, utvecklingschef, distributionsingenjör, testledare och andra affärsintressenter. I mötet ombeds utvecklaren vanligtvis att beskriva sin förändring. De behöver vanligtvis fylla i ett visst formulär med detaljer om ändrings- och återställningsplanen.

Om vissa detaljer saknas blir ändringarna inte godkända för distribution. Teamet bestämmer sedan om ändringen kan vara en del av distributionen nästa dag. QA Test Lead ombeds godkännas för att säkerställa att ändring inte påverkar någon av de befintliga testerna. I mötet planeras de slutliga distributionsartiklarna.

Den godkända listan bearbetas av distributionsteamet dagen för distributionen. Teamet kör en uppsättning program som definieras i var och en av ändringsformuläret (tillhandahålls av utvecklare) och skickar sedan ut kommunikationen när distributionen är klar.

Meddelandet Deployment Complete ger en indikation till QA-teamet att ändringarna / den nya koden är redo att testas.

Det är distributionsteamets ansvar att flytta ändringarna från DEV till QA. Efter avslutad QA-testning flyttas koden till UAT. PROD-dataflyttning är den viktigaste delen och det måste göras under stängda timmar, för under distributionen måste miljön sänkas och det måste göras med största försiktighet eftersom detta kan ha allvarlig inverkan på verksamheten.

De flesta av distributionerna av Prod görs sent på kvällen när chansen att slutanvändarna drabbas av miljön är mindre.

# 4. Planerad kontra nödsituation

Varje organisation har en distributionskalender. Många kunder följer distribution en gång i veckan och många går två gånger i veckan, säger att den planerade distributionen endast ska ske på tisdagar eller så kan det hända på tisdag och fredag. Dagen för distribution kan ändras om den planerade dagen för distribution faller på en helgdag.

bästa programvaran för att klona hdd till ssd

I avsnittet ovan har jag täckt processen som följs för alla planerad utplacering .

De planerade utplaceringarna kan ha sin egen utmaning. Tänk på ett fall där ny kod distribueras till QA-miljön och under sanity-testet identifierar teamet en blockeringsfel och testningen måste stoppas. Väntar testteamet i en vecka till nästa distribution?

För att hantera sådana situationer görs nödkorrigering och distributioner där distributionsteamet inte behöver vänta till den planerade distributionsdagen. De behöver följa och söka godkännande även för nödutplaceringar men dessa godkännanden sker vanligtvis snabbt, och de nya ändringarna kan distribueras till QA-miljö samma dag eller så snart som möjligt.

# 5. QA-checklista - före och efter distribution

Före distribution -

Hela testdesignfas sker innan koden faktiskt flyttas till miljön. Det är testutförandet som beror på kodtillgängligheten i QA-miljön medan Deployment-teamet arbetar för att få koden distribuerad i QA, QA-teamet bör se till att ha genomfört nedanstående aktiviteter -

  • Se till att testfallet granskas och godkänns
  • Se till att testteamet är tillgängligt och resursplaneringen är klar
  • Se till att testdatabehov identifieras

Efter distribution -

Efter utplaceringen är det allra första vi som QA-team gör att komma igång med vårt Sanity-test. Men innan vi börjar vårt förnuftstest bör vi se till att följande har tagits om hand -

  • QA-teamet borde ha fått meddelande från distributionsteamet om framgångsrik distribution och redo för QA.
  • QA-teamet bör hålla koll på den distribuerade byggnaden.
  • Se till att QA-teamet har listan över ändringar som har distribuerats framgångsrikt och även artiklar som inte har distribuerats även om de var planerade. Det kan hända att distributionsteamet inte kunde distribuera på grund av saknade detaljer etc.

Slutsats

Hoppas att ovanstående artikel gav dig en uppfattning om den övergripande processen för release- och distributionshantering som följts som en del av den övergripande programvaruutvecklingscykeln. Detta var bara ett generiskt förfarande som följts i de flesta organisationer, men många kunder har olika protokoll.

Författare : Den här fantastiska artikeln är skriven av STH-teammedlem Priya R.

Tyckte du att den här processen var till hjälp? Låt oss veta om implementeringsprocessen som du följer i din organisation.

Rekommenderad läsning

^