Automatizirano testiranje procesa prijave uz sustavan pristup

Prijava djeluje trivijalno samo dok radi. Ako zakaže nakon objave nove verzije, zaposlenici se nađu blokirani prije početka smjene, kupci pred korisničkim portalom, a dispečeri pred zaustavljenom obradom narudžbi. Automatizirano testiranje procesa prijave stoga ne znači jednostavno unos korisničkog imena i lozinke u obrazac. Znači ponovljivo provjeravati poslovno kritičan pristup, sa svim njegovim pravilima, iznimkama i sigurnosnim granicama.

Za mnoge timove automatizacija počinje jednim pozitivnim testnim slučajem: unos valjanih vjerodajnica, potvrda prijave, prikaz početne stranice. To ima smisla, ali kao jedini test nije dovoljno. Pogreške prijave najčešće nastaju na rubovima: kod isteklih sesija, blokiranih računa, nove višefaktorske autentifikacije ili ovlaštenja koje nakon promjene uloge više ne funkcionira ispravno. Upravo ti slučajevi moraju biti planski pokriveni.

Zašto prijava zahtijeva posebnu testnu disciplinu

Prijava je istovremeno sigurnosna funkcija, tehničko sučelje i ulazna točka u radni proces. Pogreška može biti previše otvorena i dopustiti neovlašten pristup. No može biti i prestroga te blokirati ovlaštene osobe. Oba slučaja nešto koštaju: prvi stvara rizike za podatke i usklađenost, drugi zastoje, opterećenje podrške i improvizirana rješenja.

Kod web aplikacija dolaze dodatne ovisnosti. Prijava često komunicira s davateljem identiteta, sustavom e-pošte za resetiranje lozinke, MFA aplikacijom ili direktorijskom uslugom. Kod Windows desktop aplikacija na proces mogu utjecati lokalna prava, mrežne veze i instalirane verzije. Test koji promatra samo obrazac u pregledniku ne prepoznaje pouzdano takve integracijske probleme.

Zato bi tim prije prve testne automatizacije trebao definirati što uspješna prijava znači u konkretnom sustavu. Je li dovoljna vidljiva početna stranica? Ili treba provjeriti je li učitan ispravan odabir najmoprimca, je li korisnička uloga točna i je li prva zaštićena radnja doista moguća? Za portal skladišta to bi, primjerice, bio pristup zaprimanju robe. Za dispečerski sustav to može biti odobravanje ture.

Automatizirano testiranje prijave: od modela toka do testnog slučaja

Dobra polazna točka nije skripta, nego model toka. Prijava se može opisati kao slijed jasnih stanja: neprijavljen, vjerodajnice poslane, identitet potvrđen, potrebna MFA, prijavljen, sesija istekla ili račun blokiran. Svakom stanju pripadaju dopuštene radnje i očekivane reakcije sustava.

Iz ovog modela nastaju testni slučajevi sa stvarnom poslovnom vrijednošću. Standardni pozitivan slučaj pripada tu, ali i pogrešne lozinke, nepostojeći korisnički računi i istekle poveznice za reset. Pritom je ključan očekivani odgovor. Kod pogrešnih vjerodajnica aplikacija ne bi smjela otkriti postoji li e-mail adresa. Test stoga ne provjerava samo prikazuje li se pogreška, nego i to daje li njezin tekst i ponašanje nepotrebne naznake.

Posebno su važni mehanizmi zaštite od ponovljenih neuspjelih pokušaja. Nakon definiranog broja pogrešnih unosa račun se može privremeno blokirati. Automatizirani test mora provjeriti aktivira li se blokada zaista, koliko dugo traje i dobiva li legitiman korisnik potom ponovno kontroliran pristup. Ovdje je potrebna preciznost: test koji namjerno blokira produkcijske račune stvara više problema nego što ih rješava. Takvi scenariji pripadaju u odvojeno testno okruženje s posebno stvorenim računima.

MFA, reset lozinke i Single Sign-On promatrati odvojeno

Višefaktorska autentifikacija nije detalj na kraju prijave. Ona mijenja tijek procesa. Test mora prepoznati da je nakon lozinke potrebna dodatna potvrda, te mora obuhvatiti i uspješnu i odbijenu potvrdu. Kod vremenski ograničenih jednokratnih kodova testnom okruženju potrebno je kontrolirano upravljanje vremenom i tajnama. U mnogim je slučajevima testna metoda koju predviđa davatelj identiteta smislenija od oponašanja pravog mobilnog telefona.

I reset lozinke i Single Sign-On trebali bi imati vlastite testne staze. Kod reseta su bitni slanje poruke, jedinstvenost poveznice, rok valjanosti i naknadna prijava novom lozinkom. Kod SSO-a ključno je stvara li aplikacija nakon povratka od davatelja identiteta ispravno sesiju i uredno preuzima uloge.

CAPTCHA predstavlja poseban slučaj. Treba usporiti automatizirane napade i ne bi se smjela zaobilaziti testnom automatizacijom. Smislenije je koristiti testnu konfiguraciju, službeni testni ključ ili osiguranu iznimku za testno okruženje. Zavaravanje sigurnosnih kontrola samo da bi test postao zelen nije strategija kvalitete.

Odabir prikladne tehničke razine testiranja

Ne mora svaki test prijave prolaziti kroz pravi preglednik. API testovi mogu provjeriti funkcioniraju li tokeni, sesije, poruke o pogrešci i pravila blokade ispravno. Brzi su i pomažu pronaći pogreške blizu logike autentifikacije. Testovi u pregledniku, s druge strane, pokazuju uklapaju li se polja, preusmjeravanja, kolačići, SameSite postavke i vidljiva stanja u stvaran korisnički tok.

Za kritične aplikacije smislena je kombinacija. Nekoliko end-to-end testova provjerava cijeli put putem preglednika. Ispod toga ciljani API i integracijski testovi osiguravaju varijante. To smanjuje vrijeme izvođenja i lažne uzbune. Tko svaku zamislivu kombinaciju testira isključivo u pregledniku, često dobiva spor paket testova čije održavanje troši više vremena nego što ga štedi.

Kod desktop softvera vrijedi sličan princip. Automatizirani test ne bi trebao samo provjeriti otvara li se prozor. Mora utvrditi postoji li nakon prijave ispravna veza s podacima, jesu li korisnička prava aktivna i je li dostupna središnja radna maska. To je posebno relevantno kod aplikacija u skladištu ili proizvodnji, jer radna mjesta mogu imati različite mrežne uvjete, priključke skenera ili lokalne konfiguracije.

Sigurno i ponovljivo rukovanje testnim podacima

Testovi prijave nužno rade s vjerodajnicama. Produkcijski računi zaposlenika, stvarni podaci kupaca ili MFA tajne, međutim, ne pripadaju nekontrolirano u testne skripte, zapise i snimke zaslona. Testni računi moraju biti jasno označeni, imati minimalna ovlaštenja i moći se automatski resetirati. Lozinke i tokeni osiguravaju se putem sigurnog upravljanja tajnama, a ne pohranjuju u izvornom kodu.

Jednako je važno čišćenje nakon izvođenja testa. Ako test stvara nove sesije, zapise revizije ili blokirane račune, testno okruženje mora se vratiti u definirano početno stanje. Inače test u ponedjeljak ne uspijeva samo zato što je izvođenje od petka ostavilo popratne učinke.

Za tvrtke s povjerljivim aplikacijama presudno je i mjesto izvođenja. Snimke zaslona prijavnih maski, testni video zapisi i tehnički zapisi mogu sadržavati osjetljive informacije. Vlastito hostirana testna infrastruktura poput sustava COCO ovdje može biti smislena, jer testni podaci, izvođenje i dokazi ostaju pod vlastitom kontrolom. Je li to potrebno ovisi o razini potrebne zaštite, ugovornoj situaciji i internim smjernicama. Vlastita infrastruktura nije automatski najekonomičniji izbor za svaku aplikaciju.

Stvaranje dokaza, ne samo zelenih kvačica

Testno izvješće trebalo bi QA-u, razvoju i stručnom odjelu jasno prikazati što je provjereno. Zeleni status bez konteksta malo pomaže ako objava kasnije izazove pitanja. Zato su korisni vremenske oznake, korišteno testno okruženje, testni račun, relevantni koraci, snimke zaslona kod pogrešaka i jasna poruka o pogrešci na razumljivom jeziku.

Pritom prikupljanje dokaza ne smije samo postati problem zaštite podataka. Lozinke, jednokratni kodovi, ID-ovi sesija i osobni podaci moraju biti maskirani u zapisima. Kod snimki zaslona ponekad je potrebno prekriti određena područja. Ta bi pravila trebala biti dio testne arhitekture, a ne ručni naknadni rad nakon incidenta.

Što bi timovi trebali prvo automatizirati

Prioritet se određuje prema riziku i učestalosti korištenja. Prvo dolaze standardna prijava za najvažnije uloge, pogrešne vjerodajnice, odjava i istek sesije. Zatim slijede pravila blokade, reset lozinke, MFA i promjene uloga. SSO, posebni najmoprimci ili rijetki iznimni putevi mogu slijediti kasnije, pod uvjetom da njihov ispad ne zaustavlja odmah poslovanje.

Testovi pripadaju procesu objavljivanja. Promjene obrazaca za prijavu, kolačića, ovlaštenja ili konfiguracija davatelja identiteta trebale bi pokrenuti relevantan paket testova prije nego što verzija ode u produkciju. Osim toga, isplati se planirano izvođenje u realističnom okruženju, primjerice nakon promjena infrastrukture ili zamjene certifikata. Time se pronalaze problemi koji nisu vidljivi u izoliranom razvojnom okruženju.

Najbolji test prijave na kraju nije onaj s najviše klikova. To je onaj koji rano prepoznaje stvaran ispad, razumljivo ga dokumentira i pri sljedećoj promjeni i dalje pouzdano funkcionira. Tko prijavu tretira kao jasno modeliran poslovni proces, ne štiti samo obrazac. Štiti pristup poslu koji čeka iza njega.