Menu

Co by měl QA Tester vědět o procesu správy vydání a nasazení

what qa tester should know about release

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Na našem dnešním setkání týmu manažer zkontroloval všechny na svém připravenost k provedení zkoušky . Zmínil, že „kód bude připraven na QA zítra ráno“. Co tím myslel, když řekl „kód bude připraven“, znamená to, že vývojáři dnes večer napíšou kód v prostředí QA?

Ve skutečnosti tím myslel, že nasazení se plánuje provést v noci a nový kód bude nasazen do prostředí QA pro testování.

Mnozí z vás se nyní mohou ptát, co je nasazení a co v něm opravdu dělají?

proces správy vydání a nasazení pro qa

Co se naučíte:

Celkový proces správy uvolnění a nasazení a důležitost pro tým QA

  • Proč opravdu udržujeme různá prostředí?
  • Jak se kód migruje z jednoho prostředí do druhého?

Následujícím tématům se budu věnovat v tomto článku

  1. Proč je důležité, aby si testeři byli vědomi procesu vydání a nasazení?
  2. Různá prostředí
  3. Co máte na mysli pod Build and Deployment?
  4. Plánované vs. nouzové nasazení
  5. Kontrolní seznam QA - před a po nasazení

# 1. Proč je důležité, aby si testeři byli vědomi procesu nasazení?

Naše hlavní úloha provádění testu závisí na tom, jak úspěšné bylo nasazení. Pokud tým nasazení čelil výzvám a narazil na několik problémů a nemohl správně nasadit kód, bude to jistě znamenat, že tým QA bude identifikovat spoustu chyb, které mohou souviset s prostředím nebo procesem nasazení.

  • Jsou-li si testeři vědomi procesu nasazení, pochopí důležitost dokončení svých úkolů v plánovaném časovém rámci.
  • Testeři získají představu, zda se jedná o skutečnou chybu funkčnosti nebo o něco způsobeného během nasazení, což znamená, že je testeru přiřazen testovací prvek sestavy, ale když se pokusí přihlásit na web, vidí chybu, což znamená, že prostředí nefunguje. , nelze takové problémy považovat za funkční, ale za environmentální. Pokud si tester je vědom nasazení, může problém přičíst k problému nasazení.
  • Mnoho testerů by se dalo vyhnout, pokud by testeři skutečně věděli o seznamu, který byl nasazen. Někdy se stane, že otestujete a nahlásíte problém pro oblasti, které nikdy nebyly nasazeny.

# 2. Různá prostředí

Různá prostředí

Ve výše uvedené klasifikaci jsem popsal 4 nejdůležitější prostředí, která většina organizací dodržuje, nicméně mnoho klientů udržuje mnohem více prostředí, jako je staging, pre-staging atd. Také se může lišit konvence pojmenování.

  • DEV - Vývojové prostředí je prostředí vytvořené a udržované vývojovým týmem pro psaní kódu. Přístup k tomuto prostředí je poskytován pouze vývojovému týmu. Tým QA obvykle nemá přístup do tohoto prostředí. Toto prostředí většinou používá tým Dev pro testování svých jednotek.
  • QA - Prostředí QA je prostředí, kde testování skutečně probíhá. Toto prostředí vlastní tým QA. Tým DEV nemá přístup do tohoto prostředí. Po dokončení návrhu a kódování je kód přesunut do prostředí QA, aby tým QA provedl provedení testu.
  • UAT - Test přijetí uživatelem je prostředí, kde testování provádějí obchodní uživatelé. To se provádí po dokončení testování systému. Hlavním záměrem je otestovat systém z obchodního hlediska. Přístup do tohoto prostředí je poskytován pouze podnikovým uživatelům. V některých případech však vyhledají pomoc s QA, za takových okolností bude QA týmu udělen dočasný přístup do prostředí.
  • PROD - Prostředí PROD je skutečné živé prostředí, které je vystaveno skutečným uživatelům a žádný z týmů DEV a QA nemá k tomuto prostředí přístup pro čtení / zápis. Týmy podpory produktů jsou udržovány za účelem řešení problémů souvisejících s produkčním prostředím.

Přečtěte si také=> Jak efektivně připravit „testovací zařízení“ a minimalizovat vady testovacího prostředí

# 3. Co máte na mysli pod Build and Deployment

Sestavení obsahuje hlavně kompilovaný balíček, který může zahrnovat spustitelný bat, exe, knihovny jako dll, lib a archivy jako soubory zip. Development Team vytvoří sestavení a poskytne jej týmu nasazení pro instalaci.

O kompilaci zdrojového kódu se stará hlavně vývojový tým a poté, co vygenerovali sestavení, umístí jej na určené místo, které je přístupné pro nasazení do jiného prostředí nasazovacím týmem.

Jakmile je sestavení nasazeno, tým QA je upozorněn, aby provedl sestavení ověřovacího testování (BVT) a pokud je úspěšný, tým provede zbytek funkční testování .

V některých organizacích, kde neudržují samostatný tým nasazení, poskytuje vývojový tým sestavení QA a samotný tým QA nasazení dokončí. Existuje velké riziko, v takových případech by prostředky QA měly být technicky zdravé, aby porozuměly celkovému procesu nasazení sestavení, a také by měly vědět, jak napravit, pokud dojde k problému.

Sestavení se udržují pomocí čísel, která říkají 1.0.01 nebo 1.0.03. Je tedy možné, že sestavení 1.0.01 může používat DLL v0.2 a sestavení 1.0.03 může používat DLL v0.5. Pro tým QA se stává důležité zajistit, aby bylo v prostředí nasazeno správné sestavení před zahájením testování. Je vždy dobré sledovat přehled změn poskytovaných jako součást každého sestavení.

bezplatný stahovač hudby pro Android Market

Údržba samostatného nasazovacího týmu je vždy dobrým postupem, protože pomáhá plynulému pohybu kódu z jednoho prostředí do druhého.

Nasazení je proces, jehož prostřednictvím se kód / build přesouvá z jednoho prostředí do druhého. Většina organizace v dnešní době sleduje správný kanál pro nasazení a udržuje samostatný tým, který se o vše stará.

Sestavení a nasazení

výchozí brána není k dispozici, opravte Windows 10

Před dnem nasazení se setkal tým složený z vývojáře, manažera vývoje, inženýra nasazení, testovacího vedoucího a dalších obchodních partnerů. Na schůzce je vývojář obvykle požádán, aby popsal svou změnu. Obvykle musí vyplnit konkrétní formulář s podrobnostmi o změnách a plánu odvolání.

V případě zmeškání některých podrobností nebudou změny schváleny pro nasazení. Tým poté rozhodne, zda změna může být součástí nasazení následujícího dne. Zkušební vedení QA je žádáno o schválení, aby zajistilo, že změna nebude mít vliv na žádný ze stávajících testů. Na schůzce jsou naplánovány položky konečného nasazení.

Na schváleném seznamu pracuje tým nasazení v den nasazení. Tým spustí sadu programů, jak jsou definovány v každé ze změnových formulářů (poskytnutých vývojáři), a poté odešle komunikaci po dokončení nasazení.

Zpráva Deployment Complete poskytuje indikaci týmu QA, že změny / nový kód jsou připraveny k testování.

Přesunutí změn z DEV do QA je odpovědností týmu nasazení. Po dokončení testování QA je kód přesunut do UAT. Nejdůležitější částí je přesun dat PROD, který je třeba provést mimo pracovní dobu, protože během nasazení je třeba snížit životní prostředí a je třeba jej provést s maximální opatrností, protože by to mohlo mít vážný dopad na podnikání.

Většina nasazení Prod se provádí pozdě v noci, kdy je menší šance, že prostředí zasáhnou koncoví uživatelé.

# 4. Plánované vs. nouzové nasazení

Každá organizace udržuje kalendář nasazení. Mnoho zákazníků sleduje nasazení jednou za týden a mnoho jdou na dvoutýdenní období, například k plánovanému nasazení by mělo dojít pouze v úterý, nebo k němu může dojít v úterý a pátek. Dny nasazení se mohou změnit, pokud plánovaný den nasazení připadne na svátek.

Ve výše uvedené části jsem se zabýval procesem, který se používá u všech plánované nasazení .

Plánovaná nasazení mohou mít vlastní výzvu. Pomyslete na případ, kdy je do prostředí QA nasazen nový kód a během testu zdravého rozumu tým identifikuje vadu blokátoru a testování musí být zastaveno. Čeká testovací tým na další nasazení týden?

Abychom takové situace zvládli, provádí se nouzová oprava a nasazení tam, kde tým nasazení nemusí čekat na plánovaný den nasazení. Potřebují sledovat a hledat souhlas i pro nouzová nasazení, ale tato schválení se obvykle dějí rychle a nové změny lze nasadit do prostředí QA ve stejný den nebo co nejdříve.

# 5. Kontrolní seznam QA - před a po nasazení

Před nasazením -

Celá fáze návrhu zkoušky probíhá dříve, než je kód skutečně přesunut do prostředí. Je to provedení testu, které závisí na dostupnosti kódu v prostředí QA, zatímco tým nasazení pracuje na nasazení kódu nasazeného v QA, tým QA by měl zajistit dokončení níže uvedených aktivit -

Po nasazení -

Po nasazení je první věc, kterou jako QA tým děláme, začít s naším testem zdravého rozumu. Ale než zahájíme náš test zdravého rozumu, měli bychom zajistit, aby bylo postaráno o následující -

  • Tým QA měl obdržet oznámení od týmu nasazení o úspěšném nasazení a připraven na QA.
  • Tým QA by měl sledovat nasazené sestavení.
  • Ujistěte se, že tým QA má seznam úspěšně implementovaných změn a také položek, které nebyly nasazeny, i když byly plánovány. Může se stát, že tým nasazení nemohl nasadit kvůli chybějícím podrobnostem atd.

Závěr

Doufám, že vám výše uvedený článek poskytl představu o celkovém procesu správy verzí a nasazení, který byl následován jako součást celkového cyklu vývoje softwaru. Ve většině organizací šlo pouze o obecný postup, ale mnoho zákazníků má různé protokoly.

Autor : Tento úžasný článek napsal člen týmu STH Priya R.

Považovali jste tento proces za užitečný? Dejte nám vědět o procesu nasazení, který ve vaší organizaci sledujete.

Doporučené čtení

^