Ohjelmistojen laadunvarmistuksen ABC

Kaikille lienee selvää, että ohjelmistoja kehitettäessä myös niiden laatu tulee jollakin tavalla varmistaa. Koodareiden keskuudessa välillä kuulee vitsinä heitettävän että “asiakkaat testaa”, mutta todellisuus on tietenkin jotain aivan muuta. Kun julkaistaan kaupallinen ohjelmisto, tulee sen tietenkin toimia riittävän hyvin, muussa tapauksessa potentiaaliset asiakkaat varmasti kaikkoavat nopeasti pois. Toisaalta yksi alalla yleisesti tunnettu asia on myös se, että täysin virheetöntä ohjelmistoa ei ole olemassakaan.

Tai mikäli on, niin silloin sitä ei luultavasi ketään käytä.

Laadukas koodi ja kokonaisuus kasvaa pienistä asioista

Ohjelmistokehityksessä käytetään monia eri tapoja laadunvarmistuksessa. Koodareiden päivittäinen työ sisältää paljon tähän kategoriaan liittyviä asioita. Ketterässä kehityksessä tuoteomistajan työtä on määritellä ja hyväksyä tehdyt tuotokset. He toimivat myös tietopankkina siinä, mitä asiakkaat oikeasti haluavat – minkälaista kieltä käyttöliittymässä tulee lukea ja miten toiminnallisuuden tulee toimia. Ketterän kehityksen menetelmä Scrum sisältää myös monia erilaisia laadunvarmistuskriteereitä, jotka määritellään erilliseen dokumenttiin jota koodarit noudattavat työssään. Tuotantoversioon menevä koodi vertaisarvioidaan useampien ihmisten toimesta ja puutteet korjataan heti kehitysvaiheessa, jolloin havaitut ongelmat eivät ikinä pääse asiakkaalle asti.

Testaaminen on laadunvarmistusta

Tärkeä osa laadunvarmistusta on myös ohjelmiston testaus. Käytännössä vain toiminnallisuuden manuaalinen testaaminen ohjelmiston käyttöliittymässä ei riitä, koska tehty muutos saattaa mahdollisesti vaikuttaa muihin ohjelmiston osiin. Mitä monimutkaisempi softa, sitä enemmän löytyy myös riippuvuuksia asioiden välillä ja sitä työläämmäksi muuttuu kaikkien asioiden manuaalinen testaaminen. Tässä vaiheessa yrityksessä saatetaan pohtia, että pitäisikö kenties palkata erillinen testaaja. Entäs jos toteutettu koodipätkä on jotakin, jolla ei ole käyttöliittymää? Kuinka sen laadun voi varmistaa?

Onneksi nykypäivänä automatisoidut ratkaisut valtaavat alaa kuin alaa nopeutuvassa tahdissa.Laadunvarmistuksessa tähän kategoriaan menevät esimerkiksi erilaiset koodin analysointityökalut, joiden avulla koodista voidaan löytää ongelmakohtia tai riskialttiita kohtia. Toinen iso kokonaisuus, jota ei modernissa kehityksessä voi unohtaa on automaatiotestaus. Mikäli halutaan varmistaa ohjelmiston vakaus, on tärkeää kirjoittaa ohjelmistotestejä kattamaan riittävän suuri osa ohjelmiston koodipohjasta. Testejä on useita eri tyyppisiä:

• Yksikkötestaus
  Tällä tarkoitetaan yksittäisen koodikokonaisuuden testaamista. Testin tarkoitus on varmistaa että moduuli tekee sen mitä pitääkin.
• Integraatiotestaus
  Tämän tyyppisissä testeissä yhdistellään useampi eri koodikomponentteja. Testien tarkoitus on mitata erityisesti niiden välisiä rajapintoja.
• Järjestelmätestaus
  Tässä testaustavassa testataan järjestelmää kokonaisuudessaan, ei vain yhtä ohjelmistokerrosta.

Kuka testit tekee?

Tämä voi vaihdella yrityksissä, mutta meillä Arterilla koodaajat kirjoittavat testejä itse toteuttamistaan ominaisuuksista. Osa henkilöistä myös käyttää työtapanaan ohjelmistokehityksen menetelmää TDD (=Test-Driven Development). Se tarkoittaa, että koodaus tapahtuu tekemällä aina ensin testejä ja vasta sen jälkeen toiminnallista koodia.

Mikä määrä testejä on tarpeeksi?

Tähän on olemassa paljon mielipiteitä, mutta yleinen perusperiaate on että 80% testikattavuuden yli ei kannata paljoa mennä. Olisi hyvä, että kaikkia yllämainitun tyyppisiä testejä käytetään, riippuen tietenkin ohjelmiston laajuudesta ja monimutkaisuudesta. Panostamalla esimerkiksi järjestelmätestaukseen, voidaan mahdollisesti kompensoida jonkin toisen testityypin matalampaa kattavuutta.

Onko manuaalinen testaus sitten enää tarpeen?

Testit ovat aina juuri niin hyviä kuin koodari tai tiimi pystyy tekemään. Asiakas saattaa kuitenkin käyttää järjestelmää eri tavalla kuin koodari on ajatellut.

Valitettavasti siis automaatiotestauksen toteuttaminen ei ole hopealuoti, joka ratkaisee kaikki laadunvarmistuksen haasteet. Manuaalista testausta tarvitaan siis jatkossakin, mutta sen määrä on paljon pienempi kun perustoiminnot ja riippuvuuksiin liittyvät asiat on katettu automaatiotesteillä.

Koska koodari ajaa automaatiotestit?

Testejä tulisi ajaa aina kun tekee muutoksia olemassa olevaan koodiin. Tämä voi kuitenkin olla kovin aikaa vievää, joten siitä syystä myös testien ajaminen voi olla järkevää automatisoida. Tähän löytyy hyviä työkaluja, kuten esimerkiksi Jenkins.

Laadunvarmistus ohjelmistokehityksessä on yllättävän moninainen asia ja osin tästä syystä onkin haastavaa määritellä mitään laatutasoja ohjelmistoille. Tärkeintä on kuitenkin itse määritellä ohjelmiston tarkoitus ja tavoitteet ja sen pohjalta valita riittävät laadunvarmistusmenettelyt.