Yhteinen etu ja todistustaakka
“Hirvi!” kuuluu pelkääjän paikalta. Kuski ei paina jarrua vaan kysyy ensin “Missä?”. Tottakai eläin on ensin nähtävä omin silmin ennen kuin painetaan jarrua. Tietenkään näin ei aina tieliikenteessä käy, mutta tuotekehityksessä tämä on arkipäivää.
Virheitä on kahdenlaisia. Niitä jotka tapahtuvat systemaattisesti ja niitä jotka tapahtuvat toisinaan. Jälkimmäiset ovat sitä sarjaa jonka tapahtumiseen olosuhteiden ja ajoitusten täytyy osua erityisen hyvin kohdalleen että virhe ilmenee.
Tällaisten virheiden raportointi on työlästä ja korjaaminen vielä työläämpää. Usein nämä virheet jäävätkin pitkäksi aikaa hoitamatta. Virheraportteja pallotellaan tuotekehityksestä testaukseen ja takaisin.
Developer: Could not reproduce, please retest on build 5
Test engineer: Still happens on 1 out of 10 tries
Developer: Could not reproduce, please retest on build 6, please provide a screenshot
Test engineer: Still happens… Did you even investigate?
Kallisarvoista aikaa kuluu tyhjänpäiväiseen pallotteluun todellisen syyn tutkimisen sijaan. Erityisesti tämä ongelma kertaantuu multi-site projekteissa, joissa kehitys tehdään kahdella aikavyöhykkeellä. Virheiden pallottelu saattaa kestää viikkoja ilman todellisia ratkaisuja.
Miksi testaajalla niin usein on raskas todistustaakka siitä että virhe todellakin ilmaantuu? Täytyy tuottaa kuvankaappauksia tai jopa videoita virheestä ennen kuin devaus oikeasti ottaa ongelman tutkintaan. Ongelma täytyy siis ensin omin silmin nähdä. Joskus testaajan on jopa kaivettava speksit esiin ja osoitettava niistä että raportti on todellakin vika eikä feature. Lopulta ongelmien selvittely tällä tavalla eskaloituu myös organisaatiossa ylöspäin ja ratkaisujen kustannukset kasaantuvat.
Tällaiset tilanteet johtuvat siitä että testaus ja tuotekehitys ovat niin usein napit vastakkain. Ei ole keskustelua, kommunikaatio ei ole pelannut ja tuotteen etu on unohtunut.
Suosittelemme myös:
Mahdoton tehtävä on usein uskon puutetta
Mielenhäiriöstä siinä kai oli kysymys. Tein nimittäin eilen illalla ihan pimeän lupauksen. Lupasin kirjoittaa tänään alkavassa European...
Mikä on kun ei taidot riitä?
Ilma oli sakea, tunnelma tiivis ja noin 100 kilttiä koululaista nojautui kuuntelemaan väkeviä tarinoita myynnin ihmeellisestä maailmasta. Istuin...
“Miksi testaajalla niin usein on raskas todistustaakka siitä että virhe todellakin ilmaantuu?”
Koodajan näkökulmasta testaaja ei ole tehnyt työtään kunnolla, koska ei ole toimittanut yksityiskohtaisia toisto-ohjeita, joilla virheen saa toistettua joka kerta 🙂
Juu ongelma tuotekehityksen pelikentällä on juuri nuo satunnaiset virheet.
Käytän seuraavaksi pointtini havainnollistamiseen ufo-paradoksia, koska iltapäivälehdistö on viime aikoina aiheesta niin paljon puhunut; kaikista maailman miljoonista havannoista vain yhden tarvitsee olla aito ja se riittää todistamaan tunnistamattoman lentävän kohteen olemassa olon. Vain yksi aito havainto siis riittää.
Täysin sama paradoksi pätee myös testauksessa. Yksi aito havainto virheestä riittää todistamaan, että bugi siellä on. Devaaja on kuitenkin keskimäärin varsin skeptinen, niin he luonnollisesti vaativat todisteeksi kuvia tai jopa videon. Joissain tapauksissa logi riittää.
Devaajan skeptisyys bugeja kohtaan on tiettyyn pisteeseen asti ymmärrettävää ja jopa suotavaa. Devaajan pitää välttää ajan polttamista “bugin” korjaamiseen joka päivän vääntämisen jälkeen osoittautuu tuotteen virheelliseksi käytöksi tai puutteelliseksi ohjeistukseksi tai vastaavaa. Eli pieni annos skeptisyyttä on ok!
No mitä näille satunnaisille virheille siten pitäisi tehdä? Se on hyvä kysymys, koska harvoin on loputtomasti aikaa ja rahaa kaivaa esille niitä kaikkein harvinaisimpia virheitä. Silloin tehdään priorisointi-riskianalyysi eli ns. prioriski. Prioriskin tekee ja vastuun kantaa managementti joka tietää käytössä olevat rahat ja ajan. Tiedämme, että aina ei jokaisen tuotteen tai palvelun osalta ole prioriski mennyt kohdilleen, mutta toisaalta eihän se Ferrarikaan joka kerta aja ruutulipulle asti 🙂
Entäpäs tilanteet, joissa pelkääjän paikalta huudetaan “Hirvi!”, mihin kuski vastaa “En minä mitään hirveä näe, kyllä tuo tien laidassa oleva sarvipää on poro.” ja jatkaa matkaa hidastamatta.
Näkemyserot testauksen ja developmentin välillä ovat perustavalla tasolla huomattavasti erilaiset. Testaus tekee kaikkensa löytääkseen ja todistaakseen yksittäisen virheen kun taas develoopperi yrittää hiki hatussa toteuttaa luomisen tuskaansa. Tämän luomisen seurauksena on yllättävän monesti ylpeys omasta tuotoksesta. Ylpeyden seurauksena taas jopa hyvin kirjoitettu virheraportti pystytään ohittamaan oikomalla polkuja (steppejä) jolloin virhettä ei välttämättä saadakkaan toistettua. Toinen developmentin napinan aihe on tyyliä “Eihän noin voi tehdä, ei softaa ole edes tarkoitettu tuollaiseen toimintaan.” Mutta kylmä totuus on, että jos niin on tehty, joku tulee sen tekemään uudestaankin myöhemmässä ja kalliimman korjaamisen vaiheessa. Tähän loppuu lyhyt katsaus develoopperin sielunelämään 😉 Ehkä jossain vaiheessa voisi kirjoitella myös siitä testaajan sielunelämästä, mikäli heiltä sellaista edes löytyy…
Suuri kysymys onkin sitten, että tuleeko siitä pelkääjän huutamasta hirvestä “tilastohirvi”. Eiväthän ne aina itsetuhoisin ajatuksin hyppää auton eteen 🙂
Tuo yllä mainittu on kyllä niin totta kuin vain olla ja voi. Omat havaintoni on samat.
Itse olen lähestynyt tätä “develoopperin ylpeyttä ja silmäterää” diplomaattisesti. Olen kehittänyt matkanvarrella taitojani ja ymmärrän hyvin, että toiminnon tehnyt koodaaja/arkkitehti voi olla hyvinkin ylpeä tuotoksestaan. Siksi on erittäin tarkeää miten asiansa ilmaisee.
Monesti testaaja ilmoittaa asiansa/bugin mahdollisesti jopa hivenen “iloisena” ja “naureskellen”, että nyt se “räjähti” käsille ja että sellainen “show stopperi” ettei olla ennen nähty. Kun koodaaja tuollaisen kuulee/näkee, niin se synnyttää vastareaktion jossa koodaaja alkaa puolustelemaan ja tilanne saataa äityä kovaksikkin juupas-eipäs -tupinaksi. Tämä syö suotta kaikkien energiaa ja ei varmastikkaan edesauta itse tuotteen valmistumista.
Itse saatan ilmaista asiani vastaavassa tilanteessa tyyliin: “hyvältä vaikutti tämä uusi toiminto (edellyttäen, että se oikeasti vaikutti hyvältä), mutta tämmöistä sieltä vielä löytyi”. Eli ihan normaalit sosiaaliset ja diplomaattiset menetelmät ovat sallittuja myös softan kehityksessä 😉
Vaikka olen ammattitestaajana hyvinkin tiukka koodaajien työn tarkistaja, niin asian ilmaisulla voi tilanteen ratkaista hetkessä suuntaan tai toiseen. Kannattaakin valita pienimmän vastustuksen reitti ja pelata peliä oikein ja reilusti huumoria mukaan; auttaa kummasti!! 🙂
Heippa kaikki ja kiitos hyvistä kommenteista. Itsekin olen sitä mieltä, että suurin osa tuosta napit vastakkain astelmasta johtuu joko kommunikaation puutteesta tai sen huonosta tavasta.
Diplomaattisella lähestymisellä ja hyvällä suullisella kommunikoinnilla ongelmien ratkaisussa yleensä päästään merkittävästi parempiin tuloksiin.
Samaan saumaan on tietysti pidettävä myös mielessä kulttuurierot. Intialainen devaaja suhtautuu virheraportointiin selkeästi eri tavalla kuin esimerkiksi on-site suomalainen 🙂
Voi kuinka paljon paremmin asiat olisivatkaan jos me kaikki voisimme unohtaa egomme ja painaa duunia kohti yhteistä maalia.
Terve Teemu ja kiitos kommentista. On hienoa kuulla jälleen uusia näkökulmia kaikille yhteisiin laatuasioihin!
Esitit osuvat esimerkit kaikkien kolmen osapuolen ajatusmaailmasta. Ristiriitoja tulee aina. Sehän on selvä. Loppukaneetissa halusinkin herätellä sitä tahoa, joka tällaisia projekteja vetää. Loppupeleissä tuotteen menestyminen on kaikkien osapuolten etu.
Mielenkiintoisempi tilanne tulee, kun projeksi onkin sellainen, jossa on ostaja, ulkopuolinen lopputestaaja, ulkopuolinen toimittaja. Kolme erilaista osapuolta, joilla erilaiset prioriteetit ja tarpeet. Jos projekti on myöhässä, ostaja ajattelee:”Toivottavasti ei ole pahoja bugeja ja saadaan tämä pihalle.” Toimittaja:”Mitään ei korjata, jos voidaan välttää. Nyt jo myöhässä, sakot juoksee.” Testausosapuoli:”Asiakas saa parhaan palvelun, kun testaamme kunnolla, raportoimme kaiken mitä löydämme ja jollain tavalla yritämme saada mahdollisimman paljon korjautettua kriittisyysjärjestyksessä.”
Tuossa asetelmassa vihollisuudet ovat huomattavasti selvemmät kuin kehityksenaikaisessa testauksessa, jossa ollaan ”samaa tiimiä”. Enää ei ole kyse egoista, vaan taloudellisista saavutuksista. Yhdellä tavoite päästä ilman enempiä taloudellisia tappioita, toisella tavoite saada mahdollisimman hyvää ja kuitenkin valmista, kolmannella tavoite havaita ongelmat.
Ja devaajalle – jos vain mahdollista, tehdään työkalu, joka hakkaa sitä kerran kymmenestä tapahtuvaa tilannetta niin pitkään, että kehittäjäkin sen näkee. Automaatio – ihana työkalu, kun pitää saada jotain toistettua.