Kako učinkovito izvršiti testiranje nakon objavljivanja i smanjiti utjecaj izdanja na klijente uživo

how perform post release testing effectively

Kad sam započeo karijeru kao QA, radio sam s tvrtkom koja je svoje proizvode nudila kao SaaS. Produkcijska izdanja bila su kritična i postojala je mogućnost utjecaja na funkcionalnost klijenata uživo.

Kako je baza naših klijenata rasla, kako bi upravljali rizikom i smanjili utjecaj izdanja na aktivne klijente, QA tim je usvojio praksa testiranja nakon izdanja.

Sve mi je to bilo novo i u mislima sam imao toliko pitanja i sumnji:

• Što je testiranje nakon izdanja?
• Sve sam ispravno testirao, zašto trebamo napraviti testiranje nakon objavljivanja?
• Ispitujem li sve ispočetka? Što točno radim u provjeri nakon objavljivanja?
• Što će se dogoditi ako pronađem problem? Itd.

Sretna sam što mogu priznati da sam sve svoje odgovore pronašla u prvih nekoliko produkcijskih izdanja.

Evo, dijelim to znanje sa svima vama. Odlučio sam napisati članak u formatu pitanja i odgovora kako bih vam pokazao način na koji sam otkrio odgovore.

Što ćete naučiti:

• Što je potvrda izdanja nakon produkcije?
• Koji su zadaci i aktivnosti uključeni u fazu provjere nakon objavljivanja?
• Trebam li isprobati sve ispočetka?
• Kako mogu formulirati strategiju provjere izdanja nakon produkcije?
• Tko izrađuje plan testa za postprodukciju?
• Tko odobrava plan testa za postprodukciju?
• Kada mogu izraditi plan provjere izdanja nakon produkcije?
• Dovršio sam potvrdu izdanja nakon produkcije. Što je sljedeće?
• Što će se dogoditi ako pronađem problem?
• Što još moram znati o postupku provjere izdanja nakon produkcije?
• Zaključak:
• Preporučena literatura

Što je potvrda izdanja nakon produkcije?

Po definiciji, Objavi sredstva Nakon , Izdanje produkcije odnosi se na raspoređivanje da ŽIVE / proizvodna okruženja i Verifikacija uključuje osiguravajući da izdane značajke udovoljavaju zahtjevima .

Preporučeno čitanje=> Kako učinkovito pripremiti 'Test Environment' prije početka testiranja

Cilj je provjeriti izdanje u produkcijskim / LIVE okruženjima.

pretvoriti znak u niz c ++

Ali tada se postavljaju pitanja:

• Zašto trebamo testirati postprodukciju nakon što sam sve testirao na QA okruženju?
• Zašto predviđamo da će se pojaviti problemi u proizvodnji iako smo izdanje temeljito testirali u testnom okruženju?

Mnogo je razloga zbog kojih bismo imali problema s produkcijom, iako smo možda slijedili u potpunosti Proces osiguranja kvalitete (tj. planiranje ispitivanja , pregled plana ispitivanja, ciklus ispitivanja, regresijski testovi itd.)

Razlozi zbog kojih bismo imali problema s proizvodnjom:

1) Izdavanje podataka - Podaci dostupni u proizvodnom i testnom okruženju mogu se razlikovati. To može prouzročiti propuštanje nekih glavnih slučajeva u testnim okruženjima.

2) Pitanje implementacije - Ako vaša tvrtka ima ručni postupak implementacije gradnje, vaše izdanje može biti sklonije problemima implementacije. Neki uobičajeni scenariji mogu biti, nedostaju konfiguracija ili postavke web mjesta, nedostaju DB skripte, redoslijed postavljanja koji se ne slijedi (prvo kôd, a zatim DB itd.), Pogrešno instalirane ovisnosti itd.

Također pročitajte=> Što QA tester treba znati o procesu implementacije

3) Područja utjecaja nisu identificirana - Mogu postojati neki scenariji za koje tim možda nije točno i u potpunosti identificirao pogođena područja.

Na primjer, razmotrite a SaaS okoliš.

Ako tim nije prepoznao utjecaj prerađene DB tablice na klijenta pomoću starije sheme tablice (npr. Gubitak podataka, potreba za migracija podataka prije puštanja itd.) itd. Ovo se rjeđe događa za dobro planirane projekte s preciznim zahtjevima. Ali, mogućnost još uvijek postoji.

4) Nepoznata područja utjecaja - To se može dogoditi ako opseg i pogođena područja ispuštanja nisu poznati. Na primjer, u tvrtki s nekoliko softverskih proizvoda koji dijele zajednički DB i arhitekturu, čak i mala promjena može slomiti funkcionalnost mnogih proizvoda.

Koji su zadaci i aktivnosti uključeni u fazu provjere nakon objavljivanja?

Zadaci i aktivnosti nakon objavljivanja obično uključuju:

• Potvrda izdanja nakon produkcije
• Prijavi rezultate provjere
• Prijavljivanje svih problema pronađenih u proizvodnji
• Čišćenje podataka potvrde nakon objavljivanja
• Nadgledanje nakon objavljivanja (ako je primjenjivo)

Trebam li isprobati sve ispočetka?

Nije nužno. To ovisi o verziji koja će se objaviti i analizi utjecaja.

Detaljno testiranje treba obaviti tijekom redovnog ciklusa osiguranja kvalitete. Provjera naknadnog izdanja trebala bi se izvršiti slijedeći plan testa provjere naknadnog objavljivanja koji bi trebao biti izvedenica cijelog plana ispitivanja za to izdanje.

Kako mogu formulirati strategiju provjere izdanja nakon produkcije?

Planiranje provjere izdavanja nakon produkcije mora biti izvedeno na sličan način kao i vaše redovno planiranje testa.

Strategija treba biti na istim linijama kao i ispitni tok praćen tijekom QA ciklusa. Važno je uključiti najvažnije i najvažnije korake koji omogućuju maksimalno pokrivanje funkcionalnosti.

super stvari koje možete raditi s c ++-om

Dobra strategija objavljivanja nakon produkcije trebala bi:

• Uključite korake za testiranje novih značajki, kao i glavnih postojećih značajki
• Provjeriti glavna područja utjecaja
• Omogućite maksimalno pokrivanje funkcionalnosti
• Izborno: Uključite sve kritične programske pogreške pronađene u testnom okruženju
• Neobvezno: uključite prioritet test slučajeva

Tko izrađuje plan testa za postprodukciju?

To će se razlikovati među tvrtkama i ovisit će o organizacijskoj strukturi.

Uzmimo primjer sljedeće organizacije QA tima.

U ovom će scenariju QA koji radi na određenom projektu formulirati početni plan ispitivanja nakon objavljivanja.

Tko odobrava plan testa za postprodukciju?

To će se razlikovati među tvrtkama i ovisit će o organizacijskoj strukturi.

Opet uzimajući u obzir istu organizacijsku strukturu kao što je prikazano u prethodnom pitanju, plan ispitivanja postprodukcije trebao bi biti pregledan i odobren od strane voditelj ili QA voditelj .

Kada mogu izraditi plan provjere izdanja nakon produkcije?

Plan testa za postprodukciju može se stvoriti bilo kada tijekom ciklusa razvoja softvera nakon što se utvrde i zaključaju zahtjevi, opseg razvoja i područja utjecaja. QA je obično lakše stvoriti plan testa za postprodukciju na pola puta u sprintu. To osigurava dovoljno vremena za pregled i odobrenje.

Dobra je praksa uključiti ovaj plan ispitivanja zajedno s bilo kojim službeni dokumenti za potpisivanje osiguranja kvalitete prije nego što projekt uđe u fazu implementacije i puštanja u rad.

Dovršio sam potvrdu izdanja nakon produkcije. Što je sljedeće?

Nakon dovršetka provjere objavljivanja, sljedeći će koraci biti

1) Komunikacija rezultata provjere - Rezultati provjere trebaju se priopćiti dionicima, uključujući sva pitanja koja su možda pronađena u proizvodnji.

2) Prijavljivanje svih problema pronađenih u proizvodnji u alatu za upravljanje nedostacima - Da olakšati analizu uzroka i sljedivost .

3) Čišćenje podataka o provjeri nakon objavljivanja - Čišćenje podataka treba obaviti nakon dovršetka provjere.

Na primjer, razmotrite a izdanje za aplikaciju za e-trgovinu i recimo da ste stvorili testni nalog za proizvodnju. Ovu testnu narudžbu treba otkazati nakon dovršetka provjere.

4) Nadgledanje puštanja nakon produkcije (ako je primjenjivo) - Neka izdanja zahtijevaju praćenje proizvodnje.

Na primjer, ako je tim napravio poboljšanja kako bi se poboljšalo vrijeme učitavanja stranice u aplikaciji, to bi trebalo nadgledati tijekom određenog vremenskog razdoblja kako bi se osiguralo da se poboljšanje doista vidjelo nakon objavljivanja. Odgovorna (e) osoba (e) za praćenje trebala bi biti jasno identificirana i komunicirati s njom.

Što će se dogoditi ako pronađem problem?

Svi problemi trebaju se prijaviti u Alat za upravljanje nedostacima i priopćio dionicima. Ako se pronađu bilo kakvi kritični problemi u proizvodnji, komunikacija rezultata trebala bi se dogoditi odmah, jer bi trebala biti donesena odluka ako se gradnja treba vratiti natrag kako bi se problem dalje istražio.

Važno je da se svi pronađeni problemi prijave u alatu za praćenje nedostataka. Preporučuje se da se oni postave kao zasebna vrsta izdanja (npr. Greška u postprodukciji) kako bi se prikazalo odvajanje od redovnih bugova QA ciklusa. Ta se izdanja mogu lako filtrirati ako su potrebna u svrhu analize temeljnog uzroka.

Pitanja i odgovori na temelju sql scenarija

Što još moram znati o postupku provjere izdanja nakon produkcije?

Osim stvarnog postupka provjere, plana i strategije provjere izdanja nakon produkcije, u nastavku su navedeni neki od uputa:

• Važno je postaviti jasna očekivanja u pogledu opsega i svrhe provjere nakon objavljivanja. Dionike (unutarnje i vanjske) treba upoznati sa sljedećim
  • Tim ne može sve testirati na proizvodnji
  • Tim ne može pretvoriti dane vrijedne testiranja u nekoliko sati odvojenih za provjeru nakon objavljivanja

Stoga bi se ispitivanje proizvodnje u osnovi temeljilo na odobrenom planu ispitivanja nakon proizvodnje.

Ograničenja:

Treba biti na oprezu dok je odlučivao o opsegu testiranja izdanja nakon produkcije. Postoje ograničenja onoga što i koliko zapravo možemo testirati na proizvodnji. Proizvodno okruženje ima aktivne podatke o klijentima i s njima treba postupati vrlo pažljivo. Treba napraviti dodatno planiranje za promjene koje uključuju migraciju podataka, ažuriranje, brisanje itd.

Primjer # 1): Za eSurvey tvrtku, ako testiranje uključuje odgovaranje i podnošenje ankete, QA će trebati poslati zahtjev za brisanje testne ankete nakon provjere kako ne bi utjecao na podatke prikupljene ankete klijenata i njihove statistike.

JE primjer br. 2): Za tvrtku za e-trgovinu, pretpostavimo da ažuriranje cijena SQL-a radi svaki dan u ponoć i konačnu cijenu prenosi na web mjesto. Ne možemo pokretati ovaj SQL na zahtjev, više puta u svrhu provjere nakon izdanja, jer to može dovesti do toga da se nedovršeni podaci potisnu u proizvodnju.

Štoviše, to može povećati šanse za DB mrtve točke i velika potrošnja CPU i memorijskih resursa tijekom vršnog radnog vremena što može utjecati na performanse klijentske aplikacije.

• Napor potreban za testiranje nakon objavljivanja i sve povezane aktivnosti treba biti ugrađen i uključen u projektni plan. Ovisno o poslovnim pravilima i specifičnostima projekta, to se može smatrati općim projektom ili uključenim u ciklus osiguranja kvalitete ili uključenim u plan upravljanja izdavanjem.
• Za probleme o kojima se izvještava tijekom provjere nakon objavljivanja, treba provesti analizu osnovnog uzroka kako bi se utvrdio razlog zašto problem nije rano otkriven i što se može učiniti sljedeći put da se izbjegne suočavanje s problemom. Analiza osnovnog uzroka može pomoći timu da nauči iz prošlih problema i popuniti sve praznine u provedbi. Na temelju organizacijske strukture, Test Lead ili QA Manager mogu dovršiti analizu uzroka uz pomoć projektnog tima. Neki uobičajeni korijenski uzroci mogu biti problem s kodiranjem, problem sa zahtjevima, problem s dizajnom, problem s podacima, ograničenja treće strane, nedostajući scenarij testa itd. Odgovarajuće korektivne i preventivne radnje mogu se stvoriti i pratiti.
• Dnevnici poslužitelja se također može koristiti za nadgledanje izrade nakon izdanja. Zapisnik poslužitelja može sadržavati događaje ili probleme koji možda neće biti vidljivi kupcu, ali će uzrokovati probleme u pozadini. Ovo nadgledanje može se dodijeliti kao akcijsku stavku Dev Lead i DevOps timu.

Primjer:

Pregled projekta:

Sljedeće promjene trebaju se unijeti u aplikaciju za društvene medije, posebno u postupak prijave

1. Validaciju polja prezimena treba ukloniti. Prethodno je implementiran kao „Prezime bi trebalo imati najmanje 4 znaka“ (poboljšanje za postojeće polje)
2. Primijenite preklopni gumb pored adrese e-pošte tako da korisnik može postaviti postavke privatnosti za prikaz adrese e-pošte na svom profilu (novi zahtjev za značajkom)
3. Korisnik bi trebao biti u mogućnosti odabrati svoj avatar (novi zahtjev za značajkom)
4. Smanjite API pozive tijekom postupka prijave kako biste poboljšali izvedbu aplikacije (poboljšanje)

Plan provjere izdanja nakon produkcije:

Zaključak:

S većinom softverskih tvrtki sada usvajanje Agile metodologije , povećao se broj proizvodnih izdanja.

Na primjer, dok koristite Model slapa , tim može imati produkcijsko izdanje svakih 1,5 mjeseci, no s Agile postupkom isti tim sada može imati produkcijsko izdanje svaka 2-3 tjedna.

Sa svakim produkcijskim izdanjem imamo mogućnost svjesnog ili nesvjesnog utjecaja na funkcionalnost klijenata uživo. Usvajanje potvrde izdanja nakon produkcije odmah nakon izdavanja može pružiti dodatno povjerenje u izdanje u isto vrijeme pružajući sigurnosnu mrežu za vraćanje izdanja prije nego što naši klijenti uživo naiđu na neke probleme.

Za projekte s velikim utjecajem / rizikom , plan provjere izdanja nakon produkcije može se strukturirati na temelju prioriteta testnog scenarija. Prvo se može izvršiti test kritičnog prioriteta i poslati obavijest dionicima o rezultatima i svim problemima. Ako se ne pronađu kritični problemi, provjera objavljivanja nakon produkcije može se nastaviti, u suprotnom, treba donijeti odluku o vraćanju kako bi se smanjili zastoji aplikacije i utjecaj na aktivne klijente.

Dodatno, testiranje izdanja nakon produkcije može se automatizirati a test skripte mogu se pokretati na zahtjev nakon svakog izdanja kao test regresije. Opet, treba pripaziti tijekom pokretanja automatiziranih testnih skripti u proizvodnji, jer to može utjecati na podatke i funkcionalnost klijenta uživo.

Potvrda objavljivanja nakon produkcije je zadnja crta obrane za bilo koju softversku tvrtku. Ako ne uhvatimo probleme, naši će kupci to shvatiti, a to može biti pogubno za ugled bilo koje softverske tvrtke.

Da bi se održala pouzdanost proizvoda, neophodno je da provjerimo promjene primijenjene u proizvodnji odmah nakon uvođenja.

O autoru: Ovaj korisni članak napisala je Neha B. Trenutno radi kao voditeljica osiguranja kvalitete i specijalizirala se za vođenje i upravljanje internim i offshore timovima za osiguranje kvalitete.

Podijelite svoju strategiju testiranja / savjete / iskustvo za testiranje izdanja s našim čitateljima.

Preporučena literatura

• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Preuzimanje e-knjige za testiranje primera
• Praktična primjena ručnog ispitivanja u 7 koraka prije puštanja u rad
• Ispitivanje opterećenja pomoću HP LoadRunner vodiča
• Praktično testiranje softverskog tijeka QA procesa (zahtjevi za objavljivanje)
• Razlika između testiranja radne površine, klijentskog poslužitelja i web testiranja
• Što je gama testiranje? Završna faza ispitivanja
• Što je rano testiranje: testirajte rano, često testirajte, ALI kako? (Praktični vodič)