Kako učinkovito izvesti testiranje po izdaji in čim bolj zmanjšati vpliv izdaje na odjemalce v živo

how perform post release testing effectively

Ko sem svojo kariero začel kot QA, sem sodeloval s podjetjem, ki je svoje izdelke ponujalo kot SaaS. Produkcije so bile kritične in obstajala je možnost, da vplivajo na funkcionalnost odjemalcev v živo.

Ko se je baza naših strank povečala, je ekipa za preverjanje kakovosti sprejela tveganje in zmanjšala vpliv izdaje na aktivne stranke praksa testiranja po izdaji.

To je bilo zame vse novo in v mislih sem imel toliko vprašanj in dvomov:

• Kaj je testiranje po izdaji?
• Vse sem pravilno preizkusil, zakaj moramo opraviti testiranje po izdaji?
• Ali vse preizkusim znova? Kaj natančno storim pri preverjanju po izdaji?
• Kaj se zgodi, če najdem težavo? Itd.

Z veseljem priznam, da sem vse svoje odgovore našel v prvih nekaj izdajah.

Tukaj to znanje delim z vsemi. Članek sem napisal v obliki vprašanj in odgovorov, da vam pokažem, kako sem odkril odgovore.

Kaj se boste naučili:

• Kaj je preverjanje izdaje po proizvodnji?
• Katere naloge in dejavnosti so vključene v fazo preverjanja po izdaji?
• Ali moram vse znova preizkusiti?
• Kako oblikujem strategijo preverjanja izdaje po izdelavi?
• Kdo oblikuje testni načrt za postprodukcijsko izdajo?
• Kdo odobri načrt preskusov po izdaji?
• Kdaj ustvarim načrt preverjanja izdaje postprodukcije?
• Dokončal sem preverjanje izdaje po produkciji. Kaj je naslednje?
• Kaj se zgodi, če najdem težavo?
• Kaj moram še vedeti o postopku preverjanja izdaje po izdelavi?
• Zaključek:
• Priporočeno branje

Kaj je preverjanje izdaje po proizvodnji?

Po definiciji, Objavi pomeni Po , Izdaja produkcije se nanaša na uvajanje v ŽIVO / proizvodna okolja in Preverjanje vključuje zagotovitev, da izdane funkcije ustrezajo zahtevam .

Priporočeno branje=> Kako učinkovito pripraviti 'testno okolje' pred začetkom testiranja

Cilj je preveriti izdajo v produkcijskih okoljih / okoljih LIVE.

c ++ osnovna vprašanja za razgovor

Toda potem se porajajo vprašanja:

• Zakaj moramo opraviti testiranje po izdaji, ko sem vse preizkusil v okolju QA?
• Zakaj predvidevamo, da se bodo težave pojavile v proizvodnji, čeprav smo izdajo temeljito preizkusili v testnem okolju?

Obstaja veliko razlogov, zakaj bi imeli težave s proizvodnjo, čeprav bi jim morda sledili v celoti Postopek zagotavljanja kakovosti (tj. načrtovanje preskusov , pregled načrta preizkusa, preskusni cikel, regresijski testi itd.)

Razlogi, zakaj bi imeli težave s proizvodnjo:

1) Izdaja podatkov - Podatki o proizvodnih in testnih okoljih se lahko razlikujejo. To lahko povzroči, da v preskusnih okoljih manjkajo nekatere težave.

2) Težava z razmestitvijo - Če ima vaše podjetje postopek uvajanja ročne gradnje, je lahko vaša izdaja bolj nagnjena k težavam z uvajanjem. Nekateri pogosti scenariji so lahko: manjkajoče nastavitve konfiguracije ali spletnega mesta, manjkajoči skripti DB, vrstni red uvajanja, ki se ne upošteva (najprej koda, nato DB itd.), Nepravilno nameščene odvisnosti itd.

Preberite tudi=> Kaj mora preveriti QA o postopku uvajanja

3) Območja vpliva niso bila ugotovljena - Obstajajo nekateri scenariji, pri katerih skupina prizadetih območij morda ni pravilno in v celoti opredelila.

Na primer, upoštevajte a SaaS okolje.

Če skupina ni prepoznala vpliva preoblikovane tabele DB na odjemalca s starejšo shemo tabele (npr. Izguba podatkov, potreba po selitev podatkov pred izdajo itd.) itd. Ta težava je manj verjetna za dobro načrtovane projekte z natančnimi zahtevami. Vendar možnost še vedno obstaja.

4) Neznana območja vpliva - To se lahko zgodi, če obseg in prizadeta območja sproščanja niso znana. Na primer, v podjetju z več programskimi izdelki, ki si delijo skupne baze podatkov in arhitekturo, lahko že majhna sprememba poruši funkcionalnost številnih izdelkov.

Katere naloge in dejavnosti so vključene v fazo preverjanja po izdaji?

Naloge in dejavnosti po izdaji na splošno vključujejo:

• Preverjanje izdaje po produkciji
• Prijavi rezultate preverjanja
• Poročanje o kakršnih koli težavah, najdenih v proizvodnji
• Čiščenje podatkov za preverjanje po izdaji
• Spremljanje po sprostitvi (če je primerno)

Ali moram vse znova preizkusiti?

Ni nujno. To je odvisno od gradnje, ki bo izdana, in analize učinka.

Podrobna testiranja je treba opraviti med rednim ciklom zagotavljanja kakovosti. Preverjanje naknadne izdaje je treba izvesti po preskusnem načrtu preverjanja naknadne izdaje, ki bi moral biti izpeljan iz celotnega preskusnega načrta za to izdajo.

Kako oblikujem strategijo preverjanja izdaje po izdelavi?

Načrtovanje preverjanja izdaje po proizvodnji je treba izvesti na podoben način kot običajno načrtovanje preskusov.

Strategija mora biti na istih črtah kot preskusni tok, ki je sledil med ciklom QA. Pomembno je vključiti najpomembnejše in kritične korake, ki omogočajo največjo pokritost funkcionalnosti.

Primer razvrščanja oblačkov c ++

Dobra strategija izdaje po produkciji bi morala:

• Vključite korake za preizkušanje novih funkcij in glavnih obstoječih funkcij
• Preverite območja večjih vplivov
• Omogočite največjo pokritost funkcionalnosti
• Izbirno: vključite vse kritične napake, ki so bile najdene v testnem okolju
• Izbirno: vključite prednost testnih primerov

Kdo oblikuje testni načrt za postprodukcijsko izdajo?

To se bo razlikovalo med podjetji in bo odvisno od organizacijske strukture.

Vzemimo primer naslednje organizacije QA.

V tem scenariju bo QA, ki dela na določenem projektu, oblikoval začetni testni načrt po izdaji.

Kdo odobri načrt preskusov po izdaji?

To se bo razlikovalo med podjetji in bo odvisno od organizacijske strukture.

Ponovno ob upoštevanju iste organizacijske strukture, kot je bila prikazana v prejšnjem vprašanju, bi moral načrt preskusov postprodukcije pregledati in odobriti vodja preskusov ali vodja kakovosti .

Kdaj ustvarim načrt preverjanja izdaje postprodukcije?

Načrt preskusov za naknadno izdajo je mogoče ustvariti kadar koli med ciklom razvoja programske opreme, potem ko so zahteve, obseg razvoja in področja vpliva opredeljeni in zaklenjeni. Običajno je QA lažje pripraviti testni načrt postprodukcije na sredini šprinta. To zagotavlja dovolj časa za pregled in odobritev.

Dobra praksa je vključitev tega preskusnega načrta skupaj s katerim koli formalni dokumenti o odjavi kakovosti preden projekt vstopi v fazo uvajanja in sprostitve.

Dokončal sem preverjanje izdaje po produkciji. Kaj je naslednje?

Ko bo preverjanje objave končano, bodo naslednji koraki

1) Sporočanje rezultatov preverjanja - Rezultate preverjanja je treba sporočiti zainteresiranim stranem, vključno z morebitnimi težavami, ki jih je mogoče najti v proizvodnji.

2) poročanje o morebitnih težavah, ki jih najdete v produkciji, v orodju za upravljanje napak - Za olajšati analizo vzrokov in sledljivost .

3) Počistite podatke o preverjanju po izdaji - Po zaključku preverjanja je treba očistiti podatke.

Na primer, upoštevajte a izdaja za aplikacijo e-trgovine in recimo, da ste ustvarili testno naročilo v proizvodnji. To testno naročilo je treba preklicati, ko je preverjanje končano.

4) Nadzor naknadne sprostitve (če je primerno) - Nekatere izdaje zahtevajo spremljanje proizvodnje.

Na primer, če bi ekipa naredila izboljšave, da bi izboljšala čas nalaganja strani v aplikaciji, bi bilo to treba spremljati v določenem časovnem obdobju, da bi zagotovili, da je bila izboljšava res vidna po izdaji. Odgovorna (- e) oseba (- e) za spremljanje mora biti jasno opredeljena in ji je treba sporočiti.

Kaj se zgodi, če najdem težavo?

O vseh težavah je treba poročati v Orodje za upravljanje napak in sporočili zainteresiranim stranem. Če se pri produkciji najdejo kakršne koli kritične težave, bi bilo treba nemudoma sporočiti rezultate, saj bi bilo treba sprejeti odločitev, če je treba sestavo zgradbe vrniti, da bi nadalje raziskali težavo.

Pomembno je, da se o vseh najdenih težavah poroča v orodju za sledenje napakam. Priporočljivo je, da jih postavimo kot ločeno vrsto izdaje (npr. Naknadna napaka), da prikažemo ločitev od običajnih napak v ciklu QA. Te težave je mogoče enostavno filtrirati, če je to potrebno za namene analize vzroka.

Kaj moram še vedeti o postopku preverjanja izdaje po izdelavi?

Poleg dejanskega postopka preverjanja, načrta in strategije preverjanja izdaje spodaj je nekaj napotkov:

• Pomembno je določiti jasna pričakovanja glede obsega in namena preverjanja po sprostitvi. Zainteresirane strani (notranje in zunanje) je treba opozoriti na naslednje
  • Ekipa ne more preizkusiti vsega v proizvodnji
  • Ekipa ne more stisniti dni testiranja v nekaj ur, namenjenih preverjanju po izdaji

Zato bi preskušanje proizvodnje v osnovi temeljilo na odobrenem načrtu preskusov po proizvodnji.

Omejitve:

Paziti je treba medtem ko je odločal o obsegu testiranja po izdaji. Obstajajo omejitve glede tega, kaj in koliko lahko dejansko preizkusimo v proizvodnji. Proizvodno okolje vsebuje aktivne podatke o strankah in z njimi je treba ravnati zelo previdno. Dodatno načrtovanje je treba opraviti za spremembe, ki vključujejo selitev podatkov, posodabljanje, brisanje itd.

Primer # 1): Če podjetje eSurvey vključuje preizkušanje odgovorov in oddajo ankete, mora QA po preverjanju poslati zahtevo za izbris testne ankete, da ne bo vplivalo na podatke o zbiranju anket strank in njihove statistike.

JE Primer št. 2): Za podjetje za e-trgovino predpostavimo, da se opravilo SQL za posodobitev cen zažene vsak dan ob polnoči in na spletno mesto naloži končno ceno. Tega SQL na zahtevo ne moremo zagnati večkrat z namenom preverjanja po izdaji, saj lahko to povzroči, da se nedokončani podatki potisnejo v produkcijo.

Poleg tega lahko poveča možnosti za Zastoji DB in velika poraba CPU in pomnilniških virov med največjimi delovnimi urami, kar lahko vpliva na delovanje odjemalske aplikacije.

• Prizadevanja za testiranje po sprostitvi in ​​vse s tem povezane dejavnosti je treba vključiti in vključiti v projektni načrt. Glede na poslovna pravila in posebnosti projekta se to lahko šteje za splošne stroške projekta ali vključi v cikel preverjanja kakovosti ali vključi kot del načrta upravljanja izdaje.
• Za težave, o katerih poročajo med preverjanjem po izdaji, je treba izvesti analizo vzrokov, da bi ugotovili, zakaj težava ni bila odkrita zgodaj, in kaj je mogoče narediti naslednjič, da se izognemo soočanju s težavo. Analiza osnovnega vzroka lahko ekipi pomaga, da se uči iz teh preteklih vprašanj in zapolni vse pomanjkljivosti pri izvajanju. Na podlagi organizacijske strukture lahko vodja preizkusa ali vodja kakovosti opravi analizo osnovnega vzroka s prispevki projektne skupine. Nekateri najpogostejši vzroki so lahko težava s kodiranjem, težava z zahtevami, težava z zasnovo, težava s podatki, omejitve tretjih oseb, manjkajoči testni scenarij itd. Ustrezne korektivne in preventivne ukrepe je mogoče ustvariti in jim slediti.
• Dnevniki strežnika se lahko uporablja tudi za spremljanje gradnje po izdaji. Dnevnik strežnika lahko vsebuje dogodke ali težave, ki jih stranka morda ne bo videla, bo pa povzročila težave v zaledju. To spremljanje je mogoče dodeliti kot akcijski element vodstvu razvijalcev in skupini DevOps.

Primer:

Pregled projekta:

vzorčni testni skripti za testiranje programske opreme

Pozneje je treba spremeniti aplikacijo za družabna omrežja, zlasti postopek prijave

1. Preverjanje veljavnosti priimka je treba odstraniti. Pred tem je bil izveden kot „Priimek mora imeti najmanj 4 znake“ (Izboljšanje obstoječega polja)
2. Uporabite preklopni gumb poleg e-poštnega naslova, tako da lahko uporabnik nastavi nastavitve zasebnosti za prikaz e-poštnega naslova v svojem profilu (nova zahteva za funkcijo)
3. Uporabnik mora imeti možnost izbire svojega avatarja (nova zahteva za funkcijo)
4. Zmanjšajte klice API med postopkom prijave za izboljšanje učinkovitosti aplikacije (izboljšanje)

Načrt preverjanja naknadne izdaje:

Zaključek:

Z večino podjetij s programsko opremo zdaj sprejetje metodologije Agile , število izdaj v proizvodnji se je povečalo.

Na primer, med uporabo Model slapa , ekipa ima lahko produkcijsko različico vsakih 1,5 meseca, s procesom Agile pa ima lahko ista ekipa vsake 2-3 tedne produkcijsko različico.

Z vsako produkcijsko izdajo imamo možnost, da zavestno ali nevede vplivamo na funkcionalnost odjemalcev v živo. Sprejetje preverjanja izdaje po produkciji takoj po izdaji lahko hkrati zagotovi dodatno zaupanje v izdajo in hkrati zagotovi varnostno mrežo, da se izdaja sprosti, preden naše stranke v živo naletijo na nekatere težave.

Za projekte z visokim vplivom / tveganjem , načrt preverjanja izdaje po izdelavi je mogoče strukturirati glede na prednost preskusnega scenarija. Najprej je mogoče izvesti preskus kritične prioritete in poslati sporočilo zainteresiranim stranem o rezultatih in morebitnih težavah. Če ne najdemo nobenih kritičnih težav, se lahko preverjanje izdaje po izdelavi nadaljuje, sicer pa je treba sprejeti odločitev za vrnitev, da se čim bolj zmanjša čas izpada aplikacij in vpliv na aktivne stranke.

Poleg tega testiranje postprodukcije je lahko avtomatizirano preizkusne skripte pa lahko na zahtevo zaženete po vsaki izdaji kot test regresije. Ponovno je treba biti previden med izvajanjem samodejnih preizkusnih skriptov v produkciji, saj lahko to vpliva na podatke in funkcionalnost odjemalca v živo.

Preverjanje naknadne izdaje je zadnja obrambna črta za katero koli programsko opremo. Če težav ne odkrijemo, bodo to storile naše stranke, kar lahko uniči ugled katerega koli podjetja s programsko opremo.

Da bi ohranili zanesljivost izdelka, je nujno, da takoj po uvedbi preverimo spremembe, ki se uvedejo v proizvodnjo.

O avtorju: Ta koristen članek je napisala Neha B. Trenutno dela kot vodja zagotavljanja kakovosti in je specializirana za vodenje in upravljanje lastnih in zunanjih služb za zagotavljanje kakovosti.

Delite svojo post-produkcijsko strategijo / nasvete / izkušnje z našimi bralci.

Priporočeno branje

• Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
• Prenos eBook knjige za preizkušanje
• 7-stopenjsko praktično izvajanje ročnega preskušanja pred sprostitvijo proizvodnje
• Testiranje obremenitve z vadnicami HP LoadRunner
• Praktično testiranje programske opreme QA Process Flow (zahteve za sprostitev)
• Razlika med testiranjem namizja, odjemalskega strežnika in spletnim preskušanjem
• Kaj je testiranje gama? Zaključni preizkusni oder
• Kaj je zgodnje testiranje: preizkusite zgodaj, pogosto testirajte, toda kako? (Praktični vodnik)