Avainsana: automaattitestaus

Testiautomaatio on viime vuosina rynninyt ohjelmistokehitykseen, ja syystä. Aika on rahaa: manuaalitestaukseen verrattuna automaatiolla säästetään paljon, kun ihmiset voivat keskittyä toisiin asioihin. Kuulostaa ihmiskunnan ja yritysten unelmalta: jälleen yksi tarkkuutta vaativa, työläs, toisteinen ja aikaa vievä vaihe voidaan jättää tietokoneiden huoleksi. Vaan onkohan tuo ihan niin yksinkertaista?

“Testausta tehdään monella tasolla”, huomauttaa Kari Lapinlampi. “Koodaritasolla tehdään yksikkötestejä tietyn ominaisuuden tarkistamiseksi. Automaatiossa sen sijaan testataan koko järjestelmää päästä päähän, ja pidetään sekä vanhat että uudet ominaisuudet koko ajan mukana kuviossa.”
Automaatiolla saadaan helposti ajettua myös aiemmat testit nopeasti ja täsmälleen samalla tavalla. Näin varmistetaan, etteivät uudet muutokset aiheuta uusia ongelmia. Jos esimerkiksi testataan verkkosivustoa, automaatiotestaus voidaan ajoittaa yöajalle, ja katsoa tulokset seuraavana päivänä. Koodin laatu säilyy hyvänä – ja samalla koko lopputuotteen.

“Pintapuolisella käyttäjätestauksella ei mitenkään päästä samaan laadunvarmistustasoon kuin automaattitestauksella”, sanoo Kari Lapinlampi. “Isossa projektissa olisi ylipäätään mahdotonta, että ihminen tekisi kaiken. Toki ihmistyötäkin tarvitaan kokeilevaan testaamiseen.”

“Ja määrittelyyn”, lisää Jarmo Pylkkö. “Testien määrittelyä ei voi automatisoida: siihen tarvitaan joku, joka osaa kuvata, millaisia käyttötapauksia tiettyyn ominaisuuteen liittyy.”

Kun kehitys – runko, rakenne ja käyttöliittymä – ovat riittävän pitkällä, testit kirjoitetaan toteutettaviksi käyttöliittymää vasten. Kooditason testausta toki tehdään alusta pitäen, esimerkiksi tietokannan käyttötapoja.

Testeillä ei tutkita vain toiminnallisuuksia, vaan myös suorituskykyä. Onko vaste riittävän nopea? Kestääkö järjestelmä kuormitusta? Miten häiriötilanne syntyy? Millaisia häiriöt ovat? Kehityksessä tulee päivittäin vastaan tilanteita, joissa on riskinä, että aiemmin tehty paikkaus lakkaa toimimasta. Ilman testausta ja koodinmuutoksia asiakas saattaa esimerkiksi saada virheellisen kuvan jonkin prosessin toiminnasta. Väärää dataa tarjoava, mutta oikealta näyttävä toiminto on vaarallisempi skenaario kuin se, ettei mitään tapahdu.

Kertakorjauksesta ikivihreisiin

Ohjelmistokehityksen tahti on muuttunut olennaisesti viime vuosina. “Nykyään uusia ohjelmistoversioita tulee melkein viikon välein”, sanoo Kari Lapinlampi. Ohjelmistoista on tullut ikivihreitä, evergreenejä: koko ajan julkaistaan pieniä parannuksia. “Uusienkin versioiden pitää silti olla testattuja. Versioiden julkaisukäytännöt ovat muuttuneet perusteellisesti: jatkuvan ohjelmistokehityksen CI/CD-putkessa uuden version julkaisu voi tapahtua nappia painamalla.”

Testi kertoo, onko mahdollista edetä. Koodari kehittää yksikkötestit, ja ne yhdistetään pääkehityshaaraan. Hiotulla testiautomaatiosofta Jenkins huomaa tämän, hakee uuden koodin ja ajaa testit. Jenkins on integroituna versionhallintaan. Jenkinsin kaverina käytössä on Python-pohjainen Robot Framework.

Ohjelmistoja on tarjolla paljon. “Jenkins valikoitui meidän käyttöömme, koska se on avointa lähdekoodia, ollut pitkään olemassa, hyvin tuettu ja taipuu mihin käyttöön tahansa”, toteaa Jarmo Pylkkö.

Vaikka asioita kuinka automatisoitaisiin, perusasiat pysyvät.
“Viestintä on todella tärkeää”, korostaa Kari Lapinlampi. “Kehittäjän ja testaajan välisen kommunikaation täytyy pelata.”

“Niin se tahtoo mennä, että ensin kehittäjä vie iloisena muutokset pilveen”, Jarmo Pylkkö nauraa. “Sitten testaaja lähestyy koodaria ja vetää tämän alas: lopetapa juhliminen ja palaa jäljittämään ja korjaamaan.”

(Kuvan piirteli parhaan ymmärryksensä mukaan Crayion-tekoäly. Emme ostaisi siltä käytettyä polkupyörää.)