Puhuimme blogin ensimmäisessä osassa suunnitteluvaiheen aikaisesta laadusta. Nyt on sitten vuorossa kehitysvaihe!

Tyypillisesti ohjelmistotestauksessa laatua lähestytään hyvin suoraviivaisesti: ohjelmisto ymmärretään laadukkaaksi, kun se vastaa sille kirjoitettuja vaatimuksia ja määrityksiä, ja siinä olevien virheiden määrä on matala tai virheitä ei ole.

Etenkin havaitut virheet ovat usein keskiössä kehitysvaiheen laadun tulkitsemisessa. Kehitysvaiheen aluksi ohjelmisto on virheetön, koska virheet löytävä testaus on vielä tekemättä. Testauksen alkaessa virheitä löytyy tyypillisesti paljon, mutta niiden kirjaamistahti hidastuu testauksen edessä. 

Tarkoittaako virheiden määrän väheneminen kuitenkaan sitä, että ohjelmiston laatu paranee? 

Virheiden määrä kertoo testauksen tehokkuudesta 

Projekteissa tuijotetaan avointen virheiden määrää usein ilman kritiikkiä. Moni päättelee, että suuri virheiden määrä kertoo ongelmista määrittelytyössä, kehityksessä tai testauksessa. Se ei kuitenkaan ole koko totuus; löydettyjen virheiden määrä kertoo ensisijaisesti testauksen tehokkuudesta eli siitä kuinka paljon testaajat ovat tehneet havaintoja testauksen aikana. 

Tuotannon aikana virheiden määrä heijastaa käyttäjäpalautetta. Tässä palautteessa on usein mukana paljon infrastruktuuriin liittyvää tietoa, joka ei varsinaisesti kuvaa itse järjestelmän ongelmia. Lisäksi havaintoraportteihin voi päätyä useita havaintoja samasta ongelmasta eri sanoin ilmaistuna. Ja usein joukossa on myös hyvin paljon parannusehdotuksia, etenkin järjestelmän tuotantokäytön alkupuolella!

Onko testauksessa löydetty virhe aina virhe?

Testauksen tekemiä havaintoja kutsutaan usein automaattisesti virheiksi, vaikka pitäisi puhua havainnoista. Havainnot voivat hyvin olla myös uusia vaatimuksia ja parannusehdotuksia, eivätkä olemassa olevan toiminnallisuuden virheitä. Kaikki tällaiset havainnot ovat arvokasta tietoa ja ne kannattaa kirjata erilleen virheistä. 

Valitettavasti hyvin usein nämä ovat mukana järjestelmän virheluvuissa ja antavat siten valheellisen kuvan niin virheiden määrästä kuin ohjelmiston laadusta!

Virheiden määrä kertoo laadusta vain välillisesti

Virheiden määrä ei yksinään riitä ohjelmiston laatuun liittyvien päätelmien tekemiseen. Järjestelmässä saattaa olla paljon virheitä yksinkertaisesti siksi, että sitä on testattu enemmän tai suunnitelmallisemmin, kynnys kirjata virheitä on ollut matalampi tai testaajat eivät ole ymmärtäneet vaatimuksia, vaan kirjaavat virheiksi omia mielipiteitään ohjelmiston käytöksestä.

On virheitä sitten 50 tai 500, luku ei suoraan tarkoita, että järjestelmä olisi käyttökelvoton tai huono. Vasta virheiden vaikutuksen analysointi paljastaa, miten virheiden yhteenlaskettu haitta vaikeuttaa järjestelmän käyttöä. Nyt olemme viimein päässeet virheiden kautta saatavaan varsinaiseen tietoon eli niiden vaikutukseen ohjelmiston laatuun!

Arvioidaan testauksen laatua sekä käyttökokemusta

Laadunvarmistuksen merkittävimpiä asioita on arvioida vastaako järjestelmä käyttötarkoitusta, eli voiko järjestelmällä tai laitteella tehdä niitä asioita, joiden takia se on alun perin hankittu.

All olevassa kuvassa on esitetty muutama yksinkertainen mittari ohjelmiston laadun arviointiin: 

Nämä mittarit yhdistämällä voidaan todeta, kuinka kattavasti ja laadukkaasti järjestelmä on testattu, miten avoimet havainnot vaikuttavat käyttökokemukseen sekä miten valmis järjestelmä on loppukäyttäjien mielestä tuotantokäyttöön.

Testauksessa yksittäisen mittarin tuijottaminen voi johtaa vääriin päätelmiin, koska testitulokset tai virheiden määrä kertovat vain välillisesti järjestelmän tai tuotekehitysprosessien laadusta. Virheiden luokittelun tai niiden määrän mittaamisen sijaan tulee laadunvarmistuksessa ja testauksessa muistaa alkuperäinen syy järjestelmän hankinnalle. 

Järjestelmiä rakennetaan käyttäjille tarkkaan määriteltyä käyttötarkoitusta varten, joten myös laatumittareiden pitää siksi mitata sitä, miten hyvin ja tehokkaasti nämä tarpeet täyttyvät.

Laadun mittaaminen

Näissä kahdessa blogissa on käyty läpi laadun mittaamista suunnitteluvaiheessa sekä tuotekehityksen aikana. Molemmissa vaiheissa laatua mitataan ja ohjataan erilaisilla menetelmillä sekä mittareilla. Toivottavasti lukija sai näistä ideoita miten parantaa tai mitata laatua omassa tuotekehityksessä!

Autamme mielellämme kaikessa ohjelmistojen laadun mittaamiseen liittyvässä. Erityisesti nämä blogit kirjoittanut laatugurumme Juha Pomppu tuntee nämä asiat kuin omat taskunsa, ja sparrailee näistä mielellään. Ota siis yhteyttä niin jutellaan lisää!

• Blog
|
• QA
|
• Software testing