Ako ste ikada koristili aplikaciju i pomislili „zašto ovo neće da radi?“, verovatno ste upravo naišli na – bug.
Bug je svaka greška u softveru koja dovodi do ponašanja koje programer nije planirao.
Nekada se pojavi u nekom skrivenom scenariju, a nekada pred očima svih korisnika.
Ali svaki bug ima svoj put – od trenutka kada se „rodi“ do onog kada konačno bude ispravljen.
1. Kako nastaje bug?
Sve počinje u trenutku kada developer piše novu funkcionalnost. Kod je svež, testiran lokalno i deluje da sve radi.
Ali, softver je složen sistem, a jedan deo sistema utiče na drugi, pa se greške često pojave tamo gde ih niko ne očekuje. Možda se radi o zaboravljenoj proveri, pogrešnoj logici, nekom „if“ uslovu koji nikad ne bude ispunjen.
Greška tada tiho „živi“ u aplikaciji i čeka da neko naiđe na nju.
2. Kako tester otkriva bug?
Na scenu stupa tester.
Za razliku od običnog korisnika, tester pokušava da razbije sistem.
Umesto da koristi aplikaciju „normalno“, on je ispituje – unosi neobične podatke, klikće neplaniranim redosledom, testira kombinacije o kojima programer nije razmišljao.
I baš u tim trenucima, bug ispliva na površinu.
Na ekranu se pojavi greška, dugme prestane da reaguje ili se rezultat ne podudara s očekivanim.
View this post on Instagram
3. Šta znači prijaviti bug na pravi način
Otkrivanje je tek početak.
Sada sledi prijavljivanje buga, koji nije samo poruka „ne radi“.
Tester mora da dokumentuje sve:
šta se desilo, gde se desilo, kojim redosledom je do toga došao, šta je očekivano, a šta se zapravo dogodilo.
U prilogu obično ide i screenshot ili video.
Sve to se unosi u alat za praćenje grešaka (poput Jire), gde bug dobija svoj jedinstveni ID, opis i prioritet.
Od tog trenutka, bug je „zvanično“ živ i čeka svoj red za rešavanje.
4. Ispravka bug-a
Sada je loptica ponovo kod developera. On analizira opis, pokušava da reprodukuje grešku i locira deo koda koji je problematičan.
Ponekad je rešenje jednostavno – promeni se jedan red.
Ali, često se pokaže da je greška dublja: utiče na druge module, zahteva refaktorisanje ili dodatne testove.
Kada developer popravi kod, šalje novu verziju aplikacije na proveru.
5. Ponovno testiranje softvera: da li je bug zaista nestao?
Tester ponovo ulazi u igru.
Njegov zadatak sada je da proveri da li je bug zaista ispravljen i da li je sve ostalo u redu. Ovaj korak se zove regression testing, jer proverava da popravka nije „pokvarila“ nešto drugo.
U složenim sistemima, ispravka jedne sitnice može neplanirano uticati na deset drugih stvari — zato se sve još jednom pažljivo testira.
6. Kraj puta jednog buga: zatvaranje i učenje iz grešaka
Kada tester potvrdi da greška više ne postoji, bug se zatvara u sistemu.
U idealnom slučaju – zauvek. A korisnici nikada ne saznaju da je postojala. Za njih, sve „radi kako treba“.
Ali za tim koji je radio na rešavanju, svaki zatvoreni bug znači iskustvo više i stabilniji sistem.
Put jednog buga možda zvuči kao sitnica, ali upravo ti mali koraci čine razliku između aplikacije koja radi i one koja nervira korisnike. Testeri, developeri i menadžeri zajedno prolaze kroz taj proces kako bi svaka nova verzija softvera bila pouzdanija. A svaki bug koji prođe kroz ruke QA tima – postaje lekcija.
Želiš da naučiš kako ovaj proces izgleda u praksi?
Na Cubes School kursu Testiranje softvera (QA) učiš upravo to: kako da pronađeš, prijaviš i testiraš greške — kao pravi član QA tima.
