Testauksen tehtävänä on tuottaa tietoa. Yksi keskeinen tiedon muoto on ymmärrys siitä missä määrin testauksen kohteena oleva järjestelmä toimii toiveiden, odotusten ja määrittelyjen mukaisesti. Testaajana määrittelen virheen, ”bugin” James Bachin ja Michael Boltonin tapaan: se on mitä tahansa joka voi ärsyttää järjestelmää käyttäviä sidosryhmiä (bug is anything that might bug a user). Se sisältää yhtä lailla puuttuvia ominaisuuksia, väärin suunniteltuja ominaisuuksia kuin toimimattomiakin ominaisuuksia, tai piirteitä jotka millä tahansa tapaa estävät tai haittaavat järjestelmän käyttöä. Mikä tahansa virhe ei ole tärkeää tietoa, vaan se mihin tarvitsee ja halutaan reagoida on usein tilannekohtaista. Sitä ei myöskään määritä yksittäinen toimija (esim. toteuttaja tai määrittelijä), vaan testauksen kannalta tärkeää on tarkastella asiaa erilaisten sidosryhmien kannalta. Näin suomeksi asioista puhuttaessa, käytämme usein sanan virhe tai bugi sijaan sanaa havainto – se on neutraalimpi.

Havaintoja usein kirjataan erilaisiin työkaluihin, ja työkalut sisältävät näille omia nimiään. Usein kuitenkin kyse on samasta asiasta: havainnosta, joka kertoo että jokin asia voisi vaatia keskustelua tai korjauksia. Kirjattujen havaintojen määrästä on helppo tehdä erilaisia visuaalisia kuvaajia, ja jos havaintoja vielä tarkennetusti luokitellaan, kuvaajia voidaan täsmentää luokittain. Yksi luokittelun muodoista on sen seuraaminen kuka havainnon kirjasi, ja tästä voi halutessaan sitten laskeskella että kuka kirjaa eniten korjattavaa tai kenen korjauksiin oikeasti reagoidaan.

Tapahtui eräässä organisaatiossa…

Joitakin vuosia sitten tein töitä eräässä hyvin pienessä projektissa. Olin allokoituna projektin testaajaksi puolipäiväisesti, ja lisäkseni projektissa oli osa-aikainen projektipäällikkö, osa-aikainen koodaileva asiakas/asiantuntija, sekä täysipäiväinen toteuttaja. Organisaatiossa yleisesti oltiin totuttu erilaisiin mittareihin, enkä uutena tulokkaana oikeastaan asiaan erityisesti huomiota kiinnittänyt.

Tein testaajana tiiviisti yhteistyötä toteuttajan kanssa. Koska hän oli täysipäiväinen ja minä puolipäiväinen, tapasimme tyypillisesti lounasaikaan ja juttelimme siitä mitä on tullut tehtyä edellisen keskustelun jälkeen. Tavaksemme muodostui että toteuttaja kertoi mitä ongelmaa oli parhaillaan ratkomassa tai mitä osaa toteuttamassa, ja minä kerroin mitä testaisin kyseisen kertomuksen inspiroimana jos juuri nyt ehtisin testaamaan. Kuten yleensä, puolipäiväisyyden rytmi oli vähintään epäsäännöllinen, enkä aina ollut tekemässä töitä projektille.

Muistan eräänkin hyväntuulisen keskustelun, jossa toteuttaja kertoi edellisen päivän arvaukseni säikeiden käsittelyn virheestä osuneen kohdilleen. Monisäikeisessä ajossa oli kuin olikin ongelmia, mutta ei ollut enää! Epäilyksieni inspiroimana toteuttaja oli vielä kertaalleen käynyt toteutustaan läpi, testannut itsenäisesti lisää, löytänyt ongelman, korjannut sen sekä toteuttanut vielä automaatiota valvomaan ettei ongelma hiipisi takaisin (yksikkötestaukseksi tätä usein kutsutaan). Vastaavia keskusteluita projektin edetessä käytiin useita.

Kun projekti lähestyi loppuaan, huolestunut projektipäällikkö lähestyi minua: ”Olen kuullut että olet tosi hyvä testaaja, mutta olen huolissani. Virheraportoinnin tietokannassa ei juurikaan ole raportoituja ongelmia, ja yleensä tässä vaiheessa projektia niitä on enemmän. Etkö ole testannut? Etkö olekaan hyvä testaaja ja löydä virheitä?”. Projektipäälliköllä oli tukenaan muiden projektien statistiikkaa siitä miten virheitä kirjattiin ja hämmennys oli suuri.

En ehtinyt suutani avata, kun projektin toteuttaja oli jo kertomassa, ettei ole koskaan aikaisemmin saanut testaajalta niin paljon apuja. Moni virhe jäi minulta löytämättä, koska niitä ei ollut siinä vaiheessa kun testasin hyvän yhteistyömme ansiosta.

Virheiden laskemisesta

Keskustelin viime viikolla Portlandissa Agile Open Northwest -konferenssissa erään toteuttajan kanssa. Hän kertoi tehneensä pitkään töitä testaajan kanssa, joka oli tyytyväinen kun toteuttaja jätti oman testaamisen vähälle tai jopa tarkoituksella toimitti keskeneräisen version. Kyseisen testaajan hyvyyttä oman esimiehensä toimesta arvioitiin havaintojen määrällä.

Jos testaajaa arvioidaan havainnoista ja toteuttajaa niiden puutteesta, saadaan helposti myös aikaan varsin negatiivinen yhteistyösuhde. Yhteinen tavoite vastakkainasettelun sijaan olisi tarpeen. Testaajan tuloksista havaintoraportteja vahvempi tulos voi olla havaintoraporttien puute: virheiden estäminen, niiden löytäminen varhaisessa vaiheessa ja niiden korjaaminen ilman raportointikustannusta heti löytymisen jälkeen.

Jotain numerot kuitenkin myös kertovat, itse seuraan havaintojen kirjaamisen numeroa toiveenani ja tavoitteenani että se tulee alas testauksen laadusta tinkimättä. Päivittäessäni CV:täni 2,5 vuotta organisaatiossa olleena kirjasin kirjanneeni 2261 korjattua havaintoa. Suurin osa näistä havainnoista kulkee Jirassa otsikolla ”keskeneräinen työ” – ei siis virhe. Yhteisen tekemisen periaatteena on, että kirjaan asiat Jiraan vain jos emme saa niitä saman tien korjattua. Kirjoitusvirheet korjaan itse nopeammin kuin kirjoitan niistä raportteja.

Keskeneräisestä työstä puhuminen – ja määrien laskemisen välttäminen tilanneraportoinnissa – on tehnyt hyvää tiimin yhteistyölle. Aikaisempi keskustelu siitä mikä on virhe / bugi on poissa. Keskeneräisen työn osalta voidaan miettiä mikä osa siitä tehdään ja mikä jätetään tekemättä juuri nyt.

Käyttämillämme sanoilla on merkitystä. Testaajat eivät riko koodia, he rikkovat *illuusioita* koodista. Niiltä osin kuin virheitä tai keskeneräistä työtä on tarpeen raportoida, tilanne oli näin jo testaukseen ryhdyttäessä.

maaret.pyhajarvi