Artikkelin on kirjoittanut Maaret Pyhäjärvi. Tämä teos on lisensoitu Creative Commons Nimeä-Epäkaupallinen 4.0 Kansainvälinen -käyttöluvalla.
Creative Commons -käyttölupa

Oletko kuullut virhekysynnästä (failure demand)? Tämä käsite on ollut maisemissa pitkään, mutta ehkä kuitenkin vasta etsii paikkaansa testaajan maailmankuvassa varsin keskeisenä asiana.

Virhekysyntä (failure demand) on sitä, että ei pureuduta syyhyn joka aiheuttaa ongelmia, vaan hoidetaan oireita – luoden tarvetta hoitaa ongelmia syyn edelleen jatkuessa. Käsite on kotoisin järjestelmäajattelusta ja sitä on alkujaan käytetty kuvaamaan tukifunktioon liittyvää kokonaisuuden kannalta epätervettä tilannetta, jossa tukipuheluiden määrän seuranta ohjaa lisäämään panoksia tukeen sen sijaan että sijoitettaisiin arvoketjussa korjaavaan kohtaan.

Testauksessa on paljon piirteitä, joiden vuoksi testaajan maailmankuvassa virhekysyntä voisi olla hyvä käsite säännöllisesti mieleensä muistuttaa. Kun löydämme virheitä ja autamme korjaamaan ne, opetamme samalla ohjelmistokehityksen kolleegoillemme että meihin voi luottaa vastaavassa asiassa tulevaisuudessakin. Kun meihin luotetaan ja jätetään omaa testausta vähemmälle, saadaan aikaan yhä enemmän virheitä löydettäväksi ja korjattavaksi. Pyörä pyörii ikuisesti. Ironista kyllä, osaavaa testausta tarvitaan ohjelmistokehityksessä mutta sen saatavilla oleminen luo sille yhä suuremman tarpeen ellemme aktiivisesti toimi sitä vastaan.

Kuinka toimia testauksen tarpeen kasvamista vastaan? Keskittymällä siihen että ohjelmistokehittäjien kyvyt ja mahdollisuudet itse testata ilman rinnalla toimivaa testauksen ammattilaista – erillistä testaajan roolia – kasvavat. Luomalla prosesseja, joissa erillinen testaus on joskus läsnä mutta ei aina turvaverkkona. Luomalla yhteisen rakentamisen tapoja, joissa testaaja ei tarkastele tuotosta jälkikäteen vaan on rakentajana mukana tarjoamassa toisen silmäparin ja erilaisen maailmankuvan kautta mahdollisuutta osua yhdessä yhteiseen maaliin.

Virhekysynnästä käsitteenä voidaan johtaa, että testaus ketterissä projekteissa joissa tätä asiaa erityisesti työstetään, ei tule olemaan lähelläkään sitä työtä jota perinteisissä projekteissa olemme testauksena tottuneet näkemään. Tämä lisää rekrytoivien esimiesten haastetta tiimiensä miehittämisessä, kun porukkaan tarvitaan tasapainoisesti kehittäjän ja testaajan ajatusmaailmoja, mutta erillisen testaaja-nimekkeen hyväksyminen tuottaa kokonaisuuteen heikkouksia.

Ensimmäisiä ratkaisuja on ollut vaatia testiautomaatiotaitoja rekrytoitavilta. Mutta haasteeksi muodostuu usein se että ohjelmointitaitoisia työntekijöitä on saatavilla vain rajallinen määrä suhteessa kokonaistarpeeseen. Yleensä niitä riittää vain makeimpiin projekteihin, kun taas maailmasta löytyy paljon myös perusohjelmistokehitystä. Sama haaste tosin pätee myös ohjelmistokehittäjiin – niitä kehittäjiä, jotka oikeasti osaavat rakentaa toimivia asioita asiakasnäkökulmasta ja testata löytyy yhtä lailla rajallisesti. Uskonkin siis, että monet organisaatiot tyytyvät –  vielä pitkään siihen että joukossa on osaamattomampia kehittäjiä ja heidän heikkouksiaan kompensoimassa automaatiota osaamattomia testaajia. Eivät vain tyydy vaan nauttivat hyvistä onnistumista fiksujen ei-oppikirjakokoonpanoin varustettujen tiimien tekemisessä, jossa muu kuin käsillä oleva on teoriaa eikä käytäntöä – virhekysyntää ei voi kenties poistaa vaikka sitä ei kokonaisuutena hyväksyisikään ohjaamaan omaa tekemistä.

Virhekysyntä käsitteenä ohjaa myös siihen, että rekrytointitilanteissa ei-automatisoivan testaajan pitäisi ehkä alkaa katsella paikkoja tuoteomistajatiimeissä. Ainakin oma kokemukseni on että iso osa sen tyyppisestä työstä jota olen testaajana tehnyt onkin osa ammattitaitoa, jota tuoteomistajilta odotetaan. Koska tuoteomistaja kuvaukseltaan on kuin supersankari kohtuuttomilla odotuksilla, oikea ja vasen käsi tuoteomistajatiimissä hieman erilaisin painotuksin voikin olla tarpeen. Samalla asiaa siirretään lopun tarkistuksista arvoketjussa ylävirtaan.

Muuttuvat käsitteet tekevät toistaiseksi rekrytointitilanteesta haastavan ei-koodaaville testaajille. Testaajia yleensäkin tarvitaan vähemmän kun alamme keskittymään siihen että emme suurilla massoilla korjaile asioita, joissa voisimme puuttua juurisyihin. Ehkä sitä auttaa jos itsekin ymmärrämme keskustella realistisesti kokonaisuudesta eikä vain testauksen tehtävistä?