Menu

Čo by mal tester QA vedieť o procese riadenia vydania a nasadenia

what qa tester should know about release

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Na našom dnešnom stretnutí tímu manažér skontroloval všetkých so svojimi pripravenosť na vykonanie skúšky . Spomenul „kód bude pripravený na zabezpečenie kvality do zajtra rána“. Čo tým myslel, keď povedal: „kód bude pripravený“, znamená to, že vývojári dnes večer napíšu kód v prostredí QA?

Mal tým na mysli to, že nasadenie sa plánuje v noci a nový kód sa nasadí do prostredia QA na testovanie.

Mnohí z vás sa teraz môžu pýtať, čo je to nasadenie a čo v ňom vlastne robia?

proces riadenia vydania a nasadenia pre qa

webové stránky previesť youtube videa do mp3

Čo sa dozviete:

Celkový proces správy uvoľnenia a nasadenia a dôležitosť pre tím QA

  • Prečo skutočne udržiavame rôzne prostredia?
  • Ako sa kód migruje z jedného prostredia do druhého?

Nasledujúcim témam sa budem venovať v tomto článku

  1. Prečo je dôležité, aby testeri poznali proces vydania a nasadenia?
  2. Rôzne prostredia
  3. Čo máte na mysli pod pojmom Build and Deployment?
  4. Plánované vs. núdzové nasadenie
  5. Kontrolný zoznam QA - pred a po nasadení

# 1. Prečo je dôležité, aby testeri poznali proces nasadenia?

Naša hlavná úloha vykonania testu závisí od toho, ako úspešné bolo nasadenie. Ak tím nasadenia čelil výzvam a narazil na niekoľko problémov a nemohol správne nasadiť kód, bude to určite znamenať, že tím QA identifikuje veľa chýb, ktoré môžu súvisieť s prostredím alebo procesom nasadenia.

  • Ak si testéri budú vedomí procesu nasadenia, pochopia dôležitosť splnenia svojich úloh v plánovanom časovom rámci.
  • Testéri získajú predstavu, či ide skutočne o chybu vo funkčnosti alebo o niečo spôsobené počas nasadenia. Hovorí sa, že testerovi je pridelená funkcia testovania správy, ale keď sa pokúsi prihlásiť na web, zobrazí sa mu chyba, ktorá znamená, že prostredie je nefunkčné. , nemožno takéto problémy považovať za funkčné, ale za environmentálne. Ak je tester informovaný o nasadení, môže problém považovať za problém nasadenia.
  • Mnohým problémom, ktorým sa dá vyhnúť, by sa dalo vyhnúť, ak by testéri skutočne vedeli o zozname, ktorý bol nasadený. Niekedy sa stane, že otestujete a nahlásite problém v oblastiach, ktoré nikdy neboli nasadené.

# 2. Rôzne prostredia

Rôzne prostredia

Vo vyššie uvedenej klasifikácii som sa venoval 4 najdôležitejším prostrediam, ktoré väčšina organizácií dodržiava. Mnoho klientov si však udržiava oveľa viac prostredí, ako je napríklad fázovanie, predbežné nastavenie atď. Konvencia pomenovania sa môže líšiť.

  • DEV - Vývojové prostredie je prostredie vytvorené a udržiavané vývojovým tímom na písanie kódu. Prístup k tomuto prostrediu má iba vývojový tím. Tím QA zvyčajne nemá prístup do tohto prostredia. Toto prostredie väčšinou využíva tím Dev na testovanie svojich jednotiek.
  • QA - Prostredie QA je prostredie, v ktorom skutočne prebieha testovanie. Toto prostredie vlastní tím QA. Tím DEV nemá prístup do tohto prostredia. Po dokončení návrhu a kódovania sa kód presunie do prostredia QA, aby mohol tím QA vykonať test.
  • UAT - Akceptačný test používateľom je prostredie, kde testovanie vykonávajú obchodní používatelia. To sa deje po dokončení testovania systému. Hlavným zámerom je otestovať systém z obchodného hľadiska. Prístup do tohto prostredia majú iba obchodní používatelia. Avšak pri niektorých príležitostiach vyhľadajú pomoc so zabezpečením kvality, za takých okolností dostane tím zabezpečenia kvality dočasný prístup do životného prostredia.
  • PROD - Prostredie PROD je skutočné živé prostredie, ktoré je vystavené skutočným používateľom a žiadny z tímov DEV a QA nemá prístup na čítanie a zápis do tohto prostredia. Tímy podpory produktov sa udržiavajú pri riešení problémov týkajúcich sa produkčného prostredia.

Prečítajte si tiež=> Ako efektívne pripraviť „testovacie zariadenie“ a minimalizovať chyby testovacieho prostredia

# 3. Čo máte na mysli pod pojmom Build and Deployment

Zostava obsahuje hlavne kompilovaný balík, ktorý môže obsahovať spustiteľný bat, exe, knižnice ako dll, lib a archívy ako súbory zip. Vývojový tím vytvorí zostavenie a poskytne ho nasadzovaciemu tímu na inštaláciu.

O kompiláciu zdrojového kódu sa stará hlavne vývojový tím a po vygenerovaní zostavenia ho umiestnia na určené miesto, ktoré je prístupné pre nasadenie v inom prostredí.

Po nasadení zostavy je tím QA informovaný, aby vykonal zostaviť overovacie testovanie (BVT) a ak je úspešný, tím vykonáva zvyšok funkčné testovanie .

V niektorých organizáciách, kde neudržujú samostatný tím nasadenia, poskytuje vývojový tím zostavenie QA a samotný tím QA dokončí nasadenie. Existuje veľké riziko, v takýchto prípadoch by zdroje QA mali byť technicky v poriadku, aby porozumeli celkovému procesu nasadenia zostavenia, a tiež by mali vedieť, ako postupovať v prípade problému.

Stavby sa udržiavajú pomocou čísel, ktoré hovoria napríklad 1.0.01 alebo 1.0.03. Je teda možné, že v zostave 1.0.01 môže byť spustená DLL v0.2 a v zostave 1.0.03 môže byť spustená DLL v0.5. Pre tím QA je dôležité zabezpečiť, aby sa do prostredia nasadilo správne zostavenie pred začiatkom testovania. Vždy je dobré sledovať zmeny poskytované ako súčasť každého zostavenia.

Údržba samostatného tímu nasadenia je vždy dobrým zvykom, pretože pomáha plynulému pohybu kódu z jedného prostredia do druhého.

Nasadenie je proces, prostredníctvom ktorého sa kód / build presúva z jedného prostredia do druhého. Väčšina organizácie v súčasnosti sleduje správny kanál nasadenia a udržiava samostatný tím, ktorý sa o všetky tieto záležitosti stará.

Budovanie a nasadenie

fáza životného cyklu vývoja softvéru

Pred dňom nasadenia sa stretáva tím pozostávajúci z vývojára, manažéra vývoja, inžiniera nasadenia, testovacieho vedúceho a ďalších obchodných zainteresovaných strán. Na stretnutí je vývojár zvyčajne požiadaný, aby opísal svoju zmenu. Zvyčajne musia vyplniť konkrétny formulár s podrobnosťami o zmenách a pláne zmien.

V prípade, že niektoré podrobnosti premeškajú, zmeny nebudú schválené na nasadenie. Tím potom rozhodne, či môže byť zmena súčasťou nasadenia nasledujúceho dňa. Požiada sa o vedenie testu kvality QA, aby sa zabezpečilo, že zmena nebude mať vplyv na žiadny z existujúcich testov. Na stretnutí sú naplánované položky konečného nasadenia.

Na schválenom zozname pracuje tím nasadenia v deň nasadenia. Tím spustí skupinu programov, ako sú definované v každej zo zmien zmien (poskytnuté vývojármi), a potom komunikáciu odošle po dokončení nasadenia.

Správa Deployment Complete poskytuje indikáciu tímu QA, že zmeny / nový kód sú pripravené na testovanie.

Za presun zmien z DEV na QA je zodpovedný tím nasadenia. Po dokončení testovania QA sa kód presunie do UAT. Presun dát PROD je najdôležitejšou časťou a musí sa robiť mimo pracovných hodín, pretože počas nasadenia je potrebné znížiť životné prostredie a je potrebné postupovať s maximálnou opatrnosťou, pretože by to mohlo mať vážny dopad na podnikanie.

Väčšina nasadení Prod sa vykonáva neskoro večer, keď je pravdepodobné, že prostredie bude zasiahnuté koncovými používateľmi.

# 4. Plánované vs. núdzové nasadenie

Každá organizácia vedie kalendár nasadenia. Mnoho zákazníkov sleduje nasadenie raz za týždeň a mnohí idú na dvojtýždenník. Hovorí sa, že k plánovanému nasadeniu by malo dôjsť iba v utorok alebo sa to môže stať v utorok a piatok. Dni nasadenia sa môžu zmeniť, ak plánovaný deň nasadenia pripadne na sviatok.

čo je najlepší poskytovateľ e-mailov

V predchádzajúcej časti som sa zaoberal procesom, ktorý sa uplatňuje pri všetkých plánované nasadenie .

Plánované nasadenia môžu mať svoju vlastnú výzvu. Pomysli na prípad, keď je nový kód nasadený do prostredia QA a počas testu zdravého rozumu tím identifikuje chybu blokátora a testovanie musí byť zastavené. Čaká testovací tím týždeň do ďalšieho nasadenia?

Na riešenie takýchto situácií sa robia núdzové opravy a nasadenia tam, kde tím nasadenia nemusí čakať do plánovaného dňa nasadenia. Musia nasledovať a hľadať súhlas aj v prípade núdzového nasadenia, ale tieto schválenia sa zvyčajne uskutočňujú rýchlo a nové zmeny je možné nasadiť do prostredia zabezpečovania kvality v ten istý deň alebo čo najskôr.

# 5. Kontrolný zoznam QA - pred a po nasadení

Pred nasadením -

Celá fáza návrhu skúšky prebieha skôr, ako sa kód skutočne presunie do prostredia. Je to vykonanie testu, ktoré závisí od dostupnosti kódu v prostredí QA, zatiaľ čo tím nasadenia pracuje na zavedení kódu nasadeného v QA, tím QA by mal zabezpečiť dokončenie nasledujúcich aktivít -

Po nasadení -

Po nasadení je úplne prvá vec, ktorú ako tím QA urobíme, je začať s našim testom zdravého rozumu. Ale skôr ako začneme náš test zdravého rozumu, mali by sme sa ubezpečiť, že bolo dodržané nasledovné -

  • Tím QA mal dostať od tímu nasadenia oznámenie o úspešnom nasadení a pripravený na QA.
  • Tím QA by mal sledovať nasadené zostavenie.
  • Uistite sa, že tím QA má zoznam úspešne nasadených zmien a tiež položky, ktoré neboli nasadené, aj keď boli naplánované. Môže sa stať, že nasadovací tím nemohol nasadiť kvôli chýbajúcim detailom atď.

Záver

Dúfam, že vám uvedený článok poskytol predstavu o celkovom procese správy vydaní a nasadenia, ktorý bol súčasťou celého cyklu vývoja softvéru. Vo väčšine organizácií išlo iba o všeobecný postup, avšak mnoho zákazníkov má rôzne protokoly.

Autor : Tento úžasný článok píše člen tímu STH Priya R.

Považovali ste tento proces za užitočný? Dajte nám vedieť o procese nasadenia, ktorý vo svojej organizácii sledujete.

Odporúčané čítanie

^