Grešku ili nedoslednost u funkcionisanju softverskog sistema ili samog računara nazivamo bug. Naravno i definicija bug-a zavisi od projekta, veličine tima, metodologije i još po nečega… Dobar bug report može varirati od proste rečenice preko stola, do formalnog dokumenta overenog pečatom ovlašćene osobe ili tima. Ako govorimo o najčešćem slučaju, tzv. LOB (line of business) aplikacijama, koje nisu life critical i nekoj vrsti agilnog tima koji ima jednocifren broj ljudi. Često, pored članova tima koji su zaduženi za Q/A i testiranje i drugih tehnički potkovanih članova tima, bug-ove prijavljuju i ostali beta korisnici različitog nivoa poznavanja proizvoda i tehničkog znanja. Jasno je da u ovakvom okruženju nije lako naći balans između dovoljno detalja, a ipak ne previše birokratskog pristupa prijavljivanju grešaka, nedostajućih funkcionalnosti, nedoslednosti i čega već sve može biti u softveru. Da pokušamo da dođemo do toga koje bi informacije bug report trebalo da prenese da bi smanjio frustraciju obe strane koliko je to moguće.

 

Problem

Prvi izazov je sama definicija, da li nešto jeste ili nije bug. Da pokušamo da formalizujemo opis iz uvoda.

Svako ponašanje sistema koje odstupa od specifikacije, odnosno očekivanog ponašanja od strane korisnika, ukoliko specifikacija nije formalizovana nazivamo bug, ili software bug.

Zaključujemo da je odluka da li je nešto bug ili dodatni zahtev vrlo subjektivna stvar, jer ni nema projekta sa 100% preciznom specifikacijom, a mnogi i nemaju pisanu dokumentaciju u nekoj formalnoj formi.

U slučaju greške u kucanju, lako ćemo se složiti da je u pitanju greška, tj. bug, ipak u mnogim drugim slučajevima priča je kompleksnija. Sporenja po ovom pitanju su ušla u legendu, kao čuveno: “It’s not a bug, it’s a feature.

Imam nekoliko predloga koji mogu da pomognu, pa da krenemo.

It's not a bug, it's a feature

Mi smo na istoj strani

I oni koji prijavljuju bug i oni koja ga rešavaju su na istoj strani, razvijaju isti proizvod zajedno! Očigledno, međutim u praksi lako dolazi do toga da razvojni i Q/A tim postanu ljuti protivnici. Na početku karijere sam čuo za tim gde su testeri imali nadimak Sharks, verovatno asocijacija da znaju da namirišu krv mladih programera. Ne bih preporučio ovakve šale, meni ne prijaju ni u jednoj ulozi.

Dakle, vi ste tester, kao i programeri i ostali članovi tima, učestvujete u razvoju softvera. Programeri su malo čudni, nekad možda i čudno mirišu, ali oni su nezaobilazni deo razvoja softvera 🤷‍♂️, u zajedničkom interesu je da sarađujete. Ako niste profesionalni tester a prijavili ste bug, znači da vam je stalo do proizvoda, važi isto. Ukoliko vam nije stalo do proizvoda, nemojte se praviti pametni, paljba odavde i iz bug tracker-a!

Sa druge strane, često se dešava da se prijavljen bug ne može ponoviti na developerskom okruženju, kao da ga i nema. Programeri, inženjeri i ostali razvijači, imajte na umu da kada se korisnik žali, pa se još neko potrudi i da prijavi bug, tu nečega ima 99.97%, moguće da to nije vaša greška, moguće da čak i nije greška u vašem proizvodu, ali nečega ima. Ne mogu da se setim prijavljenih bug-ova za koje se ispostavilo da nije bilo baš ničega o čemu bi trebalo razmisliti. Svaki prijavljen bug je informacija od korisnika, vredna informacija, koju tako treba i tretirati. Hvala na informaciji, hvala što nam pomažete da unapredimo naš proizvod. Potrebno nam je još informacije je u redu, ali pošto kažete hvala! Kažite hvala don’t be ‘that guy’!

Pa šta to čini dobar bug report?

Da li je to uopšte bug?

Nekada je bitno, vama možda ne, ali ipak razmislite. Možda razvojnom timu to da li nešto čekirate kao bug ili novi zahtev utiče na bonus, platu, ribanje kod šefa, šta ja znam šta sve neće izmisliti. Ako i ne utiče na zaradu direktno može da takne nečiji ego, e to je čudna zverka. Nemojte da čekirate crvenom tek onako, razmislite, konsultujte se sa nekim. 

Kojim kanal koristite za prijavu?

Naišli ste na bug i zovete šefa razvoja ili pišete na general kanalu koroporativnog slack-a? Razmislite još jednom, najverovatnije postoji bug tracker, nekada je bolje konsultujovati se sa nekim pre nego što popunite bug report.

Da li se to ponašanje sistema koje ste opisali da ponoviti?

Ovo je ključno pitanje, što je razvojnom timu lakše da ponovi problem, to je manja frustracija.

Ovo nisu bug report-i:

  • “Desilo mi se sinoć da nešto nije htelo, ali danas radi.”
  • “Sistem je pao.”
  • “Nešto neće.”

Jako je bitno da razvijni tim ima neke osnovne informacije kako bi mogao ponoviti problem. Nekoliko stvari je karakteristično:

  1. Koja aplikacija/verzija je u pitanju? Dešava se da različite aplikacije imaju sličan ili isti UI, tipa web i mobile, ukoliko pošaljete samo deo screenshot-a moguće je da na osnovu njega neće biti najjasnije o kojoj se aplikacji radi. Ako znate i verziju, bonus poeni su vaši!
  2. Okruženje?
    Ukoliko postoji više okruženja, tipa razvojno, produkciono i šta ste već izmislili, to je bitna informacija. Pod okruženjem može da se podrazumeva i klijentsko okruženje, znači npr. development build 0.42 na windows 10 64-bit javlja tu i tu grešku pri startovanju je dobar bug report. Čest primer je “mobilna aplikacija ne radi”, naravno ja probam na androidu, jer koristim android telefon, međutim ako je prijava problema iz US 90% je u pitanju problem na iOS sistemu. Često ovi problemi mogu biti rešeni jednostavnim screenshot-om celog ekrana, kako bi programer mogao da vidi koji je OS, browser, možda i vremenska zona, izabrani jezik u pitanju. Programeri vole velike monitore, ne seckajte screenshot-e nema potrebe.
  3. Koji korisnik je logovan?
    Koji korisnik je bio logovan na sistem, sa kojim pravima?
  4. Koji su podaci korišćeni?
    Pri unosu novog proizvoda dobijam tu i tu grešku jeste realan problem, međutim ukoliko zapišete i koje ste podatke uneli pri tom neuspešnom pokušaju, možda će progrmeru biti lakše da utvrdi zašto dolazi do greške.

Da ja ne izmišljam dalje, možda bi najbolje bilo da ovu listu nastavimo u komentarima :), pa možemo da uradimo i update samog posta ako se slažte? 

Jeste bug, ali da li je kritičan?

Jeste bug, da se ponoviti, imate nalog na bug trackeru, međutim vaš bug tracker ima i polje priority, koje uvek podešavate na najviši mogući nivo? Budite realni, ukoliko je u pitanju slovna greška, ili morate da kliknete dva puta na potvrdi, preživećete do sledeće nedelje, smanjite prioritet i ne nervirajte kolege.

Hvala Saši Pantoviću i ostalim kolegama na sugestijama 👍

Leave a Reply