Tässä mietteitäni siitä että kuinka lähtisin kehittämään testausautomaatiota?
Vaihe 1, Onko automatisointi mahdollista tässä tapauksessa?
Ensimmäisenä tulisi selvittää että onko halutunkaltaista testausta mahdollista automatisoida käytössä olevien resurssien puitteissa ja verrattuna käsin tehtävään testaukseen. Käytännössä tämä tarkoittaa että pitää ottaa selvää testausrajapinnoista ja jos sellaisia ei ole valmiina niin sitten saada arvio kuinka kauan haluttujen rajapintojen tekeminen kestää. Tähän vaikuttaa tosi paljon tuotteen laatu, käytetty teknologinen alusta, testauksen näkökulma ja henkilöiden kokemukset. Tällaisessa auttaa paljon keskustella osaavan koodarin kanssa. Täytyy muistaa että vaikka kuinka haluaisi automatisoida jotain niin joskus joutuu vaan nostamaan kädet pystyyn ja toteamaan että tämä on järkevämpää testata käsin.
Vaihe 2, Ensimmäisen automatisoidun testin ajaminen
Yleensä sen ensimmäisen automatisoidun testin ajaminen on isoin harppaus. Koska jos yhden testin voi automatisoida niin yleensä se seuraava vähän erilainen onnistuu paljon helpommin. Mutta mielestäni kannattaa aloittaa yhdestä helposta ja lisätä pikkuhiljaa ominaisuuksia jotta testiautomaatioympäristö pysyy kokoajan toimivana. Jos testiautomaation päästää repsahtamaan niin kohta se on ihan mahdoton korjata sillä kaikki sen ympärillä tuppaa muuttumaan niin vaatimukset kuin koodikin. Siksi hyvien ja mahdollisimman pysyvän rajapinnan löytäminen alussa on avain asemassa.
Vaihe 3, Kohti toimivaa ja helposti käytettävää testiautomaatiota
Kun automaatiota laajennetaan niin samalla pitäisi pyrkiä viemään se helposti käytettävälle tasolle. Käytännössä tämä tarkoittaa avainsana tyyppistä lähestymistapaa tai ainakin hyvää kirjastoa jota on ohjelmallisesti helppo käyttää. En näe keyword ja hyvän kirjaston välillä juurikaan eroja ja mielestäni kirjasto on helpompi toteuttaa ja ympäristönä on tuttu ohjelmointiympäristö. Tällainen kirjastorajapinta on testiscriptien kirjoittajalle tuttu ja helppo käyttöliittymä ja siten helpottaa käyttöönottokynnystä ja käytettävyyttä yleensäkkin koska työkalut on tuttuja entuudestaan.
Testien ylläpidettävyyttä voi parantaa esim. Testien kirjoittamisen koodaussäännöillä jotka ovat tarpeen varsinkin jos käytössä on TTCN-3 tyyppinen ratkaisu. Lisäksi testejä voi generoida automaattisesti erillisillä testigeneraattoreilla (Esim. OSMO tai Qtronic) jos on tarvetta laajempaan kattavuuteen. Myös on mahdollista tehdä graafisia käyttöliittymiä vaikka domain-specifin mallinnuksen avulla (Esim. MetaEdit+) joiden avulla on helpompi visualisoida testien tekoa ja ajoa. Visualisoinnin avulla testien tekeminen on yleensä paljon nopeampaa ja lisäksi helpompi omaksua jopa ei teknisten henkilöiden.
Vaihe 4, Automatisoi loppuun asti
Jos testien suorisut on 20 kohdan tee-näin-lista niin voit olla varma että se tulee tehtyä vain äärimmäisessä hädässä tai pakosta. Tee mieluummin bat tai sh tiedosto jolla koko ketju on automatisointu. Ja esim regressiotestit pitäs pyörähtää joka yö ilman että kenenkään tarvii käsin koskea mihinkään. Samoin smoke testit pitäs pyörähtää joka kommintin yhteydessä täysin automaattisesti ja valittaa isoon ääneen jos ei mene läpi.
Vaihe 5, raportoi riittävästi mutta ei liikaa
Kun testien suoritus on automatisoitu raportteja on helppo kirjoittaa ohjelmallisesti. Tässä kannattaa kuitenkin miettiä mitkä luvut ja mittarit on tärkeitä. Tärkeää on kuitenkin että jos on käytössä jokin testauksen suoritustyökalu niin raportti menee suoraan sinne ilman käsin tehtävä copy-pastea. Tällöin raportit on väkisin ajan tasalla. Raportoinnissakaan ei kannata keksiä pyörää uudestaan vaan käyttää kaikkea mahdollista olemassa olevaa apuna. Esim. Hudson build serverin löytyy plugineja jotka auttaa.
Vaihe 6, Kouluta muut
Harvoin kukaan tekee testiautomaatiota pelkästään itseään varten. Siksi on tärkeää kertoa muille mitä on tehnyt ja jos tarvetta niin kouluttaa heitäkin käyttämään sitä. On hyvin harvinaista että yksi ihminen yksi onnistuu tekemään jotain tosi hyvin siksi toisilta kannattaa kysyä kommentteja ja ottaa ne tosissaan.
Lopuksi
Kannattaa muistaa että kaikki on tapauskohtaista ja jokaiseen ylhäällä olevaan kohtaan löytyy kosolti kikkoja. Tuossa on minun näkökulmastani tärkeimpien asioiden lista, joka toivottavasti auttaa asioiden jäsentelyssä. Kerro kommenttiin jos jotain oleellista unohdin.
“Ensimmäisenä tulisi selvittää että onko halutunkaltaista testausta mahdollista automatisoida –.” Sanoisin mielummin järkevää, tehokasta, halvempaa. Teksti on hyvin pitkälti sen suuntainen, että automatisoitu testi on PAREMPI kuin manuaalinen. Mielestäni pitäisi ottaa näkökulma, jossa automaatio *tukee* testausta kokonaisuutena eikä tähtää testaukseen, joka tukee automaatiota.
“Jos testiautomaation päästää repsahtamaan niin kohta se on ihan mahdoton korjata sillä kaikki sen ympärillä tuppaa muuttumaan niin vaatimukset kuin koodikin.” Tämä johtaa vääjäämättä siihen, että testausautomaatio muuttuu kalliimmaksi kuin manuaalinen testaus. Jos taas pidetään automaatiota testauksen tukena, voidaan optimoida tämä automatisoitujen (ja sitä kautta auttamatta päivitystä vaativien) testien määrä.
“Siksi hyvien ja mahdollisimman pysyvän rajapinnan löytäminen alussa on avain asemassa.” Se johtaa siis siihen, että testausautomaation aloittaminen siirtyy myöhäisemmäksi ja myöhäisemmäksi, jolloin sen todellinen arvo häviää regression havaitsijana… Kuten koodikin, myös automaatiotestejä päivitetään. Tästä ei pääse eroon mitenkään, kun puhutaan koodista.
“Käytännössä tämä tarkoittaa avainsana tyyppistä lähestymistapaa tai ainakin hyvää kirjastoa–” Täysin samaa mieltä. Miksi tehdä asioista vaikeita, kun ne voi tehdä helposti. Tekemällä työkaluistamme sellaisia, että ne taipuvat helposti päivitettävään muotoon on yksi automaation kulmakivistä.
“–regressiotestit pitäs pyörähtää joka yö ilman että kenenkään tarvii käsin koskea mihinkään.” Automaatio ei mielestäni ole automaattista, mikäli jonkun täytyy koskea johonkin testien ajamiseksi.
“Kannattaa muistaa että kaikki on tapauskohtaista–” Hyvä pointti. Kaikki on aina kontekstiriippuvaista, joten ajatus mukana automaatiossa. Ja mitä tulee testausautomaatioon, niin mielestäni automatisoidut testit eivät ole testejä vaan tarkistuksia. Automaation yhteydessä testaaminen on yleensä tutkivanpuoleista, jotta saadaan ne testit ylipäänsä loihdituksi. Lisäksi itse testaus tapahtuu tuloksia analysoimalla. Eivät automaattiset testit tiedä onko jokin asia oikein ja jokin väärin: se tietää vain että jokin assertio ei täyty ja annetaan sille väriksi punainen. Vaikka kuinka paljon automatisoidaa, niin aina ihminen tekee päätökset! Kone vaan helpottaa antamaan dataa päätöksen tekemiseksi…
Testausautomaatio pitää sisällään monenlaista testausta, eikä kysymys ole aina “joko/tai”. Automatisaatio tuo usein lisäarvoa nykyiseen testaukseen. Funktionaalisen testauksen puolella simppeli capture-replay automatisoi jo melkoisesti ilman minkäänlaista muutosta olemassa oleviin prosesseihin. Samalla nämä talletetut testit voi ladata vaikka suorituskykytesteihin, tai vaikka tietoturvatesteihin. Samat testit tallennetaan tietenkin ehkä hieman valikoiden (esim vain failanneet testit) myös regressiotesteihin. Jopa julkaisun jälkeenkin asiakkailta voi tulla uusia nauhoituksia, eli siis uusia regressiotestejä.
Tässä esimerkkinä Codenomiconin capture-pohjainen malli-pohjainen testiautomaatioratkaisu:
http://www.codenomicon.com/defensics/traffic-capture-fuzzer/
Olen samaa mieltä. Testiautomaatiota voi tehdä hyvin monella tavalla. Mutta jos ei halua maksaa tuosta capture-fuzzerista niin saman saa tehtyä aika helposti Radamsallakin: http://code.google.com/p/ouspg/wiki/Radamsa