Avtomatizirano testiranje prijavnega procesa

Avtomatizirano testiranje prijavnega procesa postane banalna zadeva šele, ko deluje. Če odpove po izdaji, se zaposleni znajdejo pred začetkom izmene, stranke se znajdejo zaklenjene zunaj strankinega portala, ali pa se odpremniki soočajo z blokirano obdelavo naročil. Avtomatizirano testiranje prijavnega procesa torej ne pomeni preprosto vnosa uporabniškega imena in gesla v obrazec. Pomeni ponavljajoče preverjanje poslovno kritične vstopne točke z vsemi njenimi pravili, izjemami in varnostnimi mejami.

Za mnoge ekipe se avtomatizacija začne z enim samim pozitivnim testnim primerom: vnos veljavnih poverilnic, potrditev prijave in prikaz domače strani. To je smiselno, vendar samo po sebi ne zadošča kot edini test. Napake pri prijavi se pogosto pojavijo na robovih: pri poteklih sejah, zaklenjenih računih, novi metodi večfaktorske avtentikacije ali pravicah, ki po spremembi vloge ne veljajo več pravilno. Prav ti scenariji morajo biti načrtno pokriti.

Zakaj prijava zahteva posebno testno disciplino

Prijava je hkrati varnostna funkcija, tehnični vmesnik in vstopna točka v delovni proces. Napaka je lahko preveč popustljiva in dovoljuje nepooblaščen dostop. Obratno je lahko tudi preveč stroga in zaklene pooblaščene osebe. Oboje je drago: prvi primer ustvarja tveganja za podatke in skladnost, drugi pa povzroča izpade, dodatno breme podpore in improvizirane nujne rešitve.

Pri spletnih aplikacijah pridejo v poštev dodatne odvisnosti. Prijava pogosto komunicira s ponudnikom identitete, poštnim sistemom za ponastavitev gesla, aplikacijo za MFA ali imeniško storitvijo. Pri namiznih aplikacijah za Windows lahko na to vplivajo lokalne pravice, omrežne povezave in stanja različic. Test, ki gleda le obrazec v brskalniku, takšnih integracijskih težav ne more zanesljivo zaznati.

Zato bi ekipa pred začetkom katerekoli avtomatizacije testov morala opredeliti, kaj v posameznem sistemu pomeni uspešna prijava. Ali zadošča vidna domača stran? Ali je treba preveriti, ali je bila naložena pravilna izbira najemnika, ali je uporabniška vloga pravilna, in ali je prvo zaščiteno dejanje dejansko mogoče? Pri skladiščnem portalu bi to bil na primer dostop do prevzema blaga. Pri sistemu za odpremo bi to lahko bila sprostitev ture.

Avtomatizirano testiranje prijavnega procesa: od modela delovnega procesa do testnega primera

Dobra izhodiščna točka ni skripta, temveč model delovnega procesa. Prijavo je mogoče opisati kot zaporedje jasnih stanj: odjavljen, poverilnice posredovane, identiteta potrjena, zahtevana MFA, prijavljen, seja potekla ali račun zaklenjen. Vsako stanje vključuje dovoljena dejanja in pričakovane odzive sistema.

Iz tega modela nastanejo testni primeri s poslovno vrednostjo. Sem sodi standardni pozitivni primer, prav tako pa tudi neveljavna gesla, neobstoječi uporabniški računi in potekle povezave za ponastavitev. Pri tem je pomembna pričakovana povratna informacija. V primeru napačnih poverilnic aplikacija ne bi smela razkriti, ali e-poštni naslov obstaja. Test zato preveri ne le, ali se prikaže napaka, temveč tudi, da njeno besedilo in vedenje ne dajeta nepotrebnih namigov.

Posebej pomembni so zaščitni mehanizmi proti ponavljajočim se neuspešnim poskusom. Po določenem številu napačnih vnosov je mogoče račun začasno zakleniti. Avtomatiziran test mora preveriti, ali zaklep dejansko stopi v veljavo, kako dolgo traja in ali zakoniti uporabnik nato ponovno pridobi nadzorovan dostop. Tu je potrebna natančnost: test, ki namerno zaklene produkcijske račune, ustvari več težav, kot jih reši. Taki scenariji sodijo v ločeno testno okolje s posebej ustvarjenimi računi.

Ločeno obravnavanje MFA, ponastavitve gesla in enotne prijave

Večfaktorska avtentikacija ni manjša podrobnost na koncu prijave. Spremeni delovni proces. Test mora prepoznati, da je po geslu potrebna dodatna potrditev, in mora zajeti tako uspešno kot zavrnjeno potrditev. Pri časovno omejenih enkratnih kodah testno okolje zahteva nadzorovano ravnanje s časom in skrivnostmi. V mnogih primerih je testna metoda, ki jo zagotovi ponudnik identitete, bolj smiselna kot poustvarjanje pravega mobilnega telefona.

Ponastavitev gesla in enotna prijava naj prav tako dobita svoji lastni testni progi. Pri ponastavitvi so pomembni posredovanje sporočila, edinstvenost povezave, obdobje veljavnosti in poznejša prijava z novim geslom. Pri SSO je ključno, ali aplikacija po vrnitvi od ponudnika identitete pravilno ustvari sejo in čisto prevzame vloge.

CAPTCHA predstavlja poseben primer. Namenjena je upočasnitvi avtomatiziranih napadov in je ne bi smeli zaobiti prek avtomatizacije testov. Namesto tega je smiselna testna konfiguracija, uradni testni ključ ali zavarovana izjema za testno okolje. Preslepitev varnostnih kontrol samo zato, da test postane zelen, ni strategija kakovosti.

Izbira ustrezne tehnične testne plasti

Vsak test prijave ne rabi teči skozi pravi brskalnik. API testi lahko preverijo, ali žetoni, seje, sporočila o napakah in pravila zaklepanja delujejo pravilno. So hitri in pomagajo najti napake blizu logike avtentikacije. Testi v brskalniku pa pokažejo, ali polja, preusmeritve, piškotki, nastavitve SameSite in vidna stanja delujejo skupaj v resničnem uporabniškem procesu.

Pri kritičnih aplikacijah je kombinacija smiselna. Nekaj testov od začetka do konca preveri celotno pot z uporabo brskalnika. Pod tem ciljni API in integracijski testi zavarujejo variante. To zmanjša čas izvajanja in lažne alarme. Kdor testira vsako zamisljivo kombinacijo izključno v brskalniku, pogosto konča s počasnim testnim paketom, katerega vzdrževanje porabi več časa, kot ga prihrani.

Pri namizni programski opremi velja podobno načelo. Avtomatiziran test ne bi smel le preveriti, ali se okno odpre. Ugotoviti mora, ali po prijavi obstaja pravilna podatkovna povezava, ali so uporabniške pravice aktivne in ali je osrednja delovna maska dostopna. To je posebej pomembno za aplikacije v skladišču ali proizvodnji, ker imajo delovna mesta lahko različne omrežne pogoje, povezave skenerjev ali lokalne konfiguracije.

Varno in ponovljivo ravnanje s testnimi podatki

Testi prijave neizogibno delujejo s poverilnicami. Vendar produkcijski računi zaposlenih, resnični podatki strank ali skrivnosti MFA ne sodijo nenadzorovano v testne skripte, dnevnike in posnetke zaslona. Testni računi morajo biti jasno označeni, minimalno privilegirani in samodejno obnovljivi. Gesla in žetoni so zagotovljeni prek varnega upravljanja skrivnosti, ne pa shranjeni v izvorni kodi.

Enako pomembno je čiščenje po izvedbi testa. Če test ustvari nove seje, revizijske vnose ali zaklenjene račune, se mora testno okolje vrniti v določeno začetno stanje. Sicer test v ponedeljek odpove preprosto zato, ker je izvedba iz petka pustila stranske učinke.

Za podjetja z zaupnimi aplikacijami je odločilna tudi lokacija izvajanja. Posnetki zaslona prijavnih mask, testni videoposnetki in tehnični dnevniki lahko vsebujejo občutljive informacije. Samostojno gostovana testna infrastruktura, kot je COCO, je tu lahko smiselna, ker testni podatki, izvajanje in dokazi ostajajo pod lastnim nadzorom. Ali je to potrebno, je odvisno od potreb po zaščiti, pogodbenih razmer in notranjih smernic. Ločena infrastruktura ni samodejno najbolj ekonomična izbira za vsako aplikacijo.

Ustvarjanje dokazov, ne le zelenih kljukic

Testno poročilo naj QA, razvoju in poslovnemu oddelku omogoči razumeti, kaj je bilo testirano. Zelen status brez konteksta malo pomaga, če izdaja pozneje sproži vprašanja. Zato so koristni časovni žigi, uporabljeno testno okolje, testni račun, relevantni koraki, posnetki zaslona v primeru napak in jasno sporočilo o napaki v vsakdanjem jeziku.

V tem kontekstu zbiranje dokazov samo po sebi ne sme postati problem varstva podatkov. Gesla, enkratne kode, ID-je sej in osebne podatke je treba v dnevnikih maskirati. Pri posnetkih zaslona je morda treba zamegliti določena območja. Ta pravila naj bodo del testne arhitekture, ne ročno popravilo po incidentu.

Kaj naj ekipe avtomatizirajo najprej

Prioriteta je vodena s tveganjem in pogostostjo uporabe. Najprej pridejo na vrsto standardna prijava za najpomembnejše vloge, napačne poverilnice, odjava in potek seje. Nato sledijo pravila zaklepanja, ponastavitev gesla, MFA in spremembe vlog. SSO, posebni najemniki ali redke izjeme lahko sledijo pozneje, če njihov odpoved ne ustavi takoj poslovanja.

Testi sodijo v proces izdaje. Spremembe prijavnih obrazcev, piškotkov, pravic ali konfiguracije ponudnika identitete naj sprožijo ustrezen nabor testov, preden različica pride v produkcijo. Poleg tega se splača tudi načrtovana izvedba v realističnem okolju, na primer po spremembah infrastrukture ali podaljšanju certifikatov. Tako se odkrijejo težave, ki v izoliranem razvojnem okolju niso vidne.

Na koncu najboljši test prijave ni tisti z največ kliki. Je tisti, ki zgodaj zazna resnično napako, jo razumljivo dokumentira in se lahko zanesljivo izvede tudi ob naslednji spremembi. Kdor obravnava prijavo kot jasno modeliran poslovni proces, ščiti več kot le obrazec. Ščiti dostop do dela, ki čaka za njo.