Testaajan rooli muutoksessa - ajatuksia Ohjelmistotestaus 2016 -tapahtumasta

Osallistuin tänään Ohjelmistotestaus 2016 -tapahtumaan, tällä kertaa vain kuulijana. Puhujat olivat kaikki omalla tavallaan kiinnostavia ja tällä kertaa ohjelmassa oli aikataulutettuna myös keskustelua pareittain ja kaikkien kesken, mikä ehdottomasti auttoi jäsentämään puheita ja saamaan päivästä enemmän irti.

Yksi päivän suurista teemoista oli testaajan roolin muuttuminen. Aiheesta keskusteltiin hieman jo etukäteen facebookin puolella, ja puheenvuorot kiteyttivät asiaa hienosti muutamastakin näkökulmasta. Anssi Lehtelä toi esiin eri roolien välisen kommunikaation, luottamuksen ja yhteisen päämäärän merkitystä, sekä käytössä olevan julkaisumallin vaikutusta testaukseen kohdistuviin vaatimuksiin. Keskeinen viesti oli että testaajalla on mahdollisuus vaikuttaa näihin asioihin mm. testattavuuden parantamiseksi. Sami Söderblom esitteli ajatuksia liittyen antihaurauteen, testauksen toimintaympäristön haasteisiin ja testauskulttuurin luomiseen, tuoden esiin mm. yhteistyön ja kaaoksen sietämisen merkitystä. Maaret Pyhäjärvi kertoi mm. testiautomaatioon liittyvästä roolituksesta ja roolien välisestä yhteistyöstä. Erkki Pöyhönen puhui alihankintaan ja monitoimittajaympäristöön liittyvistä haasteista, ja Antti Niittyviita palvelukokemuksen (miten toinen osapuoli kokee kohtaamisen) merkityksestä arvon luomisessa. Päivän kruunasi Helena Jeret-Mäen puheenvuoro siitä miten kasvetaan testausasiantuntijaksi tai kasvatetaan aloittelevista testaajista sellaisia.

Keskusteluissa testaajan roolin kehityksestä keskeisenä nähtiin automaation merkityksen kasvu, kommunikointitaitojen merkityksen kasvu, sekä tarve integroida testausta paremmin kehitystiimeihin ja tuoda testausajattelua myös sellaisiin asioihin kuin tarjouspyyntöihin ja arkkitehtuurivalintoihin. Puhuttiin siitä, miten tärkeää on löytää itse oma roolinsa (siihen liittyvät vaatimukset ovat kuitenkin osin organisaatiokohtaisia), olla valmis poistumaan mukavuusalueeltaan, oppimaan uutta, etsimään tietoa ja toimimaan myös aktiivisesti muutoksen luomisessa ja ohjaamisessa. Liiketoiminnan ymmärtäminen, tavoitteiden asettaminen sekä kyky palastella unelmia tavoitettavissa oleviin askeliin nähtiin myös taitoina joista on testaajalle paljon hyötyä pyrittäessä ohjaamaan muutosta tavalla jolla testauksen merkitys softaprojekteissa ennemmin kasvaisi kuin pienenisi. Oma aktiivisuus, joustavuus sekä uskallus kysyä ja ehdottaa vievät asioita eteenpäin.

Jäin itse vielä miettimään, miksi ja miten pitkään me testaajat pohdimme omaa rooliamme. Testaus on muuttunut viime vuosien kuluessa paljon, ja oletettavasti se on muuttunut myös aikaisempina vuosina. Esimerkiksi mobiilikäyttöliittymät ja IoT tuovat tällä hetkellä monen testaajankin työhön uudenlaisia haasteita, ja tällaisten asioiden kimpussa painivien testaajien määrä lienee kasvussa. Tänään lopulta lähinnä katsoimme yhdessä taaksepäin, koska puheenvuorot liittyivät esittäjiensä omiin kokemuksiin, eivät tulevaisuudenvisioihin. Toki esitetyt ajatukset olivat paikoin melko radikaalejakin ja monissa organisaatioissa edelleen utopiaa kaukaisesta tulevaisuudesta. 

Kuitenkin, muutos toimintaympäristössämme jatkuu, ja sitä myötä jatkunee myös testaajan roolin muutoksen pohtiminen. Uutta tulee nopeasti, samalla vanha muuttuu hitaasti. Ehkä testauksen kenttä entisestään fragmentoituu tehden entistä vaikeammaksi puhua testauksesta yhtä aikaa konkreettisesti, yleistajuisesti ja koko yleisöä palvellen.

Keitä lienevät he jotka toivovat testausaiheisilta tapahtumilta puheenvuoroja testaajan roolin muutoksesta? Etsivätkö he tukea toiminnalleen aallonharjalla, uudenlaisissa toimintaympäristöissä? Hakevatko he uutta suuntaa vanhoja toimintamalleja noudattavissa yrityksissä? Vertaistukea muuttuvassa maailmassa luovimiseen? Tapoja nostaa arvoaan potentiaalisten työnantajien silmissä? Keinoja muuttaa itse maailmaa? Mitä he tavoittelevat toivoessaan tämän aiheen käsittelyä, vai toivovatko he tavoitetta?

Miten saada paras hyöty irti testaajasta?

Työpanoksen mittaaminen on vaikeaa. Jollain tavalla työntekijöiden suoriutumista pitäisi seurata, mutta mittareilla on paha tapa vaikuttaa ihmisten suoriutumiseen paitsi hyvässä myös pahassa.

Testaajan työn arviointia hankaloittaa se, että se on niin riippuvaista muiden työskentelystä. Samoin helpoiten muodostettavat testaajan työssä onnistumisen mittarit ovat kaikki omalla tavallaan ongelmallisia.

Löytyvät bugit riippuvat paitsi testaajasta myös kehittäjästä, joten tietyssä aikavälissä löytyvien bugien määrä tai laatu ei välttämättä kerro kovin paljoa siitä, miten hyvin testaaja on aikansa käyttänyt. Jos testaajan työtä arvioidaan mittaamalla löytyvien bugien määrää, se kannustaa testaajaa tehokkaaksi löytämään virheitä, mutta ei suuntaamaan tekemistään oleellisimpiin asioihin - näin bugikanta saadaan helposti täyttymään pienen prioriteetin virheistä. Bugien merkittävyyden arvioiminen statistiikkaa varten taas on työlästä, ellei luoteta testaajan tai hänen kanssaan työkentelevän kehittäjän omaan arvioon bugien prioriteeteistä. Toisaalta tarkkakaan tieto bugien vakavuudesta ei anna tietoa testauksen tehokkuudesta, jos testaaja käyttää paljon aikaa sellaisten asioiden manuaaliseen läpikäymiseen, joiden testaaminen kannattaisi automatisoida.

Testauksen tehokkuutta voidaan mitata myös esimerkiksi sillä, miten suuri osa raportoiduista bugeista saadaan ratkaistua kerralla, kysymättä lisätietoja bugin toistamiseksi. Tämä vaatii kuitenkin suhteellisen huolellista bugiraportointijärjestelmän käyttöä, jotta statistiikkaa saadaan helposti kerättyä, ja siten mahdollistaa myös huijaamisen. Asiakkaan löytämien bugien määrä ja laatu kertoo paljon sisäisesti tehdyn testauksen onnistumisesta, mutta tämän mittarin käyttäminen on monella tavalla hankalaa: miten tieto asiakkaan löydöistä raportoidaan ja luokitellaan, ja miten hallitaan tieto järjestelmään tehtävien päivitysten vaikutuksesta sekä niihin liittyvien testikierrosten vastuista.

Testaajan mahdollisuudet käyttää aikansa hyödyllisesti riippuvat myös siitä, mihin tahtiin testattavaa valmistuu. Hänellä ei ole valtaa vaikuttaa siihen, tuleeko asiakasprojekteista hommia tasaiseen tahtiin, vai joudutaanko vuoroin käyttämään aikaa toissijaisiin tehtäviin ja vuoroin priorisoimaan projekteja. Jos siis mitataan sitä, miten suuri osa ajasta kuluu laskutettavien projektien parissa, kannustaa se toki priorisoimaan ajankäytössä asiakasprojekteja, mutta myös käyttämään näihin projekteihin tarpeettoman paljon aikaa silloin kun asiakasprojekteja ei ole tarjolla täysipäiväisesti. Jos taas mitataan sitä, miten hyvä tuntihinta saadaan tehtävästä työstä, kipeimmin testausta kaipaavat katastrofiprojektit päätyvät testaajan ajankäytön priorisoinnissa viimeiseksi. Entä miten pitäisi huomioida tuotekehityksen tukeminen, tämä työ kun hyödyttää useita asiakasprojekteja?

Asiakastyytyväisyyttäkään ei saavuteta pelkällä testauksella, vaan siihen vaikuttavat mm. projektipäällikön kommunikointitaidot ja määrityksen tekemiseen osallistuvien kyky ymmärtää asiakkaan tarpeet ja muotoilla ne ymmärrettävästi. Jos järjestelmää ei ole onnistuttu määrittämään ja suunnittelemaan täyttämään asiakkaan tarvetta, timanttinenkaan testaus ei tilannetta pelasta. Asiakkaan löytämillä bugeilla kun on merkitystä vain, jos ne ovat syy joka estää järjestelmää täyttämästä sitä tarvetta, jota varten se hankittiin. Jos tärkeimmät valituksen aiheet ovat luonteeltaan muutospyyntöjä, liikutaan alueella jolla testaajien rooli on usein tarkoituksenmukaisinta pitää melko pienenä - ellei häntä sitten tuoda jo määritysvaiheesta alkaen asiakasrajapintaan niin, että hänellä on aidosti mahdollisuus arvioida toteutuksen soveltumista asiakkaan liiketoimintatarpeisiin.

Voidaan myös yksinkertaisesti kysyä projektihenkilöstöltä rivikoodarista projektipäällikköön, onko yhteistyö testaajan kanssa koettu hyödylliseksi, ja millaisia puutteita siinä nähdään. Tällaisten kartoitusten kompastuskiveksi vain koituu helposti se, että kenelläkään ei ole aikaa paneutua ylimääräisiksi koettuihin asioihin, kun seuraavat projektit painavat jo päälle. Lisäksi subjektiivisiin arviointeihin liittyy myös persoonallisuuksiin liittyviä piirteitä, jotka tekevät arvioinnista ylipäätään epämääräistä.


Toisaalta, onko testaajan työn mittaamisella edes merkitystä, jos organisaatio ei osaa täysin hyödyntää testaajan työpanosta?

Pystytäänkö tekeminen projekteissa aikatauluttamaan niin, että testaajan työaika saataisiin mahdollisimman tehokkaasti hyödynnettyä, eli testattavaa saataisiin eri projekteista valmistumaan mahdollisimman tasaiseen tahtiin? Mahdollistavatko projektien aikataulut sellaisen testaamisen, että ammattitestaajista on oikeasti hyötyä?

Onko organisaation sisäiset laskutuskäytännöt muodostettu niin, että projektien kannattaa hyödyntää ammattitestaajia?

Miten testaajan työaikaa hyödynnetään parhaiten silloin, kun testattavaa ei ole? Onko sisäisiä kehitysprojekteja, jotka tuovat hyötyä asiakasprojekteille, tai muita aikataulultaan väljiä tehtäviä, joihin voi käydä käsiksi, jos ei testaamalla pysty olemaan oikeasti avuksi? Tuetaanko testaajien mahdollisuuksia kouluttautua suoriutumaan paremmin työssään? Onko kehittäjien mahdollista itsenäisesti pyytää tukea testaajalta, jos he kokevat sen hyödylliseksi jotakin toiminnallisuutta rakentaessaan?

Entä mitä testaukselta ylipäätään halutaan? Onko tarkoituksena vain etsiä bugeja niin pitkään kuin projektin aikataulu ja budjetti antavat myöten, vai onko tavoitteena esimerkiksi antaa projektipäällikölle mahdollisuus keskittyä työssään olennaiseen, helpottaa kehittäjien työtä, tai saada tieto ohjelmiston laadusta tietyllä ajanhetkellä?

Kun näihin kysymyksiin löytyy vastauksia, on myös relevanttien mittareiden rakentaminen varmasti helpompaa.

Testaamisen mielekkyydestä

Joskus kuulee ihmettelyä, miten kukaan voi haluta olla ohjelmistotestaaja. Sellaiselle, joka on joutunut muun työn ohessa kliksuttelemaan läpi liudan jonkun muun naputtelemia testitapauksia testaus varmasti näyttäytyykin tylsänä ja aikaavievänä tehtävänä, josta on vaikea sanoa, turhauttaako enemmän jos kaikki menee läpi, vai jos mikään ei toimi kunnolla.

Tämä on kuitenkin hyvin kapea näkökulma testaukseen. Hyvin tehty ohjelmistotestaus saattaa alkaa jo myyntivaiheessa kun mietitään, kuinka työläitä asiakkaan toiveet ovat täyttää. Testausnäkökulma on avuksi myös luotaessa ohjelmistomääritystä, sillä yksi keskeisimpiä hyvän määrityksen ominaisuuksista on että sen perusteella voi testata, täyttääkö ohjelmisto sille asetetut vaatimukset. Testaussuunnittelua on mahdollista käyttää myös toteutuksen tukena, sillä testitapaukset saattavat tarjota paitsi konkreettisen ja selkeästi jäsennellyn tavan lähestyä määritystä, myös eräänlaisen muistilistan poikkeustilanteista, joista ohjelmiston on selviydyttävä vaikka määritys ei niitä käsittelekään.

Toki testaustehtävien suorittaminen on välillä myös suunnattoman tylsää. Mutta harva työnkuva on pelkkää hupia. Siksi kai meille työstä maksetaan, että olemme hetkittäin valmiita tinkimään omasta mukavuudestamme saadaksemme jonkin tärkeän tehtävän tehdyksi. Testauksen tehtävä on suojella liiketoimintaa niiltä katastrofeilta, joita bugit voivat aiheuttaa, eikä sankaritekojenkaan tekeminen ole pelkkää riemua.

Testaamisen mielekkyyteen voi myös vaikuttaa. Testitapauksia voi suunnitella niin, että niiden läpikäynti on ennemminkin uteliaisuutta herättelevä kuin uneliaisuutta aiheuttava kokemus. Automatisointi saattaa joskus pelastaa tekemästä niitä puuduttavimpia tehtäviä. Mielekkyyden luominen ja ylläpitäminen testauksessa lieneekin yksi niistä testauksen tehtävistä, joilla ammattilaiset erotellaan harrastelijoista, ja joissa kovimmallakin asiantuntijalla on aina mahdollisuuksia kehittyä vielä paremmaksi.