Ohjelmistojen laadunvarmistus tarkoittaa yhden yleisen määrittelyn mukaan yrityksen ohjelmistotuotantoprosessin monitorointia mittaamisen avulla ja kaikkia niitä toimenpiteitä, joilla varmistetaan tekeillä olevan ohjelmistoratkaisun laatu. Pääasiassa tässä kohtaa tarkastellaan kolmea asiaa:
- Organisaation prosessit, ohjeet, käytännöt ja dokumenttipohjat
- Projektikohtaiset prosessit, ohjeet ja käytännöt, jotka on jalostettu edellisistä
- Laadun kontrollointi eli organisaation pitää varmistaa, että sovittuja prosesseja, ohjeita ja käytäntöjä noudatetaan
Laadunvarmistuksessa on yleensä tarkkailtu ja mitattu sitä, miten dokumentoituja prosesseja ja ohjeita on noudatettu. Ehkä tästä syystä ohjelmistojen laadunvarmistus on saanut otsaansa leiman hyödyttömänä prosessin noudattamisen ja pakollisen dokumentaation tuottamisen kyylääjänä. Vesiputouksen ja V-mallin aikana tuo olikin suuressa määrin totta. Ketterä kehitys käänsi kaikki päälaelleen, mutta laadun näkökulmasta tilanne ei ole parantunut.
Tässä blogissa laadunvarmistuksella tarkoitetaan kaikkia niitä toimia, joilla ehkäistään virheiden syntymistä ja niiden leviämistä. Tätä tarvitaan jokaisessa ohjelmistoprojektissa, sillä mittaustietojen perusteella suurin ohjelmistotuotannon kustannustekijä on viimeisten 35 vuoden ajan ollut ohjelmistossa olevien virheiden löytäminen ja korjaaminen.
Mittaamisen haasteisiin kuuluvat pohjatietojen hankkiminen ja epäselvä toimintopisteiden määrittely
Mittaaminen on varmaankin osa-alueista se, joka usein todetaan turhauttavaksi tai jopa turhaksi. Kuitenkin vain mittaamalla saat tietoa siitä, miten projektilla tai yrityksellä sujuu. Henkilö, jonka mittaamisen tuloksiin ja havaintoihin luotan, on Capers Jones. Hän on todella kokenut metriikkaguru, joka on avannut mittaamisen saloja jo 70-luvulta lähtien työskennellessään IBM:llä. Kaikki tässä esitetyt numerotiedot on poimittu hänen uusimmista esityksistään.
Ohjelmistotyön mittaamiseen käytettäviin pohjatietoihin kuuluvat löydetyt virheet, työtunnit ja ohjelmiston koko sekä monimutkaisuus. Pohjatietojen avulla voidaan laskea metriikoita, joiden avulla vertaillaan yrityksen projekteja sisäisesti, toisten yritysten välillä ja yleisesti trendeihin verraten. Jokaiseen kolmen pohjatiedon saamiseen ja mittaamiseen liittyy jonkinasteisia ongelmia.
Kaikkia eri ohjelmistotuotannon vaiheista löydettyjä virheitä ei varmasti kirjata mihinkään vianhallintajärjestelmään. Tämän tietää jokainen softaa tehnyt henkilö. Työtuntien kirjaamisessa löytyy puutteita, joista yksi esimerkki on pieneen työhön tarvittu erikoisosaaminen. Toinen esimerkki liittyy julkaisun jälkeiseen ylläpitoon ja virheiden korjaamiseen käytettyihin tunteihin. Ohjelmiston kokoahan voidaan mitata esimerkiksi koodirivien määrällä, mutta mittari ei kerro mitään ohjelmiston monimutkaisuudesta.
Koon ja monimutkaisuuden yhdistävänä mittarina käytetään usein toimintopisteitä (function points). Kuten ohjelmistoalan nuoreen ikään kuuluu, toimintopisteestä on tehty useita määrittelyitä eri laitosten toimesta eli siitäkään ei ole yhtä ja samaa käsitystä. Tämä tarkoittaa samaa kuin jos metrin mittoja olisi useita erilaisia.
Ketterästä kehityksestä tuttu tarinoiden pisteytys on puolestaan erilainen koon ja monimutkaisuuden mittari, koska se on subjektiivinen ja tiimikohtainen. Ohjelmistotyön määrittelyssä käytetyt tarinat, käyttötapaukset tai ominaisuudetkaan eivät ole missään vertailtavissa standardimitoissa.
Virheitä etsiessä seuraa ohjelmistotuotannon vaiheita, menetelmää tai toimintatapaa
Missä niitä virheitä sitten oikein syntyy? Yleensähän vastaus on koodatessa, ja testauksen vika on, jos niitä ei löydetä. Alla on tilastotietoa vuodelta 2016 noin 600 yrityksen eri projekteista:
- Vaatimukset 15%
- Suunnittelu 30%
- Koodaus 40%
- Dokumentointi 8%
- Vikakorjaukset 7%
Nämä ovat siis keskiarvoja, joten ne voivat vaihdella jonkin verran eri yrityksissä ja erilaisissa projekteissa. Näitä lukuja kannattaisi jokaisen yrityksen seurata, jotta varmistuisi, mitä ohjelmistotuotannon vaihetta, menetelmää tai toimintatapaa pitäisi parantaa.
Hyvä tapa on seurata asiakkaan löytämiä vikoja ja analysoida niistä ainakin kriittisimmät. Lisäksi viat pitäisi analysoida kunnolla eikä tyytyä lausuntoon: ”Olisi pitänyt löytyä testauksessa”. Testitapaukset perustuvat usein vaatimuksiin ja määrittelyihin. Jos jo ne ovat virheellisiä, niin ovat testitapauksetkin.
Arto Stenberg,
Senior QA Consultant
arto.stenberg@q-factory.fi
