• Kandidaatin tutkielma

    Testauslähtöinen ohjelmistokehitys ja testaustehokkuus

    Nikita Zhuk
    Kandidaatin tutkielma
    Helsingin Yliopisto
    Tietojenkäsittelytieteen laitos

    Johdanto

    Perinteisissä prosessimalleissa ohjelmistoa testataan vasta sen jälkeen, kun se on saatu joko kokonaan tai osittain valmiiksi. Koska järjestelmän julkaisuajankohta on projektin lopussa yleensä jo kiinnitetty, testauksessa esille tulleita virheitä ei useinkaan ehditä korjaamaan ja näin virheellisesti toimivia ohjelmistoja päätyy asiakkaiden käyttöön. Systemaattinen testaaminen on tullut myös yhä hankalammaksi ja aikaavievämmäksi.

    Näiden ongelmien ratkaisuksi on esitetty ns. testauslähtöisiä prosessimalleja (test-driven process models), jotka perustuvat ohjelmakoodin testaamiseen pienemmissä osissa eli yksiköissä. Näiden prosessimallien pääperiaatteena on, että testit kirjoitetaan aina ennen yksikköjen toteutusta, jolloin ohjelmisto tulee testattua paremmin ja virheet löydettyä ja korjattua mahdollisimman aikaisessa vaiheessa. Yksiköiden testaamisen lisäksi testeillä pyritään myös varmistamaan, että ohjelmisto kokonaisuudessaan täyttää sille alun perin asetetut vaatimukset.

    Testauslähtöisistä prosessimalleista puhuttaessa keskitytään yleensä testauksen työvaiheisiin ja korostetaan testien olemassaoloa ennen testattavan koodin toteutusta. Testauksella on siis suuri vastuu projektin onnistumisesta. Kuitenkin pitää aina ottaa huomioon myös se, kuinka hyvin testit löytävät ohjelmakoodin virheitä ja kuinka testauksesta saa mahdollisimman kustannustehokasta. Perinteisessä IT-alan organisaatiokulttuurissa testausta ei arvosta riittävän korkealle ja se on ensimmäisenä kärsimässä projektin aikataulupaineista ja resurssipulasta.

    Yhteenveto

    Useat tieteelliset tutkimukset sekä käytännön projektit aina 60-luvulta lähtien ovat osoittaneet, että perinteiset lineaariset prosessimallit, kuten vesiputousmalli eivät useinkaan vastaa todellisiin ohjelmistokehityksen haasteisiin. Niiden dokumenttilähtöisyys ja “kerralla oikein” -mentaliteetti rajoittaa ohjelmiston muuntautumiskykyä, joka on välttämätön jatkuvasti muuttuvassa reaalimaailmassa. Tilalle on ehdotettu iteratiivisiin malleihin perustuvia ns. ketteriä malleja, joissa dokumentoinnin ja etukäteissuunnittelun määrää vähennetään, asiakkaalta saadun palautteen merkitystä painotetaan ja ohjelmistoa kehitetään lyhyissä iteraatioissa. Yhtenä näihin malleihin liittyvänä periaatteena on testauslähtöisyys, jossa testit kirjoitetaan jo ennen kuin testattavaa koodia on olemassa. Näissä malleissa testeillä ohjataan myös suunnittelua ja varmistetaan ohjelmiston korkeamman tason vaatimusten oikeellisuutta.

    Testeistä puhuttaessa tulisi kuitenkin kiinnittää huomiota myös siihen, kuinka hyvin testit löytävät ohjelmakoodin virheitä suhteessa testien suunnitteluun, toteutukseen ja suoritukseen vaadittuihin resursseihin. Koska testauslähtöisessä ohjelmistokehityksessä testeillä on suuri vastuu ohjelmiston laadun valvonnassa, myös testien tehokkuuteen tulisi kiinnittää yhä enemmän huomiota. Testausta on kuitenkin perinteisesti pidetty toisarvoisena, paljon aikaa vievänä työvaiheena, josta ollaan herkästi valmiita luopumaan aikataulupaineiden tai resurssipulan vuoksi. Yksi tärkeimmistä seikoista testauksen tehokkuuden ja testien laadun kehittämisessä on organisaatiokulttuurin kehittäminen kohti “testausystävällisempiä” asenteita.

    Testauksen tehokkuutta voidaan myös parantaa automatisoimalla joitakin testauksen työvaiheita kuten rasitustestausta, testitapausten generointia tai kattavuusmittausta. Kustannustehokas automatisointi on kuitenkin haastava tehtävä, sillä siihen liittyy lukuisia kustannustehokkuuteen vaikuttavia parametreja. Yhtenä käytännön esimerkeistä on esitelty Helsingin Yliopiston portaalihanke. Projektin regressiotestauksen automatisointipyrkimyksissä huomattiin, että vaikka testitapausten joukon jatkuva kasvu ja sen osajoukon säännöllinen toistuvuus testauksessa nostaisi automatisoinnin kannattavuutta, tekniset ongelmat käyttöliittymärajapinnassa estivät testitapausten automatisoinnin. Siksi regressiotestaus päätettiin pitää manuaalisesti suoritettavana.

    Testaustehokkuus liittyy testauslähtöiseen ohjelmistokehitykseen monella tapaa. Vaikka ennen tuotantokoodin kirjoitusta kirjoitettujen testien (tai esimerkkitapausten) tehokkuutta ei yleensä valvota, laadukkaan tuotantokoodin saavuttamiseksi testitapauksia joutuu täydentämään tuotantokoodin ollessa valmista, jolloin testaustehokkuuden valvonta, kuten kattavuusmittaus, tulevat tarpeeseen. Lisäksi testauksen automatisointi kuuluu kiinteästi testauslähtöiseen ohjelmistokehitykseen muun muuassa yksikkötestaus- ja regressiotestausvaiheissa.

    Tämän tutkielman tarkoituksena on ollut esitellä testauslähtöisyyden historiallisia taustoja sekä kertoa niistä pääperiaatteista, jotka kuuluvat testauslähtöisyyteen. Tämän lisäksi pääaiheina käsiteltiin testauksen tehostamista ja automatisointia sekä nykyisiä testaukseen liittyviä organisaatiokulttuurin haasteita. Testauksen haasteista kerrottiin myös Helsingin Yliopiston portaalihankkeen näkökulmasta.

    Kyseinen työ toimii testauslähtöisen ohjelmistokehityksen sekä testauksen tehostamisen ja automatisoinnin yleisesittelynä, jossa on pyritty ottamaan huomioon myös taloudellinen näkökulma. Käsiteltyjen asioiden haasteet on esitetty varsin abstraktilla tasolla, ja käytännönläheisempi analyysi testauslähtöisten menetelmien sekä testauksen automatisoinnin kustannustehokkuudesta sekä esitettyjen haasteiden ratkaisuista voisi olla jatkotutkimuksen aiheena.

    Tallenna tutkielma PDF-muodossa (174 KB).

    Update: January 16th, 2009
Comments are closed.
TOP