Cum scrii un bug report util: structură, limbaj și greșeli frecvente la juniori

Știi momentul acela când trimiți un bug în JIRA și după 10 minute primești un comentariu scurt de la developer: „Nu pot reproduce"? E frustrant pentru tine, e frustrant pentru ei, și între timp defectul stă acolo, nepreluat, blocând o funcționalitate. Vestea bună: nouă din zece astfel de situații se rezolvă înainte să apară, dacă bug report‑ul e scris corect de la bun început. Nu e vorba de talent. E vorba de structură, de obicei și de câteva greșeli pe care le fac aproape toți juniorii la început — inclusiv eu, când am dat primele mele bug‑uri într‑un proiect de retail. **Ce este, de fapt, un bug report util?** Un bug report util nu e o transcriere a panicii tale din momentul în care ai văzut ceva neașteptat pe ecran. Este un document tehnic scurt, clar și complet, care permite oricui — developer, QA lead, product owner — să înțeleagă CE s‑a întâmplat, CUM se reproduce și DE CE contează. Gândește‑te la el ca la un GPS: dacă dai o destinație vagă, șoferul ajunge în alt cartier. Dacă dai coordonate exacte, ajunge fix în fața ușii. Elementele esențiale sunt întotdeauna aceleași, indiferent dacă lucrezi în JIRA, Azure DevOps, TestRail sau chiar într‑un Google Sheet improvizat: - **Titlu** — concis și descriptiv - **Mediu** — browser, OS, versiune aplicație, date de test relevante - **Pași de reproducere** — numerotați, fără ambiguități - **Rezultat actual** — ce se întâmplă în realitate - **Rezultat așteptat** — ce ar trebui să se întâmple conform specificațiilor - **Severitate și prioritate** — două câmpuri diferite, nu unul singur - **Dovezi** — screenshot, video, log, query MySQL dacă e cazul **Titlul: primul lucru citit, primul lucru greșit** Cei mai mulți juniori scriu titluri de genul: „Bug la login" sau „Nu merge butonul". Aceste titluri nu spun nimic. Într‑un proiect cu 200 de bug‑uri active în JIRA, nimeni nu va ști despre ce e vorba fără să deschidă ticket‑ul. Un titlu bun urmează formula: **[Componentă] + [Acțiune] + [Efect observat]**. Câteva exemple concrete: - ❌ „Eroare la plată" - ✅ „[Checkout] Plata cu cardul eșuează cu eroare 500 când suma depășește 9.999 RON" - ❌ „Filtrul nu funcționează" - ✅ „[Catalog produse] Filtrul de preț nu returnează rezultate când limita minimă = limita maximă" Titlul bun economisește timp tuturor. E primul gest de respect față de echipa cu care lucrezi. **Pașii de reproducere: claritate chirurgicală** Acesta e corpul bug report‑ului. Greșeala clasică? Pași prea generali sau sărind peste condiții prealabile esențiale (preconditions). Înainte de pasul 1, specifică întotdeauna: ce cont folosești (rol, permisiuni), ce date există deja în sistem, ce browser și ce versiune. Dacă defectul apare doar cu un user de tip „admin" pe Chrome 124, pe Windows 11, cu un produs care are stoc 0 — spune exact asta. Un developer care testează cu un user standard pe Firefox nu va vedea niciodată problema. Pașii trebuie să fie numerotați și atomici — un singur lucru per pas: 1. Autentifică-te cu userul `admin_test@company.ro` (parolă: vezi 1Password > QA Credentials) 2. Navighează la Catalog > Produse 3. Selectează produsul „Televizor OLED 55"" (ID: 4872, stoc: 0) 4. Apasă butonul „Adaugă în coș" 5. Observă mesajul afișat în colțul dreapta‑sus Rezultat actual: Mesajul „Produs adăugat cu succes" apare, deși stocul este 0 și produsul nu poate fi livrat. Rezultat așteptat: Butonul „Adaugă în coș" să fie dezactivat sau să afișeze mesajul „Stoc epuizat". Vezi diferența? Un developer poate urmări acești pași exact, pas cu pas, fără să te întrebe nimic suplimentar. **Severitate vs. Prioritate: confuzia care irită orice lead** Acesta e probabil cel mai frecvent punct de confuzie la juniori, și apare în orice echipă — de la startup până la corporație bancară sau automotive. **Severitatea** descrie impactul tehnic al defectului: cât de mult strică el funcționalitatea sistemului. **Prioritatea** descrie urgența cu care trebuie rezolvat: cât de repede are nevoie business‑ul de fix. Un bug poate fi sever dar cu prioritate mică (ex: crash al unui modul intern folosit de 2 persoane din backoffice, o dată pe lună). Sau poate fi de severitate mică dar cu prioritate mare (ex: o greșeală de ortografie în titlul paginii principale, vizibilă de 50.000 de utilizatori pe zi — rușine mare, risc reputațional real). Clasificarea standard pe care o vei întâlni în majoritatea echipelor: - **Blocker** — sistemul nu poate fi folosit deloc - **Critical** — funcționalitate majoră nefuncțională, fără workaround - **Major** — funcționalitate afectată semnificativ, workaround posibil - **Minor** — impact redus, cosmetic sau edge case - **Trivial** — greșeli de UI, texte, alinieri minore Și da, setarea greșită a severității e un bug în bug report‑ul tău. 😊 **Dovezile: screenshot‑ul nu este de ajuns** Un screenshot e bun. Un video e mai bun. Un log de consolă sau un request/response din Chrome DevTools e adesea cel mai valoros dintre toate. Dacă lucrezi pe un proiect cu backend expus, adaugă întotdeauna: - Request‑ul HTTP (metodă, endpoint, body) — capturat din DevTools > Network sau Postman - Response‑ul primit (status code, body, mesaj de eroare) - Dacă ai acces la bază de date, un query MySQL care arată starea datelor înainte și după acțiunea care produce bug‑ul Aceste dovezi transformă un bug report dintr‑un „eu zic că e greșit" într‑un „iată dovada tehnică". Nimeni nu poate contesta un 500 Internal Server Error capturat în Postman. **Greșeli frecvente la juniori — checklist rapid** Înainte să dai Submit în JIRA, trece prin această listă: - Am scris un titlu specific, nu generic? - Am menționat mediul complet (browser, OS, versiune app)? - Am specificat precondițiile — ce date existau, ce user foloseam? - Pașii mei sunt numerotați și fiecare face un singur lucru? - Am separat „rezultat actual" de „rezultat așteptat"? - Am atașat dovezi (screenshot, video, log, request/response)? - Am setat severitatea și prioritatea corect și separat? - Am verificat că nu există deja un bug duplicat deschis? Dacă răspunsul la toate e „da", dai Submit cu încredere. **Un bug report bun este o formă de comunicare** La A4Q Summit și DevTalks, subiectul comunicării în echipele de QA revine constant: testerii care avansează rapid nu sunt neapărat cei care găsesc cele mai multe bug‑uri, ci cei care le comunică cel mai clar. Un bug report bine scris îți construiește reputația în echipă mai repede decât orice altceva. Pune‑te în papucii developerului care primește raportul tău la ora 17:45, cu o oră înainte de release. Ce ai vrea tu să găsești acolo? --- Vrei să exersezi scrierea de bug reports în contexte reale — proiecte bancare, retail, energie, ospitalitate — și să primești feedback direct de la traineri cu experiență în industrie? 🚀 Explorează cursurile noastre de pe **academiatestarii.ro** și fă primul pas concret spre cariera ta în QA. Avem programe hands‑on pentru juniori, pregătire pentru certificarea ISTQB și o comunitate de peste o mie de cursanți care au trecut exact prin unde ești tu acum. **Abia așteptăm să te vedem în echipă. ⬇** 👉 [academiatestarii.ro](https://academiatestarii.ro) #DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestareSoftware #QualityAssurance