Meniu

Arta de raportare a erorilor: Cum să comercializați și să vă remediați erorile?

art bug reporting

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

De ce este nevoie de comercializarea unui bug?

Primele lucruri care îmi vin în minte când încep să scriu acest articol sunt cuvintele lui Cem Kaner - „Cel mai bun tester nu este cel care găsește cele mai multe bug-uri sau care jenează majoritatea programatorilor. Cel mai bun tester este cel care rezolvă cele mai multe bug-uri. ”

Acum - Care este diferența dintre găsirea celor mai multe bug-uri și rezolvarea majorității erorilor ?

Nu este evident că orice eroare s-a conectat într-un sistem de gestionare a erorilor ar trebui să fie reparat de către dezvoltator? Răspunsul este nu. Factori precum timpul de comercializare a produsului, timpul de finalizare a proiectului în timp și dezvoltatorii care lucrează programele stricte impracticabile etc. obligă companiile să lanseze produsul cu câteva erori care nu vor afecta în mare măsură utilizatorii.

Raportarea erorilor art

(imagine sursă )

Cine oferă încrederea conducerii, afirmând că erorile prezente în produs nu vor avea impact asupra încrederii, fiabilității și interesului clienților părților interesate? - Inginerul de testare sau echipa de testare - este datoria fiecărui inginer de testare să remedieze erorile care ar putea avea un impact negativ asupra calității produsului.

Prioritatea bug-ului , în opinia mea, depinde în mare măsură de modul în care o problemă este prezentată de tester echipelor de dezvoltare și management.

Gândiți-vă la asta cum ar fi publicitatea sau marketingul problemei - aceasta implică 2 pași:

  1. Scrie sau raportați corect erorile
  2. Aflați totul despre eroare, astfel încât orice detalii suplimentare pot fi explicate mai bine

Ce veți învăța:

Arta raportării erorilor

Da, raportarea erorilor este o artă . Modul în care este scris un bug arată abilitățile tehnice, expertiza domeniului și capacitățile de comunicare ale unui inginer de testare.

De obicei, o eroare ar trebui să conțină următoarele informații:

  • Rezumatul erorilor
  • pasi pentru reproducere
  • Atașamente (Instantaneu, fișiere jurnal etc.)
  • Reproductibilitatea erorilor
  • Severitatea bug-ului
  • Versiune software, informații despre mediu
  • Alte informații bazate pe cerințele organizaționale.

O notă importantă: Căutați întotdeauna mai adânc pentru a găsi cauza principală a problemei și raportați-o. De exemplu, o simplă eroare de conectare cu combinația corectă de nume de utilizator și parolă poate fi legată de diverse motive, cum ar fi:

  1. Datele de autentificare nu sunt validate deloc
  2. Probleme de expirare a rețelei în cazul conectărilor la distanță
  3. Sistemul poate considera toate CAPS ca fiind non-CAPS.

Deci, ca Tester, ar trebui să puteți descifra diferențele în timp ce urmați declarațiile rezumative ale erorilor:

  • „Imposibil de conectat cu numele de utilizator și parola corecte”
  • „Imposibil de conectat cu numele de utilizator și parola corecte, atunci când numele de utilizator sau parola conține o combinație de alfabete CAPS și non-CAPS.”

Aceasta din urmă este o descriere foarte clară a problemei și nu este ambiguă. Cu aceasta, nu numai că vă creșteți credibilitatea ca tester, dar raportați și problema reală în locul unui simptom.

Acum, să aruncăm o privire la fiecare câmp implicat într-un raport de erori și să discutăm aspectele importante ale fiecăruia:

# 1. Rezumatul erorilor

Un rezumat al erorilor ar trebui să ofere un instantaneu rapid asupra a ceea ce este exact problema. Trebuie să fie precis și bine direcționat.

Exemplu :

În afară de teorie, voi încerca să explic cu exemple.

Să presupunem un modul de conectare simplu. Să presupunem că noul utilizator care vizitează un site web nu se poate conecta cu parola sa implicită. Când am prezentat același scenariu multor studenți pe care i-am instruit în faza inițială a instruirii, au existat mai multe răspunsuri ca rezumat al erorilor. Mai jos sunt câteva exemple de cum arăta rezumatul:

qa întrebări și răspunsuri la interviu pdf

' Utilizatorul nou nu se poate autentifica ”

„Conectarea utilizatorului nu funcționează conform așteptărilor”

„Utilizatorul nu se poate conecta cu parola corectă”

rezumatul erorilor greșit și corect

Din exemplele de mai sus, puteți alege o afirmație care descrie de fapt problema? Nu cred. Rezumatul trebuie să ofere întotdeauna informații complete despre scenariul care nu reușește.

Luați în considerare următoarea afirmație:

„Utilizatorul nou nu se poate conecta cu parola implicită furnizată prin e-mail sau SMS”

După cum puteți vedea, din declarația de mai sus, un dezvoltator poate înțelege clar care este problema și unde este problema.

Deci, încercați să găsiți cuvintele potrivite pentru a descrie rezumatul care ar oferi informațiile direct. Afirmațiile generice precum „nu funcționează corect”, „nu funcționează conform așteptărilor” etc., trebuie evitate.

# 2. Pași de reproducere și atașamente

Bug-urile nereproductibile ocupă întotdeauna locul din spate, chiar dacă pot fi semnificative. Prin urmare, aveți grijă să scrieți pașii corect și descriptiv.

Pașii trebuie să fie exacți și exact aceiași cu cei care au condus la problemă. Pentru erorile legate de funcționalitate, următorul exemplu este cel mai bun exemplu.

Exemplu :

Luați în considerare aceeași problemă menționată în secțiunea anterioară.

  1. Creați un utilizator nou folosind opțiunea Înscriere din pagina principală. (Exemplu de nume de utilizator: HelloUser)
  2. Se va primi un e-mail și un SMS cu o parolă implicită. ID-ul de e-mail și numărul de telefon mobil pentru SMS sunt furnizate la crearea utilizatorului la Pasul # 1. (Exemplu de e-mail: HelloUser@hello.com , Eșantion de număr de telefon mobil: 444-222-1123)
  3. Selectați opțiunea Login în pagina de pornire.
  4. În câmpul de text pentru numele de utilizator, furnizați exemplul de nume de utilizator furnizat la pasul # 1.
  5. În câmpul parolă, furnizați parola implicită primită printr-un e-mail sau SMS.
  6. Faceți clic pe butonul Conectare
  7. Rezultat asteptat: Utilizatorul ar trebui să se poată autentifica cu numele de utilizator și parola furnizate și să navigheze la pagina Contului de utilizator.
  8. Rezultat actual: Se afișează mesajul „Nume utilizator / Parolă nevalid”.

pașii raportului de defecte

Dacă oricare dintre informații nu este furnizată în eșantionul de mai sus, atunci va fi rezultă în lacune de comunicare iar dezvoltatorul nu va putea reproduce problema. Pașii trebuie să fie specifici și detaliați cu datele eșantion pe care le utilizați în timpul testării.

Dacă este posibil sau ori de câte ori este cazul, furnizați un instantaneu a ceea ce vedeți exact pe ecran. În acest fel, nu numai că va oferi dezvoltatorilor o bună vizualizare a problemei, ci și o dovadă a rezultatului testului.

nefuncțional cazurile de testare, cum ar fi stresul, stabilitatea sau cazurile de testare a performanței, pe lângă detaliile de mai sus, informații despre scenariul care provoacă stresul sistemului pot fi raportate așa cum este. În plus, există puține sisteme care raportează jurnalele pentru fiecare operație care este efectuată. Jurnalele sunt de obicei instrucțiuni de tipărire furnizate de dezvoltatori în codul lor. Ori de câte ori se execută un modul, jurnalele corespunzătoare vor fi tipărite sau afișate. Când jurnalele sunt disponibile, acest lucru ar ajuta dezvoltatorii într-o mare măsură să reproducă problema.

# 3. Reproductibilitatea erorilor

O problemă mare sau mică va avea prioritate pe baza reproductibilității. Poate fi văzut întotdeauna, uneori, rar sau chiar o singură dată. O problemă care este reprodusă ca „întotdeauna” va avea prioritate mai mare decât restul.

nu pot reproduce un defect

Deci, este de datoria unui inginer de testare să urmărească scenariul exact pentru problema care este întotdeauna reprodusă. Uneori ar putea exista puține probleme scăpate de sub controlul unui inginer de testare, care ar duce la reproducerea unei probleme doar de câteva ori, dar la mai multe încercări. În astfel de cazuri, menționați întotdeauna numărul de procese, un anumit scenariu este executat împreună cu numărul de ocazii cu care problema este văzută în timpul acelor procese.

Acest lucru, la rândul său, ar adăuga credibilitate raportului de erori menționat de dvs. Din nou, acest lucru vă va îmbunătăți reputația de tester. Vă spun mai târziu motivele pentru care aveți o bună reputație.

# 4. Severitatea bug-ului

Severitatea este, fără îndoială, unul dintre cei mai mari influențatori pentru prioritizarea bug-ului.

Următoarele sunt diferitele categorii de severitate. Vă rugăm să rețineți că acestea sunt doar mostre generale și variază de la o companie la alta.

  1. Severitate 1 - Show Stopper - pentru erori catastrofale, fără a fi remediate, utilizatorul nu va putea continua să utilizeze software-ul și nu există nicio soluție posibilă
  2. Severity 2 - High - pentru erori similare cu Severity 1, dar există o soluție
  3. Severitatea 3 - Mediu
  4. Severitate 4 - Scăzută
  5. Severitatea 5 - Trivial.

De exemplu, să comparăm două probleme similare.

În set-top box-urile noastre, puțini furnizori de servicii furnizează informațiile privind frecvența serviciului așa cum sunt reglate în prezent. Să presupunem că frecvența este afișată ca 100 MHz în loc de 100,20 MHz. Acest lucru nu poate afecta vizualizarea de către utilizator a serviciilor, dar poate avea un impact în ceea ce privește diagnosticarea monitorizării set-topurilor. Prin urmare, acest lucru poate fi prezentat ca un număr de severitate 3.

Presupunând o problemă similară în domeniul bancar: dacă soldul contului dvs. este afișat ca $ 100, în loc de $ 100.20, imaginați-vă impactul problemei. Acesta trebuie să fie un defect de severitate -1. După cum puteți vedea în ambele cazuri, problema este foarte similară cu faptul că interfața de utilizare nu afișează cifrele după punctul zecimal. Dar impactul variază în funcție de domeniul implicat.

Participare eficientă la întâlnirile de control al versiunii software

De obicei, fiecare organizație are propriul său proces de investigare și prioritizare a erorilor. În general, o întâlnire ar avea loc la intervale specifice în timpul proiectului pentru a discuta erorile și a le acorda prioritate.

Procesul în timpul acestor întâlniri este după cum urmează:

  1. Solicitați lista de erori din sistemul de gestionare a erorilor în funcție de severitate.
  2. Uitați-vă la rezumat și discutați impactul erorii asupra experienței utilizatorului asupra utilizării unui produs software.
  3. Pe baza evaluării riscului și a impactului, setați prioritatea și atribuiți bug-ul unui dezvoltator adecvat pentru remedierea acestuia.

În timpul pasului 2, este imperativ ca fiecare inginer de testare să susțină impactul bug-ului asupra experienței utilizatorului dacă bug-ul nu primește prioritatea pe care o merită. La urma urmei, testăm inginerii care consideră punctul de vedere al unui utilizator să scrie cazuri de testare și să testeze produsul.

Luați în considerare exemplul de mai sus, problema de a nu afișa cifrele după virgulă într-un domeniu bancar. Pentru un dezvoltator, poate părea o problemă mai puțin severă. S-ar putea să susțină că, în loc să declare variabila ca număr întreg, ar declara asta ca punct flotant pentru a rezolva problema și, prin urmare, mai puțin severă.

Dar, în calitate de tester, rolul dvs. este să explicați situația clientului. Punctul dvs. ar trebui să fie modul în care utilizatorul s-ar plânge în acest scenariu. Testatorul ar trebui să spună că acest lucru va provoca panică în rândul utilizatorilor, deoarece clientul își pierde banii în cenți.

Impactul de a nu comercializa corect un bug

Dacă un bug nu este comercializat corect, va crea probleme precum:

  • Prioritate incorectă a defectului
  • Întârziere în soluționarea problemelor importante
  • Eliberarea produsului cu defecte grave
  • Feedback negativ al clienților
  • Devalorizarea valorii mărcii

Impactul de a nu comercializa corect un bug

În afară de toate motivele menționate mai sus, este foarte important să vă construiți reputația de inginer de testare . Este mai mult ca și cum ai dezvolta o valoare a mărcii pentru propria persoană.

În faza inițială a carierei, dacă vă puteți păstra numărul de „Nu se poate reproduce” sau „Aveți nevoie de mai multe informații” sau „Nu este o eroare validă” sau modificări de severitate cât mai reduse posibil, într-o etapă erorile dvs. nu vor fi examinate la toate și ar fi atribuite direct dezvoltatorului corespunzător pentru a fi reparat.

Pentru a dezvolta o astfel de valoare a mărcii și pentru a câștiga încrederea echipei dvs. și a echipelor de dezvoltare / management, trebuie să dezvoltați anumite abilități tehnice în ceea ce privește testarea cunoștințelor, domeniului și abilităților de comunicare.

Concluzie

Orice produs sau serviciu mare sau mic este întotdeauna obligat să eșueze fără publicitate adecvată. Odată ce un brand este stabilit, orice produs mic poate fi un mare succes pentru public.

Acestea fiind spuse, excesul de publicitate al unui produs poate provoca, de asemenea, daune reputației.

Deci, un bug trebuie întotdeauna scris într-un mod clar, concis și precis, astfel încât să ofere o locație exactă a bug-ului în harta software extinsă / exhaustivă. Reiterez că acest lucru nu numai că îmbunătățește calitatea software-ului, ci și reduce în mare măsură costul testării și dezvoltării software-ului.

Nu este prea târziu acum! Să mergem mai departe și să reparăm imediat erorile!

implementarea arborelui binar c ++

Lectură recomandată

^