Arkisto: joulukuu 2009



Ohjelmistotestaus.fi joulutauolle

23. joulukuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 2

Tiptap!

Vetäydymme joulutauolle pariksi viikoksi. Uusi teksti murjaisee käyntiin vuoden 2010 heti viikolla 1. Palataan silloin asiaa.

Rauhallista joulua ja menestyksekästä vuotta 2010 lukijoille!

Hivenen liiketoimintalogiikan puolelle

18. joulukuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 4

Uusi blogin osoite, vanhat vinkeet.

Silti harmittaa.

Testauksenhallintatyökalun osalta iso kauppa oli ns. lähes kiinni. Lupasimme vähentää (potentiaalisen) asiakkaamme laadunvarmistuskuluja 15%. He uskoivat sen.

Sitten meille näytettiin kämmentä! Miksi näin?

Olimme myymässä (potentiaaliselle) asiakkaallemme testauksenhallinnan tehostamista, eli vastaavan työn tekemistä vähemmällä tuntimäärällä. Valitettavasti emme tajunneet, että asiakkaamme asiakas maksaa edelleen testauksesta mieluummin tunti- kuin laatuperusteisesti. Emme ymmärtäneet paikkaamme arvoketjussa. (Potentiaalisella) asiakkaallamme ei ollut mitään syytä parantaa laadunvarmistusprosessiaan.

Ajattelumalli oli kutakuinkin seuraava:

  • Maksamme 100 rahaa jokaista 100 testaukseen käytettyä aikayksikköä kohti
  • Odotamme teidän löytävän yhden virheen jokaista aikayksikköä kohti
  • Emme maksa tippaakaan enempää, vaikka saisitte kiinni 2 virhettä jokaista aikayksikköä kohti, koska hinnoittelemme alihankintatyömme tuntiperusteisesti. Alihankkijoiden vertailu on helpompaa siten!

Prosessin tehostaminen olisi tarkoittanut suoraan 15% pienempää laskutusta. Kuka sellaista haluaa?

Nykyään puhumme kovasti työn tuottavuuden kasvattamisesta. Käsittääkseni tuottavuuden kasvu tarkoittaa sitä, että samassa ajassa saadaan enemmän aikaiseksi. Tai vastaavasti sama määrä töitä saadaan tehtyä vähemmässä ajassa. Tuottavuuden kasvattamiseen vaikuttaa ensisijaisesti osaaminen. Osaamisen kautta työpäivän aikana saadaan aikaiseksi enemmän hyödykkeitä ja palveluita.

Ammattiliike vaihtaa autosi renkaat puolessa tunnissa. Kuinka paljon enemmän olisit valmis maksamaan siitä, että vaihtoon kuluisikin tunti? Maksaisitko tuplat? Tuskin. Minuakin kiinnostaa enemmän sovitun työn ja tuloksen lopullinen hinta kuin tuntiveloitus.

Isot laivat kääntyvät kovin hitaasti. Asiakkaamme (potentiaalinen) on aloittanut neuvottelunsa oman asiakkaansa siitä, että voisivat ottaa suuremman vastuun laadunvarmistustyöstä. Näin jokainen osapuoli voi keskittyä kokonaistuottavuuden kasvattamiseen.

Silloin myös laadunvarmistusprosessin kehittämiselle on tilausta. Me olemme siinä hyviä.

Yhteinen etu ja todistustaakka

4. joulukuuta, 2009 | Kirjoittaja: Antti Niittyviita
Kommentit: 7

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

Laita siis tuotekehityksen tiimit taistelemaan yhdessä lopputuotteen eteen sen sijaan että ne kilvoittelisivat keskenään. Hoida homma herättämällä koko projekti ajattelemaan asiat loppukäyttäjän näkökulmasta.