Bugiblogin ensimmäisessä osassa kerroin useimmiten vastaan tulevista ongelmista itse bugeissa. Tällä kertaa ajattelin nostaa esiin bugien virtausnopeuden tuotekehitystiimin prosessin läpi.

Virhehallinnan perusteethan ovat niin, että bugit menevät raportoijalta mielellään jonkinlaisen screenin läpi, ja sitten kun on selvä, että ne pitää korjata juuri nyt, niin kehittäjät korjaavat ne. Korjauksen jälkeen ne palautuvat testaukseen verifiointia varten. Jos verifioinnissa kaikki on ok, bugi suljetaan joko suoraan tai sitten se palautuu jollekin henkilölle, joka sulkee sen myöhemmin, kun on esimerkiksi päivitetty release note. Mutta jos verifioinnissa huomataan, että joku osa bugista on vielä korjaamatta, se palautuu kehittäjälle.

Pato jonka takana on verifioimattomia bugeja. Pelottavan näköinen, eikö?

Testaajilla liian kova kiire? – vaarana on bugipato!

Usein vastaan tuleva ongelma on se, että tiimillä on kertynyt ”verifiointivelka”, eli bugeja on fiksattu nopeammin kuin testaus pystyy niitä verifioimaan. Tässä onkin sellainen piilevä vaara, että jos tuo verifioitavana olevien bugien määrä kasvaa kovin isoksi, siitä tuleekin aikamoinen suo, kun sitä aletaan sitten myöhemmin kahlaamaan läpi. Tämä on todennäköisempää bugeille kuin tarinoille, koska agile-metodit pitävät huolen siitä, että aloitettavat tarinat ovat aika korkealla backlogilla. Lisäksi tarinat ovat usein hitaampia implementoida kuin bugifiksit.

Tilanteessa, jossa bugi on fiksattu jo viikkoja sitten on se huono puoli, että jos fiksi ei ollutkaan riittävä, testaaja sitten myöhemmin palauttaa bugin kehittäjälle, mutta kehittäjä joutuu sitten uudelleen orientoitumaan että ”mitäs minä tässä oikein teinkään”.

Tietenkin, jos tiimin itsekuri ja prosessit ovat olleet kunnossa, ja bugin kuvaus sekä kommentit bugissa ja koodissa ovat kunnossa, tämä prosessi voi olla aika nopea. Mutta se on silti hitaampi kuin jos bugi olisi ollut kehittäjän kourissa vain muutama päivä sitten. Jos kommentointikulttuuri tai bugin kuvaus on olematon tai epäselvä, on aivan selvä asia, että ihmiset joutuvat ajattelemaan samat asiat uudelleen ja syntyy aika paljon hukkatyötä, wastea.

Työmuistissa olevat asiat haihtuvat ajan myötä

Ihmisellä on kolmenlaista muistia: lyhytaikainen muisti on noin 15-30 sekunnin mittainen. Seuraava taso on työmuisti, jossa säilyy rajoitettu määrä materiaalia kohtuullisen nopeasti saatavilla. Viimeinen taso on valtava pitkäaikainen muisti, minkä kapasiteetti on suuri mutta heikkous on, että sieltä asioiden hakeminen saattaa kestää pitkään, minuutteja, tunteja tai jopa päiviä.

Työmuistissa olevat asiat haihtuvat hiljalleen pois, jos työmuistia käytetään. Käykin niin että muutaman päivän kuluessa muut, uudemmat asiat pyyhkivät aikaisemmin työmuistissa olevat asiat pois. Olisi siis kaikkein tehokkainta, jos bugi saataisiin verifiointiin muutaman päivän sisällä siitä, kun se on korjattu.

On huomattava myös, että sama koskee tietenkin myös testaajaa: myös testaaja joutuu tutustumaan bugiin ja rakentamaan sen testaamiseen ja verifiointiin sopivan ympäristön, jos sitä ei ole valmiina. Eli samalla tavalla myös bugi, joka on juuri raportoitu ja korjattu on myös tehokkain verifioida.

Mittaa myös virtausnopeutta prosessin läpi

Olisikin siis syytä pyrkiä siihen, että ne bugit, jotka korjataan, etenevät varmasti prosessin läpi mahdollisimman nopeasti. Product Ownerin ja Scrum Masterin olisikin syytä tarkkailla testauskattavuuden, pass raten ja avoimien bugien lukumäärän lisäksi myös prosessissa olevien bugien määrää ja korjausnopeutta. Mitä nopeammin bugi etenee prosessin läpi, sen parempi, ja mitä nopeammin bugi korjataan löytymisensä jälkeen, sen parempi. Silloin tiimi toimii tehokkaimmin.

Jos tiimi sallii suuren massan bugeja ”ready for retest” -tilassa, se johtaa myös vaikeuksiin priorisoida testaajien työtä. Periaatteessa testaajilla on tällöin ”To do” -listalla pahimmillaan satoja bugeja. Jos sinne tupsahtaa jotain tärkeää, se voi helposti unohtua massaan. Priorisointi tällaisessa tilanteessa on kuin yrittäisi löytää sekavasta huoneesta jotain yhtä asiaa. Siihenkin menee turhaa aikaa ja effortia.

Jos tiimi käyttää kanbania, prosessin visualisointi auttaa tässä, eli kanbanin testausvaiheeseen pitäisi kertyä paljon tikettejä odottamaan verifiointia. Kaikkein yleisin ongelma kanbanin käytössä on kuitenkin se, ettei tiimi ole määritellyt tai ei tottele itse määrittelemiään Work-in-progress -rajoja.

Jos bugipato on päässyt yllättämään, olisi se syytä räjäyttää palasiksi nopeasti. Tällöin voisi pitää esimerkiksi bugiverifiointisprintin tai -campin.

Kerron seuraavassa bugiblogin osassa miten tärkeää olisi osata ”vyöryttää” pahoja ongelmia.

Contribyte on Suomen johtava tuotejohtamisen ja ketterän tehokkuuden osaaja. Tehosta oman tiimisi tai organisaatiosi toimintaa esimerkiksi kutsumalla meidät käymään: Teemme tiimin toiminnasta assessmentin, jolla saadaan lisää tehoja tuotekehityksestä irti helposti! Sijoitus on pieni hyötyyn nähden.