Vaš tim isporučuje brže nego ikada. AI napiše funkcionalnost, napiše testove, suite postane zelen, pull request prolazi. I onda se na planiranju pojavi pitanje, obično od osobe koja potpisuje račune: da li nam stvarno još trebaju ljudi koji ručno klikću kroz aplikaciju, i da li nam na kraju još treba ljudska potvrda da je to to?
Treba. Oboje. I ta ljudska potvrda danas zaslužuje više prostora nego pre dve godine, ne manje.
Automatizujte sve što odgovara na pitanje da li kod radi ono što mu je rečeno. Ljude zadržite za pitanje koje nijedan test ne može da postavi: da li je aplikaciju prijatno koristiti. To su dva različita pitanja. Drugo pitanje većina timova više gotovo i ne postavlja, jer je prvo postalo toliko jeftino.
Šta AI generisan kod zaista pogreši
Podaci o ovome su tokom protekle godine postali mnogo bolji, i ne govore ono čemu su se proizvođači alata nadali.
CodeRabbit je u decembru 2025. analizirao 470 stvarnih open source pull requestova, od toga 320 sa AI kao koautorom i 150 koje su pisali samo ljudi. Kritičnih i ozbiljnih defekata na AI strani bilo je do 1,7 puta više. Greške u logici i tačnosti, znači pogrešna poslovna logika i nebezbedan tok kontrole, porasle su za 75%. Problemi sa performansama, poput preteranog I/O, javljali su se skoro osam puta češće.
Lightrun je za svoj izveštaj iz 2026. anketirao 200 SRE i DevOps rukovodilaca iz SAD, Velike Britanije i EU. Kod 43% AI generisanih izmena bilo je potrebno ručno debagovanje u produkciji, iako su prošle QA i staging. Pročitajte taj podatak dva puta, jer on rešava celu raspravu. Kapija je postojala. Nije uhvatila ništa.
SmartBear je u maju 2026. pitao 273 rukovodioca u softveru da li se kvalitet održao. Njih 70% je reklo da je već pao, jer je stvaranje koda prestiglo kapacitet za testiranje.
Ništa od ovoga nije argument protiv razvoja uz pomoć AI. Koristimo ga svakog dana i ne nameravamo da ga vratimo. Ovo je argument da je količina koda naglo porasla, a ono što taj kod proverava ostalo je tačno iste veličine.
Pitanje koje nijedan test ne postavlja
Ovde, po mom mišljenju, većina timova razmišlja naopako.
AI je zaista dobar u pretvaranju poslovne logike u kod. Dajte mu jasno pravilo i on će ga implementirati, pokriti grane i napisati test koji dokazuje da pravilo važi. Taj deo je praktično rešen, a tvrditi suprotno je nostalgija.
Ono što ne može jeste da razume svet u kome vaša aplikacija živi. Nikada nije držao telefon jednom rukom u tramvaju, sa dve crtice signala. Ne zna da vam glavna akcija stoji tačno tamo gde palac na ekranu od šest inča ne stiže. Ne zna da je stanje učitavanja tehnički ispravno, a da aplikacija zbog njega deluje pokvareno. Ne zna da je formular u redu, samo što ga nijedan čovek ne bi popunjavao tim redosledom.
Ne postoji assert za "ovo se ne oseća dobro". Nijedan test ne pada zato što je ekran zbunjujuć.
Skoro sve što gradite, gradite za ljude. Znači, čovek mora da bude taj koji potvrđuje. To nije stvar procesnog ukusa, to je oblik samog problema.
Vaše četiri opcije
1. Samo automatizovani testovi, uključujući one koje piše AI
Najjeftinije rešenje i trenutno ubedljivo najčešće. Unit testovi, integracioni testovi, CI, i sve češće sami testovi koje je napisao isti asistent koji je napisao funkcionalnost.
Brzo, na marginu skoro besplatno, i zaista hvata prave regresije. Ali ima strukturnu rupu. Kada isti model piše i implementaciju i test, oboje nastaje iz istog čitanja zahteva. Ako je to čitanje bilo pogrešno, dobijate samouvereno zelen suite koji dokazuje da pogrešna stvar radi savršeno.
2. Automatizovani testovi plus emulatori i cloud farme uređaja
Dodate BrowserStack ili slično, pustite testove kroz matrice uređaja i pregledača, skupite snimke ekrana. Nema šta da se kupuje, skalira se koliko platite, i stvarno hvata lomove u rasporedu.
Ono što ne dobijate jeste čovek koji koristi proizvod. Snimak ekrana na virtuelnom Pixelu vam kaže da se dugme iscrtalo. Ne kaže vam da li aplikacija zapinje kada se uređaj zagreje, da li notifikacija stigne baš dok gledate u ekran, ni da li je ceo tok prijatan.
3. Programeri testiraju sopstveni rad
Uobičajeno u malim timovima i bolje nego ništa. Ipak je najslabija od četiri opcije, iz razloga koji nema veze sa znanjem.
Onaj ko je napravio funkcionalnost ne može više da je vidi svežim okom. Zna koje dugme pritiska, kojim redom, sa kojim podacima. Nesvesno zaobilazi baš one putanje koje deluju pogrešno, jer su se pogrešno činile još dok ih je pisao. Tražite od programera da testira sopstveni ekran i dobićete happy path, prelepo proveren.
4. Posvećen QA čovek, na pravim uređajima, u fiksnom ritmu
Neko čiji je posao kvalitet, ko testira na hardveru koji vaši korisnici zaista imaju, po rasporedu a ne na kraju projekta.
Tako radimo mi. Jedan QA stručnjak, pun dan nedeljno po aplikaciji, na 16 fizičkih uređaja sa Android, iOS, iPadOS, macOS, Windows i Linux platformama. Ne automatizovani prolazi na tim uređajima. Čovek koji ih drži u ruci i koristi proizvod onako kako bi ga koristio korisnik.
Cena je poštena: jedan dan nedeljno, svake nedelje, koji ne proizvodi nijednu funkcionalnost. Zauzvrat vidite svoj proizvod onako kako će ga videti vaši korisnici, otprilike nedelju dana pre njih.
Gde se svaka opcija lomi
Opcija 1 se lomi tiho, i baš to je čini opasnom. Ništa ne izgleda pogrešno dok vam korisnik ne kaže, a tada je to produkcija i razgovor sa podrškom.
Opcija 2 se lomi na svemu fizičkom. Prave mreže, prave baterije, termalno usporavanje na tri godine starom Androidu srednje klase, prave ruke.
Opcija 3 se lomi na navici, i to sve jače što je programer iskusniji.
Opcija 4, ona koju preporučujem, lomi se na jedan vrlo određen i vrlo čest način: kada je QA čovek izvan petlje razvoja. Onaj ko dobije gotov build, proklikta ga i upiše tikete u backlog jeste filter, a ne povratna sprega. Sve što tako nađe već je skupo u trenutku nalaza, a tim prestaje da se oseća odgovornim za to kako se proizvod oseća, jer je kvalitet postao tuđa kolona na tabli. Ritam je ono što to sprečava. Nedeljno znači da nalazi stižu dok je kod još topao i dok se onaj ko ga je pisao još seća zašto.
I pošteno priznanje: ako je vaš proizvod interni alat, admin panel ili operativni dashboard koji koristi 20 obučenih zaposlenih bez alternative, ovo je preterana potrošnja. Ti korisnici će vam reći da je ružno i nastaviće da ga koriste, jer im je to posao. Automatizujte tačnost, zaštitite podatke, preskočite ceremoniju.
Tabela za odluku
- Samo automatizacija. Šta hvata: Regresije i logiku koju je specifikacija dobro opisala. Šta propušta: Sve što je specifikacija pogrešila, ceo UX i osećaj. Kome odgovara: API, backend servisi, interni alati.
- Plus cloud uređaji. Šta hvata: Lomove rasporeda po ekranima i pregledačima. Šta propušta: Realne uslove, da li tok ima smisla. Kome odgovara: Web proizvodi sa širokim rasponom pregledača.
- Programeri testiraju sami. Šta hvata: Očigledne kvarove, happy path. Šta propušta: Sve na šta sveže ruke prvo naiđu. Kome odgovara: Vrlo rana faza, pre prihoda.
- Posvećen QA na pravim uređajima, nedeljno. Šta hvata: Osećaj, tok i ispravno napravljenu pogrešnu stvar. Šta propušta: Strukturno ništa, ali košta dan nedeljno. Kome odgovara: Sve gde korisnik može da ode.
Uzmite ovo
Ako vaši korisnici imaju izbor, dakle consumer aplikacije, marketplace platforme, sve gde loša prva sesija završi deinstalacijom, uzmite opciju 4. Pravi čovek, na pravom hardveru, u nedeljnom ritmu, koji nije pisao taj kod. To je preporuka i ne mislim da je tesna.
Ako vaši korisnici nemaju izbor, znači interni alati i back office sistemi, uzmite opciju 1 ili 2 i uštedu uložite u tačnost i integritet podataka. Niko ne napušta ERP zato što se animacija trza.
Ako ste u regulisanoj delatnosti, zdravstvo, fintech, sve sa revizorskim tragom, treba vam dokumentovana QA funkcija bez obzira na to kako se korišćenje oseća. "To je napisao AI" nije odgovor koji revizor prihvata, i neće postati.
Jedno pravilo važi za sve četiri: nikada ne dozvolite da ono što piše kod bude jedino što taj kod proverava. Čovek pregleda kriterijume prihvatanja pre nego što ih AI dodirne, drugi čovek potvrđuje rezultat. U suprotnom sami sebi ocenjujete domaći, samo mašinskom brzinom.
Verovatno ne morate nikoga da zapošljavate zbog ovoga
Ovde je greška u suprotnom smeru. Posle svega gore napisanog, refleks je da se zaposli QA inženjer. Za većinu timova sa jednim ili dva proizvoda to je puna plata za posao kome iskreno treba jedan dan nedeljno.
Postavku smo napravili za sopstvene projekte i ispostavilo se da nije popunjena, pa je nudimo i drugim timovima. Jedan QA stručnjak, jedan dan nedeljno, 16 uređaja sa Android, iOS, iPadOS, macOS, Windows i Linux platformama, koji testira vaše buildove na hardveru koji vaši korisnici zaista koriste. Nalaze dobijate dok je kod još topao, bez stalnog zaposlenja i bez police pune telefona koji će za tri godine biti zastareli.
U Conimex IT gradimo softver po meri za web i mobilne uređaje u Laravelu, Reactu i React Nativeu, kao Laravel Community Partner, i koristimo AI podršku kroz ceo proces. Upravo zato je dan za ručno testiranje kod nas zaštićen, a ne opcionalan.
Ako isporučujete rad rađen uz AI brže nego što stižete da ga proverite, i niste sigurni da li je poslednja ljudska kapija u vašem procesu stvarna ili samo formalnost, pogledaćemo to zajedno sa vama. Pišite nam na [email protected].