Meniu

3 strategii pentru tratarea unui defect de blocare

3 strategies dealing with blocker defect

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Defectele de blocare adaugă tone de dramă zilelor de testare altfel regulate.

În acest articol, vreau să abordez câțiva pași pe care un tester îi poate face atunci când se ocupă de ei.

Voi presupune că dragii noștri cititori înțeleg deja gravitatea și prioritatea defectelor. Aveți nevoie de o recapitulare rapidă? Verificați acest lucru.

Acum, înseamnă întotdeauna că trebuie să oprim complet testarea dacă întâmpinăm o problemă de blocare?

În unele cazuri, „Da”, dar poate că nu întotdeauna. Ar putea exista cazuri în care este posibilă o anumită activitate de testare.

Faceți față defectului blocant

imagine sursă

Mai jos sunt câteva situații pe care le-am trăit în cariera mea de tester. Cred cu tărie că pașii descriși mai jos (consolidați ulterior într-o diagramă) trebuie urmăriți pentru a simplifica acest proces.

Să sărim direct.

Pași pe care ar trebui să îi faceți atunci când întâlniți un defect de blocare

Pasul 1: Când întâlniți o problemă, investiți timp pentru a găsi cauza principală.

Cred cu tărie că, în calitate de tester, munca noastră nu se termină raportarea defectelor . Dacă timpul ne permite, ar trebui să explorăm ce ar fi putut cauza problema. Este posibil să nu putem întotdeauna să subliniem exact zona problemei, dar încercăm să depanăm cât mai mult posibil. Aceleași detalii pot fi actualizate în defect ca și comentarii suplimentare.

Am făcut acest lucru mult în proiectele mele, iar acest lucru a dus la o soluție rapidă. Beneficiile analizei cauzei radiculare sunteți:

  • Fiind o valoare adăugată, aceasta poate oferi cu siguranță o direcție mai bună dezvoltatorului pentru remedierea erorilor.
  • De asemenea, testerul QA poate recunoaște dacă această problemă este creată de sine (probleme de introducere a datelor sau de utilizare umană) și, dacă da, poate fi rezolvată chiar de tester. Atunci când astfel de erori sunt raportate dezvoltatorilor fără ca noi să verificăm de la finalul QA, acestea sunt considerat un non-issue și ar putea crea o reputație negativă pentru tester.

Deci, vă sugerăm să verificați întotdeauna la sfârșitul nostru înainte de a înregistra un defect.

Iată câteva exemple în timp real din proiectele mele care vor consolida punctele de mai sus:

Am lucrat la un proiect în care testarea noastră ar necesita ca să aruncăm un fișier într-o locație specificată. Redenumiți-l pentru a se potrivi cu numele din configurație. O lucrare programată ar prelua fișierul de date și ar încărca datele în sistem. După care, vom valida datele din baza de date și front-end.

c ++ cum se utilizează stringstream

Obișnuiam să întâmpinăm probleme în care s-ar executa lucrarea, dar datele nu se vor încărca și, la investigare, s-a întâmplat deoarece testerul nu a schimbat numele în timp ce a lăsat fișierul la locație.

Acesta a fost un blocaj pentru noi, dar nu ceva care a necesitat atenția dezvoltatorului. A trebuit să fim atenți la detalii și să evităm greșeli atât de mici.

Următoarele sunt câteva categorii comune, cauze principale și remedii:

# 1) Fișier gazdă Problema - Spuneți, fișierul gazdelor dvs. are parametri incorecți și care cauzează problema. În acest caz, puteți actualiza singur fișierul gazdă sau puteți solicita ajutor de la cineva cu acces pentru a actualiza și continua execuția testului.

Un defect pentru același lucru ar trebui ridicat, astfel încât dezvoltatorii să investigheze, dar cu soluția alternativă testarea funcțională poate fi continuată.

Notă: Verificați cu echipele de proiect dacă este în regulă ca echipa QA să facă aceste modificări înainte de a face acest lucru.

# 2) Configurare - Adesea, am observat probleme de configurare, cum ar fi faptul că nu indicăm mediul corect sau alte probleme de configurare, care blochează probleme. Și în astfel de cazuri, testerii pot face modificări și pot continua cu testarea.

cel mai bun spațiu de stocare în cloud pentru fișiere mari

Notă: Încă o dată, solicitați permisiunea înainte de a face acest lucru.

# 3) Emiterea codului - Dacă credeți că problema se datorează codului, nu se poate face nimic mult de către testeri. Înregistrați un defect de blocare și așteptați ca remedierea să continue cu testarea.

# 4) Problemă de implementare - Desfășurarea necorespunzătoare este o altă cauză comună a problemelor de blocare și acestea pot fi surprinse în timpul testului de sănătate. Și aici, testarea trebuie oprită imediat până când se primește o nouă versiune.

# 5) Mediu în jos - Dacă mediul nu funcționează, spuneți că baza de date nu se conectează la server sau adresa URL nu funcționează în cazul site-urilor web; testerii nu pot face prea multe în aceste cazuri decât să raporteze un defect și să aștepte ca sistemul să funcționeze.

Prin urmare, dacă există o soluție, utilizați-o pentru a continua testarea. Singura modalitate de a găsi, dacă această soluție există, este prin investigarea cauzei principale. Cel mai adesea ar putea exista o alternativă.

Pasul 2: Este foarte ușor să cădeți într-o buclă infinită atunci când investigați cauza principală. Deci, asigurați-vă că nu consumă toată ziua și niciun efort.

Iată câteva indicații:

  • Găsiți un echilibru și recunoașteți punctul de oprire când ajungeți acolo.
  • Experiența și expertiza unui tester sunt esențiale pentru un RCA de succes. Cu toate acestea, este o idee bună să implicați echipa și conducătorul echipei, atunci când este necesar.
  • Când simțiți că RCA consumă mult timp, raportați mai întâi problema imediat și oferiți cât mai multe informații. O captură de ecran este întotdeauna utilă.
  • Dacă este necesar, urmăriți. Trimiteți un e-mail managerului sau dezvoltatorului pentru a atrage atenția asupra problemei critice.
  • Continuați depanarea după avertizarea părților necesare.

Motivul pentru care defectele blocantului trebuie raportate imediat:

  • Conducerea ar trebui să fie conștientizată de toate perioadele de nefuncționare în cazul în care problema se întâmplă să fie un defect showstopper. Aceste informații trebuie transmise clientului și pot solicita, de asemenea, actualizări ale planului de proiect (cronologii QA), modificări ale livrabilelor etc.
  • Orice întârziere în livrabilele QA trebuie să fie susținută cu dovezi. Deci, este întotdeauna mai bine să comunicați cât mai curând posibil, în loc să așteptați până la sfârșitul zilei.

Pasul 3: Acum, trecând la ultimul pas, de când am terminat de analizat și comunicat problema, ce urmează?

  • Dacă problema blochează accesul la o zonă funcțională, verificați dacă aceasta are un impact asupra altor zone
  • Dacă aplicația front-end este oprită, verificați dacă testarea backend / middleware / bază de date poate fi continuată.
  • Dacă nu poate avea loc nicio activitate de execuție a testului, încercați să faceți acest lucru lucrați la unele documente legat de proiectul dumneavoastră.
  • Puteți încerca, de asemenea identifica domeniile pentru automatizare dacă repeti manual multă muncă. Automatizarea nu trebuie să utilizeze întotdeauna un instrument. Spuneți că generarea de rapoarte este o sarcină monotonă pentru dvs., acesta este un domeniu care poate fi automatizat prin macro-uri Excel simple și altele.
  • Petreceți timp știind despre instrumentele open source care pot fi implementate în proiectul dvs.
  • Nu în ultimul rând , lucrați spre inovație, mantra care conduce lumea în prezent!

In cele din urma , diagrama de flux care rezumă întreaga discuție!

Diagramă de flux: pași pentru gestionarea unui defect de blocare

defect de blocant

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

Ce pași luați când întâlniți orice defect de blocare?

Lectură recomandată

^