Automatizovano testiranje procesa prijave

Automatsko testiranje procesa prijave postaje banalno pitanje tek kada funkcioniše. Ako propadne nakon izdanja, zaposleni se suočavaju sa početkom smene, kupci se nalaze zaključani van korisničkog portala, ili dispečeri imaju posla sa blokiranom obradom narudžbina. Automatsko testiranje procesa prijave stoga ne znači jednostavno unošenje korisničkog imena i lozinke u obrazac. Znači ponovljenu proveru kritične tačke pristupa sa svim njenim pravilima, izuzecima, i bezbednosnim granicama.

Za mnoge timove automatizacija počinje jednim pozitivnim test slučajem: unosom važećih kredencijala, potvrdom prijave, i prikazom početne stranice. Ovo ima smisla, ali samo po sebi nije dovoljno kao jedini test. Greške prijave se često javljaju na ivicama: sa isteklim sesijama, blokiranim nalozima, novom metodom višefaktorske autentifikacije, ili ovlašćenjima koja više ne važe ispravno nakon promene uloge. Upravo ovi scenariji moraju biti pokriveni na planiran način.

Zašto prijava zahteva posebnu disciplinu testiranja

Prijava je istovremeno bezbednosna funkcija, tehnički interfejs, i ulazna tačka u tok rada. Greška može biti previše popustljiva, dozvoljavajući neovlašćen pristup. Nasuprot tome, može biti i previše stroga, blokirajući ovlašćene pojedince. Oboje je skupo: prvi slučaj stvara rizike za podatke i usklađenost, dok drugi izaziva zastoje, opterećenje podrške, i grozničava hitna rešenja.

Za veb aplikacije u igru dolaze dodatne zavisnosti. Prijava se često komunicira sa provajderom identiteta, sistemom pošte za resetovanje lozinke, MFA aplikacijom, ili direktorijumskim servisom. Kod desktop aplikacija za Windows, lokalna prava, mrežne veze, i statusi verzija mogu imati uticaj. Test koji gleda samo obrazac u pregledaču ne može pouzdano otkriti takve probleme integracije.

Zato bi tim pre početka bilo kakve automatizacije testova trebalo da definiše šta znači uspešna prijava u datom sistemu. Da li je dovoljna vidljiva početna stranica? Ili treba proveriti da li je učitan pravilan izbor zakupca, da li je korisnička uloga ispravna, i da li je prva zaštićena akcija zaista moguća? Za skladišni portal to bi bio, na primer, pristup prijemu robe. Za dispečerski sistem to bi moglo biti oslobađanje ture.

Automatsko testiranje procesa prijave: od modela toka rada do test slučaja

Dobra polazna tačka nije skripta, već model toka rada. Prijava se može opisati kao niz jasnih stanja: odjavljen, kredencijali preneseni, identitet potvrđen, MFA potreban, prijavljen, sesija istekla, ili nalog blokiran. Svako stanje uključuje dozvoljene akcije i očekivane odgovore sistema.

Iz ovog modela proizlaze test slučajevi sa poslovnom vrednošću. Standardni pozitivan slučaj spada ovde, ali i pogrešne lozinke, nepostojeći korisnički nalozi, i istekli linkovi za resetovanje. Ovde je važna očekivana povratna informacija. U slučaju pogrešnih kredencijala, aplikacija ne bi trebalo da otkrije da li imejl adresa postoji. Test stoga proverava ne samo da li se prikazuje greška, već i da li njen tekst i ponašanje ne pružaju nepotrebne nagoveštaje.

Mehanizmi zaštite od ponovljenih neuspešnih pokušaja posebno su relevantni. Nakon definisanog broja pogrešnih unosa, nalog može biti privremeno blokiran. Automatizovani test mora proveriti da li blokada zaista stupa na snagu, koliko dugo traje, i da li legitimni korisnik naknadno povraća kontrolisan pristup. Ovde je potrebna preciznost: test koji namerno blokira produkcijske naloge stvara više problema nego što rešava. Takvi scenariji spadaju u odvojeno test okruženje sa posebno kreiranim nalozima.

Zasebno razmatranje MFA, resetovanja lozinke, i Single Sign-On

Višefaktorska autentifikacija nije sitan detalj na kraju prijave. Menja tok rada. Test mora prepoznati da je nakon lozinke potrebna dodatna potvrda, i mora mapirati i uspešnu i odbijenu potvrdu. Za vremenski zasnovane jednokratne kodove, test okruženje zahteva kontrolisano rukovanje vremenom i tajnama. U mnogim slučajevima, test metod koji obezbeđuje provajder identiteta smisleniji je od rekreiranja pravog mobilnog telefona.

Resetovanje lozinke i Single Sign-On takođe bi trebalo da dobiju sopstvene test putanje. Za resetovanje, prenos poruke, jedinstvenost linka, period važenja, i naknadna prijava sa novom lozinkom su bitni. Za SSO, ključno je da li aplikacija ispravno kreira sesiju i čisto preuzima uloge nakon povratka od provajdera identiteta.

CAPTCHA predstavlja poseban slučaj. Namenjene su usporavanju automatizovanih napada i ne bi trebalo da se zaobilaze putem automatizacije testova. Umesto toga, smislena je test konfiguracija, zvaničan test ključ, ili obezbeđen izuzetak za test okruženje. Prevariti bezbednosne kontrole samo da bi test bio zelen nije strategija kvaliteta.

Izbor odgovarajućeg tehničkog sloja testa

Ne mora svaki test prijave da prolazi kroz pravi pregledač. API testovi mogu proveriti da li tokeni, sesije, poruke o greškama, i pravila blokade ispravno funkcionišu. Brzi su i pomažu u pronalaženju grešaka blizu logike autentifikacije. Testovi u pregledaču, s druge strane, pokazuju da li se polja, preusmerenja, kolačići, SameSite podešavanja, i vidljiva stanja uklapaju u stvarnom toku rada korisnika.

Za kritične aplikacije, kombinacija je smislena. Nekoliko end-to-end testova proverava kompletnu putanju koristeći pregledač. Ispod toga, ciljani API i integracioni testovi obezbeđuju varijante. Ovo smanjuje vreme izvršavanja i lažne alarme. Ko testira svaku zamislivu kombinaciju isključivo u pregledaču, često završi sa sporim test paketom čije održavanje troši više vremena nego što štedi.

Za desktop softver važi sličan princip. Automatizovan test ne bi trebalo samo da proverava da li se prozor otvara. Mora utvrditi da li nakon prijave postoji ispravna veza sa podacima, da li su prava korisnika aktivna, i da li je centralna radna maska dostupna. Ovo je posebno relevantno za aplikacije u skladištu ili proizvodnji jer radna mesta mogu imati različite mrežne uslove, veze sa skenerima, ili lokalne konfiguracije.

Bezbedno i ponovljivo rukovanje test podacima

Testovi prijave neizbežno rade sa kredencijalima. Produkcijski nalozi zaposlenih, pravi podaci kupaca, ili MFA tajne, međutim, ne spadaju nekontrolisano u test skripte, zapisnike, i snimke ekrana. Test nalozi moraju biti jasno označeni, minimalno privilegovani, i automatski obnovljivi. Lozinke i tokeni se obezbeđuju putem bezbednog upravljanja tajnama, umesto da se čuvaju u izvornom kodu.

Podjednako je važno čišćenje nakon izvršavanja testa. Ako test kreira nove sesije, revizione unose, ili blokirane naloge, test okruženje se mora vratiti u definisano početno stanje. U suprotnom, test u ponedeljak propada jednostavno zato što je izvršavanje iz petka ostavilo sporedne efekte.

Za kompanije sa poverljivim aplikacijama, mesto izvršavanja je takođe odlučujuće. Snimci ekrana maski za prijavu, test video snimci, i tehnički zapisnici mogu sadržati osetljive informacije. Samostalno hostovana test infrastruktura poput COCO može ovde imati smisla jer test podaci, izvršavanje, i dokazi ostaju pod sopstvenom kontrolom. Da li je ovo neophodno zavisi od potreba zaštite, ugovornih situacija, i internih smernica. Odvojena infrastruktura nije automatski najekonomičniji izbor za svaku aplikaciju.

Generisanje dokaza, ne samo zelenih kvačica

Izveštaj o testu bi trebalo da učini razumljivim za QA, razvoj, i poslovno odeljenje šta je testirano. Zelen status bez konteksta malo pomaže ako izdanje kasnije izazove pitanja. Korisni su stoga vremenske oznake, korišćeno test okruženje, test nalog, relevantni koraci, snimci ekrana u slučaju grešaka, i jasna poruka o grešci na svakodnevnom jeziku.

U ovom kontekstu, prikupljanje dokaza samo po sebi ne sme postati problem zaštite podataka. Lozinke, jednokratni kodovi, ID-jevi sesija, i lični podaci moraju biti maskirani u zapisnicima. Za snimke ekrana, možda će biti potrebno zamutiti određena područja. Ova pravila bi trebalo da budu deo test arhitekture, ne ručna doradu nakon incidenta.

Šta bi timovi trebalo prvo da automatizuju

Prioritet je vođen rizikom i učestalošću korišćenja. Prvo dolazi standardna prijava za najvažnije uloge, pogrešni kredencijali, odjava, i istek sesije. Zatim slede pravila blokade, resetovanje lozinke, MFA, i promene uloga. SSO, posebni zakupci, ili retke putanje izuzetaka mogu slediti kasnije, pod uslovom da njihov kvar ne zaustavlja odmah poslovanje.

Testovi spadaju u proces izdavanja. Izmene u obrascima za prijavu, kolačićima, ovlašćenjima, ili konfiguraciji provajdera identiteta trebalo bi da pokrenu odgovarajući test paket pre nego što verzija ode u produkciju. Dodatno, isplati se planirano izvršavanje u realističnom okruženju, na primer nakon promena infrastrukture ili obnavljanja sertifikata. Ovo pronalazi probleme koji nisu vidljivi u izolovanom razvojnom okruženju.

Na kraju, najbolji test prijave nije onaj sa najviše klikova. To je onaj koji rano otkriva stvarni kvar, razumljivo ga dokumentuje, i i dalje se može pouzdano izvršavati pri sledećoj izmeni. Ko tretira prijavu kao jasno modelovan poslovni proces, štiti više od samog obrasca. Štiti pristup poslu koji čeka iza nje.