Eipä juuri enää tule vastaan tuotekehitystiimejä, joilla ei olisi käytössä jonkin sortin online-bugityökalu. JIRA on ehkä suosituin, mutta bugeja voidaan hallita myös muillakin työkaluilla. Oli tiimi sitten miten kokenut tai laatutyötä tekevä tahansa, yleensä niitä bugeja vain kuitenkin käytännössä on enemmän tai vähemmän. Yleensä kaikki kehittäjät – ihmisiä kun ovat – tekevät bugeja. Hyvin toimiva tiimi ja laadukas prosessi auttaa vähentämään bugien määrää, mutta kyllä niitä silti aina tulee, eikä siitä kannata niin morkkikseen mennä. Löytynyt ja toistettavissa oleva bugi on ihan hyvä asia, sillä ne ovat helppoja korjata. Löytymättömät ja epäselvät bugit ovatkin niitä päänsäryn aiheuttajia.

Bugit ovat siis ”fact of life” tuotekehityksessä, ja olennaista onkin, että niiden kanssa työskentely olisi mahdollisimman helppoa ja sulavaa. Ei mennä tässä blogissa virheiden etsimiseen eikä hallintaan, eli priorisointiin ja siihen, miten virheet pitäisi tuotekehitysmasiinan läpi ajaa. Haluan nimittäin nostaa nyt esiin vielä perustavampaa laatua olevan asian: itse bugiraportin.

Vaikka kuulostaa pilkunviilaamiselta puhua itse bugiraportista, niin bugirapsojen puutteet ovat kuitenkin murheellisen yleinen ongelma. Epäselvä bugiraportti saa hukkaamaan aikaa, kun kehittäjä alkaa sitä katsoa, ja se voi johtaa myös väärään prioriteettiin, kun Product Owner ei sitä ymmärrä. Lisäksi voidaan hukata olennaista tietoa testisetupista. Käydäänpä seuraavaksi läpi yleisimmät ongelmat ja niiden seuraukset sekä miten niiltä voidaan helposti välttyä.

One-linerit

One-linerit tarkoittavat bugeja, joissa on vain otsikko. Jep, ei mitään kuvausta tai kommentteja. Kuulostaa hassulta, että kukaan raportoisi tämmöisiä, mutta raportoija on näitä kirjoittaessaan yleensä ajatellut, että kyllähän se bugin otsikko jo kertoo kaiken olennaisen, ei siihen mitään kuvausta enää tarvita. Sitä paitsi on ihan kamala kiire nyt. Toinen tilanne, missä näitä näkee käytettävän on, kun kaksi kehittäjää keskustelee jostain ongelmasta ja pääsee lopputulokseen, ja toinen sanoo toiselle ”tee mulle tästä tiketti”. Tässä molemmat ovat TUOLLA HETKELLÄ tienneet mistä on kyse.

One-linerit ovat ongelmallisia sitten, kun tuosta hetkestä onkin kulunut viikko tai kuukausi. Voipa hyvin olla, että asianosaisetkaan eivät enää kuukauden päästä muista, mitä kyseinen tiketti tarkoitti. Vaikka fiksi olisikin tehty nopeasti, saattaa se jäädä esimerkiksi odottelemaan testauksen verifiointia joksikin aikaa. Myöhemmin tikettiä katsottaessa joutuu jopa korjauksen tekijä jonkin aikaa muistelemaan, mistähän tässä olikaan kyse.

Vielä suurempia vaikeuksia one-linerit tuottavat muille tiimin jäsenille tai Product Ownerille. Jos ei ollut keskustelussa mukana, on pelkästään otsikon tulkinnan varassa arvatessaan, mistä tässä tiketissä on kyse. PO tai testaaja voi joutua kyselemään kehittäjiltä testatakseen tai priorisoidakseen bugin oikein.

Olisikin syytä pitää tiukka sääntö, että one-linereita ei sallita koskaan.

Entä jos one-lineri raportoidaan off-site tiimille? Nyt onkin vasta keitos syntymässä. Off-site tiimi, jos vielä sattuu olemaan eri aikavyöhykkeellä, joutuukin suurella varmuudella lähtemään chattaamaan, soittelemaan tai mailailemaan lisätietoja.

Kaikkeen tähän menee vain turhaa aikaa ja työtä. Ja se bugin kuvauksen kirjoittaminen puolestaan ei montaa minuuttia vie. Olisikin syytä pitää tiukka sääntö, että one-linereita ei sallita koskaan. Helpoin tapa enforcata tätä on, että kaikille tehdään selväksi, että one-linerit palautetaan aina heti takaisin originaattorille bumerangina.

Tajunnanvirtakuvaus

Jos mennään katsomaan jonkun projektin bugeja ja otetaan avoinna olevien listalta vaikka 20 bugia niin väittäisin, että puolet on kirjoitettu niin, että niissä on kuvauksena 4-5 rivinen lause, joka kertoo, mikä ongelma on kyseessä. Bugin raportoija kertoo siinä oman käsityksensä mukaan vapaamuotoisesti minkälaisesta asiasta on kyse.

Vaikka tämä tilanne onkin jo paljon parempi kuin ensimmäinen ongelma, se pakottaa lukijan kuitenkin ”luetun ymmärtämiseen”. Vapaamuotoinen lausekuvaus on kirjoitettu usein fokusoituen suoraan ongelmatilanteeseen. Tästä tulee seuraavia vaikeuksia:

• Lukija saattaa ymmärtää bugin väärin.
• Vapaamuotoisessa kuvauksessa on hankala kertoa, mitä raportoija on tehnyt saadakseen bugin aikaan – toistamisen yrittäminen on hankalaa ja työlästä.
• Ongelmaan fokusoituminen saattaa hämärtää sitä, mitä raportoija on odottanut oikeasti tapahtuvan.
• Yleensä näissä kuvauksissa puuttuu kaikki tieto siitä, minkälaisella testisetupilla bugi löytyi, toistuuko se aina vai harvoin ja tieto siitä, milloin se ei toistu.

Tiimin olisikin syytä teroittaa kaikille tikettejä tyypillisesti luoville ihan bugien luomisen perusteet. Bugeissa olisi syytä olla aina vähintään seuraavat tiedot:

• Otsikko
• Prioriteetti
• Kuvaus
  • Preconditions: mitä täytyy tehdä ennen kuin varsinaisia toistosteppejä yrittää?
  • Stepit: mitkä stepit pitää mennä läpi, jotta bugi toistuu?
  • Expected result: mitä raportoija odotti tapahtuvan?
  • Actual result: mitä oikeasti tapahtui?
  • More info:
    • Miten käyttäjä voi toipua bugista?
    • Milloin bugi EI TOISTU?
    • Toistuuko bugi aina/usein/harvoin/ei helposti toistettavissa?

Nämä ylläolevat olisi syytä olla aina. Itseasiassa ne olisi hyvä tatuoida testaajien käsivarteen. No, ei sentään. Mutta kun nämä tiedot säännönmukaisesti kirjoitetaan bugeihin, on bugi nopeasti ymmärrettävissä ja priorisoitavissa oikein, ja kuukausienkin päästä helposti palautettavissa mieleen. Näillä tiedoin ei myös ole ihan niin tarkkaa, miten hyvin bugin otsikko osuu kohdalleen.

Nuo more info -kohdan asiat voivat kuulostaa turhilta. Tarkennetaanpa niitä vähän: toistuvuustiheyttä ja toipumisen helppoutta voi bugia priorisoiva ihminen käyttää sen päättämiseen onko ongelma CRITICAL vai MAJOR. Tämä on tärkeää, kun lähestytään myynnin aloitusta. Taas tieto siitä, milloin bugi toistuu ja milloin se EI TOISTU on olennaisen tärkeää, koska se auttaa kehittäjää nopeammin pääsemään root causen kimppuun.

”Mä korjasin sen”

Kolmas asia, minkä toivoisi yleistyvän bugien osalta on se, että kehittäjät tarvittaessa kommentoisivat bugia hiukan laajemmin.

Kolmas asia, minkä toivoisi yleistyvän bugien osalta on se, että kehittäjät tarvittaessa kommentoisivat bugia hiukan laajemmin. Myönnetään, että joskus ”Fixed” on riittävä tieto, mutta monesti Product Ownerina olin kiitollinen, kun kommentissa kerrottiin laajemmin esimerkiksi mihin brancheihin korjaus on mergetty, millä tavalla korjaus on tehty, ja mitä regressiovaaraa siitä seuraa.

Ideaalisti kehittäjän kommentissa olisi seuraavat tiedot:

• Missä buildissa fiksi on mukana?
• Mihin brancheihin korjaus meni?
• Mitä muutettiin ja millä tavalla bugi pitäisi retestata/verifioida?
• Mitä regressiovaaraa korjauksesta syntyi, ja millä tavalla pitäisi testaajien ajaa regressiotestejä?

Branch-tieto olisi hyvä saada tietenkin myös työkalun kenttiin, jos työkalu sitä tukee. Voi myös olla, että tiimissä on yleisesti sovittu, että pelkkä ”Fixed”-kommentti riittää tai koko kommenttia ei tarvita, jos erityistä regressiovaaraa ei ole. Tämä olisi kuitenkin hyvä yhteisesti sopia. Ei se silti kovin kauaa kestä kehittäjältä kirjoittaa: ”Fixed to all branches, available in next NB.” ja lisäksi jos tulee regressioriskiä ”Following scenarios should be retested: …”

Jos fiksi ja sen kommentti menee myös koodikatselmuksen läpi, pitäisi katselmointia varten olla myös mukana tietoa siitä, mihin muutoksia tehtiin ja miksi, jotta katselmoija pystyy nopeammin asennoitumaan katselmoitavaan muutossettiin.

Perusasiat kuntoon 

Kun menee katsomaan jonkin projektin bugimassaa, siellä on suuri osa bugeja, jotka ovat vähän epäselviä. Otsikko on hieman ohi varsinaisen aiheen ja kuvaus on tajunnanvirtakuvaus. Useimmiten tuossakin tiimissä osa bugeista vastaa paljon paremmin yllä esittämiäni ohjeita. Olisi hauska verrata statistiikkaa, miten nopeasti bugit, jotka on raportoitu ”oikein” virtaavat prosessin läpi verrattuna bugeihin, jotka ovat kuvaamallani tavalla epäselviä. Veikkaisin, että oikein kirjoitetut bugit virtaavat läpi paremmin, koska niiden kanssa työskentely on helpompaa ja tehokkaampaa.

Perustelu huonojen virheiden kirjoittamiselle on yleensä kiire. Kuitenkin on niin, että yllä kuvaamistani syistä epäselvät bugiraportit vaan luovat ihmettelyn ja sekaannuksen kautta paljon hukkatyötä, joka olisi vältettävissä ihan muutaman minuutin paremmalla kirjoittamisella silloin, kun bugia avataan. Bugit ovat tuotekehityksen inputtia, raaka-ainetta. Tuotekehityskone toimii paremmin, kun raaka-aine on laadukasta.

Kerron seuraavassa blogissani lisää ongelmista mihin olen törmännyt bugien hallinnoinnissa.

Jos Contribyte tulee tekemään assessmenttia teille, vilkaisemme myös bugikantaanne. Auta armias, jos siellä on one-linereita! Silloin myymme teille kalliilla koulutuksen bugien raportoinnista. Tulee halvemmaksi ottaa ilmainen oppitunti näin blogikirjoituksesta!