Testaus ja testiautomaatio on aiemmin mielletty lähinnä yhdeksi osaksi ohjelmistokehitystä, mutta digitalisaation kehityksen myötä aihe on tullut tutuksi lähestulkoon jokaisessa yrityksessä. Monessa tapauksessa testaaminen ja liiketoiminnalle kriittisten prosessien varmistaminen on pudonnut yrityksen syliin ostettujen järjestelmien mukana vähän yllättäen. Esimerkiksi pilvipohjaisiin järjestelmiin siirryttäessä ei ole välttämättä osattu ennakoida kuinka isosta ja pysyvästä muutoksesta testaamissa on kysymys.
Tilannetta vaikeuttaa se, että vaadittavassa laajuudessaan aihe on monelle yritykselle uusi eikä olemassa olevaa testauskulttuuria tai muuttuneeseen tarpeeseen skaalautuvia käytäntöjä vielä ole. Testausrupeamat ovat aiemmin hoituneet muutamien järjestelmäasiantuntijoiden johdolla ja kohdistuneet usein hyvinkin spesifeihin ja ennalta tiedettyihin muutoksiin. Mitään laajamittaista ja säännöllistä regressiotestausta ei ole tehty, tai sitä on tehty todella harvoin.
Kun järjestelmätoimittajien versiopäivityksiä alkaa yhtäkkiä valumaan vähintään kvartaaleittain ja kaiken testaamisen tapahduttava muutamassa viikossa, ollaan tilanteessa, jossa aiemmat käytännöt ja resurssit eivät enää riitä. Haastetta lisää kun järjestelmien liiketoimintaprosessit riittävän tarkasti tuntevia henkilöitä on yleensä vain kourallinen, koostuen suureksi osaksi liiketoiminnan asiantuntijoista. He toki tuntevat testattavat prosessit, mutta pitkässä juoksussa heitä ei voi kuormittaa testaamisella määräänsä enempää ilman negatiivista vaikutusta muuhun tuottavuuteen.
Kuvattujen haasteiden ja kasvavan testauskuorman kanssa päädytään nopeasti lopputulemaan, että testaukseen tarvitaan apua ja ison testaajajoukon sijasta järkevämmäksi lähestymistavaksi nähdään testiautomaatio.
Testiautomaatiotarpeen tiedostamisesta on usein pitkä matka tilanteeseen, jossa automaatio hoitaa mitään kokonaista osaa testaustarpeista. Yksi selkeä pullonkaula on tarvittavien resurssien kartoittaminen ja hankkiminen. Jos testauskokonaisuutta ja tarvittavan testauksen määrää oli aiemmin vaikea hahmottaa ilman suunnitelmallista työskentelyä aiheen parissa, niin vielä vaikeampaa on hahmottaa kaikkia testiautomaation vaatimuksia. Yhtäkkiä olisi saatava vastauksia siihen, millaisia kyvykkyyksiä tarvitaan, kuinka paljon niitä tarvitaan, kuinka kauan niitä tarvitaan, mistä niitä saadaan ja paljonko ne maksavat?
Tyypillisesti automaation käyttöönottoprojekti sisältää jonkinlaisen suunnittelu- ja valmisteluprosessin, jonka laajuus on usein suoraan verrannollinen yrityksen lähtötilanteeseen testauksen suhteen. Lopputuotoksena on vähintään testaussuunnitelma, riittävän yksityiskohtaisesti määritellyt käyttötapaukset, sekä tekninen analyysi testattavista prosesseista ja niiden soveltuvuudesta automatisoitavaksi. Lisäksi tarvitaan testiympäristöt, -käyttäjät ja -data. Lopuksi päätetään, miten asiat priorisoidaan, monitoroidaan, raportoidaan ja reagoidaan,sekä missä tätä kaikkea hallinnoidaan. Iso kasa erilaisia asioita osattavaksi useammallekin ihmiselle jaettuna.
Kun päästään teknisiin suoritteisiin, erilaisten kyvykkyyksien tarve kasvaa. Projektin tekninen toteutus vaatii infraosaajia, ohjelmistokehittäjiä ja testiautomaatioasiantuntijoita. Vaihtoehtoisesti voidaan valita jokin kaupallinen tuote, jolla osa haasteista saadaan valmiiksi taklatuksi.
Usein kaiken tarvittavan osaamisen määrä on niin vaikea hahmottaa etukäteen, että hankinta-, tai rekrytointipäätöksen jälkeen lähdetään etsimään sekalaista määrää konsultteja/henkilöitä ilman tietoa todellisesta osaamistarpeesta. Rekrytointiprosessit ovat tällöin usein tarpeettoman raskaita, vievät aikaa ja testiautomaation eteneminen käyttöönottopäätöksestä käynnistysvaiheeseen voi olla vielä useiden kuukausien – ja useiden testaussyklien – päässä.
Testing as a Service
Kuvitellaan jos esimerkiksi rakentamisen suhteen mentäisiin aiemman tyyppiseen hankintamalliin. Sivuutetaan vakiintuneet toimintamallit ja lasketaan itse tarvittavat resurssit seuraavalle kolmelle vuodelle tavoitteena saada toimitilat saneerattua. Suunnitellaan onnistuneesti kaikki tarpeet ja hankitaan ne onnistuneesti. Niinpä. Vaikeaa on jaa varmaan myös melko hidasta, kallista ja riskialtista.
Mitä jos käännetään asetelma toisin päin, entä jos testausta- ja testiautomaatioprojekteja voisi tilata ja toimittaa kuten putkiremonttia? Tai jos pilkotaan asiaa vielä pienempiin osiin. Miksi ostaa kerralla kokonainen projekti, jos ensi alkuun tarvitaan vain pienempi yksittäinen palikka, joka edistää asiaa hallitusti määränsä verran kerrallaan.
Tilaaja ostaa palveluna ja toimittaja huolehtii, että tilaajalla on aina projektin kulloisessakin työvaiheessa sillä hetkellä tarvittava ydinosaaminen käytössään. Työtä ja kustannuksia voidaan rytmittää ketterästi tilaajalle sopivimmalla aikataululla ja kapasiteetilla. Joissain tilanteissa palvelu voi olla muutama jatkuvasti projektissa tarvittava henkilö ja tarpeen tullen määrää voidaan skaalata tilanteeseen sopivaksi. Toisessa tapauksessa se voi olla yksi yleinen henkilöresurssi mallilla, jossa työpanoksen antaa tänään testimanageri, huomenna cloud-asiantuntija ja ensi viikolla testiautomaatiokehittäjä. Kolmannessa tapauksessa voidaan esimerkiksi sopia määrämittainen 2vko-1kk mittainen sprintti, jossa toimittaja toimittaa yhdessä määritellyn työmääräarvioon perustuvan työsuoritteen ja vastaa sen toteutumisesta (=remontti). Palvelu skaalaa kaikissa tapauksissa ylös ja alas. Tarpeen ja tilanteen mukaan.
Goforelta saat testiautomaatiota ketterästi palveluna
Nopeus ja ketteryys on suoraan toimintamallissa. Se ei sido tilaajaansa mihinkään muuhun kuin yhteen kioskiostokseen, joka voi olla vaikkapa tietty koulutus tai yhden käyttötapauksen automatisointi. Laskutus juoksee ainoastaan silloin kun tekeminen on käynnissä ja toimittaja varmistaa, että oikeanlainen osaaja varmistaa sovitun lopputuloksen. Yhden henkilön sijaan toteutuksen takana on aina isompi tiimi, josta löytyy kaikki tarpeellinen osaaminen mihin tahansa kohtaan projektin aikana.
Kasvata ohjelmistokehityksesi tuottavuutta testiautomaation avulla:
