Hur man utför test efter lanseringen effektivt och minimerar effekterna av lanseringen för levande kunder

how perform post release testing effectively

När jag började min karriär som QA arbetade jag med ett företag som erbjöd sina produkter som SaaS. Produktionsreleaser var kritiska och det fanns en möjlighet att påverka funktionaliteten för liveklienterna.

När vår kundbas växte, antog QA-teamet för att hantera risken och minimera effekterna av släppet för levande kunder testmetoden efter släpp.

Det här var helt nytt för mig och jag hade så många frågor och tvivel i tankarna:

• Vad är test efter lansering?
• Jag testade allt ordentligt, varför behöver vi testa efter släpp?
• Testar jag allt igen? Vad gör jag exakt vid verifiering efter utgivningen?
• Vad händer om jag hittar ett problem? Etc.

Jag är glad att erkänna att jag hittade alla mina svar inom mina första produktionsreleaser.

Här delar jag den kunskapen med er alla. Jag valde att skriva artikeln i ett fråga- och svarformat för att visa hur jag upptäckte svaren.

Vad du kommer att lära dig:

• Vad är verifiering efter publicering?
• Vilka uppgifter och aktiviteter ingår i verifieringsfasen efter släpp?
• Behöver jag testa allt igen?
• Hur formulerar jag verifieringsstrategi efter produktionslansering?
• Vem skapar testplanen för lansering efter lansering?
• Vem godkänner testplanen för lansering efter produktion?
• När skapar jag verifieringsplanen för release efter produktion?
• Jag slutförde verifieringen efter lanseringen. Vad kommer härnäst?
• Vad händer om jag hittar ett problem?
• Vad mer behöver jag veta om verifieringsprocessen efter release?
• Slutsats:
• Rekommenderad läsning

Vad är verifiering efter publicering?

Per definition, Posta betyder att Efter , Produktionsrelease hänvisar till distribution till LIVE / produktionsmiljöer och Verifiering inkluderar och se till att de släppta funktionerna uppfyller kraven .

Rekommenderad läsning=> Hur man effektivt förbereder 'Testmiljö' innan du börjar testa

Målet är att verifiera släpp på produktionen / LIVE-miljöer.

char till int konvertering c ++

Men frågorna uppstår då:

• Varför behöver vi göra test efter lansering när jag testade allt i QA-miljö?
• Varför räknar vi med att det kommer att uppstå problem vid produktionen även om vi testade utgåvan noggrant i testmiljön?

Det finns många anledningar till varför vi skulle ha problem med produktionen även om vi kanske har följt fullständigt Kvalitetssäkringsprocess (dvs. testplanering , testplan granskning, testcykel, regressionstest etc.)

Anledningar till att vi skulle ha problem med produktionen:

1) Datafråga - De tillgängliga uppgifterna om produktions- och testmiljöer kan variera. Detta kan leda till att vissa hörnärtesproblem missas i testmiljöer.

2) Distributionsproblem - Om ditt företag har en manuell implementeringsprocess kan din release vara mer benägen för distributionsproblem. Några vanliga scenarier kan vara, saknade konfigurations- eller platsinställningar, saknade DB-skript, implementeringsordning som inte följts (kod först, sedan DB etc.), beroenden installerade felaktigt etc.

Läs också=> Vad QA-testare borde veta om implementeringsprocessen

3) Påverkningsområden har inte identifierats - Det kan finnas några scenarier för vilka de drabbade områdena kanske inte har identifierats korrekt och fullständigt av teamet.

Till exempel, överväga a SaaS miljö.

Om teamet inte identifierade effekterna av en ombyggd DB-tabell på en klient med hjälp av äldre tabellschema (t.ex. dataförlust, behov av datamigrering före utgivningen, etc.) osv. Det här är mindre troligt att det här problemet händer för välplanerade projekt med exakta krav. Men möjligheten finns fortfarande.

4) Okända slagområden - Detta kan inträffa om omfattningen och de påverkade områdena för släppet inte är kända. Till exempel, i ett företag med flera programvaruprodukter som delar gemensam DB och arkitektur, kan även en liten förändring bryta funktionaliteten hos många produkter.

Vilka uppgifter och aktiviteter ingår i verifieringsfasen efter släpp?

Uppgifter och aktiviteter efter produktionsrelease inkluderar vanligtvis:

• Verifiering efter publicering
• Rapportera verifieringsresultat
• Rapporterar eventuella problem som hittats vid produktionen
• Rensa upp verifieringsdata efter släpp
• Övervakning efter släpp (om tillämpligt)

Behöver jag testa allt igen?

Inte nödvändigtvis. Detta beror på vilken version som ska släppas och konsekvensanalysen.

Detaljerad testning bör göras under en vanlig QA-cykel. Verifiering efter utsläpp bör göras genom att följa en testplan för utgivningsverifiering som ska vara ett derivat av den fullständiga testplanen för den utgåvan.

Hur formulerar jag verifieringsstrategi efter produktionslansering?

Planeringsverifieringsplanering efter produktion måste göras på samma sätt som din vanliga testplanering.

Strategin bör vara på samma linjer som testflödet som följs under QA-cykeln. Det är viktigt att inkludera de viktigaste och viktigaste stegen som möjliggör maximal funktionstäckning.

bästa gratis PC-programvara

En bra strategi efter lanseringen bör:

• Inkludera steg för att testa nya funktioner såväl som större befintliga funktioner
• Kontrollera större påverkansområden
• Tillåt maximal funktionstäckning
• Valfritt: Inkludera alla kritiska buggar som hittades i testmiljön
• Valfritt: Inkludera prioritet för testfall

Vem skapar testplanen för lansering efter lansering?

Detta kommer att variera mellan företag och beror på organisationsstrukturen.

Låt oss ta ett exempel på följande QA-teamorganisation.

I det här scenariot kommer QA att arbeta med det specifika projektet att formulera den första testplanen för release efter produktion.

Vem godkänner testplanen för lansering efter produktion?

Detta kommer att variera mellan företag och beror på organisationsstrukturen.

Återigen med tanke på samma organisationsstruktur som visas i föregående fråga, bör testplanen för produktion efter publicering ses över och godkännas av testledaren eller QA-chefen .

När skapar jag verifieringsplanen för release efter produktion?

Testplanen för släpp efter produktion kan skapas när som helst under programutvecklingscykeln efter att kraven, utvecklingsomfånget och påverkansområdena har identifierats och låsts. Det är vanligtvis lättare för QA att skapa testplanen för produktion efter lanseringen halvvägs in i sprinten. Det säkerställer att det finns tillräckligt med tid för granskning och godkännande.

Det är en bra praxis att inkludera denna testplan tillsammans med någon formella QA-avskrivningsdokument innan projektet går in i distributions- och släppfasen.

Jag slutförde verifieringen efter lanseringen. Vad kommer härnäst?

När verifieringen efter släppningen är klar skulle nästa steg vara

1) Kommunikation av verifieringsresultat - Verifieringsresultaten ska meddelas intressenterna inklusive eventuella problem som kan ha hittats vid produktionen.

2) Rapportera eventuella problem som hittats vid produktionen i Defect Management-verktyget - Till underlätta analys av rotorsaker och spårbarhet .

3) Rensa efter verifieringsdata efter släpp - Datainstädningen måste göras efter att verifieringen är klar.

Till exempel, överväga a för en e-handelsapplikation och säg att du skapade en testorder för produktion. Denna testorder måste avbrytas efter att verifieringen är klar.

4) Övervakning efter frisläppande av produktion (om tillämpligt) - Vissa utgåvor kräver övervakning av produktionen.

Till exempel, om teamet gjorde förbättringar för att förbättra sidladdningstiderna i applikationen, måste detta övervakas under en viss tidsperiod för att säkerställa att förbättringen verkligen sågs efter utgivningen. Den eller de ansvariga personerna för övervakningen bör tydligt identifieras och kommuniceras till.

Vad händer om jag hittar ett problem?

Eventuella problem bör rapporteras i Verktyg för defekthantering och kommuniceras till intressenterna. Om några kritiska problem upptäcks vid produktionen bör kommunikation av resultat ske omedelbart eftersom ett beslut skulle behöva fattas om byggnaden måste rullas tillbaka för att undersöka frågan ytterligare.

Det är viktigt att alla hittade problem rapporteras i Defect Tracking Tool. Det rekommenderas att dessa tas upp som separat frågestyp (t.ex. Post Production Bug) för att visa separering från vanliga QA-cykelfel. Dessa problem kan enkelt filtreras bort om det behövs i syfte att analysera orsaken.

Vad mer behöver jag veta om verifieringsprocessen efter release?

Förutom den faktiska verifieringsprocessen, planen och strategin efter produktionsversionen, nedan är några tips:

• Det är viktigt att ställa tydliga förväntningar på omfattning och syfte med verifiering efter släpp. Intressenter (interna och externa) bör göras medvetna om följande
  • Teamet kan inte testa allt på produktionen
  • Teamet kan inte klämma ihop testvärda dagar till några timmar avsedda för verifiering efter publicering

Därför skulle testningen av produktionen i huvudsak baseras på en godkänd plan för släpptest efter produktion.

Begränsningar:

Vederbörlig försiktighet bör iakttas samtidigt som man bestämmer omfattningen av släpptester efter produktion. Det finns begränsningar för vad och hur mycket vi faktiskt kan testa på produktionen. Produktionsmiljön har levande kunddata och måste hanteras mycket noggrant. Ytterligare planering bör göras för ändringar som involverar datamigrering, uppdatering, radering etc.

Exempel nr 1): För ett eSurvey-företag, om testning innebär att besvara och skicka undersökningen, skulle QA behöva skicka en begäran om att ta bort testundersökningen efter verifiering så att den inte påverkar insamlingsdata för kundundersökningen och deras statistik.

ÄR exempel # 2): För ett e-handelsföretag, låt oss anta att en prisuppdatering SQL-jobb körs vid midnatt varje dag och laddar upp det slutgiltiga priset till webbplatsen. Vi kan inte köra denna SQL on-demand, flera gånger i syfte att verifiera efter utgivningen, eftersom detta kan leda till att oavslutade data pressas till produktion.

Dessutom kan det öka chanserna för DB spärrar och hög förbrukning av CPU- och minnesresurser under högsta arbetstid som kan påverka klientapplikationens prestanda.

• De ansträngningar som krävs för test efter lansering och alla relaterade aktiviteter bör vara inbyggda och inkluderas i projektplanen. Beroende på affärsreglerna och projektspecifikationerna kan detta betraktas som projektkostnader eller inkluderas i kvalitetscykeln eller ingår som en del av planen för frisläppshantering.
• För de problem som rapporteras under verifiering efter släpp bör grundorsaksanalys genomföras för att ta reda på orsaken till att problemet inte upptäcktes tidigt och vad som kan göras bättre nästa gång för att undvika att möta problemet. Grundorsaksanalysen kan hjälpa teamet att lära sig av dessa tidigare problem och fylla i eventuella luckor i implementeringen. Baserat på organisationsstrukturen kan testledaren eller QA-chefen slutföra orsaken till analysen med inlägg från projektteamet. Några vanliga grundorsaker kan vara en kodningsfråga, kravproblem, designproblem, dataproblem, tredjepartsbegränsningar, saknad testscenario etc. Motsvarande korrigerande och förebyggande åtgärder kan skapas och spåras.
• Serverloggar kan också användas för att övervaka byggnaden efter släpp. Serverlogg kan innehålla händelser eller problem som kanske inte är synliga för kunden men som kommer att orsaka problem i backend. Denna övervakning kan tilldelas som en åtgärdspost till Dev lead och DevOps team.

Ett exempel:

Projekt Överblick:

Följande ändringar måste göras i en applikation för sociala medier, särskilt i registreringsprocessen

1. Validering av efternamnfält måste tas bort. Det implementerades tidigare som ”Efternamnet ska innehålla minst fyra tecken” (Förbättring för befintligt fält)
2. Implementera växlingsknappen bredvid e-postadressen så att användaren kan ställa in sekretessinställningarna för e-postadressen som ska visas på sin profil (ny funktionsförfrågan)
3. Användaren ska kunna välja sin avatar (begäran om ny funktion)
4. Minska API-samtal under registreringsprocessen för att förbättra applikationsprestanda (förbättring)

Verifieringsplan efter produktionslansering:

Slutsats:

Med de flesta programvaruföretag nu anta Agile-metoden har antalet produktionsutgåvor ökat.

Till exempel, medan du använder Vattenfall modell , kan ett team ha en produktionsrelease var 1,5 månad, men med Agile-processen kan samma team nu ha en produktionsrelease var 2-3: e vecka.

Med varje produktionsrelease har vi en möjlighet att medvetet eller omedvetet påverka liveklienternas funktionalitet. Antagandet av verifieringen efter produktionsrelease omedelbart efter utgivningen kan ge ytterligare förtroende för utgåvan samtidigt som det ger säkerhetsnätet för att rulla tillbaka utgåvan innan våra live-kunder stöter på några problem.

För projekt med hög inverkan / risk kan planeringsverifieringsplan efter produktion struktureras baserat på testscenariets prioritet. Kritiskt prioritetstest kan utföras först och kommunikation skickas till intressenter om resultat och eventuella problem. Om inga kritiska problem hittas kan verifieringen efter produktionsutgåvan fortsätta, annars måste beslutet om återställning tas för att minimera driftstopp och påverkan på levande klienter.

Dessutom, släpptester efter produktion kan automatiseras och testskript kan köras på begäran efter varje release som ett regressionstest. Återigen bör vederbörlig försiktighet iakttas när du kör de automatiska testskripten vid produktion eftersom det kan påverka live-klientdata och funktionalitet.

konvertera youtube till mp4 hög kvalitet

Verifiering efter släppning av produktion är sista försvarslinjen för alla programvaruföretag. Om vi ​​inte fångar problemen kommer våra kunder att göra det och detta kan vara förödande för något programvaruföretags rykte.

För att bibehålla produktens tillförlitlighet är det viktigt att vi verifierar de förändringar som används i produktionen direkt efter distributionen.

Om författaren: Den här hjälpsamma artikeln är skriven av Neha B. Hon arbetar för närvarande som kvalitetssäkringschef och är specialiserad på ledning och ledning av interna och offshore kvalitetsgrupper.

Dela din teststrategi / tips / erfarenhet efter lansering med våra läsare.

Rekommenderad läsning

• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Testing Primer eBook Download
• 7-stegs praktisk implementering av manuell testning innan produktionen släpps
• Lasttestning med HP LoadRunner-handledning
• Praktisk programvarutestning av QA-processflöde (krav att släppas)
• Skillnad mellan Desktop, Client Server Testing och Web Testing
• Vad är gammatestning? Det sista testetappen
• Vad är tidig testning: Testa tidigt, testa ofta MEN hur? (En praktisk guide)