Laatu on nykypäivänä olennainen osa ohjelmistojen käyttökokemusta. Mutta miten ohjelmistolaatua mitataan eri tuotekehityksen vaiheissa?

Usein ohjelmistolaatua ajatellaan vain testauksen näkökulmasta, jolloin helposti keskitytään vain kehitysvaiheen aikaisiin toimenpiteisiin. Testitulokset, virheiden määrä ja virheiden luokat ovat hyvin yleisiä laadun mittareita. 

Tuotteen laatuun vaikuttaa merkittävästi suunnitteluvaiheen tehtävät – kaikki lähteekin hyvistä vaatimuksista ja määrityksistä!

Testauksella voidaan melko helposti todistaa täyttyykö kirjattu vaatimus tai määritys vai ei. Yksinkertaistettuna voisi väittää, että järjestelmä on tarkoituksenmukainen ja jopa hyvälaatuinen, kun se täyttää vaatimukset.

Kuitenkin testauksen lähtökohtana oleva vaatimus voi olla todellisten loppukäyttäjien mielestä väärä, vähemmän tärkeä tai sitten kaikkia vaatimuksia ei ole edes kirjattu ylös. Testaustuloksiin vaikuttaa myös vahvasti testaajan omat mielipiteet ja toiveet (“tämän pitäisi toimia haluamallani tavalla”) – toisinaan jopa vahvemmin kuin kirjattu dokumentaatio.

Jotta laadun mittaaminen eri tuotekehitysvaiheissa aukeaa paremmin, käydäänpä mittaamistapoja läpi koko matkalta. Aloitetaan mittausmatkamme laadun mittaamiseen vaatimuksista!

Vaatimusten laadukkuus

Kehitysprojekti alkaa tarpeesta saavuttaa jotain. Nämä ovat joko muutoksia olemassaolevaan järjestelmään tai selkeä tarve kokonaan uudelle järjestelmälle. Vaatimusten kerääminen aloitetaan järjestelmällisesti ja tässä kuullaan eri sidos- ja käyttäjäryhmien toiveita. Vaatimukset kerätään yhteen ja priorisoidaan, jolloin saadaan aikaiseksi pakollisten ja valinnaisten vaatimusten lista.

Järjestelmän laatu alkaa rakentua jo tässä vaiheessa pitkää tuotekehitysprojektia! Vaatimusten määrämuotoisuus, ymmärrettävyys sekä yksiselitteisyys vaikuttavat merkittävästi seuraavien vaiheiden tehokkuuteen sekä lopputulokseen.

Vaatimusten laadukkuus on melko helppo testata esimerkiksi tarkistuslistan avulla. Listalla voi olla esimerkiksi seuraavia asioita:

Jokainen organisaatio voi luonnollisesti tehdä oman tarkistuslistan esimerkiksi tämän esimerkin pohjalta.

Vaatimusten kattavuus

Yleinen testauksen mittari on vaatimuskattavuus eli miten kattavasti testit kattavat järjestelmälle kirjatut vaatimukset. Mutta vaatimuksillekin löytyy oma kattavuuden mittaustapa ja ISO/IEC 25010 -standardi käsitteleekin erilaisia vaatimustyyppejä.

Suurin osa vaatimuksia on ns. toiminnallisia vaatimuksia, jotka kuvaavat millaista toiminnallisuutta järjestelmässä on. ISO/IEC 25010 lisää toiminnallisten vaatimusten lisäksi myös ei-toiminnallisia vaatimuksia 7 eri kategoriaan seuraavasti.

Varmistamalla että myös ei-toiminnalliset osa-alueet huomioidaan vaatimus- ja määrittelyvaiheissa mahdollistetaan myös niiden testaaminen sekä sen kautta laadun mittaaminen.

Määritysten laadukkuus

Vaatimuksista johdetaan määritykset, jotka kuvaavat tarkemmin miten vaatimus toteutetaan. Tässä arkkitehdit, kehittäjät sekä testaajat yhdessä toimien voivat vaikuttaa merkittävästi siihen että järjestelmä saadaan kehitettyä tehokkaasti mutta myös laadukkaaksi.

Aivan vastaavasti kuin vaatimusvaiheessa, määrityksille on suositeltavaa tehdä tarkistuslista. Se voi olla jopa sama kuin vaatimuksille, mutta on myös hyvä huomioida muutama asia.

1.  Onko määritys jäljitettävissä vaatimukseen/vaatimuksiin? Tällä varmistetaan että mitään ei unohtunut ja kaikki tärkeä toteutetaan.

2.  Onko määrityksessä huomioitu negatiiviset vaatimukset eli miten järjestelmä ei kuulu toimia (esimerkiksi väärien syötteiden käsittely ja virhetilanteet). Tällä on suuri merkitys järjestelmän virheettömään käyttöön, kun järjestelmä osaa paremmin ohjata käyttäjää.

3.  Onko määrityksissä huomioitu testattavuus? Hyvät, selkeät määritykset tehostavat testausta merkittävästi.

Laadun mittaaminen

Suunnitteluvaiheella on siis suuri vaikutus tuotteen laatuun jo ennen kuin järjestelmää on vielä varsinaisesti kehitetty tai testattu. Laadun ja testauksen huomioiminen tässä vaiheessa on ns. Shift Left-ajattelua, jossa pyritään siirtämään näiden tehtävien tekemistä projektin alkupäätä kohti.

Seuraavassa blogin osassa jatkamme mittausmatkaamme kehitysvaiheeseen ja tutustumme esimerkiksi virheiden merkitykseen laadun mittauksessa.

• Blog
|
• QA
|
• Software testing