Bug Online

Kod testiranja programske opreme veliku ulogu igra dobra i pravovremena komunikacija između testera, voditelja projekta i developera. Profesionalni testeri trebaju imati osnovna znanja o programiranju, a s druge strane programeri trebaju poznavati osnove testiranja. Iskustva iz prakse pokazuju da se često dešava da programeri nedovoljno testiraju vlastiti kôd ako u tvrtki postoji odjel za testiranje.

S druge strane, pogotovo u Hrvatskoj, često se događa da programer nema vremena testirati softver zbog nerealnih rokova, konkurentnih prioriteta i opasno premalog broja ljudi na projektu, a manjak obrazovanih profesionalnih testera već je sada vidljiv. To je velika pogreška jer je zadatak svakog programera da nakon svake promjene izvornog koda (npr. ispravljanje buga, ugradnja novih funkcionalnosti) prvo testira na lokalnom računalu je li promjena koda korektna i uzrokuje li pojavu novih pogrešaka. Najgore što se može desiti jest da programer ne testira kôd, a u tvrtki nema testera ili dovoljno vremena za testiranje i isporučeni softver direktno dolazi na "testiranje kod korisnika".

Očito sljepilo

Kada su programeri prepušteni sami sebi i svojem testiranju koda, dolazi do jednog očitog sljepila kojeg bismo mogli nazvati "ne vidim slona skrivenog u travi". Naime, provode li se sati u rješavanju jednog problema, gubimo iz vida detalje i ponekad ne vidimo očiti problem, dok bi ga osoba sa strane koja nije provela vrijeme gledajući u naš kôd uočila u par trenutaka. Znači, kada se i ima vremena za vlastito temeljito testiranje, to ne znači da nitko više ne treba obavljati testiranje prije nego što promjene u aplikaciji uvedemo u produkciju. U takvim čestim slučajevima kada nema dovoljno resursa u timu, preporučljivo je da kôd testiraju timski kolege jer oni ne boluju od našeg sljepila.

Izvještaj o pogrešci (bug report, issue report, defect report) pisana je komunikacija između testera, programera i voditelja projekta, odnosno nadležnog menadžera. U svakom dobro napisanom izvještaju o pogrešci najvažnije su sljedeće informacije: (1) sažetak problema, (2) koraci za reproduciranje pogreške, (3) očekivani rezultat i (4) opis dobivenog rezultata. Održavanje baze podataka izvještaja o pogreškama jedno je od obilježja dobro organiziranog programskog tima. Dobro napisani izvještaji o pogreškama omogućuju donošenje poslovnih odluka, doprinose bržem ispravljanju programskih pogrešaka i time štede vrijeme i novac.

Cilj je također smanjiti tzv. ping pong izvještaja o bugu između programera i testera. Najčešći razlog za ping pong jest da programeri kažu da ne mogu reproducirati bug, ispravak pogreške će im uzeti previše vremena, bug je nevažan i korisnik neće primijetiti pogrešku, bug je nerealističan (npr. corner case), izvještaj nije dovoljno jasan, izvještaj se ne temelji na činjenicama (npr. "mislim da je problem..."), izvještaj je nekompletan ili je pridružen pogrešnoj osobi ili komponenti aplikacije. Jedan od velikih izazova u praksi jest znati izgraditi povjerenje i dobru komunikaciju između testera i programera da se izbjegne ping pong koji nastaje kao posljedica nepovjerenja ili loše napisanih izvještaja o pogreškama (npr. "aplikacija ne radi"). Jedan od zadataka testera jest da piše kvalitetne izvještaje o pogreškama, tj. svaki bug treba dobiti šansu da bude riješen. Tester također treba biti otvoren za sugestije za poboljšanje kvalitete svojih izvještaja o problemima.