Tunteet pinnassa

Nyt on 23. Toukokuuta ja istun Hotelli Haagan huoneessa. Olen Michael Boltonin vetämällä Rabid Software Testing -kurssilla. Kurssi on huikea ja palaan siihen vielä kattavammin myöhemmin.

Antti Niittyviita Provelta kommentoi minulle kirjoittamistekniikastani hotellin aulassa. Hänen mielipteensä kirjoittamistyylistäni oli se, että annan kerralla liikaa... Hmmmm... On totta että kirjoitan tunteella ja tunnin, mutta tämänkertainen kirjoitelmani ei ole tunnin mittainen. Tunteet ovat siinä kuitenkin mukana.

Hah! Tunteet eivät kuulu projektimaailmaan! Meillä pitää olla faktoja eikä tunteita! Mittarit kertovat meillä tarvittavat asiat ja muu on turhaa nyyhkytystä! Vai onko?

Suomessa ei ole kovin paljoa puhuttu testauksesta tunteiden pohjalta, mutta Michaelin mukaan nopean ja tehokkaan tutkivan testauksen yksi kulmakivistä on tunteiden liittäminen testaukseen. Tunteet toimivat toiminnan laukasijana. Usein viitataan intuitioon, perstuntumaan, jne. tapauksissa, joissa meillä ei ole suoranaista faktaa tai mittareita kertomaan asioista. Mittarina toimii siis henkilö itse. Esimerkkinä Michael käytti autolla ajamista: "Jos mietit, että ajanko liian lujaa, ajat liian lujaa." Ihminen saa tuntemuksia erilaisten tapahtumien johdosta, esimerkiksi hämmennys testatessa tarkoittaa, että jokin testauksen kohde on hämmentävä. Tämä toimii mittarina sille, että kaikki ei välttämättä ole kohdallaan.

Tämä siis puhtaasti sitä, mitä kurssilla opetettiin... Miten tämä siis kääntyy esimerkiksi meidän yrityksemme testausprosessiin? Kun prosessi on määritelty sellaiseksi, että automaatio näyttelee (tai tulee näyttelemään) suurta osaa, täytyy testauksen hallinnan luovia itselleen väylä tuonne. BDD tyyppisen prosessin johtaminen tunteella ei välttämättä ole se, mitä johtoporras tai asiakas haluaa kuulla. Voidaanko tunteen pohjalta kuitenkin tehdä bisnespäätöksiä? Tarvitseeko kaikki päätökset tehdä mittareiden pohjalta?

Jos testaaja saa tunteen, että "tässä on jokin vialla", eikö se ole maailman paras mittari? Jos jokin toiminnallisuus herättää epäluuloa, eikös se ole vahvempi mittari kuin "3 minor defectiä, joista kaksi korjataan 9. sprintissä"? Jos testaaja tuntee turhautumista siitä, että ei löydä toiminnallisuudesta enempää vikoja, kertooko se enemmän kuin "S-käyrän taittuminen toiminnallisuuden vikakertymää tarkasteltaessa"?

Kuinka siis esittää liiketoiminnalle arvio järjestelmään liittyvistä riskeistä, jos ne pohjataan mittareihin? Voidaanko testausprosessiin liittää tutkivan testauksen tuoma reaktiokyvyn kasvattaminen sekä tunteiden "kuunteleminen", mutta säilyttää iteraatiomallin automatisoitu regressiotestaus? Testausprosessiin tulisi liittää vaihe, joka on rinnan muun testauksen kanssa, joka käsittelee testattavaa tuotetta tutkivan testauksen näkökantilta, mutta joka tapahtuu rinnan kaiken muun testauksen kanssa. Heuristiset menetelmät ja sessiopohjainen testauksen hallinta voivat vapauttaa resursseja kankeista manuaalisista testausprosesseista ilman että manuaalisesta testauksesta luovutaan (ja tätäkin ajatusta maailmalla viedään eteen- ja taaksepäin). Tämä prosessimalli mahdollistaisi automaation tuoman jatkuvan ja nopeatempoisen raportoinnin etujen liittämisen tutkivaan testaukseen ja älykkääseen päätöksentekoon.

Mutta Antin mielipidettä kunnioittaakseni aion pitäytyä nyt lyhyessä pohdiskelussa ja vielä tämän viikon aikana aion avata sanaisaa arkkuani toisen merkinnän puitteissa. Siihen asti... tunteella mukana.