Hae it-yrityksiä
osaamisalueittain:

Asiakkuudenhallinta CRM BI ja raportointi HR Tuotekehitys ja suunnittelu Toiminnanohjaus ERP Taloushallinto Markkinointi Webkehitys Mobiilikehitys Käyttöliittymäsuunnittelu Tietoturva Verkkokaupparatkaisut Ohjelmistokehitys Integraatiot Pilvipalvelut / SaaS Tekoäly (AI) ja koneoppiminen Lisätty todellisuus ja VR Paikkatieto GIS IoT Microsoft SAP IBM Salesforce Amazon Web Services Javascript React PHP WordPress Drupal
Contribyte » Bloggaus

Bugipato syö tehoja

Bloggaus 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.

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.

Pinterest
Contribyte logo

Lisätietoja

Yritysprofiili Contribyte kotisivut

Tagit

Jos tarjontatagi on sininen, pääset klikkaamalla sen kuvaukseen

Liiketoimintaprosessi

Tietohallinto

Erikoisosaaminen

Ketterät menetelmät
Ohjelmistokehitys

Toimialakokemus

IT

Tarjonnan tyyppi

Konsultointi
Koulutus

Omat tagit

bugi
tulevaisuuden tuotekehitys

Siirry yrityksen profiiliin Contribyte kotisivut Yrityshaku Referenssihaku Julkaisuhaku

Contribyte - Asiantuntijat ja yhteyshenkilöt

Premium-profiilia ei ole aktivoitu. Aktivoi premium-profiili näyttääksesi tässä lisäämäsi 3 asiantuntijaa.

Contribyte - Muita referenssejä

Contribyte - Muita bloggauksia

Löydä sopivimmat it- ja ohjelmistoyritykset liiketoiminnan kehityskumppaneiksi

ite wikin yrityshaku »

It- ja ohjelmistoalan työpaikat

Kaikki it-alan työpaikat »

Premium-asiakkaiden viimeisimmät referenssit

ite wikin referenssihaku »

Tapahtumat & webinaarit

Kaikki it-alan tapahtumat »

Premium-asiakkaiden viimeisimmät bloggaukset

ite wikin julkaisuhaku »

Digitalisaatio & innovaatiot blogimedia

Blogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä
Loka 30
Suomalainen innovaatiotoimisto on kansainvälisesti palkittu ja kehittää digitaalisia palveluita maailman suurimmille firmoille - Näin Hellonin palvelumuotoiluprosessi eroaa it-toimittajien mallista
Hellon on kerännyt useita kansainvälisiä digitaalisen designin palkintoja
Loka 11
Digipalvelulain saavutettavuusvaatimuksia aletaan soveltaa uusiin verkkopalveluihin 28.6.2025 - Näin asetus vaikuttaa digitaalisten palveluiden kehityshankkeisiin
Digipalvelulaki sisältää kolme keskeistä vaatimusta saavutettavuudesta
Loka 10
Digitalisaatiokentän syksyn tapahtumia 2024
Ite wikin tapahtumasivu koostaa yhteen digitalisaatiokentän tapahtumat ja webinaarit
Siirry blogiin

Etusivu Yrityshaku Pikahaku Referenssihaku Julkaisuhaku Blogimedia