Manuaalisen testauksen profiilin nostaminen

Testauksen automatisointi on manuaalisen testauksen suorittamista koneellisesti, jonkin testausohjelman avulla. Automaatio onkin muodostunut suureksi osaksi nykypäivän testausta ja sillä on vankkaa kannatusta läpi testaus-skenen. Lähes kaikki testaajat ovat vakuuttuneita automaation hyödyistä - myös minä. Kuinka moni enää kuitenkaan uskoo manuaalisen testauksen voimaan testauksessa?

Automaatiota arvostetaan suhteessa enemmän kuin manuaalista testausta: kun etsin manuaalisesta testauksesta kertovaa materiaalia, jokaisessa oli vähintään ohjeistus kuinka automatisoida nuo manuaaliset testit. On ilman muuta totta, että automatisoidut testit vievät vähemmän aikaa ajaa, kunhan ne on toteutettu. Onko kuitenkin jokin kuitenkin pudonnut kelkasta matkan varrella, koska manuaalinen testaus testauksena on maailman hienoin asia (puhtaasti oma mielipide eikä minulla ole tieteellistä faktaa tukemaan tätä väitettä)?

Testauksen automaation helppoutta korostetaan monessa paikassa (mm. Bhavian Turakhia esityksessään), vaikka helposti automaation toteuttaminen on huomattavasti vaikeampaa kuin manuaalinen testaaminen. Testausautomaation edut eivät siis suinkaan ole testit toteuttamisen helppoudessa, ainakaan kaikissa tapauksissa. Pentti Pohjolainen kirjoitta gradussaan:

Ennen kuin voidaan automatisoida, täytyy toimiva manuaalinen testausjärjestelmä olla olemassa. Sen täytyy sisältää vähintään seuraavat piirteet: Ensinnäkin yksityiskohtaiset testitapaukset sekä odotetut tulokset, jotka perustuvat vaatimusmäärittelyihin ja suunnitteludokumentteihin.

Tämä tarkoittaa käytännössä sitä, että sen lisäksi että pitää olla hyvä määrittely- ja suunnitteludokumentaatio, tulee tapaus pystyä testaamaan ylipäänsä. Lisäksi Pohjolainen viittaa siihen, että järjestelmän toiminta tulee olla ennustettavissa tarkkaan, että tiedetään mikä loppu tulema tulee tarkalleen olemaan. Automaatiota ei kannata tehdä ilman tarkistuksia. Manuaalisessa testauksessa tarkistuksen tulevat automaattisesti, kun tulosta tarkistetaan! (No menipähän saivarteluksi..)

Testausautomaatio on äärimmäisen kannattavaa silloin, kun samaa tapausta ajetaan useita kertoja. Jos puhutaan ketteristä menetelmistä, joissa iteraatioita on paljon, yönylitestit tuovat lisäarvoa ja ennustettavuutta, jne., testausautomaatio on tehokas työkalu. Jos verrataan manuaalisen testauksen kustannuksia iteraatiotilanteissa, ei manuaalisen testauksen kustannustehokkuus yllä lähellekään automaatiossa säästettäviä summia. Mitä tapahtuu, kun määrittely muuttuu? Mitä tapahtuu, kun muutetaan komponenttien nimeämispolitiikkaa? Mitä tapahtuu muutoksen yhteydessä? Jotain muuttuu! Kun testiautomaation kohteena oleva järjestelmä muuttuu, täytyy testi päivittää. Kun testi päivitetään, sen toiminta tulee ensin varmistaa jollakin tapaa että testi itse ei jää vialliseksi -> manuaalinen testaus. Kun tehdään automatisoitua testausta ketterissä menetelmissä, voidaan olla varmoja, että testien päivitystä tapahtuu. Kuinka suuret kustannukset aiheutuvat testien päivittämisestä, koestamisesta, uudelleenajamisesta? Kuinka "hauskaa" (lainatakseni herra Turakhiaa) testien päivittäminen on, kun koko sovelluslogiikka muuttuu?

Manuaalisen testauksen ollessa pääasiallinen lähestymistapa edellä mainitussa tapauksessa, voidaan manuaalisesti saada palaute nopeammin kuin automatisoiduissa testeissä. Automaation kannattava voimahan on sen "palautteen nopeus". Jos tämä voima katoaa, onko automaatiosta mitään hyötyä? Toki joitakin testitapauksia on vaan puhtaasti viisaampi testata automaattisesti, mutta näissäkään tapauksissa ei puhuta puhtaasta automaatiosta vaan manuaalisen testauksen tukena käytettävästä työkalusta, jossa testausta helpotetaan työkalun ominaisuuksilla. Hyvänä esimerkkinä on suorituskykytestaus, joka ei luonnistu ihan helposti manuaalisesti... vaikkakin mm. Sokoksen verkkokaupan case-esittelyssään kerrottiin koko kehittäjätiimin (noin 100 henkeä) tehneen viiden minuutin aikana pikaisen suorituskykytestin, jossa kaikki kirjautuivat verkkokauppaan, jne. Pointti on kuitenkin se, että manuaalinen testaus sitä tukevin työkaluin on usein tehokkaampaa kuin puhtaasti automaattinen testaus.

F-secure on yksi testauksen edelläkävijöitä Suomessa ja heidän automaation toteutustavat herättävät minussakin kateutta. Voiko kuitenkaan samaa mallia soveltaa kaikkialle? Onko järkevää toteuttaa automaatiota sellaisiin projekteihin, joissa kalenteriajassa on viikko testausaikaa ja määrittelyt ovat powerpoint-tasolla (onko kenellekkään tuttu malli?) tai toteutus on niin paljon myöhässä, että vesiputousmallinen projekti karsii taas testauksesta? Ei heilläkään kuitenkaan ole hylätty automaatiota vaan se tukee heidän manuaalista testaustaan ja toimii "takaporttina", jolla mahdollistetaan regression poissulkeminen mahdollisimman pian. Heidän testausprosessinsa on sen mallinen, että automaatio mahdollistaa kypsän softan pääsyn manuaaliseen testaukseen.

No, kaikki tämä puhe automaation ongelmista ei tarkoita sitä, että automaatio pitäisi karsia kokonaan pois. Ei suinkaan! Päämääränä on tuoda älykkyys takaisin testaukseen (oliko se se, mikä taannoin putosi kelkasta?). Älykkyydellä en suinkaan tarkoita teknistä tietämystä tai taitoa, vaan sellaista älykkyyttä, mikä testaajalla pitää olla: kyseenalaistava älykkyys. Voidaanko puhua älykkyydestä, jos työkalujen tarjoajat mainostavat manuaalista testausta vanhentuneeksi? Voidaanko puhua älykkyydestä, kun koko laadun pohjaksi muodostetaan yönylitestien vihreänä pitäminen? Voidaanko puhua älykkyydestä, kun mottona on testauksen automatisointi, jolloin myös testauksen suunnittelu on automaattista? Jos kaikki on automaattista, niin mihin sitä älykkyyttä itse asiassa tarvitaan edes? (Onnistuinko puhumaan itseni pussiin...)

Sivusin aiemmin manuaalisen testauksen palautteen "hitautta" verrattuna automaatioon. Minulle on itselleni tuputettu teesiä "automaatiolla palaute on sekunteja, kun manuaalisella se on päiviä". Mitä tapahtuu, kun automaattista testisettiä pitää päivittää ja kyseinen setti voidaan ajaa vasta seuraavana päivänä? Testataan se manuaalisesti, kun kerran samoilla spekseillä se automatisoidaankin. Palaute on jopa nopeampi. "Automaattiset raportit", joku sanoo. Muun muassa Quality Center, Microsoftin Test Manager ja Test Runner ovat yksi keino palautteen nopeuttamisessa. Eikös se vähän niin kuin syö automaatiolta sen pääteesin? Tokihan pitkissä iteraatioissa automaatio on kustannustehokkaampi ja se huomaa regression nopeammin. Näissä tilanteissa se tulee kuitenkin ajatella työkaluna, jolla annetaan enemmän aikaa manuaaliseen testaukseen. Manuaalinen testaus huomaa erilaisia vikoja kuin automaatio, ja yleensä automatisoidaan ne tapaukset, missä manuaalisesti vikoja huomataan.

Ei manuaalinen testaus tietenkään mikään ihmelääke ole. Se ei ole idioottivarma, mutta ei sen pidäkään olla! Jos olisi olemassa idioottivarma testausmenetelmä, niin ei asiasta kiisteltäisi! Manuaalisen testauksen kompastuskiviä on (ja tulee aina olemaan) sen kustannustehokkuus iteratiivisessa projektimallissa. Älykkäällä manuaalisella testauksella voidaan kuitenkin löytää paljon enemmän kuin automaatiolla. Ei-älykäs testaus on usein se, mitä vasten automaatiota verrataan: testitapauksissa harpotaan, testien tarkistaminen unohtuu, jne. Tilastollinen tosiasia on (en pysty löytämään tämän julkaisijaa, mutta muistaakseni löytyy James Bachin webinaarista, en kuitenkaan mene oikeuteen tästä lainauksesta ;) ), että

80% kaikista automaatiotestitapauksista on kuraa eivätkä todellisuudessa testaa mitään.

Voiko manuaalisesta testauksesta sanoa kuitenkaan samaa? Jos järjestelmä on alhaalla, niin näyttääkö manuaaliset testit vihreää, koska tarkistus puuttuu?

Jos siis saataisiin manuaaliseen testaukseen integroitua joitakin automaation peruspiirteitä (eli nopea vaste ja raportoinnin helppous), voitaisiin manuaalista testausta nostaa voimakkaammin automaation rinnalle. Ehkä tällä tavoin manuaalisen testauksen piiriin saataisiin lisää huippuosaajia, jotka kehittäisivät testaustekniikoita ja -metodeita manuaalisen testauksen piirissä. Totta kai nykyiset testingdojot ja testingweekendit ovat nostaneet profiilia, mutta miten se saadaan nostettua samalle tasolle automaation tekniikan kehityksen kanssa? Miten voidaan tehdä manuaalisesta testauksesta seuraava ISO JUTTU? Miten saadaan ihmiset ymmärtämään, että testauksen tehokkuus ja eritoten kustannustehokkuus riippuu puhtaasti testaajien älykkyydestä eikä automaatiotyökalun käytettävyydestä?

Suorituskykytestaus integraatioprojektissa

Projektipäällikkö pyysi minua tekemään suorituskykytestaussuunnitelman integraatioprojektiin. Ongelma on vain se, että meiltä puuttuu kokonaan NFR:t. En ole koskaan aiemmin tehnyt suorituskykytestaussuunnitelmaa, joten nyt pitäisi sellaisen tekemiseen paneutua.

Ensiksi täytyy löytää vastaus kysymykseen "Miksi testaamme suorituskykyä?". Tässä tapauksessa varmaankin pyritään ensikädessä luomaan ne raamit, missä järjestelmä tällä hetkellä on. Tämän takia täytyisi siis siis rajata se alue, jossa suorituskykytestit tehdään ja selvittää arvio sielttä liikkuvista massoista. Jos suorituskyvyssä ilmenee ongelmia, niin ne on helpompi paikata ennen kun niistä muodostuu tuontannollisia ongelmia. Lisäksi tulevaisuuden kannalta tulee selvittää millaisia pullonkauloja saattaa olla tiedossa ja missä vaiheessa tuotteen elinkaarta.

Pullonkaula saattaa vääristää end-to-end prosessin kaikkien komponenttien suorituskykyä. Jos yhdessä kohdassa on pullonkaula, se tulee eristää ja poistaa. Tämä voi lisäksi vapauttaa yhden pullonkaulan aiheuttamia lisäpullonkauloja edempänä prosessissa.

Toinen kysymys mihin tarvitaan vastaus on "Miten testaamme suorituskykyä?". Integraatioprojektissa testaus kannattaa suorittaa työkalulla, joka pytyy muodostamaan halutun määrän sanomia halutussa ajassa ja lähettämään niitä haluttuun end-pointiin.

Lisäksi täytyy tietää, millaisilla testeillä testaamme suorituskykyä.

Käyttäjämäärätestaus (Performance): Integraatiotestauksessa on harvoin kysymys käyttäjän/käyttäjien suorittamasta toiminnasta vaan kahden järjestlemän keskenäisestä kommunikoinnista. Integraatiotestauksessa ei tarvitse siis ottaa huomioon käyttäjämäärätestausta sellaisenaan, vaan käyttäjien sijaan lisätäänkin kommunikoivia järjestelmiä (lähteitä/threadeja). Pyritään siis etsimään se kohta, jolloin lähteiden määrä alkaa aiheuttaa hitautta tai sovelluksen toiminta muuttuu.

Massatestaus (Volume): Intergaatio testauksessa on tärkeä tietää, kuinka paljon sanomia järjestelmä pytyy käsittelemään kerrallaan. Lisäksi on tärekää, että pyritänkö luomaan suorituskykytesti niin, että syötetään yhdestä lähteestä sanomia samanaikaisesti vai useasta yhtäaikaa. Tässä pyritään siis selvittämään,e ttä suoriutuuko järjetelmä vaadituista arvoista. Tässä tapauksessa emme tiedä, mitä vaatimuksia on, joten tämä jää tällä kertaa pimentoon.

Kuormitustestaus (Stress): Integraatiotestauksessa on tärkeää löytää ne tilanteet, jolloin sanomien/tapahtumien määrä on siis suuri, että se vaikuttaa järjestelmän käyttäytyimiseen. Tässä testauksessa voidaankin ottaa arvioitu sanomamäärä ja lisätä sitä 20% joka kierroksella (mahdolliseseti lisätä säikeiden määrää aina välillä). Pyritään lisäämään niin kauan, että järjestelmä ei enää toimi.

Yhtäaikaisuus (Concurrency): Integraatiotestauksessa yhtäaikaiset käyttäjät ei ole oleellisia, mutta yhtäaikaiset (toisensa kumoavat) tapahtuman ovat. Pyritään siis luomaan testi, jolla luodaan yhtaisiaisia, toisensa kumoavia toimintoja. Tällä voidaan selvittää esim. jonoihin kasaantuvia ristiriitaisia tapahtumia.

Suorituskykyä testatessa voidaan yhdistää sekä sanomien määrällä että lähteiden määrällä testausta, jolloin voidaan saada erilaisia testituloksia. Integraatiotestauksessa täytyy myös pyrkiä siihen, että testidata on tuotantoa vastaavaa.