Search
scrum
Testiautomaatio varmistaa onnistuneen kehittämisen

Niin kauan kuin muistamme, testiautomaatio on ollut testauksen saralla yksi kuumista perunoista. Tilanne ei vaikuta juurikaan muuttuneen 10-15 vuoden aikana. On toki yrityksiä, joissa testiautomaatio on ollut arkipäivää jo pitkään, mutta paljon on vieläkin yrityksiä, joissa testiautomaatiota ei tehdä lainkaan tai sen jalkauttamisessa on ongelmia. Syitä tähän on varmasti monia. Alla neljä yleisimmin kuultua syytä, miksi testiautomaation ottaminen käyttöön kehitysprosessissa tuottaa haasteita.  

Väite 1: ”Ei me voida aloittaa testiautomaation rakentamista vielä, koska kehittäminen on niin kesken.” 

Ketterässä kehittämisessä ja DevOps-maailmassa kehittäminen on aina lähtökohtaisesti kesken. Testiautomaation tulee tukea kaikkia kehittämisen vaiheita ja maturiteettiasteita. Testiautomaation – kuten myös manuaalitestauksen – tulee sietää kehityksen keskeneräisyyttä. On totta, että testitapausten päivittämiseen muuttuvassa tilanteessa menee aikaa. Päivittäminen muutostilanteessa on kuitenkin nopeampaa, kuin testiautomaation rakentaminen alusta asti vasta silloin, kun kaikki on valmista. 

Miten testiautomaatio rakennetaan?

Testiautomaatiota rakennetaan iteroiden ja rinnan kehittämisen etenemisen kanssa, jolloin siitä saadaan hyötyä jo kehittämisen alkuvaiheessa. Testiautomaation tekeminen ajatellaan osaksi kehitysprosessia, ei erillisenä tehtävänä tai pakollisena pahana.

Määritellään testiautomaatio osaksi tehtävän kokonaisuuden valmiuden määritelmää, DoD (Definition of Done). 

Huomioidaan kokonaisuuden tai muutoksen testattavuus jo osana määrittelyä ja kehittämistä, sekä testataan aikaisin ja usein (ns. shift left -testaus). Tärkeää on myös tehdä hyvä pohjarakenne ja perusta testiautomaatiolle, jotta ylläpidettävyys on helppoa. 

Väite 2: ”Meillä on niin kompleksinen ympäristö, ettei tähän voi tehdä testiautomaatiota.” 

Automaatiota voi ja kannattaa tehdä koko kokoonpanon lisäksi myös pienemmille osakokonaisuuksille. Tällöin myös virheiden jäljitettävyys ja kohdistaminen on helpompaa. Mikään ei ole niin monimutkainen ympäristö, etteikö siinä voitaisi hyödyntää testiautomaatiota. Täytyy löytää vain oikea taso sekä malli, jolla testiautomaatiota voi ja kannattaa tehdä. Yksi malli ei päde kaikkiin tilanteisiin eikä ympäristöihin. 

Miten testiautomaatio rakennetaan erityisen monimutkaisiin ympäristöihin?

Mietitään, mitä kannattaa ja voi automatisoida. Jos kokonaisuus on liian monimutkainen, automaatiota voidaan hyödyntää integraatioiden testaukseen tai vaikkapa testiaineiston luomiseen. Ulkopuolisia rajapintoja voi testauksessa tarvittaessa simuloida erilaisilla malleilla.  

Väite 3: ”Tähän vain menee rahaa ja takaisinmaksuaika on pitkä.” 

On totta, että alkuinvestoinnit voivat olla suuret. Esimerkiksi ympäristön pystytyksen ja perustan määrittelemisen aikana on enemmän menoja kuin tuloja. Toisaalta, kun pohjatyöt on tehty hyvin, uusien testien rakentaminen on melko nopeaa. Uusissa testeissä voi hyödyntää usein myös muiden testien osuuksia. On kuitenkin hyvä muistaa, että testejä pitää myös ylläpitää ja päivittää kehityksen edetessä, jotta niistä on hyötyä myös jatkossa. Tämäkin vaatii aikaa, rahaa ja resursseja. 

Miten testiautomaation takaisinmaksuaikaa voi nopeuttaa?

Takaisinmaksuaikaa (ROI) voi nopeuttaa sillä, että automaatiotakin rakennetaan pienissä paloissa. Tällöin hyötyä saadaan myös pitkin matkaa, eikä vasta lopussa. Tämä on mahdollista vain silloin, kun testiautomaatio on kiinteästi mukana kehittämisen prosessissa.

Usein unohdetaan, että jos regressiotestausta tehdään manuaalitestauksena, sekin maksaa. Testaajia harvoin myöskään motivoi samojen toiminnallisuuksien manuaalinen testaaminen viikoista tai jopa vuosista toiseen. Mikäli regressiotestit on automatisoitu, voidaan manuaalitestauksessa keskittyä muihin osuuksiin, esim. uusiin toiminnallisuuksiin, käytettävyysasioihin jne.  

Väite 4: ”Ei meillä ole tähän resursseja.” 

Ehkä yleisin ongelma kuitenkin on, että tekijät puuttuvat. Tässä voi olla useita eri näkökulmia: ei ole tarvittavaa osaamista tai on osaamista, mutta tälle tekemiselle ei ole varattu aikaa.  

Miten varmistaa testiautomaation resursointi?

Tiimissä on tarvittava osaaminen ja johdolta on tekemiselle myös tarvittava tuki. Testiautomaatiota arvostetaan ja se nähdään tärkeäksi ja tarpeelliseksi osaksi kehittämisen prosessia. Jos osaamista tai aikaa ei ole itsellä, kannattaa miettiä, voisiko aloittamiseen ostaa tukea ulkopuolelta. 

Miten lähteä liikkeelle?  

  • Tee suunnitelma, mitä ja miten kannattaa automatisoida.
    • Minkälainen kehittämisen prosessi on? 
    • Mitä testiautomaatiolla tavoitellaan ja miten sitä mitataan? 
    • Millä työkaluilla automaatiota tehdään? 
    • Tehkää testiautomaatiosta ensin PoC (Proof of Concept). 
  • Onko työhön vaadittavaa osaamista ja johdon tuki?
    • Testiautomaation tekeminen vaatii omaa teknistä osaamista. Usein kuitenkin unohdetaan liiketoiminnan osuus suunnittelussa. On tärkeää, että testiautomaation suunnittelussa ja kehittämisessä on mukana sekä teknistä että liiketoiminnallista osaamista. Tällöin tehdään oikeita asioita, joista saadaan paras hyöty. 
    • Huomioi myös resurssien vaihtuminen. Automaation kehittäminen ei saa olla henkilöitynyt, eikä koskaan vain yhden ihmisen varassa.  
    • Hyödynnä ulkopuolinen apu aloittamisessa, tilanteen analysoinnissa ja sparrailussa. 
  • Aloita pienesti, älä niele koko elefanttia kerralla.
    • Tässäkin iteratiivinen kehittäminen on paikallaan. Ensin kannattaa tehdä pohjatyöt, esim. Robot Frameworkissa kirjastot ja yhteiskäyttöiset avainsanat.  
    • Aloita kevyemmistä testeistä (ns. savutesteistä), joita voi käyttää esim. asennusten verifioimiseen. 
    • Laajenna sen jälkeen perusregressiotestisettiin, jossa on huomioitu liiketoiminnallisesti tärkeimmät toimenpiteet. 
    • Ota testiautomaatio mukaan jatkuvaan kehittämiseen.

Miksi testiautomaatioon kannattaa panostaa?  

Testiautomaatiolla saadaan testausprosessiin tehokkuutta, tarkkuutta sekä kattavuutta. Se mahdollistaa nopeamman julkaisuprosessin sekä palautteen saamisen. Jos halutaan päästä jatkuvaan julkaisumalliin, testiautomaatio on pakollinen osa kehittämisprosessia. Testiautomaatio ei kuitenkaan korvaa ihmissilmää ja manuaalisessa testauksessa saatavia hyötyjä, mutta testiautomaatio mahdollistaa testaajien paremman käytettävyyden sekä kustannustehokkuuden. 

Herättikö tämä ajatuksia?

Mikäli haluat keskustella lisää teidän tilanteestanne, ota meihin rohkeasti yhteyttä. Mietitään yhdessä, miten testiautomaatio saataisiin osaksi teidän kehittämistänne.

Tarja Kunnasvuo

TESTAUSPÄÄLLIKKÖ

Tarja on ISTQB-sertifioitu testauksen ammattilainen, jolla on monipuolista osaamista myös testauksen koordinoinnista sekä testauksen toimintatapojen kehittämisestä.

Tomi Cederqvist

QA-ASIANTUNTIJA

Tomi on toiminut useissa eri tuotekehitysprojektien rooleissa yli 20 vuotta. Tomin keskeistä osaamista ovat testauksen ohjaus ja kehittäminen, testiautomaatio sekä DevOps.

Reflector on ICT-talo, jonka ykköstehtävä on auttaa asiakkaitamme liiketoiminnan isoissa ja pienissä muutoshankkeissa. Ketterästi ja riippumattomasti.

Jaa artikkeli

Voisit pitää myös näistä:

Kokonaisarkkitehtuuri Reflector

Ota yhteyttä, mietitään yhdessä juuri teille parhaat ratkaisut

Täytä tiedot ja siirry lataamaan tutkimus

Kokonaisarkkitehtuuri Reflector

Get in touch!