Sattumanvaraisuutta kannattaa lisätä tarkokoin harkiten jotta on mahdollistai tulkita tuloksia. Esim jos palvelun köyttäjän ikä voi olla 15-120 vuotta, niin valitaan ikä joka testicasessa randomilla. Jos järjestelmässä ei saa olla ikään liittyvää logiikkaa ja sinne joskus tulee niin se ilmenee kyllä aikanaan testeissä.

Sattumanvaraisuutta voi lisätä hyvin monin tavoin. Alla pari tapaa ja työkalua joilla asiaa voi alkaa kokeilemaan. Järjestys on helpoimmasta vaikeampaan.

1. Laita testikoodiin luku random funktiolla rajoissa joissa sen ei pitäs vaikuttaa kyseiseen testiin

2. Blab työkalulla voi generoida validia rakenteellista koodia

3. Fuzzerit kuten Radamsa generoi näennäisen satunnaista dataa jota voi laittaa kohtiin joiden ei pitäisi mennä koskaan rikki. Esim. Julkiset rajapinnat

4. Mallipohjaisella testauksella voi lisätä helposti loogista sattumanvaraisuutta. Joko niin että generoidaan joka testiajon aluksi uudet caset tai ajetaan ns. Online mallipohjaista testausta. Osmo tester on halpa ja helppo työkalu

Aika: 15.2.2012 klo 13-16
Paikka: Elektroniikkatie 3 (auditorio), Oulu

Alustavat panelistit:
Ari Takanen, Codenomicon
Olli-Pekka Puolitaival, F-Secure
Antti Niittyviita, Prove
sekä pari muuta testausalan ammattilaista

Ilmoittaudu mukaan laittamalla nimesi listaan täällä: http://www.doodle.com/iknypgd3972qkxec

Tilaisuus on ilmainen, ja isäntänä toimii F-Secure

Lopuksi on tuttuun tapaan mahdollisuus ilmoittaa etsivänsä työn tekijöitä tai töitä.

Now we have planned first seminar and the main topic is surprisingly model-based testing (MBT). The idea is that morning is for people who are not familiar with MBT and afternoon is for people who wants to update their knowledge or hear what is state-of-the-art.

Full program and registration are available here

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.

OSMO tester lyhyesti

OSMO tester on helppokäyttöinen mallipohjainen testaustyökalu. Se ei vaadi erikoistaitoja java-koodauksen lisäksi.  OSMO on hyvä silloin kun haluaa ottaa jonkinlaista mallipohjaista testausta äkkiä käyttöön. Jos käyttää laajemmin ja haluaa parempia algoritmeja testien optimointiin niin kannattaa toki ostaa joku hyvä kaupallinen työkalu.

OSMO on LGPL lisenssin alainen eli ei saastuta omaa koodiasi kovassakaan käytössä. Itse työkalu on myös helposti laajennettavissa ja siihen on helppo kirjoittaa uusia algoritmeja ja muista laajennuksia vaikka visualisointi ja jäljitettävyyspuolelle.

Kokeile ja hämmästy kuinka helppoa mallipohjainen testaus on!!

Jos haluat lisätietoja niin mailaa ja kysy olli-pekka.puolitaival (at) vtt.fi

Suurin osa näyttää olevan tekstualisiin kieliin mutta graafisia tarjoaa ainakin: MetaEdit+ ja Whole Platform.

Tekstuaalisista kannattaa kokeilla ainakin MPS:ssää. En ole itse vielä kerennyt, mutta joku päivä.

Siitä vain kokeilemaan.

1. Testautomaatiotyökalujen valinnassa
2. Vipuvartena

Työkalujen käyttöön otossahan tärkeintä olisi että oikeasti mietitään mitkä työkalut on tässä relevantteja, eikä väkisin tehdä kaikkia tekemisen ilosta. Tottakai yrityksen on tärkeää määritellä jokin rajattu työkalusetti joka on ensisijaisesti käytössä ja josta valitaan projektikohtaisesti. Muutoin osaaminen hajautuu liikaa ja kaikki aika menee opetteluun. Tärkeää on myös sopia väli steppejä joissa tarkastellaan onko valittu linja oikea sen sijaan että pusketaan väkisin eteenpäin. Testausautomaation ei tahdota oikein  ymmärtää olevan ihan normaalin softakehityksen tapaista työtä ja että tismalleen samat menetelmät sopivat siihenkin.

Vipuvartena testausautomaatiota voidaan käyttää, niin että rakennetaan joku framework vaikka kuormitustestaukseen ja sitten testaaja alkaa tekemään sen avulla tutkivaa testausta. Aivan liian usein näkee että tehdään iso työ testiautomaation pystytykseen ja sitten sillä ajetaan vain pari positiivista testiä. Tottakai kannattaa tehdä myös tosi keljuja testejä, vaikka vaan tekemisen helppoudesta jos hyvä automaatio on käytössä.

Tutkivan testausautomaation periaatteet voisivat kuulua vaikka seuraavasti:

• Mietitään vapaasti mitä kannattaa tehdä ottaen huomioon käytössä oleva työkalusetti
• Lähdetään pienestä liikkeelle ja analysoidaan ollaanko menossa oikeaan suuntaan
• Kun on testien ajoympäristö käytössä niin hyödynnetään sitä myös tutkivaan testaukseen

PS: VTT:llä ollaan kehittämässä helppokäyttöistä ja nopeasti pystytettävää mallipohjaista testaustyökalua. Testiversio on jo saatavilla täällä.

Testaustapahtumissa pyöriessä kuulee voimakasta puhetta sertifikaatteja vastaan ja puolesta, riippuen puhujan taustasta. Tällaisen puheen kuunteleminen meinaa aiheuttaa turhaan ennakkoluuloja, vaikka itse koulutus ei ole kovin ihmeellinen.

Päällimmäisenä jäi mieleen että perustason koulutus tarjoaa kattavan yleiskuvankuvan ohjelmistotestauksesta. Tämä on hyvä siksi että yleensä töissä käyttää enemmän tai vähemmän eri keinoja, joten on joskus paikallaan kerrata kattavammin eri tekniikoita. Koulutuksessa ei keretä syvällisesti tutustumaan tekniikoihin mutta tulee toki ilmi eri konstien idea, eli miksi sitä tehdään ja mihin se sopii. Itselläni testausautomaatio on tuttu mutta esim. katselmointimenetelmät oli aika vähällä tiedolla.

Suosittelen käymään koulutuksen ainakin jos

• Olet testaaja ja haluat varmistaa että tiedät kaikki yleisimmät menetelmät
• Olet tekemisissä testauksen kanssa ja haluat yleiskuvan ohjelmistotestauksesta

Itse kävin Symbion järjestämän koulutuksen. Tulevista koulutuksista uutisoidaan TestausOSY:n sivuilla, ja jos tykkää suomen kielestä niin sellainenkin on tarjolla tääll.

Kirjoitelkaa toki kommenteihin omia kokemuksianne koulutuksista.