Avainsanat: ‘laatukustannus’

Testaaja samoilee sienimetsällä

maanantai, 23 huhtikuuta, 2012 | Kirjoittaja: Antti Niittyviita

Erittäin herkullisen, mutta kuitenkin myrkyllisen korvasienen satokausi lähestyy kovaa kyytiä. Sehän tarkoittaa samoilemista hiekkapohjaisissa kangasmetsissä. Kokenut korvasienestäjä tietää parhaat paikat ja löytää fiiliksellä myös uudet apajat.

Uuden kauden tullen Simo Sienestäjä ajelee jälleen tutun metsätien päähän ja lähtee patikoimaan saalisrepun kanssa. Tavoitteena on päästä makkaranpaistoon läheisen lammen rantaan, kuten aina keväisin. Simo samoilee kangasmaastossa bongaillen aktiivisesti reitillään olevia korvasieniä. Saalistakin löytyy ja reppu painaa mukavasti makkarapaikoille päästessä. Simo on tyytyväinen

Simon päivätyö on ohjelmistotestaus. Hän päättää kokeilla tällä kaudella työpaikalta tuttua menetelmää ja kirjaa reittinsä alla olevalle kartalle tarkasti. Askel askeleelta. Kun Simo on saanut edellisen saaliin ryöpättyä ja pataan, hän lähtee uudelle metsäretkelle. Vieläkö saalista mahtaa kertyä, jos Simo samoilee makkarapaikoille samoja jalanjälkiä?

 

Että näin. Toteaa Simo makkarapaikoilla. Toisella kerralla kuljetut kilometrit eivät tuottaneet odotettua tulosta. Sienimatkan dokumentointi vei kohtuuttomasti aikaa ja matkan uudelleen kulkemisen konkreettiset tulokset jäivät laihoiksi. Simo saattoi vain todeta itsestään selvyyden. Parhaat tulokset syntyvät, kun hän valitsee hieman uuden reitin jokaisella reissulla erikseen.

Aivan sama pätee ohjelmistojen testaukseen. Uusia bugeja ja uutta tietoa testattavasta tuotteesta löytyy joka kerta vähemmän, kun testaajalle puetaan ravihevosen silmälaput ja laitetaan kulkemaan samaa polkua kerran toisensa jälkeen.

Jos rahaa ja aikaa on rajallisesti käytettävissä, niin kannattaa keskittyä olennaiseen. Testien suunnittelussa tärkeintä on kuvata tavoite. Se, mitä tulee tulla testatuksi. Kun testaaja saa valita reitin itse, tuloksia syntyy varmasti enemmän.

Share

Testaus voi tuplata ohjelmistotuotteen tuloksen

maanantai, 12 maaliskuuta, 2012 | Kirjoittaja: Antti Niittyviita

Ohjelmistoprojekti koostuu kolmesta olennaisesta kuluerästä. Juuri rakkaudella säveltämäni loru kertoo, mistä tässä kolmen kärjessä on kysymys.

Mistä on pienet ohjelmistoprojektit tehty,

mistä on pienet ohjelmistoprojektit tehty?

Koodauksesta, testauksesta, teknisen velan mittauksesta.

Niistä on pienet ohjelmistoprojektit tehty!

Jos tällaista pientä, noin miljoonan euron, ohjelmistoprojektia pysähtyy hetkeksi ajattelemaan tarkemmin, niin sen kulurakenne voisi näyttää tältä:

  1. Koodaus. 600k€: Ohjelmiston kehittäjällä on tarve saada softa toimitusvalmiiksi. Softan kaikkien haluttujen ominaisuuksien kehittäminen vie karkeasti ajatellen saman määrän työaikaa ja rahaa kaikissa tapauksissa. Featuret vaan pitää saada valmiiksi. Sitä faktaa ei voi paeta.
  2. Testaus. 50k€: Ohjelmistoprojektin toinen oleellinen kuluerä on testaus. Tyypillisesti tavoitellessa kovaa tulosta softaprojektista testaus on se paikka mistä leikataan kustannuksia. Useimmiten testauksen kulut ovat luokkaa 5-10% kehityksen kokonaiskuluista, kun suositus olisi 20-40%.
  3. Tekninen velka. 350k€: Kaikissa ohjelmistoprojekteissa muodostuu teknistä velkaa. Se koostuu lopputuotteeseen päätyvistä virheistä ja ongelmista, jotka aiheuttavat toimituksen jälkeen kustannuksia reklamaatioiden, takuukorjausten ja päivitysten muodossa. Lisäksi se voi aiheuttaa tulonmenetyksiä, kun maine laatutuotteiden toimittajana kärsii.

Kun tällainen projekti tuottaa liikevaihtoa 1.200k€ tulos on tasolla 200.000€ (20%). Hyvin toteutettu testaus voi kuitenkin säästää ohjelmiston elinkaaren kuluja suhteella 1:3.

Testausinvestoinnin vaikutus

Testausinvestoinnin vaikutus

Oikein suunnitellun testauksen avulla 100k€ lisäinvestointi laatuun voisi auttaa löytämään jopa 1000 bugia enemmän projektin aikana. Tekninen velka jäisi näistä ongelmista syntymättä ja ne voitaisiin korjata jo tuotekehityksen aikana. Lisäinvestoinnin avulla mainittu kolmen kuluerän summa onkin vain 800k€, mutta mitä se sitten tarkoittaa?

No tietysti lisää rahaa! Ohjelmistotuotteen tulos kaksinkertaistuu ja laadukkaampi tuote tekee myös varmasti paremmin kauppansa!

Share

Testauksen automatisointiko mullistaisi it-alan?

maanantai, 27 helmikuuta, 2012 | Kirjoittaja: Jussi Niittyviita

Tietoviikon tammikuussa julkaisemassa artikkelissa puhutaan testauksen automatisoinnista ja it-alan muuttuvasta ilmapiiristä. Avasin artikkelin kiinnostuneena, mutta aivoni jäivät lyömään tyhjää heti ensimmäisen lauseen kohdalla:

Ohjelmistotestaajan työ ja koko testaaminen ovat muuttumassa.

Testauksen perimmäisenä tarkoituksena on nostaa esille ne virhekohdat tuotteesta, jotka haittaavat loppukäyttäjän käyttökokemusta. Vaikka testaaminen saattaisi lisääntyä tuotteiden monimutkaistuessa, testauksen tarkoitus ei muutu mihinkään. Onko siis tarkoituksenmukaista ajaa ohjelmistotestaajan työtä ja koko testaamista muutoksen tielle?

Tietoviikon artikkelin lisäksi useasta lähteestä kuulee nykyään samaa raitaa missä lauletaan, että pitäisi panostaa enemmän testauksen automatisointiin. Joillekin automatisointi tuntuu olevan uuden testamentin veroinen ohjenuora työelämän pitkospuille. Sen nimeen vannotaan ja siihen panostetaan aina vain enemmän ja enemmän. Liekköhän tässä ollaan muutoksen tiellä ohituskaistalla vai ajamassa rampilta alas hitaaseen ja tukkoiseen taajamaan…

Vaikka testauksen automatisointi kannattaakin tietyissä tilanteissa, mielestäni testauksen automatisoinnin yhteydessä ei voi puhua testauksesta.  Kun testaustyö automatisoidaan, kyseessä on enää vain koneellinen tarkistus. Testauksen ja koneellisen tarkistuksen välillä on hurja ero. Niin pitkään kuin tuotteiden loppukäyttäjinä ovat ihmiset, ei varsinaista testausta kannata korvata koneellisesti. Koneet löytävät pieniä ja teknisiä nippelivirheitä, kun taas ihmiset löytävät fiilispohjaisia virheitä. Väitän, että olennainen osa virheistä löytyy jälkimmäisellä tavalla. Se on osa, joka vaikuttaa merkittävästi tuotteen myyntipotentiaaliin.

Jos testaamisen lisääntyessä testaajien määrä pienenee, ollaan ohjelmistokehityksessä hyvin vaarallisella tiellä. Tuolla tiellä merkittäviä virheitä jää löytymättä sitä mukaa kun rahaa palaa automatisoinnin suitsuttamiseen ja toteuttamiseen. Silloin kannattaa pysähtyä kysymään: Onko kyseinen yhtälö todellakin taloudellisesti kannattava?

Share

Mitä yhden virheen hinnalla olisi saanut aikaan?

keskiviikko, 11 tammikuuta, 2012 | Kirjoittaja: Antti Niittyviita

Cadillac SRX on jämäkän näköinen auto. Sitä valmistaa maailman suurin autovalmistaja General Motors. Vuoden 2011 mallin tullessa markkinoille ajoneuvon matkustajaturvallisuus oli ratkaistu ohjelmistolla, jossa kaikkien istuinpaikkojen ilmatyynyistä vastasi yksi järjestelmä.

Markkinoille tulon jälkeen GM:n insinöörit huomasivat kauhukseen hyvin perustavanlaatuisen virheen ilmatyynyjen hallintajärjestelmässä. Mikäli pelkääjän paikalla ei ajon aikana istu ketään, järjestelmä kytkee pois päältä myös takamatkustajien kattokiskossa olevan ilmatyynyn, joka suojaa päätä kuollettavalta iskulta.

Vian löytymisen jälkeen GM joutui kutsumaan Yhdysvalloissa 47,401 ja muualla Pohjois- Amerikassa 3,099 autoa huoltoon ja järjestelmäpäivitykseen. Siis yhteensä 50,500 autoa. Huoltokutsun toimenpiteet eivät takuulla olleet kovin yksinkertaiset.

Jos yhden auton softapäivitysprosessin läpivienti kutsun lähettämisestä huoltoon veisi yhden tunnin valmistajan ja huoltoyritysten työaikaa se kustantaa maltillisella 50 € tuntihinnalla 2,525,000 €. Puhumattakaan imagohaitasta tai asiakkaalle aiheutuneesta mielipahasta.

Lupasin taannoin myydä vain testauksen konkreettisimpia tuloksia – löytämiäni bugeja – hintaan 79 € / kappale. Tuohon hintaan minä olisin sitoutunut metsästämään GM:lle 31,962 bugia.

Share

Vuoden 2011 kalleimmat bugit listattu

tiistai, 3 tammikuuta, 2012 | Kirjoittaja: Jaakko Sakaranaho

Test Magazine on listannut vuoden 2011 kalleimmat softabugit.

Kalleimman bugin ykköspaikan valloitti rahoituspalveluita tarjoavan yrityksen softavirhe, joka aiheutti sijoittajille 217 miljoonan dollarin tulonmenetykset. Lisäksi USA:n arvopaperimarkkinoita valvova elin SEC lätkäisi päälle 25 miljoonan dollarin sakon. Näin ollen yhden bugin hinnaksi yritykselle tuli 242 miljoonaa Yhdysvaltain dollaria eli n. 185 miljoonaa euroa.

Koko listauksen voit lukea täältä.

On jälleen hyvä hetki muistuttaa:

Testaus on investointi. Investoinnin tarkoituksena on löytää virheet siinä vaiheessa, kun niiden korjaaminen on halvinta.

Hyvää vuotta 2012 kaikille!

Share