Meniu

Ce ar trebui să știe Testerul QA despre procesul de gestionare a lansării și implementării

what qa tester should know about release

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

În întâlnirea echipei noastre de astăzi, managerul a verificat cu toată lumea disponibilitate pentru executarea testului . El a menționat că „codul va fi gata pentru QA până mâine dimineață”. Ce a vrut să spună când a spus că „codul va fi gata”, înseamnă că dezvoltatorii vor scrie codul în mediul QA în această seară?

De fapt, el a vrut să spună că implementarea este planificată să se facă noaptea, iar noul cod va fi implementat în mediul QA pentru testare.

Este posibil ca mulți dintre voi să vă întrebați ce este implementarea și ce fac cu adevărat în ea?

proces de gestionare a lansării și implementării pentru qa

Ce veți învăța:

Procesul general de gestionare a lansării și implementării și importanței pentru echipa QA

  • De ce întreținem într-adevăr medii diferite?
  • Cum se migrează codul dintr-un mediu în altul?

Voi acoperi următoarele subiecte în acest articol

  1. De ce este important ca testerii să fie conștienți de procesul de lansare și implementare?
  2. Medii diferite
  3. Ce vrei să spui prin Build și Deployment?
  4. Planificat vs. Deplasare de urgență
  5. QA Checklist - Înainte și după implementare

# 1. De ce este important ca testerii să fie conștienți de procesul de implementare?

Sarcina noastră principală de execuție a testului depinde de cât de reușită a fost implementarea. Dacă echipa de implementare s-a confruntat cu provocări și a întâmpinat mai multe probleme și nu a putut implementa codul în mod corespunzător, aceasta va indica cu siguranță că echipa QA va identifica o mulțime de erori care pot fi legate de mediu sau de procesul de implementare.

  • Dacă testerii sunt conștienți de procesul de implementare, vor înțelege importanța îndeplinirii sarcinilor lor în intervalul de timp planificat.
  • Testerii își vor face o idee dacă problema este într-adevăr o eroare de funcționalitate sau ceva cauzat în timpul implementării spun că un tester este atribuit să testeze funcția de raport, dar când încearcă să se conecteze la site-ul web, vede o eroare care înseamnă că mediul este defect. , astfel de probleme nu pot fi considerate ca fiind probleme funcționale, ci ca de mediu. Dacă testerul este conștient de implementare, poate raporta problema ca fiind o problemă de implementare.
  • Multe non-probleme ar putea fi evitate dacă testerii sunt într-adevăr conștienți de lista care a fost implementată. Uneori se întâmplă să testați și să raportați o problemă pentru zonele care nu au fost niciodată implementate.

# 2. Medii diferite

Medii diferite

În clasificarea de mai sus am acoperit cele mai importante 4 medii pe care le urmăresc cea mai mare organizație, cu toate acestea, mulți clienți mențin mult mai multe medii cum ar fi stagierea, pre-stagierea etc. De asemenea, convenția de numire ar putea diferi.

  • DEV - Mediul de dezvoltare este cel creat și întreținut de echipa de dezvoltare pentru scrierea codului. Accesul pentru acest mediu este acordat doar echipei de dezvoltare. De obicei, echipa QA nu are acces la acest mediu. Acest mediu este folosit în cea mai mare parte de echipa Dev pentru testarea unității lor.
  • QA - Mediul QA este cel în care are loc de fapt testarea. Acest mediu este deținut de echipa QA. Echipa DEV nu are acces la acest mediu. După finalizarea proiectării și codării, codul este mutat în mediul QA pentru ca echipa QA să efectueze executarea testului.
  • UAT - Test de acceptare a utilizatorului este un mediu în care testarea este efectuată de utilizatorii de afaceri. Acest lucru se face după finalizarea testării sistemului. Intenția majoră este de a testa sistemul din punct de vedere al afacerii. Accesul la acest mediu este oferit doar utilizatorilor de afaceri. Cu toate acestea, în unele ocazii solicită asistență pentru asigurarea calității, în astfel de circumstanțe, echipei de asigurare a calității li se oferă acces temporar la mediu.
  • PROD - Mediul PROD este mediul live real care este expus utilizatorilor reali și niciuna dintre echipele DEV și QA nu are acces de citire / scriere la acest mediu. Echipele de asistență pentru produs sunt întreținute pentru a rezolva problemele legate de mediul de producție.

Citește și=> Cum să pregătiți eficient „patul de testare” și să minimizați defectele mediului de testare

întrebare și răspuns la java interviu pentru mai proaspete

# 3. Ce vrei să spui prin Build și Deployment

O versiune conține în principal pachetul compilat care ar putea include bat executabil, exe, biblioteci precum dll, lib și arhive precum fișiere zip. Echipa de dezvoltare creează construcția și o furnizează echipei de implementare pentru instalare.

Compilarea codului sursă este asigurată în principal de echipa de dezvoltare și, după ce au generat compilarea, o plasează într-o locație specificată, accesibilă echipei de implementare pentru implementarea într-un mediu diferit.

Odată ce construirea este implementată, echipa QA este notificată să facă testarea verificării construcției (BVT) și dacă are succes, echipa efectuează restul testarea funcțională .

În unele organizații în care nu mențin o echipă de implementare separată, echipa de dezvoltare asigură construcția către QA, iar echipa QA finalizează implementarea. Există un risc mare implicat, în astfel de cazuri resursele de asigurare a calității trebuie să fie tehnic solide pentru a înțelege procesul general de implementare a construcției și, de asemenea, ar trebui să știe cum să remedieze dacă apare o problemă.

Build-urile sunt întreținute folosind numere, cum ar fi 1.0.01 sau 1.0.03. Deci, este posibil ca versiunea 1.0.01 să ruleze DLL v0.2 și versiunea 1.0.03 să ruleze DLL v0.5. Devine important pentru echipa QA să se asigure că construirea corectă este implementată în mediu înainte de începerea testării. Este întotdeauna o idee bună să țineți evidența modificărilor furnizate ca parte a fiecărei construcții.

Menținerea unei echipe de implementare separate este întotdeauna o bună practică, deoarece ajută la mișcarea lină a codului dintr-un mediu în altul.

Implementarea este un proces prin care codul / compilarea este mutat dintr-un mediu în altul. Majoritatea organizației în aceste zile urmează un canal adecvat pentru implementare și menține o echipă separată care se ocupă de toate acestea.

Construire și implementare

faza ciclului de viață al dezvoltării software-ului

Înainte de ziua desfășurării, se întâlnește o echipă formată din dezvoltator, manager de dezvoltare, inginer de implementare, șef de testare și alți factori interesați. În cadrul întâlnirii, dezvoltatorului i se cere de obicei să descrie schimbarea sa. De obicei, trebuie să completeze un anumit formular cu detalii privind modificările și planul de revenire.

În cazul în care unele detalii sunt omise, modificările nu sunt aprobate pentru implementare. Echipa decide apoi dacă schimbarea poate face parte din implementarea zilei următoare. Conducătorul de test QA este solicitat pentru aprobare pentru a se asigura că modificarea nu va afecta niciunul dintre testele existente. În cadrul întâlnirii, sunt planificate elementele finale de implementare.

Lista aprobată este elaborată de echipa de implementare în ziua implementării. Echipa rulează un set de programe definite în fiecare dintre formularele de modificări (furnizate de dezvoltatori) și apoi trimite comunicarea pe măsură ce implementarea este completă.

Mesajul Deployment Complete oferă o indicație echipei QA că modificările / noul cod sunt gata să fie testate.

Este responsabilitatea echipei de implementare să mute modificările de la DEV la QA. După finalizarea testării QA, codul este mutat în UAT. Mutarea de date PROD este cea mai importantă parte și trebuie făcută în timpul orelor libere, deoarece în timpul desfășurării mediul trebuie redus și trebuie făcut cu cea mai mare atenție, deoarece acest lucru ar putea avea un impact sever asupra afacerii.

Majoritatea implementărilor Prod se fac noaptea târziu, când șansele ca mediul să fie afectat de utilizatorii finali sunt mai mici.

# 4. Planificat vs. Implementare de urgență

Fiecare organizație menține un calendar de implementare. Mulți clienți urmează implementarea o dată pe săptămână și mulți merg la o săptămână, spun că implementarea planificată ar trebui să se întâmple doar marți sau se poate întâmpla marți și vineri. Zilele pentru desfășurare se pot schimba dacă ziua planificată pentru desfășurare se încadrează într-o zi de sărbătoare.

c ++ funcția de sortare cu bule

În secțiunea de mai sus, am acoperit procesul care este urmat pentru orice desfășurarea planificată .

Implementările planificate pot avea propria provocare. Gândiți-vă la un caz în care noul cod este implementat în mediul QA și în timpul testului de sănătate, echipa identifică un defect de blocare și testarea trebuie oprită. Echipa de testare așteaptă o săptămână până la următoarea implementare?

Pentru a rezolva astfel de situații, remedierea de urgență și implementările se fac acolo unde echipa de implementare nu trebuie să aștepte până la ziua planificată de implementare. Ei trebuie să urmărească și să solicite aprobarea chiar și pentru implementările de urgență, dar aceste aprobări se întâmplă de obicei rapid, iar noile modificări pot fi implementate în mediul QA în aceeași zi sau cât mai curând posibil.

# 5. QA Checklist - Înainte și după implementare

Înainte de implementare -

Intregul faza de proiectare a testului are loc înainte ca codul să fie de fapt mutat în mediu. Execuția testului depinde de disponibilitatea codului în mediul QA în timp ce echipa de implementare lucrează la obținerea codului implementat în QA, echipa QA ar trebui să se asigure că a finalizat activitățile de mai jos -

  • Asigurați-vă că cazurile de testare sunt revizuite și aprobate
  • Asigurați-vă că echipa de testare este disponibilă și planificarea resurselor este finalizată
  • Asigurați-vă că sunt identificate nevoile de date de testare

După implementare -

După implementare, primul lucru pe care îl facem noi ca echipă de QA este să începem cu testul nostru de sănătate. Dar, înainte de a începe testul de sănătate, ar trebui să ne asigurăm că au fost luate în considerare următoarele -

  • Echipa QA ar fi trebuit să primească notificări de la echipa de implementare cu privire la implementarea cu succes și pregătită pentru QA.
  • Echipa QA ar trebui să țină evidența construcției implementate.
  • Asigurați-vă că echipa QA are lista modificărilor implementate cu succes și, de asemenea, a articolelor care nu au fost implementate chiar dacă au fost planificate. Se poate întâmpla ca echipa de implementare să nu se poată implementa din cauza lipsei detaliilor etc.

Concluzie

Sper că articolul de mai sus v-a dat o idee despre procesul general de gestionare a lansării și implementării urmat ca parte a ciclului general de dezvoltare software. Aceasta a fost doar o procedură generică urmată în majoritatea organizațiilor, însă mulți clienți au protocoale diferite.

Autor : Acest minunat articol este scris de Priya R., membru al echipei STH.

Ați găsit util acest proces? Spuneți-ne despre procesul de implementare pe care îl urmați în organizația dvs.

Lectură recomandată

^