Testaaminen koodista tuotantoon asti, vasemmalta oikealle

29.7.2019 / by Esko Hannula

Ohjelmistotestaus, tuo tietojärjestelmäkehityksen outolintu. Mutta miksi näin on? Yleisellä tasolla testaamisen kustannuksia tai kestoa on jopa suhteellisen helppo arvioida. Tästä huolimatta juuri testausvaihe on laajalti tunnustettu pullonkaulaksi ohjelmistojen julkaisuprosesseissa.

Perinteisissä IT-projekteissa testaaminen aloitettiin melko myöhäisessä vaiheessa, sillä siihen keskityttiin vasta hieman ennen projektin päättymistä. Tämä johtui osittain siitä, että testaaminen ei onnistunut ennen kuin kaikki järjestelmän eri osiot oli saatu koottua yhdeksi kokonaisuudeksi. Testaajat kutsuivat tämän kaltaista kehitysprojektin viime metreillä toteutettavaa testausta “big bang“ -nimellä. Oli myös tavallista, että alun perin muutaman viikon mittaiseksi suunniteltu “big bang” testausjakso saattoi venyä nopesti jopa 10 kuukauden pituiseksi rupeamaksi. Kallista, arvaamatonta ja kuitenkin valitettavan yleistä.

Otetaan tarkasteluun “big bang” -testausta havainnollistava esimerkki. Oletetaan ensinnäkin, että yksi ohjelmoija on tehnyt koodivirheen. Tämän jälkeen viisi muuta ohjelmoijaa on kirjoittanut uutta koodia virheellisen koodin pohjalta. Kun ensimmäinen yksittäinen virhe lopulta löydetään ja korjataan, tämä vaikuttaa myös myöhemmin kirjoitettuihin koodikappaleisiin, sillä ne käyttäytyvät todennäköisesti korjaustoimenpiteiden jälkeen virheellisesti. Esimerkin yksittäistapauksen jälkeen voidaan kuvitella, kuinka monta sataa kertaa tällainen toistuu monimutkaista ohjelmistokoodia kirjoitettaessa. Jos vastaava virhe tapahtuu, tuloksena syntyy vain paniikinomainen testaa-korjaa-testaa-kierre, joka tuottaa jatkuvasti uusia virheitä, ennen kuin vanhoja on edes ehditty korjata.

Jotta edellämainittu tilanne voidaan välttää, tulee ohjelmistokehityksessä testaaminen aloittaa mahdollisimman varhaisessa vaiheessa ja paljon lähempänä alkuperäistä koodia. Toisin sanoen, testausta on siis siirrettävä vasemmalle. Näin ongelmakohdat ja virheet kyetään tunnistamaan ja korjaamaan sekä vielä tarkistamaan korjausten toimivuus ennen kuin virheet vaikuttavat koko muuhun järjestelmään. Mitä aikaisemmin testaus aloitetaan, sitä pidemmälle aikajaksolle se jakautuu ja näin ollen prosessiin osallistujien lukumäärä on myös pienempi.

Syitä riittävän aikaiseen testaamiseen on nykyään yhä helpompi löytää. Ketterät menetelmät, uudenaikaiset työkalut ja edullinen tietotekniikka ovat poistaneet vanhanaikaisia esteitä testaamisen tieltä. Mikäli haluat selvittää, kuinka ammattimaisia ketterästi toimivat tiimisi ovat, selvitä miten he testaavat... vai testaavatko ollenkaan.

Kehitys ei kuitenkaan ole suinkaan pysähtynyt tähän. Internet, pilvi, ja ketterät menetelmät ovat fasilitoineet kokonaan uuden tavan suunnitella, rakentaa ja julkaista ohjelmistoja. Tietojärjestelmät eivät ole enää irrallisia tai yksittäisiä hitaasti muuttuvia monoliitteja, sillä ne on koottu yhteen näennäisesti itsenäisistä elementeistä ja jatkuvista uusista julkaisuista.

Esimerkiksi ERP-järjestelmä on todennäköisesti linkitetty CRM-järjestelmään. ERP voi olla yrityksen sisäinen järjestelmä, mutta CRM voi sijaita pilvessä. ERP todennäköisesti palvelee useita itsenäisiä front end -sovelluksia ja vaihtaa jatkuvasti tietoja toimittajien ja jälleenmyyjien järjestelmien kanssa. Kun näissä järjestelmissä tapahtuu muutoksia, se todennäköisesti vaikuttaa yrityksen kriittisiin liiketoimintaprosesseihin.

Koska testausta tulee siirtää vasemmalle, on tunnistettava tarve siirtää sitä myös oikealle. Käytännössä tämä tarkoittaa jatkuvaa testien tekemistä ja seurantaa tuotantoympäristöissä, tavoitteena varmistaa järjestelmien toiminta suhteessa liiketoimintaprosesseihin. Tämä on usein jopa nopein ja edullisin tapa varmistaa, että ohjelmistot edelleen toimivat halutulla tavalla ja tukevat niitä liiketoimintaprosesseja, joita kuuluukin.

Testauksen siirtäminen vasemmalle parantaa nopeutta, laatua ja ohjelmistokehityksen tuottavuutta kun taas testien siirtäminen oikealle parantaa liiketoimintaprosessien varmuutta ja suorituskykyä erilaisissa tietojärjestelmäintegraatioissa.


Lue loput blogisarjasta:

  1. Keskity riskeihin ja riippuvuuksiin
  2. Ota DevOps käyttöön oikein
  3. Näe IT-sijoitukset tuotteina projektien sijaan
  4. Testaaminen vasemmalle ja oikealle
  5. Automatisoi
  6. Mittaa

Aiheet: Ohjelmistotestaus, Tietojärjestelmäkehitys