Kako napisati dobar bug report koji tim može odmah da koristi

Bug report nije opis frustracije. Bug report nije dnevnik rada. Bug report nije mesto gde dokazujemo da smo u pravu. Bug report je operativni dokument.

Tim ga čita. Tim ga koristi. Tim na osnovu njega odlučuje šta radi sledeće. Ako report zahteva dodatna pitanja, report nije završio posao.

Ako developer ne može da reprodukuje problem, report nije završio posao. Ako ne znamo koliko je problem opasan, report nije završio posao.

Dobar bug report smanjuje vreme do popravke. Loš bug report stvara šum, usporava tim i povećava rizik da bug ostane u produkciji.

Šta "dobar" znači u praksi

Dobar bug report daje četiri stvari, u ovom redosledu:

1. Kontekst, gde se problem dešava i u kojim uslovima.
2. Reprodukciju, kako tačno ponoviti problem.
3. Očekivanje i realnost, šta je trebalo da se desi i šta se desilo.
4. Uticaj, zašto je problem bitan, koga pogađa, koliki je rizik.

Sve ostalo je dodatna vrednost, ali ove četiri tačke su osnova.

Najčešće greške koje prave iskusni ljudi

Iskustvo nosi brzinu, a brzina često preskoči preciznost. Ovo su klasične greške koje viđamo u timovima sa ozbiljnim iskustvom.

1. Previše implicitnih pretpostavki

Autor zna sistem, pa pretpostavi da i drugi znaju. Napiše: "Ne radi export." Ne kaže koji export, koji format, koja stranica, koji korisnik, koji filteri.

2. Reprodukcija bez determinističkih koraka

Autor piše: "Ponekad se desi." To je početak, nije kraj. Ako je bug nedeterminističan, report mora da sadrži uslove i signal, šta povećava verovatnoću pojave, šta je primećeno, kakav obrazac.

3. Mešanje simptoma i uzroka

Autor sugeriše uzrok bez dokaza. Napiše: "Cache ne osvežava." Možda. Ali report treba da kaže šta se vidi. Neosvežen prikaz, pogrešni podaci, neuspešan poziv, stale state.

4. Nema uticaja

Report bez uticaja deluje kao "još jedan bug". U realnosti, bugovi se rangiraju po riziku, a ne po emociji. Ako report ne pokaže rizik, tim bira nasumično.

5. Nema artefakata

Bez screenshot-a, video snimka, network log-a, console log-a, request id-a, bug report je često "priča". A tim ne popravlja priče. Tim popravlja dokazive probleme.

Kako strukturisati bug report koji tim može odmah da koristi

1. Naslov koji nosi dijagnozu, a ne temu

Loš naslov: "Problem na checkout-u" Bolji naslov: "Checkout, PayPal, klik na Pay now vraća 500 i narudžbina se ne kreira"

Dobar naslov mora da sadrži:

• gde, modul ili ekran
• šta, konkretan simptom
• kada ili u kojim uslovima, ako je bitno
• posledicu, ako je ozbiljna

Naslov treba da omogući trijažu bez otvaranja tiketa.

2. Okruženje, precizno i relevantno

Okruženje nije lista svega što znamo. Okruženje je ono što pomaže reprodukciji.

Minimalno:

• env: prod, staging, dev
• build ili verzija aplikacije
• browser i verzija, ili device model i OS verzija
• korisnički nalog ili tip role, admin, buyer, guest
• region ili tenant, ako postoji multi-tenant ili geo varijante
• mrežni uslovi, VPN, proxy, offline, spor internet, ako utiče

Ako problem zavisi od feature flag-a, eksperimenta, A/B testa, obavezno navesti.

3. Preconditions, stanje sistema pre koraka

Napredni timovi gube sate zato što precondition nije naveden.

Primer precondition-a:

• korisnik je već ulogovan
• u korpi postoji bar jedan proizvod sa popustom
• korisnik ima neplaćenu fakturu
• u sistemu postoji entitet X sa statusom Y
• token je istekao, ili session traje duže od 30 min

Ako precondition zahteva pripremu podataka, uključiti kako kreirati podatke, ili priložiti test data, id-jeve, linkove.

4. Steps to reproduce, strogo deterministički

Koraci treba da budu kratki, numerisani, jednoznačni. Bez interpretacije. Bez "idi na". Umesto toga, konkretno.

Loše: "Otvori profil i promeni sliku." Bolje:

1. Login kao user buyer1
2. Otvori Settings, Profile
3. Klikni Upload avatar
4. Izaberi fajl avatar.png veličine 6.2 MB
5. Klikni Save

Ako je bug vezan za timing, navesti čekanje.

Ako je bug vezan za paralelne akcije, navesti redosled.

Ako je bug vezan za više tabova, navesti tabove.

Za flaky scenarije dodati:

• učestalost, npr. 3 od 10 pokušaja
• šta povećava šansu, npr. posle refresh-a, posle idle 30 sekundi, posle 3 uzastopna klika
• šta smanjuje šansu

5. Actual result, činjenično i merljivo

Actual result opisuje ono što vidimo.

• tačna poruka greške
• status kod, 500, 403, 422
• koji element je u pogrešnom stanju
• šta se desilo sa podacima, da li je entitet kreiran ili ne
• da li je UI zamrznut, da li se spinner ne gasi

Koristimo copy paste za poruke greške. Ne prepričavamo.

Ako ima console error, navodimo relevantnu liniju.

Ako ima network call, navodimo endpoint, response, request id.

6. Expected result, poslovno, ne tehnički

Expected result ne treba da bude "ne sme da pukne". Treba da bude jasno ponašanje.

• narudžbina se kreira i dobija status Paid
• korisnik dobija potvrdu i email
• UI prikazuje novi avatar i čuva ga na profilu

Ako postoji spec, dizajn ili user story, linkujemo.

7. Severity i priority, uz obrazloženje

Severity opisuje štetu. Priority opisuje redosled popravke u planu.

Mnogi timovi mešaju ova dva. Dobar report ih odvaja.

Primer severity:

• Blocker: nema workaround-a, ključni tok ne radi, gubitak prihoda
• Critical: data loss, sigurnosni rizik, plaćanje pogrešno
• Major: glavna funkcionalnost degradirana, postoji workaround
• Minor: kozmetika, mala nepravilnost bez većeg uticaja

Uz severity ide kratko obrazloženje.

Primer: Critical, jer korisnik dobija potvrdu o plaćanju, ali narudžbina ne postoji, rizik chargeback-a i reputacije.

8. Impact, konkretno i poslovno

Ovo je deo gde QA postaje strateški.

• ko je pogođen, svi korisnici, samo admini, samo EU region
• koliko često, svaki put, ponekad, samo pod opterećenjem
• šta je posledica, gubitak narudžbina, pogrešan obračun, pad konverzije
• da li postoji workaround, i koliko je skup

Bez uticaja, trijaža je slepa.

9. Attachments i evidencija

Dobar report ima dokaz.

• screenshot sa označenim delom
• video snimak, 20 do 40 sekundi, dovoljno da pokaže tok i grešku
• HAR fajl ili network export, kada je relevantno
• console log
• backend log reference, request id, correlation id
• test data, user, order id, invoice id
• vreme pojave sa timezone, da bi se logovi našli

Ako radimo u sistemu gde backend tim traži request id, report bez request id-a je polu report.

10. Suspected area, ali sa disciplinom

Napredni tester često prepozna gde je problem. To je korisno, ali mora biti jasno označeno kao hipoteza.

"Hipoteza: problem u validaciji payload-a na endpointu /checkout/confirm, jer response vraća 422 sa poljem discountCode."

Ne pišemo "sigurno je backend". Pišemo šta smo videli.

11. Scope i regresija, kako proveriti fix

Najbolji bug report pomaže i nakon popravke.

• minimalni scenario za verifikaciju
• negativni scenario, šta ne sme da se pokvari
• regresioni rizik, koje srodne funkcije proveriti

Time pomažemo timu da zatvori tiket brže, i bez ponovnog otvaranja.

Kako pisati za brzu trijažu

Kada tim ima desetine tiketa, trijaža ide brzo. U tom režimu report mora da bude skenabilan.

Pravilo za profesionalce:

• Svaka ključna informacija mora da se vidi za 15 sekundi.
• Naslov. Severity. Okruženje. Reprodukcija. Actual versus expected. Impact.
• Ako to ne može, report je predug, ili loše strukturisan.

Kako pristupiti nedeterminističnim bugovima

Flaky bugovi su najskuplji. Dobar report pravi razliku između dana i nedelje.

U report dodajemo:

• frekvenciju, npr. 30 posto pokušaja
• vremenski obrazac, npr. posle 25 do 35 sekundi idle
• korelaciju, npr. kada pop up overlay prikrije UI, ili kada token istekne
• poslednji uspešan korak, gde se tok prekida
• dodatne signale, console error, network retries, timeouts
• minimalni repro, skraćen tok koji i dalje izaziva bug

Ako ne možemo da dobijemo determinističnu reprodukciju, report mora da bude istraživački, sa dokazima i hipotezama, a ne "nešto se desilo".

Template za kopiranje:

BUG REPORT

Title:
[Module/Page] [Action] [Symptom] [Outcome]
Primer: Checkout, Credit card, klik na Pay vrati 500, narudžbina se ne kreira

Environment:
Env: (prod, staging, dev)
Build/Version:
Browser/Device:
OS:
User/Role:
Tenant/Region:
Feature flags/Experiments:
Network conditions: (normal, VPN, throttled)

Preconditions:
1.
2.
3.

Steps to reproduce:
1.
2.
3.
4.
5.

Actual result:
Opis:
Error message:
Status code:
Console error:
Network call: (endpoint, response)
Request ID / Correlation ID:

Expected result:
Opis očekivanog ponašanja:
Spec link / Story link:

Severity: (Blocker, Critical, Major, Minor)
Justification:

Priority: (P0, P1, P2, P3)
Justification:

Impact:
Affected users:
Frequency: (every time, intermittent, x/10)
Business impact:
Workaround: (yes/no, steps, cost)

Evidence / Attachments:
Screenshot:
Video:
HAR/Logs:
Test data: (user, ids, links)

Notes / Hypothesis:
Hipoteza, gde bi problem mogao biti, uz kratko objašnjenje zasnovano na dokazima.

Regression checks after fix:

1. Minimal verifikacija
2. Negativni scenario
3. Srodne funkcionalnosti za proveru