Miten pitäisi testata?

Esko Hannula 29.09.2015

Erehdyin taas kerran sekaantumaan keskusteluun, jonka aiheena oli ISTQB – tai lähinnä sen viat. Vallitsevan näkemyksen mukaan ISTQB on aikansa elänyt, jämähtänyt ja muutenkin turha. Moni kyseenalaistaa, onko siitä koskaan ennenkään ollut mitään hyötyä.

Keskustelusta jäi sellainen valitettavan tavanomainen ”näinhän se on, mutta mitä sitten?” –tunnelma. Testaajille tyypiliseen tapaan moni osaa varsin hyvin perustellen osoittaa ISTQB:n ongelmat. Se on helpompaa kuin esittää toimivia vaihtoehtoja ja perustella niiden paremmuus.

ISTQB syntyi aikoinaan ratkaisuksi ongelmiin, joiden olemassaoloa nykyinen ammattitestaajien sukupolvi ei välttämättä ole joutunut koskaan edes havaitsemaan. Ne ongelmat, joiden kanssa ammattitestaajat nykyisin painivat, eivät puolestaan todellakaan ratkea pelkän ISTQB:n avulla.

Vaikka testauksen tekemisen muodot ovat muuttuneet paljonkin, entisaikojen tasot, vaiheet, menetemät ja roolit ovat edelleen olemassa. Käymäni keskustelun provosoimana aloin pohtia erilaisia testaajarooleja, joita olen kohdannut menneisyydessä ja joita kohtaan nykyisin. Roolien kautta aukesi pelkistetynoloinen kuva testaamisen muutoksesta. Näyttää siltä, että nykyisin on neljä hyvin erilaista tapaa järjestää testaus.

Perinteinen tapa, jossa testipäällikön johtama ammattitestaajien joukko suorittaa testaussuunnitelman mukaisen testaustoimeksiannon ennenmmän tai vähemmän projektimaisesti organisoituna, on yhä voimissaan. Se saattaa vieläkin olla suosituin toimintatapa, vaikka se on jossain määrin luonnonvastainen ja varsin tehoton. Testaus on lähes aina reaktiivista: se joutuu sopeutumaan ja järjestymään sen mukaisesti, miten testauksen kohteen rakentaminen edistyy. Ei ole mikään ihme, että suunnitelmatestauksen toimintamalli on joutunut yhä enemmän ammattitestaajien epäsuosioon.

Suunnitelmapohjaisen testauksen suosittu muunnelma on ”liiketoimintatestaus”. Siinä testaustyön tekevät ammattitestaajien sijaan testauksen kohteen tulevat käyttäjät, joita kutsutaan liiketoimintatestaajiksi. Amatööritestaajat ovat harvoin kovin tuottavia, he eivät yleensä kykene negatiivisiin testitapauksiin
eivätkä koskaan suorita ei-toiminnallista testausta. Sen sijaan oman työnsä ymmärtämisessä he ovat ylivertaisia ammattitestaajaan verrattuna. Eniten ihmettelen kuitenkin sitä, että miksi organisaatioissa ylipäätään on varaa pitää työntekijöitä, joilla ei ole varsinaisia töitä tehtävänä vaan heidät
voidaan sijoittaa ”liiketoimintatestaajiksi”.

Suunnitelmapohjainen testaus oli aikoinaan merkittävä parannus verrattuna sitä edeltäneeseen ”testailuun”. Kun testattavat järjestelmät ovat tulleet isommiksi ja monimutkaisemmiksi, niiden rajat yhä sumeammiksi, keskinäiset riippuvuudet yhä dynaamisemmiksi ja kehitys- ja muutossyklit yhä lyhyemmiksi, suunnitelmaohjatusta testauksesta on tullut ongelma. Se maksaa paljon, kuluttaa valtavasti aikaa eikä edes löydä kaikkia kriittisiä virheitä.

Monet taitavat testaajat luulevat ratkaisseensa tuottavuusongelman. Tietääkseni ratkaisulla ei ole nimeä, mutta minä kutsun sitä nimellä sankaritestaus. Sankaritestauksessa yksi taitava testaaja työskentelee kehitystiimin mukana, vahvasti tutkivaa testausta ja testiautomaatiota hyödyntäen. Resepti on
tuottavuuden kannalta erinomainen. Sankaritestaus on ylivertainen tapa testata niin kauan kuin yksi testaaja riittää ja hän on erittäin pätevä. Jos henkilökemiat toimivat hyvin, sankaritestaus on skaalattavissa jopa kahden testaajan tiimiksi.

Sankaritestauksen juuret ovat ketterissä menetelmissä. Ketterään ajatteluun sopii hyvin ajatus scrum-tiimin jäsenenä olevasta monitaitoisesta, yhteistyökykyisestä testaajasta ja siinä kontekstissa sankaritestaaja on mielettömän tuottava. Sankaritestaajan on toki muistettava hämätä muita
piilottamalla koodaustaitonsa tai muuten hän joutuu aina kriittisillä hetkillä muihin töihin.

Ketterät menetelmät, joihin sankaritestauskin nivoutuu, ovat kohdanneet skaalautumisongelman. Se, mikä toimii hyvin pienellä, taitavalla tiimillä, ei toimikaan usean tiimin kokoonpanossa, johon kohdistuu monenlaista asiakas-, tuote- ja liiketoimintaohjausta. Sankaritestauksessa on samanlaisia
skaalautuvuusongelmia. Jos ketteriä tiimejä tarvitaan monta, yksi sankaritestaaja ei riitä eikä kaikkia testaustasoja voi yleensä hoitaa tiimin sisällä. Sankaritestaajan tärkein tekninen tuottavuustyökalu, testiautomaatio, käy uskomattoman kalliiksi, jos jokainen testaaja toteuttaa automaatioratkaisunsa
itse.

Sankaritestauksen pahin haaste on kuitenkin se, että sankaritestaajan älylliset ja taidolliset mitat täyttäviä testaajia ei ole maailmankaikkeudessa riittävästi. Testauksessa, kuten kaikissa tarpeellisessa ammattikunnissa joudutaan hyväksymään, että useimmat meistä ihmisistä ovat työssään melko
keskinkertaisia.

Haasteiden ei ole pakko jäädä ratkaisematta. Ketterien menetelmien skaalaamiseksi on viime vuosina ilmestynyt uskottavan näköisiä ratkaisumalleja, kuten Scaled Agile Framework. Testiautomaation tuottavuushaasteisiin on ilmaantunut jo aiemmin melko hyviä teknisiä ratkaisuja, kuten Suomessa suosittu Robot Framework. Testiautomaatioratkaisun kehittäminen ja ylläpito organisoidaan useissa yrityksissä jo omaan, erilliseen tiimiinsä, usein lähietäisyydelle jatkuvan integroinnin tai peräti jatkuvan toimituksen tekijöistä. Tutkivan testauksen lipunkantajat ovat viime vuosina keskittyneet kehittämään menetelmistöään suunnitelmallisempaan ja skaalautuvampaan suuntaan. Olemme päässeet opettelemaan uutta testauksen suunnitteluun ja organisointiin liittyvää terminologiaa.

Hetkinen! Tämä tuoksuu keisarin uusille vaatteille! Kun tehtävä työmäärä kasvaa riittävän suureksi, sen tekemiseen tarvitaan suurempi määrä ihmisiä. Kun ihmisiä on paljon, heidän keskinäinen viestintänsä muuttuu vaikeammaksi. Kun ihmisiä on paljon, heidän keskinäiset taito-, äly- ja ahkeruuseronsa ovat
huomattavat. Kun ihmisiä on paljon, heidän olemassaolonsa maksaa niin paljon, että sitä halutaan raportoida ja kokonaisoptimoida. Se, mitä tällä hetkellä tapahtuu ketterien menetelmien skaalaamisessa, johtaa vähitelleen salavihkaa varsin samanlaisiin rakenteisiin, hierarkioihin, prosesseihin ja dokumentteihin, joihin olemme perinteisten huonoiksi tuomitsemiemme menetelmien yhteydessä tottuneet. Toivon, että uudet vaatteet istuvat keisarille paremmin kuin vanhat.

Esko Hannula