Testiautomaation noidankehä

Aika monen asiakkaani ongelmat ovat ratkenneet testiautomaation avulla, tai niin he ovat kuvitelleet. Osalla on se kumma käsitys, että pelkästään jonkun vempaimen hankkiminen nopeuttaa ja parantaa testausta reilusti vanhaan tapaan verrattuna. Ennen kaikkea laajamittainen testauksen automatisointi on samanlainen kuin normaali softankehitysprojekti. Se vaatii arkkitehtuuria, määrittelyä, nimeämiskäytäntöjä, koodausta, testausta ja kokeilua.

Testauksen automatisointi vaatii paljon muuta kuin pelkän työkalun. Testausympäristön pitää olla stabiili, jotta se ei generoi omia satunnaisia haittatekijöitään automatisoijien iloksi keskellä testiajoa. Testidatan pitää olla myös kunnossa, koska muuten tulosten vertailussa on omia kivoja haasteitaan, jos testiajossa päästään edes sinne saakka. Monesti kannattaa pitää mielessä, että testiautomaatio on usein tilapohjaista: asiakas rekisteröityy, kirjautuu sisään verkkokauppaan, tekee ostoksia ja maksaa ne. Järjestelmän pitää olla tietyssä tilassa, jotta jonkin asian testauksen automatisointi olisi edes mahdollista.

Tavoitteeksi ei kannata asettaa, että koko testaus on 100% automatisoitu, vaan kannattaa pitää realismi mukana. Kehittäjän tekemä moduulitestaus on usein helpommin automatisoitavissa kuin ison järjestelmän systeemitestaus. Iso haaste on aina se, pystytäänkö automatisoimaan tarpeeksi, jotta automatisoidut testitapaukset eivät olisi käytössä pelkästään regressiotestauksessa, vaan auttaisivat jo uuden tai muutetun koodin testauksessa.

Parhaan työkalun demon olen nähnyt yhdellä toimittajalla. Hän esitteli, kuinka ensin luodaan malli. Tämän jälkeen työkalu generoi siitä koodin ja testit, jotka ajetaan koodin generoinnin jälkeen. Virheitä ei kuulemma löydy, koska koodi on niin hyvää. Olisin kyllä huolissani, jos tuollainen työkalu löytäisi edes yhden virheen.

Hyvää työpäivän jatkoa!