U poslednje vreme često se može čuti tvrdnja da će veštačka inteligencija uskoro pisati automatske testove i zameniti veliki deo posla QA inženjera. U teoriji to zvuči privlačno – AI sam kreira automatske testove tako što QA klikće po Aplikaciji a AI sam generiše kod bez da QA mora da zna bilo koji programski jezik.
U praksi stvari funkcionišu mnogo drugačije.
Automatizacija testiranja nije samo pisanje automatskih testova.
Pravi izazov u test automation-u je održavanje automatskih testova dok se aplikacija konstantno menja.
Problem koji se stalno pojavljuje: promena UI-a
Web aplikacije se razvijaju svakodnevno. Dodaju se nove funkcionalnosti, menja se dizajn, refaktoriše se frontend kod ili se menjaju biblioteke.
Svaka takva promena može uticati na lokatore Web elemenata.
Na primer, automatski test može koristiti lokator koji pronalazi dugme na stranici:
button[data-test="login-button"]
Ako developer promeni strukturu HTML-a ili atribut koji identifikuje element, automatski test će prestati da radi.
Drugim rečima, lokator “puca”.
Ovo je potpuno normalna situacija u realnim projektima i dešava se konstantno tokom razvoja aplikacije.
Zašto generisani automatski testovi brzo postanu neupotrebljivi
Kada AI generiše automatske testove bez razumevanja strukture projekta, ti automatski testovi često imaju nekoliko problema:
- lokatori su krhki i vezani za trenutni HTML
- automatski testovi nisu deo postojećeg test framework-a
- nema centralizovanog mesta za upravljanje lokatorima
- kod je težak za održavanje kad UI počne da se menja
Zbog toga se dešava da generisani automatski testovi rade prvih nekoliko pokretanja, ali već nakon nekoliko promena u aplikaciji počinju da otkazuju.
U ozbiljnim projektima to je neprihvatljivo.
Kako se zapravo rešava problem održavanja automatskih testova
Da bi automatizacija bila održiva, automatski testovi moraju biti deo dobro organizovanog test framework-a.
To podrazumeva nekoliko važnih principa.
Odvajanje lokatora od test logike
Lokatori se obično nalaze na jednom mestu (na primer kroz Page Object Model ili sličnu strukturu), tako da kada se UI promeni, potrebno je promeniti samo jedno mesto u kodu.
Strukturiran framework
Automatski Testovi nisu samo niz klikova, već deo arhitekture koja uključuje:
- page objekte
- pomoćne metode
- test konfiguraciju
- test podatke
- integraciju sa CI/CD pipeline-om
Stabilni lokatori
Iskusni QA inženjeri biraju lokatore koji su stabilni i najmanje podložni promenama u UI-u.
Sve ove stvari zahtevaju razumevanje aplikacije i iskustvo u dizajnu test automatizacije.
Gde AI ipak može da pomogne
AI može biti koristan kao pomoćni alat.
Na primer, može pomoći u:
- pisanju manjih delova koda
- generisanju pomoćnih metoda
- analizi logova ili test rezultata
Međutim, AI i dalje ne može samostalno dizajnirati održiv test automation framework niti razumeti kako će se aplikacija razvijati kroz vreme.
Zaključak
Pisanje automatizacije nije jednokratni posao. Najveći deo rada zapravo dolazi kasnije – kad aplikacija počne da se menja, a automatski testovi moraju da ostanu stabilni i održivi.
Zbog toga automatizacija zahteva pažljivo dizajniran framework, dobre lokatore i iskustvo u održavanju automatskih testova.
AI može biti koristan alat u tom procesu, ali automatizacija testiranja i dalje zahteva znanje i razumevanje koje donosi QA inženjer.