Ako efektívne vykonávať testovanie po vydaní a minimalizovať dopad vydania na živých klientov

how perform post release testing effectively

Keď som začínal svoju kariéru ako QA, pracoval som so spoločnosťou, ktorá ponúkala svoje produkty ako SaaS. Vydania výroby boli kritické a existovala možnosť ovplyvnenia funkčnosti živých klientov.

Keď sa rozrastala naša klientská základňa, prijal tím QA správu rizík a minimalizáciu dopadu vydania na živých klientov postup testovania po prepustení.

To bolo pre mňa všetko nové a v mysli som mal toľko otázok a pochybností:

• Čo je testovanie po vydaní?
• Všetko som poriadne otestoval, prečo musíme robiť testy po vydaní?
• Testujem všetko odznova? Čo presne mám robiť pri overovaní po vydaní?
• Čo sa stane, ak nájdem problém? Atď.

S potešením pripúšťam, že všetky svoje odpovede som našiel v rámci mojich prvých produkčných vydaní.

Tu zdieľam tieto vedomosti s vami všetkými. Článok som sa rozhodol napísať do formátu otázok a odpovedí, aby som vám ukázal spôsob, akým som našiel odpovede.

Čo sa dozviete:

• Čo je overenie vydania po výrobe?
• Aké úlohy a činnosti sú zahrnuté vo fáze overovania po vydaní?
• Musím všetko znovu otestovať?
• Ako môžem formulovať stratégiu overenia vydania po produkcii?
• Kto vytvára plán testovania vydania po produkcii?
• Kto schvaľuje plán testov vydania po výrobe?
• Kedy vytvorím plán overenia vydania po produkcii?
• Dokončil som overenie vydania po produkcii. Čo bude ďalej?
• Čo sa stane, ak nájdem problém?
• Čo ďalšie potrebujem vedieť o procese overovania vydania po produkcii?
• Záver:
• Odporúčané čítanie

Čo je overenie vydania po výrobe?

Podľa definície, Príspevok znamená Po , Vydanie výroby sa týka nasadenia do LIVE / produkčného prostredia a Overenie zahŕňa uistite sa, že vydané funkcie spĺňajú požiadavky .

Odporúčané čítanie=> Ako efektívne pripraviť „testovacie prostredie“ pred začatím testovania

Cieľom je overiť vydanie na produkčné / živé prostredie.

bezplatný nástroj na opravu počítačov so systémom Windows 10

Potom sa však naskytnú otázky:

• Prečo musíme robiť postprodukčné vydanie, keď som testoval všetko na prostredí QA?
• Prečo očakávame, že sa pri produkcii vyskytnú problémy, aj keď sme vydanie dôkladne otestovali v testovacom prostredí?

Existuje veľa dôvodov, prečo by sme mali problémy s produkciou, aj keď by sme mohli postupovať úplne Proces zabezpečenia kvality (t.j. plánovanie testov , preskúmanie plánu skúšky, skúšobný cyklus, regresné testy atď.)

Dôvody, prečo by sme mali problémy s výrobou:

1) Vydanie údajov - Údaje dostupné v produkčnom a testovacom prostredí sa môžu líšiť. To môže spôsobiť, že v testovacích prostrediach budú chýbať niektoré problémy s rohovými prípadmi.

2) Problém s nasadením - Ak má vaša spoločnosť proces nasadenia manuálneho zostavenia, vaše vydanie môže byť náchylnejšie na problémy s nasadením. Môžu to byť niektoré bežné scenáre, chýbajúca konfigurácia alebo nastavenia stránky, chýbajúce skripty DB, nedodržiavané poradie nasadenia (najskôr kód, potom DB atď.), Nesprávne nainštalované závislosti atď.

Prečítajte si tiež=> Čo by mal tester QA vedieť o procese nasadenia

3) Dopadové oblasti neboli identifikované - Môžu existovať niektoré scenáre, pri ktorých tím nemusel byť správne a úplne identifikovaný.

Napríklad, zvážte a SaaS prostredie.

Ak tím nezistil vplyv preformulovanej tabuľky DB na klienta používajúceho staršiu schému tabuľky (napr. Strata údajov, potreba migrácia dát pred vydaním atď.) atď. Tento problém je menej pravdepodobný pri dobre naplánovaných projektoch s presnými požiadavkami. Stále však existuje možnosť.

4) Neznáme oblasti vplyvu - Môže k tomu dôjsť, ak nie je známy rozsah a ovplyvnené oblasti uvoľnenia. Napríklad v spoločnosti s niekoľkými softvérovými produktmi zdieľajúcimi spoločné DB a architektúru môže aj malá zmena narušiť funkčnosť mnohých produktov.

Aké úlohy a činnosti sú zahrnuté vo fáze overovania po vydaní?

Úlohy a činnosti po uvoľnení po produkcii všeobecne zahŕňajú:

• Overenie vydania po výrobe
• Nahlásiť výsledky overenia
• Hlásenie akýchkoľvek problémov zistených pri výrobe
• Údaje o verifikácii po vydaní sa vyčistia
• Monitorovanie po vydaní (ak je k dispozícii)

Musím všetko znovu otestovať?

Nie nevyhnutne. Závisí to od zostavenia, ktoré sa má vydať, a od dopadovej analýzy.

Podrobné testovanie by sa malo robiť počas pravidelného cyklu kontroly kvality. Overenie po vydaní by sa malo vykonať podľa plánu testov overenia vydania po produkcii, ktorý by mal byť derivátom úplného plánu testovania pre toto vydanie.

Ako môžem formulovať stratégiu overenia vydania po produkcii?

Plánovanie overenia vydania po produkcii je potrebné vykonať podobným spôsobom ako vaše pravidelné plánovanie testov.

Stratégia by mali byť na rovnakých linkách ako skúšobný tok sledovaný počas cyklu QA. Je dôležité zahrnúť najdôležitejšie a najdôležitejšie kroky, ktoré umožňujú maximálne pokrytie funkčnosti.

super veci, ktoré môžete robiť v c ++

Dobrá stratégia postprodukčného vydania by mala:

• Zahrňte kroky na testovanie nových aj hlavných existujúcich funkcií
• Overte hlavné oblasti vplyvu
• Povoľte maximálne funkčné pokrytie
• Voliteľné: Zahrňte všetky kritické chyby, ktoré sa našli v testovacom prostredí
• Voliteľné: Zahrňte prioritu testovacích prípadov

Kto vytvára plán testovania vydania po produkcii?

To sa bude v jednotlivých spoločnostiach líšiť a bude to závisieť od organizačnej štruktúry.

Uveďme si príklad z nasledujúcej organizácie tímu QA.

V tomto scenári bude QA pracujúca na konkrétnom projekte formulovať počiatočný plán testovania vydania po produkcii.

Kto schvaľuje plán testov vydania po výrobe?

To sa bude v jednotlivých spoločnostiach líšiť a bude to závisieť od organizačnej štruktúry.

Vzhľadom na rovnakú organizačnú štruktúru, aká je uvedená v predchádzajúcej otázke, plán testov uvoľnenia po produkcii by mal byť skontrolovaný a schválený vedúci testu alebo manažér kvality .

Kedy vytvorím plán overenia vydania po produkcii?

Plán testovania vydania po produkcii je možné vytvoriť kedykoľvek počas cyklu vývoja softvéru po identifikácii a uzamknutí požiadaviek, rozsahu vývoja a oblastí dopadu. Pre QA je zvyčajne jednoduchšie vytvoriť plán testovania vydania po produkcii uprostred šprintu. Takto je zabezpečený dostatok času na preskúmanie a schválenie.

Je dobrým zvykom zahrnúť tento testovací plán spolu s akýmkoľvek formálne QA odhlasovacie dokumenty pred tým, ako projekt vstúpi do fázy nasadenia a vydania.

Dokončil som overenie vydania po produkcii. Čo bude ďalej?

Po dokončení overenia po vydaní budú ďalšie kroky

1) Oznamovanie výsledkov overovania - Výsledky overenia by sa mali oznámiť zúčastneným stranám vrátane akýchkoľvek problémov, ktoré sa mohli vyskytnúť pri výrobe.

2) Hlásenie všetkých problémov zistených pri výrobe v nástroji Správa chýb - Do uľahčiť analýzu základných príčin a sledovateľnosť .

3) Údaje o overení po vydaní sa vyčistia - Vyčistenie údajov je potrebné vykonať po dokončení overenia.

Napríklad, zvážte a vydanie pre aplikáciu elektronického obchodu a povedzte, že ste vytvorili skúšobnú objednávku na výrobu. Po dokončení overenia je potrebné túto skúšobnú objednávku zrušiť.

4) Monitorovanie vydania po výrobe (ak je k dispozícii) - Niektoré vydania vyžadujú sledovanie výroby.

Napríklad, ak by tím vykonal vylepšenia s cieľom zlepšiť časy načítania stránky v Aplikácii, bolo by to potrebné po určitú dobu monitorovať, aby sa zabezpečilo, že zlepšenie bolo po vydaní skutočne viditeľné. Zodpovedná (-é) osoba (-y) za monitorovanie by mala byť jasne identifikovaná a mala by sa o nej komunikovať.

Čo sa stane, ak nájdem problém?

Akékoľvek problémy by mali byť hlásené v Nástroj na správu defektov a oznámené zainteresovaným stranám. Ak sa v produkcii vyskytnú nejaké kritické problémy, komunikácia výsledkov by mala nastať okamžite, pretože bude potrebné prijať rozhodnutie, ak je potrebné zostavenie vrátiť späť, aby sa problém ďalej vyšetril.

Je dôležité, aby všetky nájdené problémy boli hlásené v nástroji na sledovanie chýb. Odporúča sa, aby boli uvedené ako samostatný typ problému (napr. Chyba postprodukcie), aby sa prejavilo oddelenie od bežných chýb cyklu QA. Tieto problémy je možné ľahko odfiltrovať, ak je to potrebné na účely analýzy základných príčin.

Čo ďalšie potrebujem vedieť o procese overovania vydania po produkcii?

Okrem skutočného procesu, plánu a stratégie verifikácie postprodukčného vydania sú uvedené aj niektoré ukazovatele:

• Je dôležité stanoviť si jasné očakávania týkajúce sa rozsahu a účelu overenia po prepustení. Zainteresované strany (interné a externé) by mali byť informované o nasledujúcich skutočnostiach
  • Tím nemôže vyskúšať všetko na produkcii
  • Tím nemôže vtesnať testovacie dni do niekoľkých hodín vyhradených na overenie po vydaní

Preto by testovanie výroby bolo v zásade založené na schválenom pláne testovania po uvoľnení po produkcii.

Obmedzenia:

Mali by ste venovať náležitú pozornosť pri rozhodovaní o rozsahu testovania vydania po produkcii. Existujú obmedzenia týkajúce sa toho, čo a koľko môžeme v skutočnosti testovať pri výrobe. Produkčné prostredie obsahuje živé údaje o klientoch a je potrebné s ním zaobchádzať veľmi opatrne. Mali by ste vykonať ďalšie plánovanie zmien, ktoré zahŕňajú migráciu údajov, aktualizáciu, vymazanie atď.

Príklad č. 1): Pokiaľ pre spoločnosť eSurvey, ak testovanie zahŕňa zodpovedanie a odoslanie prieskumu, QA bude musieť po overení poslať žiadosť o vymazanie testovacieho prieskumu, aby to neovplyvnilo údaje zhromaždené z klientskeho prieskumu a ich štatistiku.

JE príklad č. 2): Pre spoločnosť zameranú na elektronický obchod predpokladajme, že aktualizácia cien bude prebiehať každý deň o polnoci a aktualizovaná cena sa načíta na web. Tento SQL nemôžeme spustiť na požiadanie viackrát za účelom overenia po vydaní, pretože by to mohlo spôsobiť presunutie nefinalizovaných údajov do výroby.

Navyše to môže zvýšiť šance na Zablokovania DB a vysoká spotreba zdrojov CPU a pamäte počas špičkových pracovných hodín, čo môže mať vplyv na výkon klientskej aplikácie.

• Úsilie potrebné na testovanie po vydaní a všetky súvisiace činnosti by malo byť súčasťou a zahrnuté v projektovom pláne. V závislosti od obchodných pravidiel a špecifík projektu to možno považovať za réžiu projektu alebo zahrnúť do cyklu QA alebo zahrnúť ako súčasť plánu riadenia vydania.
• V prípade problémov, ktoré sa nahlásia počas overenia po vydaní, by sa mala vykonať analýza základných príčin, aby sa zistil dôvod, prečo sa problém nezachytil včas, a čo je možné urobiť lepšie nabudúce, aby sa mu problém nevyriešil. Analýza základných príčin môže pomôcť tímu poučiť sa z týchto minulých problémov a vyplniť medzery v implementácii. Na základe organizačnej štruktúry môže vedúci testu alebo manažér QA dokončiť analýzu hlavných príčin so vstupom od projektového tímu. Niektoré bežné základné príčiny môžu byť problém s kódovaním, problém s požiadavkami, problém s dizajnom, problém s údajmi, obmedzenia tretích strán, chýbajúci scenár testu atď. Je možné vytvoriť a sledovať príslušné nápravné a preventívne opatrenia.
• Denníky servera možno tiež použiť na sledovanie zostavenia po vydaní. Denník servera môže obsahovať udalosti alebo problémy, ktoré nemusia byť pre zákazníka viditeľné, ale spôsobia problémy v backende. Toto sledovanie je možné priradiť ako položku akcie vedúcemu Dev a tímu DevOps.

Príklad:

Prehľad projektu:

V aplikácii sociálnych médií je potrebné vykonať nasledujúce zmeny, konkrétne v procese registrácie

rozdiel medzi portom vpred a portom

1. Je potrebné odstrániť overenie poľa priezviska. Predtým to bolo implementované ako „Priezvisko by malo mať minimálne 4 znaky“ (Vylepšenie pre existujúce pole)
2. Implementujte prepínacie tlačidlo vedľa e-mailovej adresy, aby používateľ mohol nastaviť nastavenia ochrany osobných údajov pre e-mailovú adresu, ktoré sa majú zobrazovať v jeho profile (požiadavka na novú funkciu)
3. Používateľ by mal mať možnosť zvoliť si svojho avatara (žiadosť o novú funkciu)
4. Znížte volania API počas procesu registrácie a zlepšite výkon aplikácie (vylepšenie)

Plán overenia vydania po výrobe:

Záver:

S väčšinou softvérových spoločností teraz prijatie agilnej metodiky , počet produkčných vydaní sa zvýšil.

Napríklad, pri používaní Model vodopádu , tím môže mať produkčné vydanie každé 1,5 mesiaca, avšak s agilným procesom môže mať rovnaký tím teraz produkčné vydanie každé 2 - 3 týždne.

S každým produkčným vydaním máme možnosť vedome alebo nevedomky ovplyvniť funkčnosť živých klientov. Prijatie overenia postprodukčného vydania ihneď po vydaní môže poskytnúť dodatočnú dôveru k vydaniu a zároveň poskytnúť bezpečnostnú sieť proti vráteniu vydania skôr, ako naši živí klienti narazia na nejaké problémy.

Pre projekty s veľkým dopadom / rizikom , plán verifikácie postprodukčného vydania je možné štruktúrovať na základe priority testovacieho scenára. Najskôr je možné vykonať test kritickej priority a odoslať komunikáciu zainteresovaným stranám o výsledkoch a akýchkoľvek problémoch. Ak sa nenájdu žiadne kritické problémy, potom môže overovanie postprodukčného vydania pokračovať, inak je potrebné prijať rozhodnutie o vrátení, aby sa minimalizovali prestoje aplikácie a dopad na živých klientov.

Navyše, postprodukčné testovanie vydania je možné automatizovať a testovacie skripty je možné spustiť na požiadanie po každom vydaní ako regresný test. Opäť je potrebné venovať náležitú pozornosť spusteniu automatických testovacích skriptov pri výrobe, pretože to môže ovplyvniť živé údaje a funkčnosť klienta.

Overenie vydania po výrobe je posledná obranná línia pre každú softvérovú spoločnosť. Ak problémy nezachytíme, naši zákazníci budú mať a to môže byť zničujúce pre reputáciu akejkoľvek softvérovej spoločnosti.

Z dôvodu zachovania spoľahlivosti produktu je nevyhnutné, aby sme ihneď po nasadení overili zmeny nasadené do výroby.

O autorovi: Tento užitočný článok napísala Neha B. V súčasnosti pracuje ako manažérka zabezpečenia kvality a špecializuje sa na vedenie a riadenie interných a offshore QA tímov.

Podeľte sa o svoju stratégiu / tipy / skúsenosti s testovaním vydania po produkcii s našimi čitateľmi.

Odporúčané čítanie

• Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
• Stiahnutie e-knihy Testing Primer
• Sedemstupňová praktická implementácia manuálneho testovania pred uvedením do výroby
• Testovanie záťaže s výukovými programami HP LoadRunner
• Praktické testovanie softvéru, tok procesov QA (požiadavky na vydanie)
• Rozdiel medzi počítačom, klientskym serverom a webom
• Čo je to testovanie gama? Fáza záverečného testovania
• Čo je predčasné testovanie: Testujte včas, testujte často ALE Ako? (Praktický sprievodca)