Sådan udføres effektiv test efter frigivelse og minimerer virkningen af ​​frigivelsen på live klienter

how perform post release testing effectively

Da jeg startede min karriere som QA, arbejdede jeg med et firma, der tilbød sine produkter som SaaS. Produktionsudgivelser var kritiske, og der var en mulighed for at påvirke funktionaliteten for live-klienterne.

Da vores kundebase voksede, vedtog QA-teamet for at styre risikoen og minimere virkningen af ​​frigivelsen for live-klienter testpraksis efter frigivelse.

Dette var helt nyt for mig, og jeg havde så mange spørgsmål og tvivl i tankerne:

• Hvad er test efter frigivelse?
• Jeg testede alt ordentligt, hvorfor skal vi udføre test efter frigivelse?
• Tester jeg alt igen? Hvad gør jeg nøjagtigt i forbindelse med verifikation efter frigivelse?
• Hvad sker der, hvis jeg finder et problem? Etc.

Jeg er glad for at indrømme, at jeg fandt alle mine svar inden for mine første par produktionsudgivelser.

Her deler jeg den viden med jer alle. Jeg valgte at skrive artiklen i et spørgsmål og svarformat for at vise dig, hvordan jeg opdagede svarene.

Hvad du lærer:

• Hvad er bekræftelse efter frigivelse efter produktion?
• Hvilke opgaver og aktiviteter er inkluderet i verifikationsfasen efter frigivelse?
• Skal jeg teste alt igen?
• Hvordan formulerer jeg en verifikationsstrategi for frigivelse efter produktion?
• Hvem opretter testplanen for frigivelse efter produktion?
• Hvem godkender testplanen for frigivelse efter produktion?
• Hvornår opretter jeg verifikationsplanen for frigivelse efter produktion?
• Jeg afsluttede verifikationen af ​​frigivelsen efter produktionen. Hvad er det næste?
• Hvad sker der, hvis jeg finder et problem?
• Hvad skal jeg ellers vide om verificeringsproces efter frigivelse af produktion?
• Konklusion:
• Anbefalet læsning

Hvad er bekræftelse efter frigivelse efter produktion?

Per definition, Stolpe midler Efter , Produktionsudgivelse henviser til implementering til LIVE / produktionsmiljøer og Verifikation inkluderer at sikre, at de frigjorte funktioner opfylder kravene .

Anbefalet læsning=> Hvordan man effektivt forbereder “Testmiljø”, før man begynder at teste

Målet er at verificere frigivelsen i produktion / LIVE miljøer.

bedste spilstudier at arbejde for

Men spørgsmålene opstår derefter:

• Hvorfor skal vi foretage test efter frigivelse af produktion, når jeg testede alt i QA-miljø?
• Hvorfor forventer vi, at der opstår problemer i produktionen, selvom vi testede frigivelsen grundigt i testmiljøet?

Der er mange grunde til, at vi har problemer med produktionen, selvom vi måske har fulgt komplet Kvalitetssikringsproces (dvs. testplanlægning , testplan gennemgang, testcyklus, regressionstest etc.)

Årsager til, at vi har problemer med produktionen:

1) Dataudstedelse - De tilgængelige data om produktions- og testmiljøer kan variere. Dette kan få nogle hjørnesagsproblemer til at gå glip af i testmiljøer.

2) Implementeringsproblem - Hvis din virksomhed har en manuel implementeringsproces, kan din frigivelse være mere tilbøjelig til implementeringsproblemer. Nogle almindelige scenarier kan være, manglende konfiguration eller webstedsindstillinger, manglende DB-scripts, rækkefølgen af ​​implementering ikke fulgt (kode først, derefter DB osv.), Afhængigheder installeret forkert osv.

Læs også=> Hvad QA Tester bør vide om implementeringsprocessen

3) Påvirkningsområder er ikke identificeret - Der kan være nogle scenarier, hvor de berørte områder muligvis ikke er identificeret korrekt og fuldstændigt af holdet.

For eksempel, overvej en SaaS miljø.

Hvis teamet ikke identificerede virkningen af ​​en re-factored DB-tabel på en klient ved hjælp af ældre tabelskema (f.eks. Datatab, behov for datamigrering inden frigivelse osv.) osv. Dette problem er mindre sandsynligt for velplanlagte projekter med præcise krav. Men muligheden eksisterer stadig.

4) Ukendte påvirkningsområder - Dette kan ske, hvis omfanget og de berørte områder af frigivelsen ikke er kendt. For eksempel i en virksomhed med flere softwareprodukter, der deler fælles DB og arkitektur, kan selv en lille ændring bryde funktionaliteten af ​​mange produkter.

Hvilke opgaver og aktiviteter er inkluderet i verifikationsfasen efter frigivelse?

Opgaver og aktiviteter efter frigivelse efter produktion inkluderer generelt:

• Bekræftelse efter frigivelse af produktion
• Rapporter verificeringsresultater
• Rapportering af eventuelle problemer, der er fundet i produktionen
• Bekræftelsesdata efter frigivelse ryddes op
• Overvågning efter frigivelse (hvis relevant)

Skal jeg teste alt igen?

Ikke nødvendigvis. Dette afhænger af den build, der skal frigives, og konsekvensanalysen.

Detaljeret test skal udføres under regelmæssig QA-cyklus. Bekræftelse efter frigivelse skal udføres ved at følge en testplan for verifikation efter produktionsudgivelse, der skal være et afledt af den fulde testplan for denne frigivelse.

Hvordan formulerer jeg en verifikationsstrategi for frigivelse efter produktion?

Bekræftelsesplanlægning efter produktionsudgivelse skal udføres på samme måde som din almindelige testplanlægning.

Strategien skal være på de samme linjer som testflowet, der følges under QA-cyklussen. Det er vigtigt at medtage de vigtigste og kritiske trin, der giver maksimal funktionalitetsdækning.

gratis registreringsdatabase renere download til Windows 10

En god frigivelsesstrategi efter produktion skal:

• Inkluder trin til at teste nye funktioner såvel som større eksisterende funktioner
• Kontroller større påvirkningsområder
• Tillad maksimal funktionalitetsdækning
• Valgfrit: Inkluder kritiske fejl, der blev fundet i testmiljøet
• Valgfrit: Inkluder prioritet for testsagerne

Hvem opretter testplanen for frigivelse efter produktion?

Dette vil variere på tværs af virksomheder og vil afhænge af organisationsstrukturen.

Lad os tage et eksempel på følgende QA-teamorganisation.

I dette scenarie formulerer QA, der arbejder på det specifikke projekt, den indledende testplan for frigivelse efter produktion.

Hvem godkender testplanen for frigivelse efter produktion?

Dette vil variere på tværs af virksomheder og vil afhænge af organisationsstrukturen.

Igen overvejer den samme organisationsstruktur som vist i det forrige spørgsmål, skal testplanen for frigivelse af test efter produktion gennemgås og godkendes af Test Lead eller QA Manager .

Hvornår opretter jeg verifikationsplanen for frigivelse efter produktion?

Testplanen for frigivelse efter produktion kan oprettes når som helst under softwareudviklingscyklussen, efter at kravene, udviklingsomfanget og påvirkningsområder er identificeret og låst. Det er normalt lettere for QA at oprette frigivelsestestplanen efter produktionen halvvejs ind i sprinten. Det sikrer, at der er tid nok til gennemgang og godkendelse.

Det er en god praksis at inkludere denne testplan sammen med enhver formelle QA-afmeldingsdokumenter inden projektet går ind i implementerings- og frigivelsesfasen.

Jeg afsluttede verifikationen af ​​frigivelsen efter produktionen. Hvad er det næste?

Når verifikationen efter frigivelse er afsluttet, er de næste trin

1) Kommunikation af verifikationsresultater - Verificeringsresultaterne skal meddeles interessenterne, herunder eventuelle problemer, der måtte være fundet i produktionen.

2) Rapportering af eventuelle problemer, der er fundet i produktionen i Defect Management-værktøjet - Til lette rodårsagsanalyse og sporbarhed .

3) Bekræftelsesdata efter frigivelse ryddes op - Datarensningen skal udføres, når verifikationen er afsluttet.

For eksempel, overvej en frigivelse til en e-handelsapplikation og sig, at du oprettede en testordre på produktionen. Denne testordre skal annulleres, når verifikationen er gennemført.

4) Overvågning efter frigivelse efter produktion (hvis relevant) - Nogle udgivelser kræver overvågning af produktionen.

For eksempel, hvis teamet forbedrede for at forbedre sideindlæsningstiderne i applikationen, skulle dette overvåges over et stykke tid for at sikre, at forbedringen faktisk blev set efter frigivelsen. Den eller de ansvarlige personer til overvågning bør identificeres klart og meddeles.

Hvad sker der, hvis jeg finder et problem?

Eventuelle problemer skal rapporteres i Fejlstyringsværktøj og kommunikeret til interessenterne. Hvis der findes kritiske problemer i produktionen, skal kommunikation af resultater ske straks, da der skulle træffes en beslutning, hvis bygningen skal rulles tilbage for at undersøge problemet nærmere.

Det er vigtigt, at alle fundne problemer rapporteres i værktøjet Fejlsporing. Det anbefales, at disse hæves som separat udstedelsestype (f.eks. Post Production Bug) for at vise adskillelse fra almindelige QA-cyklusfejl. Disse problemer kan let filtreres fra, hvis det er nødvendigt med henblik på analyse af rodårsager.

Hvad skal jeg ellers vide om verificeringsproces efter frigivelse af produktion?

Udover den faktiske verifikationsproces, plan og strategi for frigivelse efter produktion er nedenstående nogle punkter:

• Det er vigtigt at stille klare forventninger til omfang og formål med verifikation efter frigivelse. Interessenter (interne og eksterne) bør gøres opmærksom på følgende
  • Teamet kan ikke teste alt på produktionen
  • Teamet kan ikke presse testværdier til nogle få timer, der er afsat til verificering efter frigivelse

Derfor vil testningen på produktionen i det væsentlige være baseret på en godkendt plan for frigivelse af test efter produktion.

Begrænsninger:

Der skal udvises forsigtighed mens man beslutter omfanget af test efter frigivelse. Der er begrænsninger for, hvad og hvor meget vi faktisk kan teste på produktionen. Produktionsmiljøet har live klientdata og skal håndteres meget omhyggeligt. Yderligere planlægning skal foretages for ændringer, der involverer datamigrering, opdatering, sletning osv.

Eksempel 1): For et eSurvey-firma, hvis test involverer besvarelse og indsendelse af undersøgelsen, ville QA skulle sende en anmodning om at slette testundersøgelsen efter verifikation for ikke at påvirke dataene om indsamling af klientundersøgelser og deres statistikker.

ER eksempel 2): For en e-handelsvirksomhed antager vi, at en prisopdatering SQL-job kører ved midnat hver dag og uploader den endelige pris til webstedet. Vi kan ikke køre denne SQL on-demand flere gange med henblik på verifikation efter frigivelse, da dette kan medføre, at ufærdige data skubbes til produktion.

Desuden kan det øge chancerne for DB-blokeringer og højt forbrug af CPU- og hukommelsesressourcer i spidsbelastningstimer, som kan påvirke klientapplikationens ydeevne.

• Den krævede indsats til test efter frigivelse og alle relaterede aktiviteter bør være indbygget og inkluderet i projektplanen. Afhængigt af forretningsregler og projektspecifikationer kan dette betragtes som projektomkostninger eller inkluderet i QA-cyklus eller inkluderet som en del af frigørelsesstyringsplanen.
• For de problemer, der rapporteres under verifikation efter frigivelse, bør der foretages rodårsagsanalyse for at finde ud af årsagen til, at problemet ikke blev fanget tidligt, og hvad der kan gøres bedre næste gang for at undgå problemet. Grundårsagsanalysen kan hjælpe holdet med at lære af disse tidligere problemer og udfylde eventuelle huller i implementeringen. Baseret på organisationsstrukturen kan Test Lead eller QA Manager gennemføre rodårsagsanalysen med input fra projektteamet. Nogle almindelige grundårsager kan være et kodningsproblem, kravsproblem, designproblem, dataproblem, tredjepartsbegrænsninger, manglende testscenarie osv. Tilsvarende korrigerende og forebyggende handlinger kan oprettes og spores.
• Serverlogfiler kan også bruges til at overvåge build efter frigivelse. Serverlog kan indeholde begivenheder eller problemer, der muligvis ikke er synlige for kunden, men som vil medføre problemer i backend. Denne overvågning kan tildeles som et handlingselement til Dev lead og DevOps team.

Et eksempel:

Projektoversigt:

Følgende ændringer skal foretages i et socialt medieprogram, specifikt til tilmeldingsprocessen

1. Validering af efternavn felt skal fjernes. Det blev tidligere implementeret som 'Efternavn skal have mindst 4 tegn' (Forbedring for eksisterende felt)
2. Implementer vippeknap ved siden af ​​e-mail-adresse, så brugeren kan indstille fortrolighedsindstillingerne for e-mail-adresse, der skal vises på deres profil (anmodning om ny funktion)
3. Brugeren skal være i stand til at vælge sin avatar (anmodning om ny funktion)
4. Reducer API-opkald under tilmeldingsprocessen for at forbedre applikationsydelsen (forbedring)

Bekræftelsesplan for frigivelse efter produktion:

Konklusion:

Med de fleste softwarevirksomheder nu vedtagelse af Agile-metoden er antallet af produktionsudgivelser steget.

For eksempel, mens du bruger Vandfaldsmodel , kan et hold muligvis have en produktionsudgivelse hver 1,5 måned, men med Agile-processen kan det samme hold nu have en produktionsudgivelse hver 2-3 uge.

Med hver produktionsudgivelse har vi en mulighed for bevidst eller ubevidst at påvirke live-klienternes funktionalitet. Vedtagelsen af ​​verifikation efter produktionsudgivelse umiddelbart efter frigivelsen kan give yderligere tillid til frigivelsen på samme tid, hvilket giver sikkerhedsnet til at vende frigivelsen tilbage, før vores live-kunder støder på nogle problemer.

Til projekter med stor indflydelse / risiko , kan verifikationsplan for frigivelse efter produktion struktureres ud fra testscenariets prioritet. Kritisk prioritetstest kan udføres først, og kommunikation kan sendes til interessenter om resultater og eventuelle problemer. Hvis der ikke findes nogen kritiske problemer, kan verifikationen efter frigivelse af produktionen fortsætte, ellers skal beslutningen om tilbagevenden træffes for at minimere applikationens nedetid og påvirkning af live-klienter.

Derudover test efter frigivelse kan automatiseres og testskripterne kan køres efter behov efter hver frigivelse som en regressionstest. Igen skal der udvises forsigtighed under kørsel af de automatiske testscripts på produktion, da det kan påvirke live klientdata og funktionalitet.

hvordan man repræsenterer en graf i java

Bekræftelse efter frigivelse efter produktion er sidste forsvarslinje til ethvert softwarefirma. Hvis vi ikke fanger problemerne, vil vores kunder, og dette kan være ødelæggende for ethvert softwarefirksomheds omdømme.

For at opretholde produktets pålidelighed er det vigtigt, at vi kontrollerer de ændringer, der er implementeret i produktionen straks efter implementeringen.

Om forfatteren: Denne nyttige artikel er skrevet af Neha B. Hun arbejder i øjeblikket som kvalitetssikringschef og er specialiseret i at lede og styre interne og offshore QA-teams.

Del din teststrategi / tip / erfaring efter frigivelse med vores læsere.

Anbefalet læsning

• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Test af Primer eBook Download
• 7-trins praktisk implementering af manuel test inden produktionsudgivelse
• Load Testing med HP LoadRunner-vejledninger
• Praktisk softwaretestning af QA-procesflow (krav til frigivelse)
• Forskel mellem Desktop, Client Server Testing og Web Testing
• Hvad er gammatestning? Den sidste testfase
• Hvad er tidlig test: Test tidligt, test ofte MEN hvordan? (En praktisk guide)