Testaus voi tuplata ohjelmistotuotteen tuloksen
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ä:
- 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.
- 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%.
- 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.
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!
Suosittelemme myös:
Testaus on epäeroottinen bisnes
Ohjelmistotestaus on ihan hemmetin epäeroottinen bisnes. Miksi ihmeessä se ketään kiinnostaisi? Testauspalvelu on kallista ja sen takaisinmaksua...
Tutkiva testaus ja offshore
Kävin eilen Agile Finlandin järjestämässä Agile Dinner -tapahtumassa. Paikalla oli joukko Oululaisia ohjelmistoalan ammattilaisia useista eri...
Heureka, opin juuri uuden termin eli ’Tekninen velka’. Olen käyttänyt aikaisemmin esimerkiksi termiä ’asiakkaan tekemä testaus’ tästä julkaisun jälkeen tehtävästä testauksesta joka kuormittaa asiakaspalvelua ja aiheuttaa kalliita jälkikorjauksia. Lisäksi asiakkaalle syntynyt mielipahan aiheuttama tappio on vaikesti määriteltävissä. Jotkut asiakkaat nimittäin purkavat tuntojaan Youtube-videoilla ja näistä videoista osa päätyy jopa maailman maineeseen. Kenellä on varaa päästää oma tuotteensa viallisena markkinoille ja asiakkaat sitten ovat pettymeitä ja pilkkaavat tuotetta yleisillä tiedonvaihtokanavilla? Pahimmillaan tämä haittaa tuotteen maineen lisäksi myös tuotteen tuottaneen yrityksen mainetta. Puhumme isoista asioista.
Teknistä velkaa ei kannata ottaa – korko on useinmiten liian kova.
Jo ensimmäisellä lukukerralla minulla jäi tästä artikkelista jotain nk. hampaankoloon – olen siis jo toisella kierroksella vähän paremmalla ajalla.
Ensinnäkin, tuo testaussuositus 20-40 % – olisiko sinulla sille jotain vakavasti otettavaa lähdettä? Ainoat lähteet joissa sitä tunnutaan viljelevän tosi laajalti ovat testausfirmojen markkinointimateriaalit. Toisekseen, testauksen laskeminen on aika vaikeaa. Huvittaako tai pitääkö laskea testaukseen testauksesta seuraavat korjaukset – ei varmasti testaajien mielestä, mutta vakavammin ottamissani lähteissä yleensä lasketaan reworkia, ei suinkaan aikaa ja investointia testaukseen. Cem Kanerilla ja kumppaneilla on mainio ”ikivihreä” siitä kuinka testauksen ja kehityksen kustannuksia pitäisi ja ei pitäisi vertailla – suosittelen lämpimästi.
Toisekseen, en pysty uskomaan että virhe kuin virhe on arvokas. Olen juuri parin viikon säteellä käsitellyt kaksi virhettä joiden korjauskustannus tuotannossa on kahden työpäivän luokkaa, aiheuttama ”hätäännys” vain vähän merkittävämpi ja joiden löytämiseen tarvittavat testausjärjestelyt olisivat enemmänkin puolikkaan miestyövuoden luokkaa – jos silloinkaan niihin osuisi.
Itse olen pitkään käyttänyt tuota velkakonseptia ketterien kirjoittajien opeista. Tosin omana teesinäni on, että jotain velkaa kannattaa ja jotain ei kannata ottaa. Kun raha tänä päivänä on arvokkaampaa kuin sama raha tulevaisuudessa ja velkakohteita on vielä erilaisia, joissain kohdin velanotto on erittäinkin kannattavaa taloudellisesti. Joitain velkoja annetaan valtioille, ja jotkut ovat niitä pikaluottoja – ja korot sen mukaiset. Tuotekehityksestä tarttui vahvasti se oppi, että tosiaan kaikki virheet ei siihen pikaluottojen sarjaan pääse.
Ja viimeisenä lempi-inhokkini, joka tässäkin talousartikkelissa tuli esiin: ei se testaaminen vaan se korjaaminen. Lisäinvestointi testaamiseen tuottaa joko hukkaa tai vaatii rinnalleen investoinnin korjaamiseen ollakseen minkään arvoinen.
Itse olen ollut mukana projekteissa joissa bugeja on hylätty läjä päittäin esimerkiksi siitä syystä, että korjaaminen olisi liian kallista tai sitten korjaamisen riskit olisivat liian suuret ns. regressiopelko. Teknistä velkaa on otettu myös monella muulla syyllä kuten että löydetty virhe aiheuttaa harmia vain pienelle osalle käyttäjiä tai että bugi on kosmeettinen ja sen haitta on lähinnä vain mielipaha.
Tuossa siis pieni otanta siitä millä selitteillä teknistä velkaa otetaan. Yllättävä tekijä on sitten se, että teknisen velan laatu ja määrä ovat tuntemattomia. Tämä on tilanne silloin kun tuotetta ei ole testattu.
Mentiimpäs kummalla velanottotyylillä tahansa, niin mukana pelissä on vaihteleva korko joka voi yllättäen ja arvaamatta napsauttaa kynsille. Kosmeettisena hylätty bugi voi päätyä kuvankaappauksina foorumeille joissa asiakkaat tuotetta mollaavat – tunnepitoiset virheet voivat olla kohtalokkaita virheitä. Otettu tekninen velka saattaa tulla korkojen kanssa kalliiksi – hyvin kalliiksi.
Harmikseni joudun toteamaan että olen seurannut aitiopaikalta kun tunnettu brändi alkoi ottamaan teknistä velkaa yksi tapaus toisensa jälkeen. Lopulta päädyttiin siihen tulokseen, että käyttäjien keskuudessa vallitsi jonkin sortin harmonia siitä, että kyseiset tuotteet ovat bugisia ja vaikeakäyttöisiä. Asiakkaiden mielikuvien painoarvon merkitystä ei passaa painaa villaisella.
Käytännössä teknistä velkaa syntyy aina. Testauksella velkataakka saadaan pienemmäksi ja velan laatu ja määrä pystytään määrittelemään osapuilleen.
Tervehdys Ammattitestaaja ja Maaret 🙂 Olipa mukavaa lukea teidän kommentteja jälleen palatessa puolustusvoimien kustantamalta viikon mittaiselta rentoutumismatkalta.
Teknisen velan termi on minusta mainio ja mielestäni se on myös liian vähän käytetty. Testausalan ihmiset tuntuvat olevan siitä parhaiten perillä, mutta siitäkin meidän pitäisi opetella puhumaan paremmin ja enemmän. Teknisen velan vähentäminen ei vain pienennä myöhempiä kustannuksia, vaan seurauksena siitä viivan alle jää aina parempi tulos.
Tuohon virheen arvoon liittyen täytyy sanoa, että itse uskon keskiarvoistamisen taitoon. Toiset virheet voivat olla miljoonien arvoisia ja toiset taas ei minkään arvoisia.
Velan ottaminen on aina peliä riskeillä ja todennäköisyyksillä. Korkokehityksestä ei voi koskaan olla 100-varma. Niin ei myöskään voi etukäteen tietää täysin varmasti mitkä virheet sitten lopulta ovat ne kalleimmat.
P.S. Laadin harvoin lähdeluetteloita teksteihini. Se on aivan liian työlästä hommaa ja tekstit eivät muutenkaan yritä olla tieteellistä julkaisua. 20-40% heitto saattaa juontaa juurensta jopa jostain vuosikymmenten takaa, kuten teoksesta ”Ohjelmisto tuotanto by Haikala I. & Märijärvi J. (painosta en jaksa muistaa)” Eiköhän tätäkin esittelemääni käsitystä tukevia teoksia löydy hakemistoista ja julkaisuista pilvin pimein, kun lähtee tutkimusmatkalle ohjelmistoalan julkaisuiden ihmeelliseen maailmaan. Pääasia on, että keskustelu herää 🙂
Bugien metsästykseen pitää käyttää suhteessa vain tietty määrä aikaa. Jos on tarkoitus löytää mahdollisimman monta bugia, projekti viivästyy ja kustannukset karkaavat käsistä. Sen takia on yritettävä analysoida ja käyttää pieniä hoksottimia sen verran, että ne major-bugit löydetään. Tämä pätee varsinkin resursseiltaan pieneen ohjelmistoyritykseen. Kaikki tämän jälkeen löytyvät pienet bugit voidaan korjata tuotekehityksen lomassa. Tästä seuraa myös se synernergia-hyöty, että tuotteen elinkaarta voidaan pidentää, koska asiakkailta voidaan sitten veloittaa ylläpitomaksua, koska niitä bugeja pitää kuitenkin olla korjaamassa ja siinä ohessa tulee myös kehitettyä tuotetta ja kaikki hyötyvät. Tietenkin isoissa firmoissa on voimavaroja hassata testaukseen tai mihin tahansa älämölöön niitä rahoja, mutta pienen yrityksen ei pidä haksahtaa ultra-testaukseen.
@Esa: Tuote määrää sen, pitääkö pienetkin viat löytää vai ei. Ei firman koolla ole siihen mitään osuutta. Ajattele vaikka jotain elintärkeää softaa; sen nyt on vaan toimittava aina oikein – tekipä sen iso tai pieni firma.
Rahan suhteen pitää olla kuin ison maalaistalon pojat. He tietävät, että rahaa on, mutta se tulee käyttää viisaasti. Jokaisen tällä alalla toimivan tulee tietää, että mitä aiemmin vika löydetään, sitä halvempaa sen korjaaminen on. Eli kannattaa panostaa katselmointeihin ja alemmantason testaamiseen, kuin siihen, että testataan tuote vain systeemitasolla. Mielestäni tämä on suurin virhe missä projekti päällikkö ”säästää”.
Joidenkin tutkimusten mukaan, yli 50% virheistä johtuu epäselvistä tai puutteellisista vaatimuksista. Toisin sanoen, yli puolet vioista tehdään ja testataan ”tahallaan väärin”. ja sitten niitä aletaan korjaamaan jälkikäteen. Ei ihmekkään, että aikaa ja rahaa ei ole niiden korjaamiseen.
Toinen tutkimus kertoo, että 64% featureista on lähes turhia. Miksi niitä edes tehdään, jos niitä ei kukaan käytä? Miksi niiden testauksessa sitten ”säästetään” ja annetaan vikojen mennä läpi? Eikö olisi parempaa säästöä olla tekemättä ko. featurea, jos sitä ei tarvita tai jos se saa mennä toimimattomana ulos?
@Esa. kuullostaa härskille toimntatavalle, että jätetään tuotteita tahallaan ja sitten rahastetaan asiaksta niistä uudestaan. Mikä firma toimii noin? Itse en osta softaa moisteta firmasta.
Esa & Marko,
Kiitos kommenteistanne! Huomaan, että olette aihepiirin kanssa painiskelleet ennenkin.
Mielestäni testauksessa pitää olla aina tavoitteena löytää mahdollisimman paljon tietoa ja bugeja sijoitettuun aikaikkunaan, eli rahamäärään nähden. Kovin usein kaikki muu on epäolennaista tekemistä.
Tuntuu, että tuota ajatusta tuotteen elinkaaren pidentämisestä sovelletaan erityisesti suurissa tietojärjestelmähankkeissa. Usein sellaisten hankkeiden ylläpito ja tukimaksut ovat sen verran jämerää kokoluokkaa, että fiksailu jälkikäteen on aivan kannattavaa bisnestä. Minusta vika ei kuitenkaan ole toimittajan päässä vaan monesti kysymys on heikosta osto-osaamisessa.
Jo vuonna 2000 julkaistu Dilbert kiteyttää tämän tarinan erinomaisesti. Se komeilee isona printtinä myös meidän toimiston jääkaapin ovessa: http://dilbert.com/strips/comic/2000-03-19/