Kirjautumisprosessin automaattinen testaus järjestelmällä

Kirjautuminen tuntuu banaalilta vasta, kun se toimii. Jos se lakkaa toimimasta julkaisun jälkeen, työntekijät seisovat vuoron alussa, asiakkaat asiakasportaalin edessä tai suunnittelijat estyneen tilauskäsittelyn edessä. Kirjautumisprosessin automaattinen testaus ei siis tarkoita vain käyttäjätunnuksen ja salasanan täyttämistä lomakkeeseen. Se tarkoittaa liiketoimintakriittisen pääsyn toistuvaa tarkistamista sen sääntöineen, poikkeuksineen ja turvarajoineen.

Monille tiimeille automaatio alkaa yhdellä positiivisella testitapauksella: syötä voimassa olevat kirjautumistiedot, vahvista kirjautuminen, näe etusivu. Se on järkevää, mutta riittämätöntä ainoana testinä. Kirjautumisvirheet syntyvät usein reunoilla: vanhentuneissa istunnoissa, lukituissa tileissä, uudessa monivaiheisessa tunnistautumisessa tai käyttöoikeudessa, joka ei enää toimi oikein roolinvaihdon jälkeen. Juuri nämä tapaukset on katettava suunnitellusti.

Miksi kirjautuminen vaatii erityistä testauskuria

Kirjautuminen on samanaikaisesti turvatoiminto, tekninen rajapinta ja sisäänkäynti työnkulkuun. Virhe voi olla liian salliva ja sallia luvattoman pääsyn. Se voi myös olla liian tiukka ja sulkea ulos oikeutetut henkilöt. Molemmat maksavat: ensimmäisessä tapauksessa syntyy riskejä datalle ja vaatimustenmukaisuudelle, toisessa seisokkeja, tukikuormaa ja hätäisiä erikoisratkaisuja.

Verkkosovelluksissa mukaan tulee lisäriippuvuuksia. Kirjautuminen kommunikoi usein identiteetintarjoajan, salasanan palautuksen sähköpostijärjestelmän, MFA-sovelluksen tai hakemistopalvelun kanssa. Windows-työpöytäsovelluksissa paikalliset oikeudet, verkkoyhteydet ja versiotila voivat vaikuttaa asiaan. Testi, joka tarkastelee vain lomaketta selaimessa, ei tunnista tällaisia integraatio-ongelmia luotettavasti.

Siksi tiimin tulisi ennen ensimmäistä testiautomaatiota määritellä, mitä onnistunut kirjautuminen tarkoittaa kyseisessä järjestelmässä. Riittääkö näkyvä etusivu? Vai on tarkistettava, onko oikea vuokralaisvalinta ladattu, onko käyttäjärooli oikea ja onko ensimmäinen suojattu toiminto todella mahdollinen? Varastoportaalille tämä olisi esimerkiksi pääsy tavaran vastaanottoon. Suunnittelujärjestelmälle se voisi olla kierroksen hyväksyntä.

Kirjautumisprosessin automaattinen testaus: työnkulkumallista testitapaukseen

Hyvä lähtökohta ei ole skripti, vaan työnkulkumalli. Kirjautuminen voidaan kuvata selkeiden tilojen sarjana: uloskirjautunut, kirjautumistiedot lähetetty, identiteetti vahvistettu, MFA vaaditaan, kirjautunut, istunto vanhentunut, tai tili lukittu. Jokaiseen tilaan kuuluu sallitut toiminnot ja odotetut järjestelmän vastaukset.

Tästä mallista syntyy liiketoiminta-arvoisia testitapauksia. Positiivinen vakiotapaus kuuluu joukkoon, mutta myös virheelliset salasanat, olemattomat käyttäjätilit ja vanhentuneet palautuslinkit. Odotettu palaute on tässä tärkeää. Virheellisten kirjautumistietojen tapauksessa sovelluksen ei tulisi paljastaa, onko sähköpostiosoite olemassa. Testi tarkistaa siksi paitsi sen, että virhe näytetään, myös sen, ettei sen teksti ja käyttäytyminen anna tarpeettomia vihjeitä.

Erityisen olennaisia ovat suojamekanismit toistuvia epäonnistuneita yrityksiä vastaan. Tietyn määrän virheellisiä syötteitä jälkeen tili voidaan lukita tilapäisesti. Automatisoitu testin on tarkistettava, tuleeko lukitus todella voimaan, kuinka kauan se kestää ja saako laillinen käyttäjä sen jälkeen jälleen hallitun pääsyn. Tässä tarvitaan tarkkuutta: testi, joka tahallaan lukitsee tuotantotilejä, luo enemmän ongelmia kuin ratkaisee. Tällaiset skenaariot kuuluvat erilliseen testiympäristöön, jossa on tätä varten luodut tilit.

MFA, salasanan palautus ja kertakirjautuminen erikseen tarkasteltuna

Monivaiheinen tunnistautuminen ei ole yksityiskohta kirjautumisen lopussa. Se muuttaa työnkulkua. Testin on tunnistettava, että salasanan jälkeen vaaditaan lisävahvistus, ja sen on kuvattava sekä onnistunut että hylätty vahvistus. Aikaperustaisten kertakoodien kohdalla testiympäristö tarvitsee hallitun ajan ja salaisuuksien käsittelyn. Monissa tapauksissa identiteetintarjoajan tarjoama testimenetelmä on järkevämpi kuin todellisen matkapuhelimen jäljittely.

Myös salasanan palautuksen ja kertakirjautumisen tulisi saada omat testipolkunsa. Palautuksessa merkitsevät viestin toimitus, linkin ainutkertaisuus, voimassaoloaika ja sen jälkeinen kirjautuminen uudella salasanalla. SSO:ssa ratkaisevaa on, luoko sovellus istunnon oikein ja ottaako se roolit siististi vastaan identiteetintarjoajalta palaamisen jälkeen.

CAPTCHAt muodostavat erikoistapauksen. Niiden tarkoitus on hidastaa automatisoituja hyökkäyksiä, eikä niitä tulisi kiertää testiautomaation kautta. Sen sijaan järkevää on testikonfiguraatio, virallinen testiavain tai suojattu poikkeus testiympäristölle. Turvakontrollien huijaaminen vain, jotta testi muuttuu vihreäksi, ei ole laatustrategia.

Sopivan teknisen testitason valinta

Jokaisen kirjautumistestin ei tarvitse kulkea todellisen selaimen läpi. API-testit voivat varmentaa, toimivatko tokenit, istunnot, virheilmoitukset ja lukitussäännöt oikein. Ne ovat nopeita ja auttavat löytämään virheitä lähellä tunnistautumislogiikkaa. Selaintestit puolestaan näyttävät, sopivatko kentät, uudelleenohjaukset, evästeet, SameSite-asetukset ja näkyvät tilat yhteen todellisessa käyttäjätyönkulussa.

Kriittisille sovelluksille yhdistelmä on järkevä. Muutamat päästä päähän -testit tarkistavat koko polun selaimella. Sen alla kohdennetut API- ja integraatiotestit varmistavat variantit. Tämä vähentää suoritusaikaa ja vääriä hälytyksiä. Se, joka testaa jokaisen kuviteltavissa olevan yhdistelmän yksinomaan selaimessa, saa usein hitaan sarjan, jonka ylläpito syö enemmän aikaa kuin säästää.

Työpöytäohjelmistoille pätee samanlainen periaate. Automatisoidun testin ei tulisi vain tarkistaa, avautuuko ikkuna. Sen on määritettävä, onko oikea tietoyhteys olemassa kirjautumisen jälkeen, ovatko käyttäjän oikeudet aktiiviset ja onko keskeinen työnäyttö saavutettavissa. Tämä on erityisen olennaista varasto- tai valmistussovelluksissa, koska työpisteillä voi olla erilaisia verkko-olosuhteita, skanneriyhteyksiä tai paikallisia kokoonpanoja.

Testidatan turvallinen ja toistettava käsittely

Kirjautumistestit työskentelevät väistämättä kirjautumistietojen kanssa. Tuotannon työntekijätilit, todelliset asiakastiedot tai MFA-salaisuudet eivät kuitenkaan kuulu hallitsemattomasti testiskripteihin, lokeihin ja kuvakaappauksiin. Testitilien on oltava selkeästi merkittyjä, minimaalisin oikeuksin varustettuja ja automaattisesti palautettavissa. Salasanat ja tokenit toimitetaan turvallisen salaisuuksien hallinnan kautta, ei säilytetä lähdekoodissa.

Yhtä tärkeää on siivous testiajon jälkeen. Jos testi luo uusia istuntoja, tarkastusmerkintöjä tai lukittuja tilejä, testiympäristön on palattava määriteltyyn lähtötilaan. Muuten maanantain testi epäonnistuu vain siksi, että perjantain ajo jätti sivuvaikutuksia.

Yrityksille, joilla on luottamuksellisia sovelluksia, myös suorituspaikka on ratkaiseva. Kirjautumisnäyttöjen kuvakaappaukset, testivideot ja tekniset lokit voivat sisältää arkaluontoista tietoa. Itse isännöity testi-infrastruktuuri kuten COCO voi olla tässä järkevä, koska testidata, suoritus ja näyttö pysyvät omassa hallinnassa. Onko tämä tarpeen, riippuu suojaustarpeesta, sopimustilanteesta ja sisäisistä ohjeista. Oma infrastruktuuri ei ole automaattisesti taloudellisin valinta jokaiselle sovellukselle.

Näytön tuottaminen, ei vain vihreitä merkkejä

Testiraportin tulisi tehdä QA:lle, kehitykselle ja liiketoiminnalle ymmärrettäväksi, mitä testattiin. Vihreä tila ilman kontekstia auttaa vähän, jos julkaisu myöhemmin herättää kysymyksiä. Hyödyllisiä ovat siksi aikaleimat, käytetty testiympäristö, testitili, olennaiset vaiheet, kuvakaappaukset virhetilanteissa ja selkeä virheilmoitus arkikielellä.

Tässä yhteydessä näytön kerääminen ei saa itsessään muodostua tietosuojaongelmaksi. Salasanat, kertakoodit, istuntotunnukset ja henkilötiedot on peitettävä lokeissa. Kuvakaappauksissa voi olla tarpeen sumentaa tietyt alueet. Näiden sääntöjen tulisi olla osa testiarkkitehtuuria, ei manuaalista jälkityötä poikkeaman jälkeen.

Mitä tiimien tulisi automatisoida ensin

Prioriteetti ohjautuu riskin ja käyttötiheyden mukaan. Ensin tulevat vakiokirjautuminen tärkeimmille rooleille, virheelliset kirjautumistiedot, uloskirjautuminen ja istunnon vanheneminen. Sitten seuraavat lukitussäännöt, salasanan palautus, MFA ja roolinvaihdokset. SSO, erikoisvuokralaiset tai harvinaiset poikkeuspolut voivat seurata myöhemmin, kunhan niiden epäonnistuminen ei välittömästi pysäytä toimintaa.

Testit kuuluvat julkaisuprosessiin. Kirjautumislomakkeiden, evästeiden, käyttöoikeuksien tai identiteetintarjoajan konfiguraation muutosten tulisi laukaista asiaankuuluva testisarja ennen kuin versio menee tuotantoon. Lisäksi kannattaa suunniteltu ajo todellisuutta vastaavassa ympäristössä, esimerkiksi infrastruktuurimuutosten tai sertifikaattien vaihdon jälkeen. Tämä löytää ongelmia, jotka eivät näy eristetyssä kehitysympäristössä.

Lopulta paras kirjautumistesti ei ole se, jossa on eniten klikkauksia. Se on se, joka havaitsee todellisen vian ajoissa, dokumentoi sen ymmärrettävästi ja voidaan silti suorittaa luotettavasti seuraavan muutoksen yhteydessä. Se, joka kohtelee kirjautumista selkeästi mallinnettuna liiketoimintaprosessina, suojaa muutakin kuin lomakkeen. Se suojaa pääsyä työhön, joka odottaa sen takana.