Key Takeaways: Najvažnije je odmah reći da sukob između developera i QA testera nije stvar ega pojedinaca, već posledica loše postavljenih procesa, neusklađenih ciljeva i kulture u kojoj se brzina nagrađuje više od kvaliteta. Druga važna stvar je da automatizacija i AI ne znače kraj QA profesije, ali znače kraj komforne zone za sve koji i dalje misle da je dovoljno ručno kliknuti kroz aplikaciju i poslati prijavu baga bez konteksta.
U ovom tekstu bavićemo se pravim razlozima zašto između developera i QA testera tako često varniči, gde nastaju tenzije u svakodnevnom radu, zašto fraza „works on my machine“ i dalje živi kao neka vrsta industrijskog folklora, šta vraćanje tiketa zapravo govori o organizaciji tima i da li manuelno testiranje ima budućnost u eri automation testing-a (automatizovanog testiranja), CI/CD-a (kontinuirane integracije i isporuke) i AI alata. Priča je važna jer moderni softver više ne trpi sporost, lošu komunikaciju i silose između ljudi koji bi morali da rade kao jedan sistem, a ne kao zaraćene frakcije.
Istina je manje romantična nego što industrija voli da predstavi. Developer želi da isporuči, QA želi da zaustavi problem pre korisnika, menadžment želi da sve bude i brzo i stabilno, a realnost uglavnom kaže da ne može sve odjednom. U tom trouglu najlakše je pronaći krivca, a najteže popraviti proces. Zato su rasprave između developera i QA tima često samo simptom mnogo dublje bolesti: kompanije koja kvalitet tretira kao poslednju kontrolnu tačku, umesto kao ugrađenu osobinu proizvoda.
Nije mržnja, nego sudar dve logike rada
Naslov je oštar, ali stručan odgovor mora da bude precizan: većina developera ne mrzi QA testere, baš kao što ni većina QA inženjera ne mrzi developere. Ono što postoji jeste dugotrajna profesionalna tenzija između dve uloge koje gledaju isti proizvod iz potpuno različitih uglova. Developer gradi funkcionalnost, dok QA traži gde funkcionalnost puca. Developer se meri po isporuci, brzini, implementaciji i rešavanju zadatka. QA se meri po otkrivanju rizika, rubnih slučajeva, regresija i iskustva krajnjeg korisnika. Kada su rokovi loši, specifikacija nejasna, a odgovornost mutna, taj odnos lako sklizne u pasivnu agresiju.
Drugim rečima, developer je prirodno motivisan da kaže: „Evo, završeno je.“ QA je prirodno motivisan da kaže: „Nije završeno dok ne dokažemo da neće pući.“ U zdravom timu ta dva impulsa se dopunjuju. U lošem timu oni se sudaraju. Tada tester developeru deluje kao kočnica, a developer testeru kao osoba koja stalno pokušava da provuče poluzavršen posao kroz sistem.
Tu nastaje prvi veliki nesporazum. Developer često misli da QA „traži dlaku u jajetu“. QA često misli da developer „gura kod na silu“. A istina je da i jedni i drugi često rade racionalno u okviru loše postavljenog procesa. Kada kompanija slavi brz deployment (isporuku) više nego stabilan proizvod, normalno je da QA počne da liči na unutrašnju opoziciju. Kada QA nema dovoljno tehničkog konteksta, normalno je da developer bug report doživi kao neprecizan, frustrirajući i skup za tumačenje.
Gde zapravo počinje rat: „radi kod mene“
Malo je rečenica u IT industriji koje izazivaju više nervoze od one čuvene: „Kod mene radi.“ To nije samo tehnička opaska. To je kulturni signal. Ona često znači da developer testira u svom lokalnom okruženju, sa svojim podacima, svojom konfiguracijom, svojim pregledačem (browser-om), svojom verzijom servisa i svojim pretpostavkama. QA, s druge strane, testira u drugom kontekstu: staging okruženju, različitom nizu podataka, možda drugoj ulozi korisnika, drugačijem redosledu koraka ili na uređaju koji više liči na realnu upotrebu.
Zato „radi kod mene“ često uopšte ne znači da QA greši. To samo znači da sistem nije dovoljno robustan da radi dosledno u realnim uslovima. U modernom razvoju softvera to je ogroman problem, jer CI/CD prakse upravo postoje da bi se razlika između lokalnog razvoja i stvarnog okruženja smanjila. U srži DevOps-a nalazi se automatizacija procesa testiranja, build-a i isporuke, upravo zato da individualna „lokalna istina“ ne bude važnija od ponovljivog i proverljivog procesa.
Drugim rečima, kad čujete „works on my machine“, to nije odbrana. To je priznanje da tim nema dovoljno dobru standardizaciju okruženja, test podataka, nadzora (monitoring-a) ili deployment discipline. Problem nije u jednoj osobi, nego u procesu koji dopušta da lokalno ponašanje aplikacije bude bitnije od stvarne upotrebe.
Vraćanje tiketa nije birokratija, nego ogledalo kvaliteta
Druga velika tačka sukoba jeste vraćanje tiketa. U skoro svakom timu postoji ista scena: developer zatvara task, QA otvara bag, developer kaže da to nije bag nego očekivano ponašanje (expected behavior), product owner kaže da nije tako zamišljeno, pa se tiket vraća, premešta, menja mu se labela i na kraju svi gube vreme. Ovakva dinamika retko je znak da su ljudi nesposobni. Mnogo češće je znak da tim nema dobru definiciju završenosti (definition of done), jasne kriterijume prihvatanja (acceptance criteria) i dovoljno ranu saradnju između razvoja, testiranja i produkta.
Kada QA vraća tiket, developer to često doživljava lično, kao osporavanje sopstvenog rada. To je greška, ali je razumljiva. Svaki bag je u nekoj meri udar na osećaj stručnosti, naročito ako je developer pod pritiskom roka. S druge strane, kada QA dobije polovičan fiks, nejasan komentar ili tiket zatvoren bez stvarnog objašnjenja, on to doživljava kao znak nepoštovanja. Odatle kreće ono tiho trovanje odnosa koje ne eksplodira odmah, ali posle nekoliko sprinteva počne da razara poverenje.
U ozbiljnim timovima vraćanje tiketa nije politički čin, nego deo povratne sprege (feedback loop). Problem nastaje kada je sistem podešen tako da svaki vraćen tiket izgleda kao poraz pojedinca, umesto kao informacija da proces ima rupu. Tu menadžment često greši: meri brzinu zatvaranja, a ne kvalitet isporuke. A kada se meri pogrešna stvar, ljudi počinju da optimizuju ponašanje za metriku, a ne za proizvod.
Zašto QA developerima deluje kao neprijatelj
Treba biti brutalno iskren: QA često deluje kao neprijatelj onome ko želi da pomeri stvar dalje, završi posao i smanji backlog. To je posebno izraženo u timovima koji žive u stalnom crunch režimu (režimu preopterećenja), gde se svaki bag doživljava kao nova prepreka planu koji je i onako nerealno postavljen. U takvom okruženju developer ne vidi QA kao partnera u kvalitetu, nego kao nekoga ko stoji između njega i „done“ statusa.
Ali to je kratkovida logika. Kada QA ne pronađe problem pre produkcije, problem ne nestaje. Samo menja lokaciju. Umesto da bag eksplodira unutar tima, eksplodira kod korisnika. A tada su trošak, reputaciona šteta i operativni stres daleko veći. Tretiranje testiranja kao „nužnog zla“ dugoročno urušava digitalne proizvode i povećava cenu svake naredne promene.
Drugim rečima, developer kome QA „ide na živce“ često zapravo oseća nešto drugo: pritisak. QA mu samo postaje najvidljivije lice tog pritiska. Ako rok nije realan, arhitektura je krhka, tehnički dug raste, a produktni tim stalno menja prioritete, normalno je da će se frustracija preliti na onoga ko poslednji proverava isporuku.
Zašto developer QA-ju deluje kao neko ko stalno gura poluproizvod
I druga strana ima svoje argumente. QA testeri vrlo često rade sa funkcionalnostima koje su formalno gotove, a praktično nedovršene. Dokumentacija kasni, acceptance criteria su mutni, rubni slučajevi (edge cases) nisu razrađeni, obrada grešaka (error handling) je slaba, a plan za vraćanje na staro (rollback plan) ne postoji. U takvom kontekstu tester počinje da ima osećaj da stalno čisti za nekim drugim.
To je jedan od razloga zašto dobar QA retko sebe vidi kao „klikača“. On vrlo brzo shvati da njegov posao nije da potvrdi da srećni put radi, nego da razbije iluziju da je sistem stabilniji nego što zaista jeste. Kada developer pošalje feature sa porukom „sve je gotovo“, a QA za dvadeset minuta nađe tri regresije, problem nije u QA-ju što „kopka“, nego u timu koji kvalitet proverava prekasno.
Zbog toga najbolji QA inženjeri vremenom postaju vrlo direktni, ponekad i neprijatno precizni. Ne zato što uživaju u konfliktu, nego zato što znaju cenu bagova koji prođu u produkciju. Njihova skepsa nije cinizam, već profesionalni refleks.
Manuelno testiranje nije mrtvo, ali više nije dovoljno
Sada dolazimo do dela koji najviše boli tržište. Manuelno testiranje nije nestalo i neće nestati preko noći. Ali ideja da će u modernom timu biti dovoljno samo ručno testirati osnovne scenarije i slati screenshot sa opisom problema postaje sve manje održiva. Automatizacija, CI/CD, API testiranje, regresioni testovi (regression suites), provere performansi i AI-assisted testiranje menjaju osnovnu definiciju QA rada.
To ne znači da automatizacija „jede“ manuelni QA na prost i linearan način. Kvalitetni izvori iz prakse i edukativnih materijala ponavljaju isto: ne može se sve automatizovati, a ljudska procena ostaje nezamenjiva tamo gde su važni kontekst, upotrebljivost, nepredviđeni obrasci ponašanja i istraživačko testiranje (exploratory testing).
Ali važi i suprotno: ogroman deo repetitivnog, predvidivog i regresionog posla treba automatizovati, jer je preskup, spor i nepouzdan ako ostane potpuno ručan. Tu nema mnogo romantike. Ako firma i dalje ručno prolazi iste login, checkout, CRUD i permission scenarije iz sprinta u sprint, problem nije samo u efikasnosti, već i u tehnološkoj zrelosti tima.
Automatizacija ne preti samo QA-ju, nego svima
Naslov namerno provocira da automatizacija „preti da ih sve zameni“, ali stručna istina je malo složenija. Automatizacija ne menja samo QA. Menja developere, DevOps, produktne timove, tehničku podršku, pa čak i menadžment. DORA 2024 izveštaj naglašava da AI povećava individualnu produktivnost, kvalitet dokumentacije i brzinu određenih aktivnosti, ali istovremeno može negativno uticati na stabilnost isporuke (delivery stability) i njen protok (throughput). To znači da više automatizacije ne garantuje automatski i bolji sistem.
To je važna lekcija za sve koji misle da će „AI pisati testove, pa nam QA više ne treba“. Prema podacima World Quality Report 2025-26, 43% organizacija eksperimentiše sa GenAI u QA sektoru, ali samo 15% to skalira na enterprise nivou. Takođe, 60% organizacija i dalje ima problem sa sigurnim i skalabilnim test podacima, a 58% sa usvajanjem AI alata u praksi. Mnogo se priča o inteligentnoj automatizaciji, ali zrelost procesa u praksi i dalje ozbiljno zaostaje.
Automatizacija nije čarobni prekidač. Ako je proces loš, automatizovaćete loš proces. Ako su zahtevi nejasni, pisaćete testove za nejasne zahteve. Ako tim ne razgovara dobro, samo ćete brže proizvoditi nesporazume. Zato automatizacija bez procesne discipline često ne rešava sukob između developera i QA-ja, nego ga samo preseli na novi nivo: sada se ljudi ne svađaju oko ručnih bagova, već oko nestabilnih testova (flaky tests), loše održivosti test framework-a i lažnog osećaja sigurnosti.
Budućnost manuelnog QA: manje kliktanja, više razmišljanja
Ako treba sažeti budućnost QA profesije u jednoj rečenici, ona bi glasila ovako: nestajaće rutinski manuelni posao, a rasti potreba za tehnički jačim, analitički zrelijim i poslovno pismenijim inženjerima kvaliteta (quality engineers). World Quality Report posebno ističe da se među najvažnijim veštinama sve više traže rad sa generativnim AI-jem, temeljne veštine obezbeđivanja kvaliteta i meke veštine (soft skills), uključujući jasnu usmenu i pisanu komunikaciju.
To je potpuno logično. Budući QA neće biti osoba koja samo prijavljuje bag. Biće osoba koja razume sistem, zna gde su najveći rizici, ume da sarađuje sa developerima na testabilnosti aplikacije, zna kada test treba automatizovati, ume da čita logove, razume API ponašanje, koristi CI pipeline i ume da razlikuje stvarni defekt od loše definisanog zahteva.
Zato će manuelni QA opstati tamo gde postoji realna ljudska vrednost: u proceni poslovne logike, dizajniranju testova, validaciji složenih tokova i kritičkom razmišljanju o tome šta sistem zapravo radi korisniku. Ono što neće opstati jeste čisto mehanička varijanta posla bez tehničke evolucije.
Najveći problem nije odnos developer-QA, nego kultura firme
Ovde dolazimo do najvažnije poente celog teksta. U većini slučajeva, problem nije ni developer ni QA, već organizacija koja nije odlučila šta joj je kvalitet. Ako je QA uključen tek na samom kraju, naravno da će delovati kao blokada. Ako developeri nemaju vremena za unit testove, code review i refaktorisanje, naravno da će u QA fazi pucati više stvari. Ako produktni tim menja prioritete usred sprinta, a menadžment traži i brzinu i nula bagova, naravno da će tenzije eskalirati.
DORA 2024 posebno ističe da nestabilni organizacioni prioriteti ozbiljno smanjuju produktivnost i povećavaju burnout (sagorevanje), čak i kada postoje dobri lideri i solidna dokumentacija. To je presudno za ovu temu, jer veliki deo sukoba između developera i QA tima uopšte nije tehnički. To je posledica stalnih promena prioriteta, preopterećenja i rada u sistemu koji ljude tera da se brane umesto da sarađuju.
U takvoj kulturi svako traži mikro-krivca: developer krivi QA, QA krivi developera, menadžer oboje. A pravi problem ostaje netaknut – firma nema ozbiljnu strategiju kvaliteta.
Kako izgleda zdrav odnos između developera i QA-ja
Zdrav odnos ne znači da sukoba nema. Zdrav odnos znači da se sukob koristi da proizvod bude bolji, umesto da ljudi postanu ogorčeni. U takvim timovima QA ulazi rano u proces i na refinement sastanke, kriterijumi prihvatanja su jasni, definicija „gotovog“ posla uključuje testiranje, developeri pišu osnovne automatske testove, QA učestvuje u proceni rizika, a tiket nije politički dokument nego zajednička radna jedinica.
U praksi to znači nekoliko vrlo konkretnih stvari:
-
QA ne dobija feature prvi put tek kada je „završen“.
-
Developer ne čeka QA da bi otkrio ono što je mogao da uhvati unit ili integracionim testom.
-
Bug report nije puka poruka „ne valja“, nego precizan tehnički opis sa koracima, očekivanim i stvarnim rezultatom.
-
Retrospektiva (retro) nije puka formalnost, već sigurno mesto gde tim iskreno govori gde proces puca.
-
Automatizacija se uvodi tamo gde ima poslovnog smisla, a ne zato što to dobro zvuči u prezentaciji.
Tu se menja i ton komunikacije. Umesto „vratio si mi tiket“, razgovor postaje „šta nam je promaklo i kako da nam sledeći put to ne promakne“. Zvuči banalno, ali to je razlika između tima koji raste i tima koji samo gura sprinteve dok se članovi međusobno pasivno iscrpljuju.
Ono što niko ne voli da kaže naglas
Sada i najneprijatniji deo. Neki developeri zaista ne vole QA zato što im oni kvare priču o sopstvenoj efikasnosti. Neki QA testeri zaista ne vole developere zato što developeri ponekad tretiraju kvalitet kao tuđi posao. Neki menadžeri potajno ne vole ni jedne ni druge kada se usude da im saopšte da rok nije realan. I da, deo manuelnog QA tržišta zaista će nestati ili se drastično preoblikovati pod pritiskom automatizacije, AI alata i očekivanja da kvalitet bude ugrađen u sam pipeline, a ne samo dodat na kraju kao zakrpa.
Ali to ne znači da će QA nestati. Naprotiv, kvalitet postaje važniji nego ikad, samo više neće biti dovoljan stari model u kome jedan deo tima gradi, drugi deo proverava, a svi glume da to nije savršen recept za konstantan sukob.
Budućnost pripada onim timovima u kojima developer razume kvalitet, QA razume sistem, automatizacija pokriva ono što mora da bude ponovljivo, a menadžment konačno prestane da tretira kvalitet kao luksuz koji usporava roadmap proizvoda.
Prava istina je verovatno manje dramatična, ali i znatno ozbiljnija od naslova: developer i QA nisu prirodni neprijatelji. Oni su dve strane istog problema koji se zove isporuka pouzdanog softvera pod nerealnim pritiskom. Kada kompanija to ne razume, nastaje sukob. Kada to razume, QA više nije „kočnica“, developer više nije „fabrika bagova“, a automatizacija nije pretnja, nego alat koji konačno tera i jedne i druge da rade pametnije, a ne samo brže.
