Jak efektivně provádět testování po vydání a minimalizovat dopad vydání na živé klienty

how perform post release testing effectively

Když jsem zahájil svou kariéru jako QA, pracoval jsem se společností, která své produkty nabízela jako SaaS. Vydání produkce byla kritická a byla možnost ovlivnit funkčnost živých klientů.

Jak se naše klientská základna rozrůstala, přijal tým QA řízení rizik a minimalizaci dopadu vydání na živé klienty postup testování po vydání.

To bylo pro mě všechno nové a v mysli jsem měl tolik otázek a pochybností:

• Co je testování po vydání?
• Testoval jsem všechno správně, proč musíme dělat testování po vydání?
• Zkouším všechno znovu? Co přesně mám dělat při ověření po vydání?
• Co se stane, když najdu problém? Atd.

S potěšením přiznávám, že jsem všechny své odpovědi našel během prvních několika produkčních vydání.

Zde sdílím tyto znalosti s vámi všemi. Rozhodl jsem se napsat článek ve formátu otázek a odpovědí, abych vám ukázal způsob, jakým jsem objevil odpovědi.

Co se naučíte:

• Co je ověření vydání po výrobě?
• Jaké úkoly a aktivity jsou zahrnuty do fáze ověření po vydání?
• Musím vše znovu otestovat?
• Jak mohu formulovat postprodukční strategii ověření vydání?
• Kdo vytváří plán testů vydání po produkci?
• Kdo schvaluje plán testů vydání po produkci?
• Kdy vytvořím plán ověřování vydání po produkci?
• Dokončil jsem ověření produkce po produkci. Co bude dál?
• Co se stane, když najdu problém?
• Co dalšího potřebuji vědět o procesu ověřování vydání po produkci?
• Závěr:
• Doporučené čtení

Co je ověření vydání po výrobě?

Podle definice, Pošta prostředek Po , Vydání výroby odkazuje na nasazení do LIVE / produkčního prostředí a Ověření zahrnuje ujistěte se, že vydané funkce splňují požadavky .

Doporučené čtení=> Jak efektivně připravit „testovací prostředí“ před zahájením testování

Cílem je ověřit vydání v produkčním / živém prostředí.

nejlepší čistič PC a optimalizátor zdarma

Ale pak vyvstávají otázky:

• Proč musíme dělat postprodukční testování vydání, když jsem vše testoval na QA prostředí?
• Proč očekáváme, že v produkci dojde k problémům, i když jsme vydání důkladně otestovali v testovacím prostředí?

Existuje mnoho důvodů, proč bychom měli problémy s produkcí, i když bychom je mohli následovat kompletní Proces zajištění kvality (tj. plánování testů , přezkoumání plánu zkoušek, zkušební cyklus, regresní testy atd.)

Důvody, proč bychom měli problémy s výrobou:

1) Vydání údajů - Data dostupná v produkčním a testovacím prostředí se mohou lišit. To může způsobit, že v testovacích prostředích budou chybět některé problémy s rohovými případy.

2) Problém s nasazením - Pokud má vaše společnost manuální proces nasazení, může být vaše vydání náchylnější k problémům s nasazením. Některé běžné scénáře mohou být, chybějící konfigurace nebo nastavení webu, chybějící DB skripty, nedodržení pořadí nasazení (nejprve kód, poté DB atd.), Nesprávně nainstalované závislosti atd.

Přečtěte si také=> Co by měl Tester QA vědět o procesu nasazení

3) Dopadové oblasti nebyly identifikovány - Mohou existovat některé scénáře, u nichž tým nemusel správně a úplně identifikovat postižené oblasti.

Například, zvažte a SaaS životní prostředí.

Pokud tým nezjistil dopad re-faktorované tabulky DB na klienta používajícího starší schéma tabulky (např. Ztráta dat, potřeba migrace dat před vydáním atd.) atd. Tento problém je méně pravděpodobný u dobře naplánovaných projektů s přesnými požadavky. Ale tato možnost stále existuje.

4) Neznámé oblasti dopadu - K tomu může dojít, pokud není znám rozsah a ovlivněné oblasti vydání. Například ve společnosti s několika softwarovými produkty sdílejícími společné DB a architekturu může i malá změna narušit funkčnost mnoha produktů.

Jaké úkoly a aktivity jsou zahrnuty do fáze ověření po vydání?

Úkoly a aktivity po vydání produkce obecně zahrnují:

• Ověření vydání po produkci
• Nahlásit výsledky ověření
• Hlášení problémů zjištěných při výrobě
• Vyčištění údajů o ověření po vydání
• Monitorování po vydání (je-li k dispozici)

Musím vše znovu otestovat?

Ne nutně. To závisí na sestavení, které má být vydáno, a analýze dopadů.

Podrobné testování by mělo být provedeno během běžného cyklu QA. Ověření po vydání by mělo být provedeno podle plánu testů ověření vydání po produkci, který by měl být derivátem úplného plánu testování pro toto vydání.

Jak mohu formulovat postprodukční strategii ověření vydání?

Plánování ověřování vydání po produkci je třeba provést podobným způsobem jako vaše pravidelné plánování testů.

Strategie by měly být na stejných linkách jako zkušební tok sledovaný během cyklu QA. Je důležité zahrnout nejdůležitější a nejdůležitější kroky, které umožňují maximální pokrytí funkčnosti.

jak otevřít soubory bin ve Windows 10

Dobrá strategie postprodukčního vydání by měla:

• Zahrňte kroky k testování nových i hlavních stávajících funkcí
• Ověřte hlavní oblasti dopadu
• Povolit maximální pokrytí funkčnosti
• Volitelné: Zahrňte všechny kritické chyby, které byly nalezeny v testovacím prostředí
• Volitelné: Zahrňte prioritu testovacích případů

Kdo vytváří plán testů vydání po produkci?

To se bude u různých společností lišit a bude to záviset na organizační struktuře.

Uveďme si příklad následující organizace týmu QA.

V tomto scénáři bude QA pracující na konkrétním projektu formulovat počáteční testovací plán postprodukčního vydání.

Kdo schvaluje plán testů vydání po produkci?

To se bude u různých společností lišit a bude to záviset na organizační struktuře.

Znovu s ohledem na stejnou organizační strukturu, jaká je uvedena v předchozí otázce, by měl být plán postprodukčního vydání přezkoumán a schválen vedoucí testu nebo manažer QA .

Kdy vytvořím plán ověřování vydání po produkci?

Plán testování postprodukční verze lze vytvořit kdykoli během cyklu vývoje softwaru poté, co jsou identifikovány a uzamčeny požadavky, rozsah vývoje a oblasti dopadu. Pro QA je obvykle snazší vytvořit postprodukční testovací plán vydání uprostřed cesty do sprintu. Tím je zajištěn dostatek času na kontrolu a schválení.

Je dobrým zvykem zahrnout tento testovací plán spolu s jakýmkoli formální QA odhlásit dokumenty než projekt vstoupí do fáze nasazení a vydání.

Dokončil jsem ověření produkce po produkci. Co bude dál?

Po dokončení ověření po vydání budou další kroky

1) Sdělení výsledků ověření - Výsledky ověření by měly být sděleny zúčastněným stranám, včetně případných problémů, které by mohly být zjištěny při výrobě.

2) Hlášení veškerých problémů nalezených v produkci v nástroji Správa defektů - Do usnadnit analýzu hlavních příčin a sledovatelnost .

3) Vyčištění údajů o ověření po vydání - Vyčištění dat je třeba provést po dokončení ověření.

Například, zvažte a vydání aplikace eCommerce a řekněte, že jste vytvořili zkušební objednávku na produkci. Po dokončení ověření je třeba tuto testovací objednávku zrušit.

4) Monitorování vydání po výrobě (je-li k dispozici) - Některá vydání vyžadují monitorování produkce.

Například, pokud tým provedl vylepšení za účelem zlepšení doby načítání stránky v aplikaci, bude to nutné po určitou dobu sledovat, aby bylo zajištěno, že zlepšení bylo skutečně vidět po vydání. Odpovědná osoba (osoby) za monitorování by měla být jasně identifikována a měla by jí být sdělena.

Co se stane, když najdu problém?

Jakékoli problémy by měly být hlášeny v Nástroj pro správu defektů a sděleny zúčastněným stranám. Pokud se v produkci vyskytnou kritické problémy, komunikace výsledků by měla proběhnout okamžitě, protože je třeba učinit rozhodnutí, pokud je třeba sestavení vrátit zpět, aby se problém dále prošetřil.

kde můžete sledovat anime online zdarma

Je důležité, aby všechny nalezené problémy byly nahlášeny v nástroji pro sledování defektů. Doporučuje se, aby byly vyvolány jako samostatný typ problému (např. Post Production Bug), aby se zobrazilo oddělení od běžných chyb cyklu QA. Tyto problémy lze snadno odfiltrovat, pokud je to nutné pro účely analýzy hlavních příčin.

Co dalšího potřebuji vědět o procesu ověřování vydání po produkci?

Kromě skutečného procesu, plánu a strategie ověřování vydání po produkci jsou níže některé ukazatele:

• Je důležité stanovit jasná očekávání ohledně rozsahu a účelu ověření po propuštění. Zainteresované strany (interní i externí) by měly být informovány o následujících skutečnostech
  • Tým nemůže otestovat všechno na produkci
  • Tým nemůže vtěsnat dny v hodnotě testování do několika hodin vyhrazených pro ověření po vydání

Proto by testování výroby bylo v zásadě založeno na schváleném plánu testování po vydání verze.

Omezení:

Je třeba věnovat náležitou pozornost při rozhodování o rozsahu testování po vydání produkce. Existují omezení toho, co a kolik můžeme ve výrobě skutečně otestovat. Produkční prostředí obsahuje živá data klientů a je třeba s ním zacházet velmi opatrně. Mělo by být provedeno další plánování změn, které zahrnují migraci dat, aktualizaci, mazání atd.

Příklad č. 1): Pokud u společnosti eSurvey zahrnuje testování zodpovězení a odeslání průzkumu, QA bude muset po ověření zaslat požadavek na smazání testovacího průzkumu, aby to nemělo vliv na data sběru průzkumu klienta a jejich statistiky.

JE příklad č. 2): U společnosti s elektronickým obchodem předpokládejme, že úloha aktualizace cen SQL běží každý den o půlnoci a na web nahraje konečnou cenu. Tento SQL nemůžeme spustit na vyžádání, několikrát za účelem ověření po vydání, protože to může způsobit, že budou nefinalizovaná data přenesena do produkce.

Navíc to může zvýšit šance na Zablokování DB a vysoká spotřeba zdrojů CPU a paměti během špičkových pracovních hodin, což může ovlivnit výkon klientské aplikace.

• Úsilí potřebné pro testování po vydání a všechny související činnosti by mělo být zabudováno a zahrnuto do plánu projektu. V závislosti na obchodních pravidlech a specifikách projektu to lze považovat za režii projektu nebo zahrnout do cyklu QA nebo zahrnout jako součást plánu správy vydání.
• U problémů, které jsou hlášeny během ověření po vydání, by měla být provedena analýza hlavních příčin, aby se zjistil důvod, proč se problém nezachytil brzy a co lze udělat příště, aby se mu problém nevyhnul. Analýza hlavních příčin může týmu pomoci poučit se z těchto minulých problémů a vyplnit případné mezery v implementaci. Na základě organizační struktury může vedoucí testu nebo manažer QA dokončit analýzu hlavních příčin se vstupem od projektového týmu. Některé běžné příčiny mohou být problém s kódováním, problém s požadavky, problém s designem, problém s daty, omezení třetích stran, chybějící scénář testu atd. Lze vytvořit a sledovat odpovídající nápravná a preventivní opatření.
• Protokoly serveru lze také použít ke sledování sestavení po vydání. Protokol serveru může obsahovat události nebo problémy, které nemusí být pro zákazníka viditelné, ale způsobí problémy v back-endu. Toto monitorování lze přiřadit jako položku akce vedoucímu Dev a týmu DevOps.

Příklad:

Přehled projektu:

V aplikaci sociálních médií je třeba provést následující změny, konkrétně proces registrace

1. Je třeba odebrat ověření pole příjmení. Dříve bylo implementováno jako „Příjmení by mělo mít minimálně 4 znaky“ (Vylepšení pro stávající pole)
2. Implementujte přepínací tlačítko vedle e-mailové adresy, aby uživatel mohl nastavit nastavení ochrany osobních údajů pro e-mailovou adresu, která se bude zobrazovat na jejich profilu (požadavek na novou funkci)
3. Uživatel by měl mít možnost vybrat si svého avatara (požadavek na novou funkci)
4. Snižte volání API během procesu registrace, abyste zlepšili výkon aplikace (vylepšení)

Plán ověřování vydání po produkci:

Závěr:

S většinou softwarových společností nyní přijetí metodiky Agile , počet produkčních vydání se zvýšil.

Například, při používání Model vodopádu , tým může mít produkční vydání každé 1,5 měsíce, avšak s agilním procesem může mít stejný tým nyní produkční vydání každé 2-3 týdny.

S každým vydáním produkce máme možnost vědomě nebo nevědomě ovlivnit funkčnost živých klientů. Přijetí ověření produkce po produkci bezprostředně po vydání může poskytnout další důvěryhodnost vydání a současně poskytnout bezpečnostní síť proti vrácení vydání, než naši živí klienti narazí na některé problémy.

Pro projekty s velkým dopadem / rizikem , plán ověřování vydání po produkci lze strukturovat na základě priority testovacího scénáře. Nejprve lze provést test kritické priority a zaslat komunikaci zainteresovaným stranám o výsledcích a problémech. Pokud se nenajdou žádné kritické problémy, pak může ověřování postprodukční verze pokračovat, jinak je třeba učinit rozhodnutí o vrácení zpět, aby se minimalizovaly prostoje aplikace a dopad na živé klienty.

Dodatečně, postprodukční testování vydání lze automatizovat a testovací skripty lze spustit na vyžádání po každém vydání jako regresní test. Při spuštění automatických testovacích skriptů na produkci je třeba věnovat náležitou pozornost, protože to může ovlivnit živá data a funkce klienta.

Postprodukční verzí vydání je poslední obranná linie pro jakoukoli softwarovou společnost. Pokud problémy nezachytíme, naši zákazníci budou, což může být pro pověst jakékoli softwarové společnosti zničující.

Abychom zachovali spolehlivost produktu, je nezbytné, abychom ověřili změny nasazené do produkce ihned po nasazení.

O autorovi: Tento užitečný článek napsal Neha B. V současné době pracuje jako manažer zajišťování kvality a specializuje se na vedení a řízení interních a offshore QA týmů.

Sdílejte svou strategii / tipy / zkušenosti s testováním vydání po produkci s našimi čtenáři.

Doporučené čtení

• Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
• Testování stahování e-knih Primer
• 7kroková praktická implementace manuálního testování před vydáním výroby
• Testování zátěže s výukovými programy HP LoadRunner
• Praktické testování softwaru Tok procesu QA (požadavky na vydání)
• Rozdíl mezi stolním počítačem, klientským serverem a webovým testováním
• Co je to gama testování? Fáze závěrečného testování
• Co je to Early Testing: Test Early, Test often ALE Jak? (Praktický průvodce)