Monimutkaisten B2B SaaS -ratkaisujen testaaminen: miten QA.techin agentit käsittelevät rooleja, käyttöoikeuksia ja dataohjattuja kulkuja

Yksinkertaisia tuotteita on helppo testata, ja nykyään tuskin kukaan enää rakentaa yksinkertaisia tuotteita. QA.techin kanssa työskentelemillämme B2B SaaS -alustoilla on yhteinen profiili: useita käyttäjärooleja erilaisine käyttöoikeuksineen, näyttöjä, joiden koko rakenne riippuu niiden taustalla olevista tiedoista, työnkulkuja, jotka kattavat tusinan verran vaiheita ja useita riippuvuuksia, sekä yhä useammin toiminnallisuutta, joka ulottuu verkkoon, rajapintaan ja mobiiliin yhden käyttäjäpolun aikana.

Juuri tällä alueella komentosarjapohjainen testiautomaatio maksaa eniten ja kattaa vähiten. Jokainen rooli moninkertaistaa polkujen määrän. Jokainen tietotila moninkertaistaa ne jälleen. Testikokonaisuus, joka kattaisi yhdistelmät rehellisesti, olisi tuotetta suurempi – joten käytännössä tiimit ohjelmoivat onnelliset polut, tarkistavat loput pistokokein manuaalisesti ja hyväksyvät aukon.

Tässä artikkelissa eritellään, miten QA.techin agentit käsittelevät kutakin näistä monimutkaisuuden ulottuvuuksista eri tavalla. Esimerkit perustuvat perehdytyksiin tiimeissä, jotka toimivat fintech-alalla, HR-teknologiassa, verkkokauppainfrastruktuurissa ja terveydenhuollossa – tuotteissa, joissa ”tallenna vain työnkulku” ei olisi koskaan toiminut.

Oikea ajattelumalli: perehdytät uutta kollegaa

Alla olevan kokonaisuuden ymmärtämisen mahdollistava näkökulma tuli itse asiassa asiakkaalta. QA-vastaava, joka seurasi agentin tutustumista alustaan ensimmäistä kertaa, kysyi: ”Toimiiko se siis kuin uusi työntekijä yrityksessä?” Juuri niin. Agentti liittyy tiimiisi samalla tavalla kuin terävä uusi laadunvarmistaja liittyisi – se tutustuu tuotteeseen, rakentaa siitä mielessään mallin, esittää kysymyksiä törmätessään epäselvyyksiin ja saa ensimmäisten viikkojensa aikana ajoittain korjauksia. Ero näkyy siinä, mitä tapahtuu seuraavaksi: sen rakentamasta ymmärryksestä tulee pysyvä tietämysgraafi, se ei koskaan unohda korjausta ja soveltaa jokaista asiayhteyden osaa kaikkiin tuleviin testeihin.

Tämä ajattelumalli on tärkeä, koska juuri monimutkaiset tuotteet hyötyvät ”uuden työntekijän” vaiheesta. Komentosarja tuntee yhden polun tuotteesi läpi. Koulutettu agentti tuntee tuotteesi.

Roolit ja käyttöoikeudet: opeta sille koko kartta ja anna sitten mikä tahansa avain

Käyttöoikeusjärjestelmät ovat kohta, jossa komentosarjapohjaiset testikokonaisuudet luovuttavat hiljaisesti. Jos alustallasi on ylläpitäjän, esihenkilön ja jäsenen roolit – tai viisikymmentä asiakaskohtaista roolikokoonpanoa – komentosarjapohjainen lähestymistapa edellyttää erikseen laadittua kattavuutta jokaista roolia varten, ja se vanhenee heti käyttöoikeuksien muuttuessa.

Agenttipohjainen lähestymistapa kääntää tämän toisin päin. Ensin agentti tutustuu tuotteeseesi ylläpitäjän tilillä, jolloin sen tietämysgraafi kattaa koko käyttöliittymän: jokaisen näytön, jokaisen toiminnon ja jokaisen olemassa olevan työnkulun. Sitten annat sille rajoitettuja tilejä. Jäsenenä kirjautuessaan agentti näkee vähemmän vaihtoehtoja – ja koska se tuntee koko kartan, se ymmärtää mitä puuttuu ja miksi sen sijaan, että pienempi käyttöliittymä hämmentäisi sitä.

Tästä eteenpäin käyttöoikeuksien testaus muuttuu keskusteluksi. Kerro agentille: ”Tämän käyttäjäryhmän jäsenenä sinun pitäisi nähdä vain X, Y ja Z”, niin se tarkistaa rajan. Ja tässä on yksityiskohta, josta tiimit pitävät: kun rajoitettu käyttäjä ei aidosti pääse näytölle, agentti kirjaa testin läpäistyksi – todisteeksi siitä, että käyttöoikeusjärjestelmä toimii. Vahvistat odotuksen kerran, agentti tallentaa sen, ja kokonainen turvallisuuden kannalta merkityksellinen varmennusluokka suoritetaan jatkuvasti ilman, että kukaan kirjoittaa sille komentosarjaa.

Tieto-ohjautuvat työnkulut: sama tavoite, eri tiedot, ei uudelleenkirjoittamista

Paljon tietoa sisältävissä SaaS-palveluissa työnkulku on harvoin vaikea osa – vaikeita ovat muunnelmat. Tietueen luominen on yksi testi; sen luominen viidelläkymmenellä erilaisella tietoprofiililla, joista joidenkin pitäisi onnistua ja joidenkin tulla hylätyiksi, on kohta, jossa manuaalinen testaus hukkuu ja komentosarjat muuttuvat ylläpitämättömiksi parametrimatriiseiksi.

Koska agentti toimii tavoitteiden eikä tallennettujen vaiheiden perusteella, tietojen vaihtaminen vaatii vain yhden ohjeen: ”Suorita tämä testitapaus uudelleen näillä tiedoilla.” Työnkulun tuntemus säilyy; vain syötteet muuttuvat. Kielteiset tapaukset toimivat samalla tavalla – kuvaile, mikä pitäisi hylätä, ja agentti tarkistaa, että tuote kieltäytyy silloin kun sen pitäisi. Kaikissa vapaatekstikentissä, joita jokainen monimutkainen tuote on täynnä, agentti hyödyntää sille antamaasi tuoteyhteyttä syöttääkseen järkeviä arvoja. Kun se arvaa väärin, korjaat sen ymmärrystä kerran sen sijaan, että paikkaisit komentosarjaa.

Pitkät työnkulut: agentti tuntee jo edellytykset

Yrityksille suunnatuissa SaaS-työnkuluissa on riippuvuusketjuja – kauppaa ei voi muokata ennen kuin kauppa on olemassa, pyyntöä ei voi hyväksyä ennen kuin joku lähettää sen, eikä kymmenettä vaihetta voi testata ilman yhdeksää ensimmäistä. Komentosarjapohjaisissa testikokonaisuuksissa tästä tulee alustuskoodia: testitietoja, alustuksia ja apukomentosarjoja, jotka muodostavat oman ylläpitotaakkansa.

Agentti käsittelee ketjuja samalla tavalla kuin ihminen: muistamalla. Kun se on suorittanut työnkulun, kaikki sen jälkeinen rakentuu tämän tiedon varaan. Pyydä sitä testaamaan sopimuksen alijakoja, ja se tietää, että sopimuksen luominen tulee ensin – koska se on tehnyt sen ja polku on tallennettu sen tietämysgraafiin. Edellytysten mukaiset työnkulut, kuten kirjautuminen, määritetään kerran ja niitä käytetään uudelleen kaikkialla. Mitä syvällisempiä työnkulkusi ovat, sitä tärkeämpää tämä kumuloituminen on, koska jokainen vaihe, jonka agentti jo tuntee, on vaihe, jota kenenkään ei tarvitse kirjoittaa uudelleen.

Eri käyttöliittymien väliset matkat: verkkosivusto, API ja mobiili yhdessä testissä

Modernien SaaS-palvelujen todelliset käyttäjämatkat eivät kunnioita testaustyökalujen rajoja. Käyttäjä määrittää jotain verkkosivustolla, webhook käynnistyy, tietue päivittyy API:n kautta ja ilmoitus saapuu mobiilisovellukseen. Useimmat tiimit testaavat jokaista käyttöliittymää erillisessä työkalussa erillisillä skripteillä ja toivovat, että rajapinnat toimivat.

QA.tech suorittaa nämä yhtenä päästä päähän ulottuvana testinä: työnkulku voi alkaa verkkotuotteesta, sisältää keskellä API-testivaiheita ja päättyä natiiviin iOS- tai Android-sovellukseen, jolloin matka varmennetaan tavalla, jolla asiakkaasi sen todellisuudessa kokevat. Alustoilla, joissa käyttöliittymien väliset rajapinnat ovat juuri se kohta, johon virheet piiloutuvat – maksut, ilmoitukset ja synkronointi – tämä sulkee aukon, jota käyttöliittymäkohtaiset työkalut eivät rakenteensa vuoksi pysty sulkemaan.

Mihin tämä kaikki johtaa

Monimutkaisten tuotteiden parissa työskentelevien tiimien toimintamalli on yhdenmukainen. Ensimmäiset viikot ovat yhteistyöhön perustuvia – agentti tutkii, kysyy ja saa korjauksia, samalla kun tiimisi oppii ohjeistamaan sitä. Sitten kysymysten määrä vähenee ja testauksen työmäärä irtautuu tuotteen monimutkaisuudesta: uudet roolit, uudet tietotilat ja uudet työnkulun vaiheet sulautuvat tietämysgraafiin sen sijaan, että ne synnyttäisivät uutta skriptityötä.

Tulos näkyy käytettyinä tunteina. Pricer, vähittäiskaupan teknologiayritys, jonka alusta on juuri tällainen monimutkainen ja dataintensiivinen tuote, mittasi 390 QA-tunnin säästön vuosineljännestä kohden siirrettyään varmennuksen QA-agenteille – näin vapautunut kapasiteetti voitiin käyttää julkaisemiseen testausinfrastruktuurin ylläpidon sijaan.

Tekniikan johtajat mainitsevat myös hiljaisemman hyödyn: agentin tutkimus tuo esiin yhdistelmiä, joita kukaan ei ajatellut testata. Kun kattavuus tulee järjestelmästä, joka on kartoittanut koko tuotteen, eikä testitehtävien työjonosta, ”oletko ajatellut tätä?” muuttuu kysymykseksi, jonka alusta esittää sinulle.

Onko sinulla tuote, joka rikkoo testaustyökalut? Ohjaa QA.techin agentit testiympäristöösi – ne on rakennettu juuri monimutkaisia tuotteita varten.