Automatska regresijska testiranja za web aplikacije

Promijenjeni promotivni kod, novo pravo uloga ili ažuriranje servisnog dijela plaćanja mogu srušiti web aplikaciju na mjestu koje nitko nije dirao mjesecima. Upravo tu nastupaju automatizirani regresijski testovi za web aplikacije: oni opetovano provjeravaju funkcioniraju li provjereni poslovni procesi i dalje nakon promjena. Ne kao teorijska mjera kvalitete, već tamo gdje pogreška blokira narudžbe, kretanje zaliha, račune ili korisničke račune.

Za mnoge timove problem počinje neprimjetno. Izdanja (releaseovi) traju dulje jer odjeli ručno klikaju iste ključne procese. Znanje o testiranju nalazi se kod pojedinačnih osoba. I prije ažuriranja ostaje neugodno pitanje: što smo propustili? Automatizacija pritom ne zamjenjuje ni stručnu odgovornost ni smisleni istraživački rad. Ona čini ponavljajuće, poslovno kritične provjere pouzdanima, ponovljivima i slijediva.

Što automatizirani regresijski testovi zapravo osiguravaju

Regresijski test odgovara na jednostavno pitanje: radi li i nakon promjene nešto što je prije funkcioniralo? Kod web aplikacije rijetko se radi samo o jednoj tipki. Relevantni su kompletni procesi kroz sučelje, ovlaštenja, sučelja (API) i bazu podataka.

Primjer iz operativnog sustava: zaposlenik se prijavljuje, unosi primitak robe, knjiži promjenu zaliha, izrađuje otpremnicu i predaje pošiljku dostavnoj službi. Svaki korak može izgledati tehnički ispravno, a da ipak zakatači u međusobnoj interakciji. Možda se količina spremi, ali se ne ažurira u zalihi. Možda se generira oznaka, ali nedostaje referentni broj. Možda proces radi samo za administratore, ali ne i za ulogu u skladištu.

Automatizirani testovi mogu takve putove (journeys) izvršiti s definiranim unosima i provjeriti rezultate. To uključuje vidljive rezultate u korisničkom sučelju, kao i vrijednosti stanja, generirane dokumente, e-poštu ili odgovore API-ja. Korist raste kada se provjera organizira blizu operativnih rizika — a ne prema broju tehnički mogućih testnih slučajeva.

Koje web procese prvo treba automatizirati

Nema svaki klik odmah pravo na automatizirani test. Stranica s postavkama koja se rijetko koristi i ima mali potencijal štete može se najprije provjeriti ručno. S druge strane, procesi s čestim promjenama, visokom iskorištenšću ili jasnim financijskim i operativnim posljedicama moraju rano ući u testni paket.

Posebno su vrijedni testovi za prijavu (login), poništavanje lozinke i zaključavanje računa. Oni osiguravaju pristup aplikaciji i na njih često utječu promjene servisa identiteta, upravljanja sesijama ili sigurnosnih pravila. Jednako su važni i glavni procesi poput unosa narudžbi, izračuna cijena i poreza, odobrenja, knjiženja zaliha, generiranja dokumenata i sučelja prema otpremi, ERP-u ili pružateljima usluga plaćanja.

Za rukovodstvo i stručne odjele pomaže trijezna prioritetizacija. Nemojte najprije pitati koja je stranica najlakša za testiranje. Pitajte: koja pogreška zaustavlja smjenu, stvara naknadni rad ili dovodi do netočnih informacija za klijente? Iz toga nastaje popis testova koji štiti stvarno poslovanje.

Testni slučaj treba provjerljiv rezultat

„Kreiranje narudžbe“ još uvijek nije dobar testni slučaj. Bolje je: komercijalist s ulogom prodaje kreira narudžbu za postojećeg kupca, dodaje artikl s definiranom količinom, sprema ga i generira broj narudžbe. Nakon toga status je „otvoren“, suma odgovara pravilima, a narudžba se pojavljuje na popisu otvorenih predmeta.

Ta preciznost nije birokracija. Ona sprečava testove koji doduše klikaju, ali ne mogu utvrditi je li stručni rezultat točan. Također olakšava usklađivanje između razvoja, QA-a i stručnog odjela. Upravo kod prilagođenih (custom) sustava, stručnjaci su često jedini pouzdani izvor za ono što „ispravno“ u svakodnevnom životu zapravo znači.

Testna piramida umjesto automatizacije preglednika za sve

Testovi preglednika su vrijedni, ali nisu cijela strategija testiranja. Izvršavaju se sporije, podložniji su nestabilnim testnim podacima i mogu se srušiti nakon malih prilagodbi korisničkog sučelja ako su selektori loše odabrani. Tko svako pravilo provjerava isključivo preko sučelja, obično gradi spor paket koji zahtijeva mnogo održavanja.

Poslovnu logiku poput izračuna cijena, provjera količina ili prijelaza stanja trebalo bi testirati tamo gdje je implementirana — primjerice kao unit ili integracijski test. Sučelja se mogu ciljano provjeravati s kontroliranim odgovorima. End-to-end testovi temeljeni na pregledniku tada ostaju rezervirani za rijetke puteve kod kojih je ključna interakcija svih komponenti.

Kod PHP 8.4 aplikacija s MySQL 8 bazom podataka to primjerice znači: pravila izračuna i validacije osiguravaju se blizu koda, transakcije baze podataka i API ugovori testiraju se integrirano, dok test preglednika prati kompletnu narudžbu sve do generiranog dokumenta. To je manje spektakularno od velike zbirke vidljivih testova klikanja, ali pruža brže povratne informacije i manji napor održavanja.

Stabilnost nastaje kroz testne podatke i jasne tehničke granice

Mnogi projekti automatizacije ne propadaju zbog alata za testiranje, već zbog nekontroliranih preduvjeta. Ako je testni račun blokiran, ako testna narudžba od prethodnog dana još uvijek postoji ili ako vanjski servis upravo sporo odgovara, nastaje lažni alarm. Takvi nestabilni testovi brzo gube povjerenje tima.

Testni podaci se stoga moraju svjesno kreirati i čistiti. Korisni su vlastiti tenantzi ili jasno razgraničeni skupovi podataka, jedinstvene oznake po testnom pokretanju i definirana početna stanja. Test ne smije slučajno ovisiti o redoslijedu drugih testova. Tamo gdje su uključeni vanjski servisi, treba jasno odlučiti: koristi li se realno testno okruženje ili se sučelje simulira za dotični test? Obje opcije mogu biti ispravne.

Selektori također zaslužuju pažnju. Testovi ne bi trebali ovisiti o klasama izgleda, položajima teksta ili slučajnim HTML strukturama. Stabilne oznake izričito namijenjene testovima smanjuju nepotrebno održavanje. To je mala tehnička odluka s velikim učinkom kada se sučelje i dizajn redovito razvijaju.

Ugradnja automatiziranih regresijskih testova u proces izdanja (release)

Najbolji test malo pomaže ako se ručno pokreće samo prije velikih izdanja. Smisleno je stupnjevito izvršavanje: brzi testovi koda i sučelja izvode se pri svakoj promjeni. Najvažnije putanje preglednika (browser journeys) izvode se kod pull requestova ili prije isporuke u staging okruženje. Opsežnije provjere mogu se odvijati noću ili prije planiranog produkcijskog izdanja.

Povratna informacija je ključna. Neuspješan test ne treba samo crveni simbol, već upotrebljive upute: koji su podaci korišteni? U kojem se koraku dogodila pogreška? Koji zaslon (screenshot) ili zapisnik to dokazuje? Za timove bez vlastitog velikog QA odjela, razumljivi nalazi su posebno vrijedni. Moraju moći prepoznati nalazi li se defekt u sustavu, u testnim podacima ili u testnom okruženju.

COCO se ovdje može koristiti kao samostalno hostana (self-hosted) testna infrastruktura za izvršavanje testnih procesa, snimanje dokaza i obradu rezultata jasnim jezikom. To je posebno relevantno kada se snimke zaslona, unutarnja sučelja ili testni podaci ne bi trebali prenositi u vanjski oblak. Self-hosted ipak ne znači da ne zahtijeva održavanje: prava pristupa, ažuriranja, kapaciteti i pravila zadržavanja moraju se planirati jednako uredno kao i sami testovi.

Što metrike govore — a što ne

Rastući broj automatiziranih testova nije dokaz kvalitete. Paket s 2000 površnih testova može ponuditi manju zaštitu nego 40 uredno održavanih testova za kritične tokove vrijednosti. Pitanja poput sljedećih su rječitija: koliko traje povratna informacija nakon promjene? Koliko se relevantnih pogrešaka otkrije prije produkcije? Koliko su često pogreške u testiranju zapravo lažni alarmi? I koji su poslovno kritični procesi dokazano pokriveni?

Trajanje izvršavanja također je praktičan faktor. Ako paket isporučuje rezultate tek nakon četiri sata, zaobilazi se u svakodnevnom radu. Ako u 15 minuta isporuči jasan signal o prijavi, narudžbi, zalihi i dokumentima, podržava donošenje odluka prije izdanja. O primjeni i riziku ovisi koja je dubina potrebna. Interni alat za planiranje zahtijeva nešto drugačije nego portalan za klijente s plaćanjima i osobnim podacima.

Pravi početak manji je nego što mnogi očekuju

Započnite s procesom čiji bi prekid bio osjetan i u potpunosti ga obuhvatite. Definirajte očekivani rezultat zajedno s osobama koje taj proces koriste svakodnevno. Osigurajte kontrolirane testne podatke, stabilna tehnička uporišta i slative dokaze. Tek kada taj prvi test radi pouzdano, dodaje se sljedeći proces.

Tako ne nastaje impresivna, ali krhka kulisa testiranja. Nastaje otporna linija sigurnosti za promjene — korak po korak, tamo gdje vaša web aplikacija doista nosi poslovanje.