Hvordan utføre test etter utgivelsen effektivt og minimere effekten av utgivelsen for live klienter

how perform post release testing effectively

Da jeg startet karrieren som kvalitetssikring, jobbet jeg med et selskap som tilbød sine produkter som SaaS. Produksjonsutgivelser var kritiske, og det var en mulighet for å påvirke funksjonaliteten til live-klientene.

Etter hvert som kundebasen vår vokste, vedtok QA-teamet for å håndtere risikoen og minimere virkningen av utgivelsen til live-kunder testutøvelsen etter utgivelsen.

Dette var helt nytt for meg, og jeg hadde så mange spørsmål og tvil i tankene mine:

• Hva er testing etter utgivelse?
• Jeg testet alt ordentlig, hvorfor trenger vi å gjøre testing etter utgivelsen?
• Tester jeg alt igjen? Hva gjør jeg nøyaktig i forbindelse med bekreftelse etter utgivelsen?
• Hva skjer hvis jeg finner et problem? Etc.

Jeg er glad for å innrømme at jeg fant alle svarene mine i løpet av de første produksjonsutgivelsene mine.

Her deler jeg den kunnskapen med dere alle. Jeg valgte å skrive artikkelen i et spørsmåls- og svarformat for å vise deg hvordan jeg oppdaget svarene.

Hva du vil lære:

• Hva er utgivelsesbekreftelse etter produksjon?
• Hvilke oppgaver og aktiviteter er inkludert i verifiseringsfasen etter utgivelsen?
• Må jeg teste alt på nytt?
• Hvordan formulerer jeg bekreftelsesstrategi etter produksjonen?
• Hvem lager testplanen for lansering av utgivelsen?
• Hvem godkjenner testplanen for frigjøring etter produksjon?
• Når oppretter jeg bekreftelsesplanen for utgivelsen etter produksjon?
• Jeg fullførte verifiseringen av utgivelsen etter produksjonen. Hva blir det neste?
• Hva skjer hvis jeg finner et problem?
• Hva mer trenger jeg å vite om bekreftelsesprosessen etter produksjonen?
• Konklusjon:
• Anbefalt lesing

Hva er utgivelsesbekreftelse etter produksjon?

Per definisjon, Post midler Etter , Produksjonsutgivelse refererer til distribusjon til LIVE / produksjonsmiljøer og Bekreftelse inkluderer sørge for at funksjonene som er utgitt oppfyller kravene .

Anbefalt lesing=> Hvordan effektivt forberede “Testmiljø” før du begynner å teste

Målet er å verifisere utgivelsen i produksjon / LIVE-miljøer.

konverter char til int i c ++

Men spørsmålene dukker opp:

• Hvorfor trenger vi å gjøre utgivelsestesting etter produksjon når jeg testet alt på QA-miljø?
• Hvorfor forventer vi at det vil oppstå problemer i produksjonen, selv om vi testet utgivelsen grundig i testmiljøet?

Det er mange grunner til at vi har problemer med produksjonen, selv om vi kanskje har fulgt fullstendig Kvalitetssikringsprosess (dvs. testplanlegging , testplangjennomgang, testsyklus, regresjonstester etc.)

Årsaker til at vi har problemer med produksjonen:

1) Dataproblem - Dataene som er tilgjengelige om produksjons- og testmiljøer kan variere. Dette kan føre til at noen hjørnesaksproblemer blir savnet i testmiljøer.

2) Problem med distribusjon - Hvis firmaet ditt har en manuell distribusjonsprosess, kan utgivelsen din være mer utsatt for distribusjonsproblemer. Noen vanlige scenarier kan være, manglende konfigurasjons- eller nettstedsinnstillinger, manglende DB-skript, distribusjonsrekkefølge som ikke følges (kode først, deretter DB osv.), Avhengigheter installert feil osv.

Les også=> Hva QA Tester bør vite om implementeringsprosessen

3) Påvirkningsområder er ikke identifisert - Det kan være noen scenarier som de berørte områdene kanskje ikke har blitt identifisert riktig og fullstendig av teamet.

For eksempel, vurder a SaaS miljø.

Hvis teamet ikke identifiserte effekten av en re-factored DB-tabell på en klient ved bruk av eldre tabellskjema (f.eks. Tap av data, behov for datamigrering før utgivelse osv.) osv. Dette problemet er mindre sannsynlig for godt planlagte prosjekter med nøyaktige krav. Men muligheten eksisterer fortsatt.

4) Ukjent påvirkningsområder - Dette kan oppstå hvis omfanget og berørte områder av utgivelsen ikke er kjent. For eksempel, i et selskap med flere programvareprodukter som deler vanlig DB og arkitektur, kan til og med en liten endring bryte funksjonaliteten til mange produkter.

Hvilke oppgaver og aktiviteter er inkludert i verifiseringsfasen etter utgivelsen?

Utgivelsesoppgaver og aktiviteter etter produksjon inkluderer vanligvis:

• Bekreftelse etter utgivelse
• Rapporter bekreftelsesresultater
• Rapporterer eventuelle problemer som er funnet på produksjonen
• Bekreftelsesdata etter utgivelse rydder opp
• Overvåking etter utgivelse (hvis aktuelt)

Må jeg teste alt på nytt?

Ikke nødvendigvis. Dette avhenger av byggingen som skal frigjøres og konsekvensanalysen.

Detaljert testing bør utføres under vanlig QA-syklus. Bekreftelse etter utgivelse bør gjøres ved å følge en testplan for utgivelsesverifisering, som skal være et derivat av den fullstendige testplanen for utgivelsen.

Hvordan formulerer jeg bekreftelsesstrategi etter produksjonen?

Bekreftelsesplanlegging etter produksjonsutgivelse må gjøres på samme måte som din vanlige testplanlegging.

Strategien skal være på samme linje som testflyten som følges under QA-syklusen. Det er viktig å inkludere de viktigste og kritiske trinnene som tillater maksimal funksjonalitetsdekning.

oops konsepter i c # med eksempler for erfarne

En god utgivelsesstrategi etter produksjonen bør:

• Inkluder trinn for å teste nye funksjoner, så vel som store eksisterende funksjoner
• Bekreft store påvirkningsområder
• Tillat maksimal funksjonalitetsdekning
• Valgfritt: Inkluder kritiske feil som ble funnet i testmiljøet
• Valgfritt: Inkluder prioritet til testtilfellene

Hvem lager testplanen for lansering av utgivelsen?

Dette vil variere fra selskap til selskap og vil avhenge av organisasjonsstrukturen.

La oss ta et eksempel på følgende QA-teamorganisasjon.

I dette scenariet vil QA som arbeider med det spesifikke prosjektet formulere den første testplanen for frigjøring etter produksjon.

Hvem godkjenner testplanen for frigjøring etter produksjon?

Dette vil variere fra selskap til selskap og vil avhenge av organisasjonsstrukturen.

På nytt vurderer den samme organisasjonsstrukturen som vist i forrige spørsmål, og testplanen for utgivelse av produksjonsprøven bør gjennomgås og godkjennes av Test Lead eller QA Manager .

Når oppretter jeg bekreftelsesplanen for utgivelsen etter produksjon?

Testplanen for frigjøring etter produksjon kan opprettes når som helst i løpet av programvareutviklingssyklusen etter at kravene, utviklingsomfanget og påvirkningsområdene er identifisert og låst. Det er vanligvis lettere for kvalitetssikringsselskapet å lage en plan for utgivelsen av testproduksjonen midt på sprinten. Det sikrer at det er nok tid til gjennomgang og godkjenning.

Det er en god praksis å inkludere denne testplanen sammen med noen formelle QA-avloggingsdokumenter før prosjektet går inn i distribusjons- og frigjøringsfasen.

Jeg fullførte verifiseringen av utgivelsen etter produksjonen. Hva blir det neste?

Etter at bekreftelsen etter utgivelsen er fullført, vil de neste trinnene være

1) Kommunikasjon av verifiseringsresultater - Bekreftelsesresultatene skal kommuniseres til interessentene, inkludert eventuelle problemer som kan ha blitt funnet i produksjonen.

2) Rapportere eventuelle problemer som er funnet på produksjonen i Defect Management-verktøyet - Til legge til rette for årsaksanalyse og sporbarhet .

3) Bekreftelsesdata etter utgivelse rydder opp - Dataryddingen må gjøres etter at bekreftelsen er fullført.

For eksempel, vurder a utgivelse for en e-handelsapplikasjon og si at du opprettet en testordre på produksjon. Denne testordren må avbrytes etter at bekreftelsen er fullført.

4) Overvåking etter frigjøring etter produksjon (hvis aktuelt) - Noen utgivelser krever overvåking av produksjonen.

For eksempel, hvis teamet gjorde forbedringer for å forbedre sidetiden i applikasjonen, må dette overvåkes over en viss periode for å sikre at forbedringen faktisk ble sett etter utgivelsen. Den eller de ansvarlige personene for overvåking bør identifiseres tydelig og kommuniseres til.

Hva skjer hvis jeg finner et problem?

Eventuelle problemer bør rapporteres i Verktøy for feilhåndtering og kommunisert til interessentene. Hvis det oppdages noen kritiske problemer ved produksjonen, bør kommunikasjon av resultatene skje umiddelbart, da det må tas en beslutning om byggingen må rulles tilbake for å undersøke problemet nærmere.

Det er viktig at alle problemene som er funnet blir rapportert i Defect Tracking Tool. Det anbefales at disse løftes opp som en egen utgivelsestype (f.eks. Post Production Bug) for å vise separasjon fra vanlige QA-syklusfeil. Disse problemene kan enkelt filtreres ut hvis det er nødvendig for å gjøre årsaksanalyse.

Hva mer trenger jeg å vite om bekreftelsesprosessen etter produksjonen?

Foruten den faktiske bekreftelsesprosessen, planen og strategien etter produksjonsutgivelsen, er det noen tips:

• Det er viktig å stille klare forventninger til omfanget og formålet med verifisering etter utgivelsen. Interessenter (interne og eksterne) bør gjøres oppmerksom på følgende
  • Teamet kan ikke teste alt på produksjon
  • Teamet kan ikke presse testverdier på noen timer til noen timer som er satt av til bekreftelse etter utgivelsen

Derfor vil testingen på produksjonen i det vesentlige være basert på godkjent testplan etter produksjonsutgivelse.

Begrensninger:

Forsiktig bør utvises mens man bestemmer omfanget av utgivelsestesting etter produksjon. Det er begrensninger på hva og hvor mye vi faktisk kan teste på produksjon. Produksjonsmiljøet har live klientdata og må håndteres veldig nøye. Ytterligere planlegging bør gjøres for endringer som involverer datamigrering, oppdatering, sletting etc.

Eksempel 1): For et eSurvey-selskap, hvis testing innebærer å svare på og sende inn undersøkelsen, vil QA måtte sende en forespørsel om å slette testundersøkelsen etter bekreftelse for ikke å påvirke dataene om innsamling av klientundersøkelser og deres statistikk.

ER eksempel # 2): For et e-handelsselskap, la oss anta at en prisoppdatering SQL-jobb kjører ved midnatt hver dag og laster opp den endelige prisen til nettstedet. Vi kan ikke kjøre denne SQL på forespørsel, flere ganger med sikte på bekreftelse etter utgivelsen, da dette kan føre til at uferdige data blir presset til produksjon.

Videre kan det øke sjansene for DB fastlåser og høyt forbruk av CPU og minne ressurser i løpet av topp arbeidstid som kan påvirke ytelsen til klientapplikasjonen.

• Innsatsen som kreves for testing etter utgivelsen og alle relaterte aktiviteter, bør være innebygd og inkluderes i prosjektplanen. Avhengig av forretningsregler og prosjektspesifikasjoner, kan dette betraktes som prosjektkostnad eller inkluderes i kvalitetssyklus eller inkluderes som en del av frigjøringsstyringsplanen.
• For problemene som rapporteres under verifisering etter utgivelse, bør årsaksanalyse utføres for å finne ut årsaken til at problemet ikke ble fanget tidlig og hva som kan gjøres bedre neste gang for å unngå å møte problemet. Grunnårsaksanalysen kan hjelpe teamet til å lære av disse tidligere problemene og fylle ut eventuelle hull i implementeringen. Basert på organisasjonsstrukturen kan Test Lead eller QA Manager fullføre årsaksanalysen med innspill fra prosjektgruppen. Noen vanlige grunnårsaker kan være et kodeproblem, kravproblem, designproblem, dataproblemer, tredjepartsbegrensninger, manglende testscenario etc. Tilsvarende korrigerende og forebyggende handlinger kan opprettes og spores.
• Serverlogger kan også brukes til å overvåke bygningen etter utgivelsen. Serverlogg kan inneholde hendelser eller problemer som kanskje ikke er synlige for kunden, men som vil forårsake problemer i backend. Denne overvåkingen kan tilordnes som et handlingselement til Dev lead og DevOps team.

Et eksempel:

Prosjekt oversikt:

Følgende endringer må gjøres i et sosialt medieprogram, spesielt i påmeldingsprosessen

hva er en shockwave flash-fil

1. Validering av etternavn felt må fjernes. Det ble tidligere implementert som ‘Etternavn skal ha minimum 4 tegn’ (Forbedring for eksisterende felt)
2. Implementer vippeknappen ved siden av e-postadressen, slik at brukeren kan angi personverninnstillingene for e-postadressen som skal vises på profilen sin (forespørsel om ny funksjon)
3. Brukeren skal kunne velge sin avatar (forespørsel om ny funksjon)
4. Reduser API-anrop under registreringsprosessen for å forbedre applikasjonsytelsen (forbedring)

Bekreftelsesplan for produksjonsutgivelse:

Konklusjon:

Med de fleste programvareselskapene nå vedta Agile-metoden , har antall produksjonsutgivelser økt.

For eksempel, mens du bruker Fossmodell , et team kan ha en produksjonsutgivelse hver 1,5 måned, men med Agile-prosessen kan det samme teamet nå ha en produksjonsutgivelse hver 2-3 uke.

Med hver produksjonsutgivelse har vi en mulighet for å bevisst eller uvitende påvirke funksjonaliteten til live-klientene. Vedtakelsen av utgivelsesverifisering etter produksjon umiddelbart etter utgivelsen kan gi ekstra tillit til utgivelsen samtidig som det gir sikkerhetsnettet for å rulle tilbake utgivelsen før våre live-kunder kommer over noen problemer.

For prosjekter med stor innvirkning / risiko , kan verifiseringsplan for produksjonsutgivelse struktureres basert på prioriteten til testscenariet. Kritisk prioritetstest kan utføres først, og kommunikasjon kan sendes til interessenter om resultater og eventuelle problemer. Hvis det ikke blir funnet noen kritiske problemer, kan verifiseringen av utgivelsen etter produksjon fortsette, ellers må beslutningen om tilbakestilling tas for å minimere nedetid på applikasjonen og påvirke live-klienter.

I tillegg utgivelsestesting etter produksjon kan automatiseres og testskriptene kan kjøres på forespørsel etter hver utgivelse som en regresjonstest. Igjen, bør du være nøye med å kjøre de automatiserte testskriptene under produksjon, da det kan påvirke live klientdata og funksjonalitet.

Bekreftelse etter frigjøring etter produksjon er siste forsvarslinje for ethvert programvareselskap. Hvis vi ikke tar tak i problemene, vil kundene våre, og dette kan være ødeleggende for omdømmet til ethvert programvareselskap.

For å opprettholde produktets pålitelighet er det viktig at vi verifiserer endringene som er implementert i produksjonen umiddelbart etter distribusjonen.

Om forfatteren: Denne nyttige artikkelen er skrevet av Neha B. Hun jobber for tiden som kvalitetssikringsleder og spesialiserer seg i ledelse og ledelse av internt og offshore kvalitetslag.

Del teststrategien / tipsene / erfaringene dine etter produksjonsutgivelsen med leserne våre.

Anbefalt lesing

• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Testing Primer eBook Download
• 7-trinns praktisk implementering av manuell testing før produksjonsutgivelse
• Lastetesting med HP LoadRunner-opplæringsprogrammer
• Praktisk programvaretesting av QA-prosessflyt (krav til utgivelse)
• Forskjellen mellom Desktop, Client Server Testing og Web Testing
• Hva er gammatesting? Den siste testfasen
• Hva er tidlig testing: Test tidlig, test ofte MEN hvordan? (En praktisk guide)