Kuinka testaus kannattaa rakentaa - oppeja tutkivan testauksen työkurssilta vol 1

Minulla oli ilo päästä osallistumaan Maaret Pyhäjärven järjestämälle Tutkivan testauksen työkurssille. Kerään päivästä käteen jääneitä ajatuksia muutamaankin blogipostaukseen, joita toivoakseni saan puhtaaksikirjoitettua vielä lähipäivinä. Tarkoitus ei ole referoida koulutusta vaan jäsentää omia ajatuksia aiheen tiimoilta, eli tekstit ovat pitkälti omaa tulkintaani ja sen ympärille kietoutuvia ajatuksiani.

Kurssi oli rytmitetty niin, että lyhyitä teoriasessioita seurasi aina lyhyt paritestaussessio, jonka tulokset purettiin lyhyesti ennen siirtymistä seuraavaan teoriasessioon. Työskentelytapana tämä oli erinomainen, vaihtelu piti hyvin hereillä ja tekeminen konkretisoi läpikäytyjä asioita. Lisäksi paritestaus soi mahdollisuuden oppia parin tapaa testata, mikä toi mainion lisän kurssin antiin. Suosittelenkin lämpimästi kurssia kenelle tahansa testauksesta kiinnostuneelle.

Testasimme FreeMind-sovellusta, joka on ilmainen Java-pohjainen ideakarttatyökalu. Kukaan kurssille osallistunut ei ollut käyttänyt sitä aikaisemmin, mutta osalla oli kokemusta muista vastaavista sovelluksista.

Ad hoc -testaus

Ensimmäinen testisessiomme oli ad hoc -testausta. Saimme 25 minuuttia aikaa tutustua sovellukseen parhaaksi katsomallamme tavalla. Koska käytettävissä olevan ajan puitteissa ei ollut mielekästä lähteä tutustumaan dokumentaatioon, lähdimme yksinkertaisesti kokeilemaan, miten järjestelmä toimii. Tähän on oleellisesti kaksi mahdollista lähestymistapaa.

• Miettiä, mihin sovellusta on tarkoitus käyttää, ja lähteä kokeilemaan, kuinka hyvin se tämän tarpeen täyttää
• Katsoa, mitä toimintoja käyttöliittymästä löytyy, ja lähteä kokeilemaan, mitä ne tekevät

Ad hoc -testaus on hyvä tapa lähteä tutustumaan uuteen testauskohteeseen. Kun testaajalla ei ole juurikaan tietoa testattavasta toiminnallisuudesta, hän on vapaampi tekemään havaintoja. Esimerkiksi käytettävyyteen liittyvät omituisuudet jäävät ehkä helpommin kiinni, jos käyttäjän näkökyky ei ole ohjeiden ja määritysten tuomien odotusten rajoittama - useinhan loppukäyttäjäkään ei ole speksiä koskaan nähnyt. (Tämä ei tietenkään varsinaista käytettävyystestausta korvaa, mutta voi silti olla yksi kustannustehokas tapa parantaa käytettävyyttä.) Myös määrityksen lukeminen testausnäkökulmasta on helpompaa, jos on saanut jo hieman pyöritellä testattavaa järjestelmää.

Huono puoli ad hoc -testauksessa on, että kun toimintaa ei fokusoida millään tavalla, ei ole mitään takeita siitä, että sillä saavutettasiin relevantteja havaintoja. Keskeisiä toiminnallisuuksia saattaa jäädä testaamatta kokonaan, jos ne eivät ole käyttöliittymässä riittävän ilmeisesti tyrkyllä, ja testauksesta raportointi (muuten kuin löytyneiden bugien osalta) on vaikeaa. Lisäksi riski sille, että bugiraporttien joukosta löytyy käyttäjän virheestä tai ymmärtämättömyydestä johtuvia ihmeellisyyksiä, on suurimmillaan kun järjestelmää vain käydään summittaisesti läpi.

Myös käyntiin pääseminen uuden järjestelmän kanssa kestää jonkin aikaa, kun testaaja joutuu pohtimaan, mitä sen kanssa voisi yrittää tehdä ja mihin sitä voisi haluta käyttää, mutta tätä pidän itse väistämättömänä osana testausta. Oppiminen on prosessi joka vie aikaa, ja tehdäkseen hyvin testausta on opittava ja havainnoitava testattavaa kokonaisuutta. Ad hoc -testaus on siis parhaimmillaan testaukseen valmistautumista, ensivaikutelman hakemista testauksen kohteeseen, sekä ajatusten keräämistä testauksen suunnittelun tueksi.

Tavoitteellinen tutkiva testaus

Toiseen testisessioomme saimme tehtäväksi tietyn kokonaisuuden testaamisen. Ohjeena oli puolen sivun kuvaus kokonaisuudesta, joka kertoi, miten siihen pääsi käsiksi, mihin tarkoitukseen se oli rakennettu, sekä listasi siihen kuuluvat keskeisimmät toiminnallisuudet.

25 minuuttia kului nopeasti, ja vaikka toiminnallisuus oli meille uusi, pääsimme heti täysipainoisesti käsiksi työhön. Toki ohjelman toimintalogiikka oli tullut jo edellisen testisession yhteydessä hieman tutuksi.

Toiminnallisuus oli sen verran keskeneräinen, että paritestaus sujui varsin jouhevasti toisen testatessa ja toisen kirjoittaessa ylös havaintoja. Bugeja löydettiin lähes kaksinkertainen määrä edelliseen testisessioon verrattuna, ja tuntuma oli että ne myös olivat käytön kannalta relevantimpia.

Tutkivan testauksen etuja on useita. Tekniikkana se minimoi testaussuunnitteludokumentaation tarpeen viemättä kuitenkaan testaukselta suunnitelmallisuutta ja kurinalaisuutta. Näin vähäinen käytettävissä aika saadaan käytettyä mahdollisimman tehokkaasti, painottaen testausta eikä testausta ohjaavan dokumentaation luomista ja ylläpitämistä. Tutkiva testaus on myös hauskaa, se auttaa testaajaa pysymään valppaana ja tekemään siten myös sellaisia huomioita, joita suunnitteluvaiheessa ei ole osattu ennakoida.

Testaus käyttötapauksia (tai testitapauksia) vasten

Kolmanteen testisessioon saimme taas uuden rajatun kokonaisuuden testattavaksi. Tällä kertaa testauksen tueksi annettiin kahden sivun mittainen vaatimusmääritys, joka oli kirjoitettu luettelemalla kokonaisuuden keskeiset toiminnallisuudet sekä kuvaamalla askeleittain niistä jokaisen käyttö.

Kuten odottaa saattoi, mitä orjallisemmin testaajat seurasivat määritystä, sitä vähemmän bugeja löytyi. Määrityksessä kuvatut toiminnot pystyi kaikki viemään läpi virheittä. Kuitenkin niiden ympärille oli rakennettu käyttöliittymään yhtä jos toista, jonka käyttötarkoitus ei ollut käyttäjän näkökulmasta ollenkaan itsestäänselvä, eikä niiden kokeileminen vakuuttanut siitä että toiminnot olisivat valmiita. Kaiken lisäksi listan loppupäässä kuvattiin toiminnallisuuksia, joiden käyttäminen teki testimateriaalista oleellisesti monimutkaisempaa, ja täten tiettyjä listassa aikaisemmin kuvattuja toimintoja olisi syytä testata uudelleen listan läpikäymisen jälkeen. Tähän ei kuitenkaan testisession antaman ajan puitteissa ollut mahdollisuutta. Kenties testaus olisikin kannattanut tehdä takaperoisessa järjestyksessä.

Todettiin, että tällaista dokumettia voi käyttää testauksessa hyödyksi muutamallakin tavalla

• Dokumentti kuvasi keskeisten toimintojen käytön, joten se toimi tapana perehdyttää testaaja testattavaan kokonaisuuteen.
• Tällaista dokumenttia voisi jopa käyttää rajaamaan testauksesta pois dokumentin kuvaamat toiminnot. Työnsä vakavasti ottava kehittäjä on todennäköisesti testannut ne jo. (Pidemmän määrityksen kanssa näin ei luonnollisestikaan voida toimia. Tässä tapauksessa dokumentti näytti siltä kuin se olisi kirjoitettu pintapuolisen testauksen ohessa ikään kuin käyttöohjeeksi toiminnoille.)
• Mikäli dokumentti kuvasi korkeimman prioriteetin toiminnallisuudet, sitä voisi käyttää eräänlaisena muistilistana, johon palata myöhemmässä testauksen vaiheessa sen tarkistamiseksi, onko oleellisimmat toiminnallisuudet testattu riittävän perusteellisesti ja riittävän myöhäisessä vaiheessa. Esim. regressiotestauksen suunnitteluun se voisi olla toimiva työkalu.

Samat hyödyt voitaisiin kuitenkin saavuttaa muillakin tavoin. Esimerkiksi demosessiossa, jossa kehittäjä esittelee testaajalle rakentamansa toiminnallisuuden, testaaja saa sekä perehdytyksen toiminnallisuuteen että käsityksen siitä, mitä toimintoja kehittäjä on testannut. Tällaisen istunnon lisäetuna olisi testaajan mahdollisuus esittää kysymyksiä, jotka voisivat johtaa joko testaajan entistä parempaan testaukseen, tai siihen että kehittäjä löytäisi toteutuksestaan korjattavaa jo ennen varsinaisen testauksen alkua.

Mitä jäi käteen

Sekä päivän aikana käyty keskustelu että käytännön harjoitukset tukivat käsitystäni, että tehokkain tapa löytää bugeja on nimenomaan tavoitteellinen tutkiva testaus. Tämä ei kuitenkaan tarkoita, että tutkiva testaus olisi ainoa tekniikka, jota kannattaa käyttää. Ad hoc -testauksella on myös oma arvonsa haluttaessa löytää järjestelmään uusia näkökulmia. Lisäksi määritettyjen toiminnallisuuksien läpikahlaamiseen sekä työn priorisointiin myös rakenteeltaan melko perinteinen testaussuunnittelu puolustaa paikkaansa, kunhan suunnittelu tehdään järkevästi, riittävän karkealla tasolla. Yksityiskohtaiset ohjeet kun toimivat kuin laput silmillä, vaikeuttaen muiden asioiden huomioimista.

Myös paritestaus sekä testauksen jakaminen eri teeman ympärillä pyöriviin sessioihin vaikuttivat toimivilta tavoilta hakea tehoja testaukseen.

Myös testauksen automatisoinnista keskusteltiin lyhyesti. Erityisesti yksikkötestipuolella automatisointi on erinomainen väline, mutta järjestelmätestauspuolella sen käyttö on jossain määrin kyseenalaista. Automaation rakentaminen vie moninkertaisen ajan verrattuna manuaaliseen testaukseen, ja automaattitestien ylläpitäminen järjestelmän muuttuessa on työlästä. Tämä ei kuitenkaan tarkoita, etteikö automaattitesteilläkin voisi olla paikkansa myös järjestelmätestausvaiheessa. Kaikkea ei aina ole edes mahdollista testata käsin käyttöliittymästä, ja lisäksi joskus testiautomaatiota on mahdollista pienin variaatioin monistaa tavalla, joka parantaa testikattavuutta tai helpottaa testimateriaalin luomista niin, että testien kirjoittamiseen käytetty aika saadaan ainakin osin kompensoitua niiden ajamisen nopeudella. Lisäksi suhteellisen muuttumattomien kokonaisuuksien testauksen automatisointi voi tuoda regressiotestaukseen merkittävän avun. Oleellista automatisoinnissa onkin analysoida, missä siitä saavutetaan suurin hyöty, sekä tietenkin ymmärtää, ettei se yksin riitä testattaessa järjestelmiä, joita ihmisten on tarkoitus käyttää.