Devaajan tilitykset (Osa 1)
Me koodaajat olemme kofeiinia sovelluksiksi muuntavia otuksia joille tavallinen ihminen viestii lähettämällä bugiraportteja. Pahimmillaan “raportti” on vain ilmoitus “Tämä ei toimi”. Parhaimmillaan se on tyhjentävä, mutta napakka selostus, jota lukiessa voi jo keksiä ratkaisun.
Valitettavan usein raportti on ensin mainitun kaltainen. Siitä seuraa verenpaineen nousua ja epäterve tarve kommunikoida. Usein haaskaantuu myös arvokasta aikaa useammalta osapuolelta.
Peruskoulussa voisi aivan hyvin yhden ainekirjoituskotitehtävän vaihtaa bugiraportin kirjoittamiseen. Koodareiden ja FedExin lentokonemekaanikkojen hermojen säästämisen ohella siitä voi olla hyötyä vaikka takuupalautusasioissa. Tärkeä kansalaistaito siis!
Riittävän hyvä raportti on mielestäni helppoa tehdä. Pitää vain muistaa kaksi ässää – stepit ja screenshot. Eli vaiheittainen selostus: mistä aloitettiin, mitä tehtiin, minne päädyttiin. Jos haluaa olla oikein super, niin kannattaa raportoida myös minne olisi pitänyt päätyä. Lisäksi tässäkin tapauksessa vanha sananlasku pitää paikkansa: Kuva kertoo enemmän kuin tuhat sanaa.
Kirjoittaja tietää mistä puhuu. Hän on tuottanut enemmän bugeja kuin raportteja.
* Juhamatti Niemelä on pitkän linjan testausautomaatioguru ja koodaaja kuumimmasta päästä. Hänellä on ollut sormensa pelissä myös Tarantula -testauksenhallintajärjestelmän kehityksessä.
Suosittelemme myös:
Työ, tarkoitus ja kommunikaatio
Asiaa palautteen antamisesta ja sen kommentit kertovat ohjelmistokehityksen kommunikoinnin haastavuudesta. Kehittäjiä tympii, kun testaajilta tulee...
Kannattaako bugi korjata?
Softabugien luokittelussa on vuosien varrella tullut vastaan vaikka minkälaisia virityksiä. Vakavuus, vaikutus, prioriteetti, riski tai toistuvuus...
Tämä on aihe jonka kanssa me testaajat touhuamme päivittäin. Itse tapaan sanoa kanssa testaajilleni, että jokainen bugirapsan kanssa vietetty minuutti säästää kolme minuuttia aikaa lähitulevaisuudessa kun devaajat alkavat kysellä lisätietoja ja puuttuvia liitteitä. Kokemukseni mukaan suhde tosiaan on tuo 1/3.
Silloin tällöin saan kehuja devaajilta hyvistä bugirapsoista ja se on minulle ammattiylpeys josta en tingi. Bugirapsa on minulle ammattitestaajana se yksi asia joka täytyy saada nappiin.
Keskimäärin minulta kuluu bugin raportoimiseen parikymmentä minuuttia. Ei ole tavatonta, että aikaa bugin raportoimiseen kuluu tunteja, kun valmistellaan huolella tarvittavat liitteet sun muut. Toki ymmärrän sen, että jos kyse on kriittisestä virheestä, niin en odota tunteja asian eteenpäin viemiseksi, vaan annan raportin viipymättä face-to-face tai puhelimella tai jollain muulla kommunikaatiovälineellä. Kriittisessä tapauksessa varsinaisen bugirapsan ehtii tehdä sitten hieman myöhemmin kunhan ensin saadaan olennainen tieto liikkeelle.
Niin tai näin – bugirapsan täytyy olla jämäkkä, perusteellinen, riittävän pitkä mutta samalla riittävän lyhyt. Kun mukaan laittaa kuvankaappauksen ja videon maustettuna selosteella, niin voi hyvin olettaa, että virheen korjaus käynnistyy ilman ryintää.
Tuhansia bugiraportteja lukeneena product ownerina tuo luku on jopa alakanttiin tai kuvaa ehkä vain testaajien käyttämää aikaa. Kun kehittäjät koittavat epätoivoisesti toistaa bugia huonon rapsan perusteella ja odottelevat tarkentavia tietoja testaajilta, aikaa kuluu huomattavasti enemmän.
Sanoisin että jokainen bugirapsaan käytetty minuutti säästää aika koko hankkeessa ainakin kolme tuntia.
Olisi hyvä jos ongelman raportoimisen taitoa opastettaisiin edes korkeakouluissa tai ainakin useammissa softakehitysfirmoissa. Pahimmillaan raportti ymmärretään väärin mistä seuraa runsaasti haaskattua aikaa ja revittyjä hiuksia. Hyvä olisi painottaa yksiselitteisyyden merkitystä, sillä se on huomattavasti tärkeämpää kuin kieliopin oikeellisuus tai hyvä kieli. Klassinen esimerkki: ”Avasin menusta välilehden ja se katosi näkyvistä” ei kerro mikä ”se” on, toisin kuin ”Avasin menusta välilehden ja välilehti katosi näkyvistä” mikä kuitenkaan ei ole niin hyvää kieltä. Jälkimmäinen on kuitenkin kertaluokkaa parempi bugiraportti.