Heikki Ihalainen
Audit Oy
Audit teetti viime keväänä kyselyn suomalaisiin ohjelmistotaloihin. Tavoitteena oli selvittää, kuinka ne hoitavat ohjelmistotestauksen. Vastaukset saatiin 48 ohjelmistotalolta, jotka työllistivät keskimäärin 57 henkilöä ja joiden liikevaihto oli keskimäärin 36 mmk. Vastausprosentti oli lähes 30, joten tuloksia voinee pitää vähintäänkin suuntaa antavina.
Kyselyymme vastanneet yrityksen arvioivat ohjelmiston elinkaaren kustannusten jakautuvan eri vaiheisiin seuraavasti: määrittely 16%, suunnittelu 16%, ohjelmointi 29%, testaus 14% ja ylläpito 25%. Ulkomailla tehtyjen selvitysten mukaan ylläpidon osuus elinkaaren kustannuksista on huomattavasti suurempi ja lisäksi sen ennakoidaan jatkossa edelleen kasvavan.
Ylläpitokustannukset jakautuivat eri tekijöiden suhteen seuraavasti: muutokset käyttäjien tarpeissa 46%, muutokset tiedoissa 17%, laitteistomuutokset 7%, virheiden korjaukset 19% ja muut syyt 11%.
Yli puolet vastanneista (54%) myönsi, että ohjelmistotestauksesta on jouduttu tinkimään aikataulusyistä! Luku ei varmaankaan ole ainakaan liian pieni, sillä vastaavissa kyselyissä ulkomailla jopa kolme neljäsosaa vastanneista on joutunut vähentämään testaukseen varattua aikaa projektiaikataulun kiinni saamiseksi.
Lähes kolme neljännestä (71%) vastanneista oli sitä mieltä, että testaamiseen on käytettävissä liian vähän resursseja. Tästä syystä johtunee, että vain 29% vastanneista piti testauksensa tasoa vähintään "hyvänä". Tulokset ulkomaisista kyselyistä osoittavat, että vain vajaa neljännes ohjelmistotaloista pitää ohjelmistotestauksensa tasoa kattavana.
Ohjelmistokehityksen apuvälineistä tietokantajärjestelmät, raportointityökalut ja sovelluskehittimet olivat luonnollisesti käytössä lähes kaikilla. Ohjelmistotestauksen apuvälineet (CAST, Computer Aided Software Testing) puolestaan olivat yhtä harvinaisia kuin CASE välineetkin. Lieneekö tämä osasyy ohjelmistokehityksen tuottavuusongelmiin?
CASE välineillä rakennettava tietojärjestelmä voidaan "piirtää" tavalla, jonka käyttäjätkin ymmärtävät. Ohjelmistotestauksen apuvälineillä voidaan testauksen tavoite muuttaa oikeaksi: virheiden etsinnäksi toimivuuden todistamisen sijaan.
Testauksen apuvälineillä sovelluksen kaikki toimintavaihtoehdot voidaan helposti testata käyttäen sekä oikeita että virheellisiä tietoja. Tavanomainen testaustapa on käydä sovellusta läpi suunnittelijan ajattelemassa loogisessa järjestyksessä käyttäen vain oikeita syöttötietoja. Sovelluksen lopullinen käyttäjä ei todellisessa tuotantoympäristössä kuitenkaan aina toimi näin.
Selvityksen mukaan kaksi kolmannesta ylläpitokustannuksista aiheutui muutoksista käyttäjien tarpeissa ja virheiden korjauksista. Voi vain arvailla, kuinka paljon ylläpitokustannuksissa voitaisiin säästää CASE ja CAST työkaluilla. Kuitenkin vain vajaa kolmannes vastaajista aikoi investoida testaustyökaluihin!
Mikä on sitten laatujärjestelmän suhde ohjelmistolaatuun? Vastanneista yli kolmanneksella oli laatujärjestelmä käytössä. Kyselyn mukaan osa niistäkin, joilla on laatujärjestelmä käytössä, on joutunut tinkimään testauksesta aikataulusyistä! Yhdessä ohjelmistotalossa, jonka laatujärjestelmä on sertifioitu, suunnittelijoiden mukaan jopa määrittelystä tingitään kireiden projektiaikataulujen takia. Mikä onkaan lopputuloksen laatu, kun ei edes ehditä selvittää mitä asiakas tarvitsee? Riittävän ajan varaaminen määrittelyvaiheeseen on tietysti myös osittain asiakkaan vastuulla, sillä onhan määrittelyvaihe kaiketi kaikkein tärkein vaihe sovelluksen elinkaaressa. Laatujärjestelmillä ei välttämättä olekaan niin hyvää kaikua kuin toimittajat kuvittelevat. Yhden asiakkaan mukaan toimittajan sertifioitu laatujärjestelmä vain byrokratisoi asiakassuhdetta ja on yleensä vain este joustavalle toiminnalle. Tukeeko laatujärjestelmä laadun tuottamista, jos se vain tyytyy dokumentoimaan toimittajan tavan toimia ja unohtaa asiakkaan?
Testausta on pitkään pidetty välttämättömänä pahana, joka tehdään kehitysprojektin loppuvaiheessa, mikäli aika antaa myöten. Testauksen pitäisi kuitenkin olla integroituna osana mukana jokaisessa kehitysprojektin vaiheessa. Itse asiassa jo määrittelyvaiheessa tulisi tehdä päätökset, kuinka sovellus tullaan testaamaan.
Loppukaneettina on erään englantilaisen ohjelmistotalon edustajan käsitys testauksen tasosta ohjelmistoteollisuudessa:
"My experience suggests that our industry still regards testing as an overhead let the customer test it, then we'll fix the bugs and release an update... until software companies start getting sued for non performance of their products this will not change."
Heikki Ihalainen,
Audit Oy,