Resepti ohjelmistojen testaamiselle

Ohjelmistojen rooli teollisuusympäristössä kasvaa jatkuvasti: ohjelmistoja on enemmän, ne ovat monimutkaisempia sekä riippuvaisempia toisistaan. Ne ovat vastuussa merkittävistä ja vaarallisista laitteista. Diplomityössä selvittämäni perusteella ohjelmistojen testaamista ei kuitenkaan aina nähdä tärkeänä ja se on usein työvaihe, jota ei oteta vakavasti ja jota laiminlyödään ensimmäisenä resurssi- tai aikataulupaineiden alla. Tarve testaamiselle ei kuitenkaan katoa ja testaamisen tärkeys voi korostua ikävällä tavalla vasta projektin julkaisuvaiheessa. Tutkin diplomityössäni, miten toiminnallinen testaaminen voidaan tuoda pysyväksi osaksi olemassa olevaa kypsää teollisuusohjelmistoprojektia, ja miten tunnistaa tärkeimmät testattavat toiminnot ja testata niitä tehokkaasti. Ei-toiminnallinen testaus (suorituskyky, tietoturva yms.) jäi aiheen laajuuden vuoksi tutkimusskoopin ulkopuolelle.

Työn tuloksena oli testaamisen resepti, joka vaatii kolme raaka-ainetta: edellytykset, suunnitelmat ja implementaation.

Edellytykset luovat pohjan

Testaaminen, ja erityisesti automaattinen testaaminen, vaatii paljon resursseja. Tätä resurssikäyttöä ole aina helppoa perustella, sillä testaamisen hyödyt eivät välttämättä ole ilmiselviä ainakaan niille, jotka eivät ole päivittäin tekemisissä ohjelmiston kanssa. Edellytysten kannalta tärkeintä onkin se, että koko organisaatio, mutta erityisesti johto, saadaan ymmärtämään testaamisen tärkeys. Tehokkain tapa perustella testaamista on puhua luvuilla ja tuoda aihetta näkyvämmäksi. Vahvoja perusteluja testaamiselle voivat olla esimerkiksi virheiden korjaamisen kuluvan ajan mittaaminen, arviot virheiden mahdollisesta kustannuksesta tai laadun kehittyminen. Näiden metriikoiden tueksi voidaan laatia arviot/mallinnukset siitä, miten testaamisen kehittäminen auttaisi tilanteessa ja kuinka nopeasti säästöjä voisi syntyä. Edellytysten toinen osa vaatii projektin analysointia, sillä testaaminen vaatii onnistuakseen osaamista ja resursseja, joita organisaatiosta on löydyttävä.

Toisaalta on tärkeää tunnistaa se, minkälainen elinkaari projektilla on ennen kuin päätetään miten testaamista lähdetään edistämään. Testaamisen automatisoinnilla on kiistattomia etuja: case-tutkimusten perusteella mitattu ROI testaamisen automatisoinnille voi olla kymmeniä tai jopa tuhansia prosentteja. Ajallisten ja rahallisten säästöjen lisäksi tutkimuksissa raportoitiin myös tyytyväisemmistä asiakkaista. Toisaalta elinkaaren päässään oleville tai lyhyille projekteille ei välttämättä kannata suunnitella kattavaa testiautomaatiota, sillä automatisointiin sijoitettu resurssi vaatii aina pidemmän takaisinmaksuajan kuin manuaalinen testaus.

Suunnitelmien pohjalta nopeasti eteenpäin

Testaussuunnitelman kannalta on tärkeää analysoida projekti ensin yleisellä tasolla, jotta tiedetään minkä kanssa ollaan tekemisissä, mikä on tärkeää ja missä ovat mahdolliset kipukohdat testaamisen automatisoinnin kannalta.

• Maturiteetti. Testaamisen automatisoinnille kaikkein hedelmällistä aikaa on se vaihe, kun projekti on riittävän pitkällä, eli ohjelmistossa on ominaisuuksia, joiden osalta voidaan olettaa, ettei rikkovia muutoksia ole enää luvassa. Automaattisten testien implementointi sellaisille ominaisuuksille, joiden tiedetään muuttuvan, aiheuttaa vain rikkinäisiä testejä ja siten tehottomuutta.
• Turvallisuuskriittiset tekijät. On tärkeää tunnistaa onko ohjelmisto suoraan tai epäsuorasti yhteydessä turvallisuuskriittisiin laitteisiin. Näiden osa-alueiden testaaminen tulee olla ensisijaista. Teollisuusympäristössä tällaisia usein löytyy useita.
• Ulkoiset tekijät. Riippuvuus muista ohjelmistoista ja tarve kustomoinnille ovat asioita, jotka lähtökohtaisesti hankaloittavat testattavuutta. Toisista ohjelmistoista riippuvien tai kustomoitujen ominaisuuksien kirjo tulee olla selvillä ennen kuin ominaisuuksien testaamista lähdetään suunnittelemaan. Näiden ominaisuuksien testaaminen automaattisesti ei välttämättä ole mahdotonta, mutta jos tarkoituksena on tuoda automaattista testausta projektiin mahdollisimman tehokkaasti ja kattavasti, niin implementointi kannattaa aloittaa muualta.

Diplomityöni osana loin mallin, jolla testaustarvetta ja prioriteettia voidaan arvioida yksittäisten ominaisuuksien tasolla. Mallin tarkoituksena on saavuttaa mahdollisimman kattava testisuunnitelma, jolla voidaan päästä testaamisessa alkuun mahdollisimman tehokkaasti. Malli perustuu ohjelmiston ominaisuuksien arviointiin seitsemän tekijän pohjalta: riittävä maturiteetti (a), toiminnallinen kriittisyys (b), turvallisuuskriittisyys (c), riippuvuudet muista ominaisuuksista (d), riippuvuus muista ohjelmistoista (e), kustomointi (f), virhehistoria (g), julkaisufrekvenssi (h) ja nopea kehitysfrekvenssi (i).

Erityisesti teollisuusohjelmistoja testatessa on ensiarvoisen tärkeää saada myös ohjelmiston käyttäjän näkökulma ja ammattitaito mukaan jo suunnitteluvaiheessa. Teollisuuden ohjelmistoja käyttävät usein oman ammattikuntansa erikoisosaajat, joilla on korvaamattoman arvokasta tietoa mm. mahdollisesta virhehistoriasta (g), turvallisuuskriittisistä rajapinnoista (c) ym.

Ennen implementointia täytyy myös selvittää, miten testataan. Testityökalun valinta on monen tekijän summa: työkalun tulee ensisijaisesti kattaa testaamisen tarpeet, mutta olla myös pitkäikäinen/tuettu, jotta käyttöä voi jatkaa tulevaisuudessa sekä olla helposti omaksuttavissa kehittäjien/testaajien nykyisellä osaamisella.

Implementointi kestää ikuisuuden

Testejä kehittäessä täytyy muistaa kolme perusperiaatetta, jotta testaaminen pysyy ylläpidettävänä: standardit, tulosten raportointi ja uudelleenkäytettävyys. Standardit tässä kontekstissa tarkoittavat ensisijaisesti projektin tai organisaation sisäisiä käytäntöjä: nimeämiskäytännöt, ohjeet yms, joiden täytyy olla yhtenäisiä, jotta testien korjaaminen ja uusien ihmisten liittyminen projektiin pysyy mahdollisimman saumattomana. Testaamisen käytetyn resurssin perustelu on helpompaa, kun lopputulos on näkyvää: siksi jo testejä kehitettäessä täytyy huomioida, miten testien tuloksista saadaan ymmärrettäviä raportteja helposti. Hyvä testi kertoo myös asiaan perehtymättömälle mitä testattiin ja miksi se onnistui tai ei onnistunut. Uudelleenkäytettävät komponentit ovat ohjelmistotuotannossa arkipäivää ja samaa periaatetta tulisi vaalia myös testejä kehittäessä.

Testien kehittäminen tulee tunnistaa jatkuvaksi prosessiksi. Ylläpito ei vaadi ihmeitä, jos pohjatyö on tehty hyvin, mutta työkalujen ja käytäntöjen kehittyessä ympärillä on hyvä uudelleenarvioida myös testaussuunnitelmia ja -työkaluja.

Ainekset testaamiseen pähkinänkuoressa

Reseptin voi vedostaa kolmeen eri osaan.

• Edellytykset:
  • Johdon tuki. Tuen saamiseksi ei aina välttämättä tarvita erityisiä toimia, mutta perusteluita testaamiselle voi mallintaa esimerkiksi erilaisten metriikoiden avulla (virheen kustannus, ajalliset säästöt, asiakastyytyväisyys ym.).
  • Elinkaari ja resurssit. Automaatio on lähes aina perusteltua, mutta korkean etukäteiskustannuksen takia asiaa täytyy punnita projektin elinkaari ja olemassa olevat resurssit huomioon ottaen
• Suunnittelu:
  • Projektin läpikäynti. Tarkoituksena on kartoittaa muun muassa testaamisen kannalta kriittisiä pisteitä sekä automaattista testaamista mahdollisesti hankaloittavia seikkoja. Luodun mallin avulla projektin ominaisuuksien testaamiselle arvioidaan prioriteetti esimerkiksi niiden turvallisuuskriittisyyden ja virhehistorian perusteella.
  • Työkalut. Testaustyökalujen tulee ensisijaisesti kattaa testaustarpeet, mutta olla mielellään myös helposti omaksuttavia ja hyvin tuettuja.
• Implementointi
  • Perusperiaatteet. Standardit ja dokumentaatio, tulosten raportointi ja uudelleenkäytettävyys luovat pohjan ylläpidettäville ja hyödylliselle testaamiselle.