Većina ljudi koji hoće u testiranje softvera krene od pretrage „kako postati QA tester“ ili „QA kurs“ i dobije spisak alata: JIRA, Postman, Selenium, Playwright. Spisak alata ne govori ništa o poslu. Ovaj tekst opisuje šta QA tester stvarno radi na projektu, šta mora da zna da bi taj posao radio, kojim redom se to uči i gde početnici najčešće greše. Pisan je iz svakodnevnog rada, ne iz brošure.
Kako izgleda jedan dan QA testera na projektu
Projekat se vodi kroz Scrum board u JIRA-i. Kolone su najčešće TO DO, IN PROGRESS, REVIEW, READY FOR TESTING, TESTING i DONE. Programer završi tiket, drugi programer mu pregleda kod (Review), pa tiket stiže u READY FOR TESTING. Tu počinje tvoj posao: uzmeš tiket, dodeliš ga sebi, prebaciš ga u TESTING i testiraš ono što u tiketu piše, plus sve ono što u tiketu ne piše a može da pukne.
Ako je sve u redu, tiket ide u DONE. Ako nađeš bug, pišeš bug report u komentaru tiketa, taguješ programera koji je radio na njemu (vidi se u istoriji tiketa) i vraćaš tiket u TO DO. Bug report ima uvek isti kostur: naslov koji kaže šta ne radi, tačne korake koji dovode do greške, šta se očekivalo, šta se stvarno desilo, okruženje (browser, uređaj, verzija) i screenshot ili snimak. Programer mora da može da ponovi grešku bez da te išta pita.
Klasična greška juniora: umesto bug reporta u tiketu, pošalje programeru privatnu poruku. Programer objasni zašto jedan deo tiketa ne može da se uradi, junior to prihvati i validira tiket kao urađen. Bug stigne do klijenta za nekoliko dana i krivica je u potpunosti na testeru, jer u tiketu nema traga da je problem ikad prijavljen. Sve što nađeš ide u tiket, pisano, sa datumom.
Druga stvar koju ćeš naučiti prvog meseca: u timovima koji do skoro nisu imali testera, kolona READY FOR TESTING često ne postoji i tim se opire da je uvede. Bez nje ne znaš šta je spremno za testiranje i posao je nemoguć. Tester se za tu kolonu bori odmah, prve nedelje.
Prvo se uči proces, tek onda alati
Tester ne testira samo gotove tikete. Pre Refinement sastanka tražiš od Product Ownera koji tiketi će se prolaziti i za njih pišeš prvu verziju test case-ova. Na Refinementu ih ukratko prodiskutuješ sa timom. Do Sprint Planninga test case-ovi se finalizuju. Kad tiket u toku sprinta stigne na testiranje, već imaš plan šta proveravaš, umesto da improvizuješ.
Ovde je razlika između testera koji „klikće“ i testera koji vredi timu: test case-ovi pisani pre nego što je kod napisan nateraju programera i PO-a da vide rupe u zahtevu dok je jeftino da se isprave. Zato je Agile i Scrum prvo što se uči, pre ijednog alata: šta je user story, šta su acceptance criteria, šta se radi na Daily-ju, Review-u i Retro-u iz ugla testera i šta znači sprint od dve nedelje za tvoj raspored.
Početnička greška broj dva: test case-ovi se prođu mehanički, bez razmišljanja šta još treba da se proveri. U velikom broju slučajeva nemoguće je napisati sve testove pre nego što vidiš funkcionalnost uživo na test okruženju. Kad tiket stigne, prođeš finalizovane test case-ove, pa razmisliš šta si propustio.
Manuelno testiranje: kako se stvarno piše test case
Uzmi običnu login formu. Pozitivni test: ispravan email i lozinka, korisnik ulazi. Negativni: pogrešna lozinka, prazna polja, email bez znaka @. Boundary: lozinka od tačno minimalnog i tačno maksimalnog broja karaktera, pa jedan karakter manje i jedan više. Edge: specijalni karakteri, razmak na početku i na kraju, kopirana lozinka sa nevidljivim znakom. Jedna login forma daje petnaest do dvadeset test case-ova, i svaki od njih je u nekom projektu bio bug.
Struktura test case-a je uvek ista: preduslov, koraci, očekivani rezultat. Ako korak ne može da se ponovi po napisanom, test case je loš. Test case-ovi se grupišu u Test Scenario, scenariji u Feature, a izvršavanje se beleži kao Test run sa statusima Pass, Fail i Skip.
Tri skupa testova koja ćeš stalno vrteti: Smoke (deset do dvadeset najkritičnijih provera koje kažu da li je nova verzija uopšte upotrebljiva, traje kratko i radi se posle svakog deploya), Sanity (brza provera baš onog dela koji je menjan) i Regression (ceo skup pre release-a, da ono što je radilo i dalje radi). Tester koji zna koji skup kad da pokrene štedi timu dane.
Princip koji se uči prvi i zaboravlja najčešće: ništa se ne pretpostavlja. „Verovatno radi“ nije rezultat testa. Rezultat testa je merljiv: ovaj korak, ovaj unos, ovaj ishod.
Developer Tools: šta tester gleda, a šta ne prijavljuje
Network kartica u browseru ti je uvek otvorena, sa uključenim filterom Fetch/XHR, jer te zanimaju API pozivi koje stranica šalje, ne slike i fontovi. Klik na akciju u aplikaciji, pogled na Network: koja metoda je pozvana, koji status kod je server vratio, šta je poslato i šta je stiglo nazad. Kad dugme „ne radi“, to ti odmah kaže da li je problem na frontendu (poziv nije ni otišao) ili na backendu (otišao je i vratio 500).
Console kartica pokazuje JavaScript greške, ali tester ne prijavljuje svaku. Mnoge su „soft fail“: funkcija padne, aplikacija nastavi da radi, korisnik ništa ne primeti. Neučitan font sa CDN-a je greška u konzoli, ali nije bug. Prijavljuje se ono što utiče na korisnika. Razlikovanje ta dva je deo posla koji se uči na primerima, ne iz definicije.
Isti alat služi i za negativne testove kojih se početnici ne sete: simulacija prekida internet veze ili jako spore veze usred ključnog koraka. Na aplikaciji za kupovinu to je korak plaćanja. Šta se desi kad veza pukne posle klika na „Plati“? Da li je novac skinut, a porudžbina nije napravljena? To se testira pre release-a, ne posle prve žalbe.
I prikaz: nekoliko rezolucija monitora i bar dva telefona (jedan Android, jedan iPhone), uz napomenu da simulacija u browseru nije isto što i pravi uređaj, pa se kritični tokovi proveravaju i na fizičkom telefonu.
API testiranje: granica između testera i QA inženjera
Aplikacija koju vidiš je samo lice; posao rade API-ji. Da bi ih testirao, moraš da razumeš HTTP metode (GET čita, POST pravi, PUT i PATCH menjaju, DELETE briše), status kodove (2xx uspeh, 4xx greška na strani klijenta, 5xx greška na serveru), šta je endpoint, šta su path i query parametri i kako se čita JSON odgovor.
U Postman-u napraviš kolekciju zahteva za aplikaciju koju testiraš, sa varijablama za okruženje (dev, staging), i za svaki zahtev napišeš provere: status kod je 200, odgovor sadrži polje koje očekuješ, vrednost je tačna, odgovor stiže u razumnom vremenu. Negativni API testovi su obavezni: pogrešan parametar, nedostajući token, tuđi ID. Veliki deo bugova se ovako nađe pre nego što ih frontend uopšte prikaže, i zato tržište sve manje traži testere koji API preskaču.
SQL: provera onoga što aplikacija tvrdi da je uradila
Aplikacija kaže „korisnik registrovan“. Da li jeste? Otvoriš bazu i proveriš: SELECT * FROM users WHERE email = ‘test@primer.rs’. Da li je red upisan, da li su polja tačna, da li je lozinka sačuvana kao hash a ne kao tekst. Osnovni SELECT, WHERE, ORDER BY i spajanje dve tabele su sve što ti treba na početku, a bez toga zavisiš od programera za svaku proveru.
Programiranje: koliko treba testeru, a koliko ne
Za automatske testove moraš da razumeš promenljive, tipove podataka, if i petlje, metode, klase i objekte, i osnovne principe objektno orijentisanog programiranja: enkapsulaciju, nasleđivanje, apstrakciju. Toliko. Ne treba ti da praviš aplikacije, treba ti da čitaš i pišeš test kod i da razumeš zašto framework izgleda tako kako izgleda.
Tržište radi u dva jezika za automatizaciju web aplikacija: Java (uz Selenium) i JavaScript ili TypeScript (uz Playwright). Princip je isti, sintaksa se razlikuje. Ko nauči jedan, drugi prelazi za nekoliko nedelja. Greška početnika je da pre automatizacije krene da uči kompletan frontend (HTML, CSS, JavaScript za pravljenje stranica) ili backend, potroši mesece i ne stigne do testova. Za testera je programiranje alat, ne cilj.
Automatizacija: šta se automatizuje i kako izgleda test
Automatsko testiranje je pretvaranje test case-ova koje bi tester ručno pokretao u kod koji sam prolazi korake, proverava očekivane rezultate i prijavljuje grešku. Razlog je prost: ručno testiranje ne može da isprati tempo u kome programeri svaki dan isporučuju nešto novo. Ne automatizuje se sve, nego najčešći i najbitniji testovi: login, kupovina, registracija, sve što se izvršava pri svakoj novoj verziji.
Piramida testova: najviše unit testova (pišu ih programeri), zatim API testovi (brzi, stabilni, tu tester najviše doprinosi), na vrhu najmanje UI testova (spori i najlomljiviji). Početnici obično krenu od vrha, jer se UI test vidi, pa im posle pola godine framework padne pod sopstvenom težinom.
Tri stvari od kojih zavisi da li automatski testovi žive ili umru: lokatori, struktura i čekanje. Lokator je način na koji test nalazi element na stranici (CSS selektor ili XPath); lokator vezan za dinamički ID ili za pun XPath od korena stranice puca pri prvoj izmeni dizajna. Struktura je Page Object Model: svaka stranica aplikacije ima svoju klasu sa elementima i akcijama, testovi pozivaju te akcije, pa se izmena na stranici popravlja na jednom mestu umesto u pedeset testova. Čekanje: fiksne pauze („sačekaj tri sekunde“) su najčešći uzrok testova koji čas prolaze, čas padaju; čeka se na uslov, ne na vreme.
Selenium i Playwright rade isti posao na različit način. Selenium je duže na tržištu i ima ogromnu bazu postojećih projekata; Playwright ima ugrađeno čekanje, brži je i lakši za početak. Oglasi traže i jedno i drugo, pa je znanje oba realna prednost pri prvom zaposlenju.
Git i CI/CD: gde testovi žive
Test kod nije na tvom računaru, nego u repozitorijumu, uz kod aplikacije. Moraš da znaš da napraviš branch, commit, push i pull request, i da rešiš konflikt kad dvoje menjaju isti fajl. CI/CD (na primer GitHub Actions) pokreće testove automatski pri svakoj izmeni koda ili po rasporedu: programer pošalje kod, pipeline pokrene Smoke skup, i za nekoliko minuta tim zna da li je nešto puklo. Tester koji zna da veže svoje testove u pipeline je onaj koga tim traži.
AI u testiranju: šta prepustiti, šta proveriti
Danas tester svakodnevno koristi AI: da iz user story-ja dobije prvi nacrt test case-ova, da napiše bug report iz nekoliko natuknica, da generiše test podatke, da objasni deo koda ili predloži lokator. To štedi sate. Ali AI ne zna tvoju aplikaciju, ne vidi test okruženje i ne snosi odgovornost kad bug stigne do klijenta. Svaki test case koji AI napiše se čita i dopunjuje, svaki automatski test koji AI predloži se pokreće i proverava. AI je ubrzanje za inženjera koji zna šta radi; za nekoga ko ne zna, samo brže proizvodi pogrešne testove.
Kojim redom se uči i koliko traje
Redosled nije stvar ukusa, jer svaki korak pretpostavlja prethodni:
- Proces: Agile, Scrum, JIRA, user story, bug tiket.
- Manuelno testiranje i dokumentacija: tipovi testova, test case, Smoke, Sanity, Regression.
- Developer Tools i osnovni tehnički pojmovi: HTTP, status kodovi, API, JSON.
- API testiranje u Postman-u.
- SQL.
- Programiranje u obimu za testera: Java ili JavaScript, OOP osnove.
- Automatizacija: lokatori, Page Object Model, Selenium i Playwright.
- Git i CI/CD.
- Mobilne aplikacije (Appium) i AI kao alat u svakodnevnom radu.
Realan obim za sve ovo, uz rad na zadacima posle svake oblasti, je 60 do 70 sati rada sa nekim ko to radi svaki dan, plus bar toliko samostalnog rada. Bilo da učiš sam ili kroz QA kurs, redosled i obim su isti; razlika je u tome ko ti pokaže grešku kad zapneš i koliko dana izgubiš dok je sam ne nađeš.
Šta treba da imaš pre nego što pošalješ prvu prijavu za posao
- Test case-ove za jednu javnu aplikaciju (na primer demo prodavnicu), napisane tako da ih neko drugi može izvršiti bez tebe.
- Bar jedan bug report kojeg se ne stidiš: naslov, koraci, očekivano, dobijeno, okruženje, screenshot.
- Postman kolekciju sa proverama za javni API, sa pozitivnim i negativnim zahtevima.
- Mali automation framework na GitHub-u: Page Object Model, nekoliko testova za ključne tokove, README koji objašnjava kako se pokreće.
- Sposobnost da na razgovoru objasniš razliku između Smoke i Regression skupa, šta je status kod 401 i zašto fiksne pauze u testovima ne valjaju.
Ko ima ovo, ima više od većine kandidata koji na razgovor dođu sa spiskom alata. Posao testera nije poznavanje alata, nego navika da ništa ne pretpostaviš, da svaki nalaz zapišeš tamo gde ga tim vidi i da razumeš proizvod bolje od onog ko ga je napisao.