Ketterällä testauksella laatua BI-hankkeisiin

13.03.2016 Projektinhallinta, Tietovarastointi

Testaamaton ei ole valmis. Verrattain yksinkertaista, eikö totta!

Ei itse asiassa ole. Testaus jää BI-hankkeissa (eikä pelkästään niissä) monesti yllättävän vähälle huomiolle, ja seuraukset ovat tuntuvia. Katsotaanpa aluksi hypoteettista esimerkkiä. Perinteisen projektin perinteinen testausvaihe on kaikille tuttu, ja se menee jotakuinkin näin:

1. Koodari toteuttaa toiminnot X, Y ja Z projektin puolivälissä.

2. Testaaja testaa toiminnot X ja Z projektin loppuvaiheessa kuuden kuukauden kuluttua (jos aikataulussa on vielä siinä vaiheessa tilaa testaukselle).

3. Jos testauksen raportoinnista on erikseen sovittu, kirjataan ohjausryhmää varten että ”Toiminnot X ja Z testattiin. Z:n vaatimat korjaukset toteutetaan osana jatkoprojektia.”

4. Toiminto Y toimii väärin neljän kuukauden ajan käyttöönoton jälkeen, kunnes se huomataan sattumalta ja korjataan ylitöitä vaativana hotfixinä suoraan tuotantoympäristöön.

Kaikille lienee selvää että edellä kuvattu tapahtumien kulku ei ole täysin optimaalinen.
Perinteisen vesiputousprojektin testauksen ongelmat ovat usein seuraavanlaisia:

  • Valtaosa kaikesta testauksesta tehdään erillisessä testausvaiheessa projektin lopuksi. Juuri mitään testaushavaintoja ei enää ehditä korjata ennen käyttöönotto-deadlinea. Usein myös testauksesta leikataan, jos aikataulu menee liian tiukaksi.
  • Toiminnon toteutuksen ja sen testauksen välissä kuluu kauan aikaa. Tämä kasvattaa teknistä velkaa: bugin korjaus on sitä vaikeampaa ja kalliimpaa, mitä pidempi aika sen syntymisestä on kulunut.
  • Rajalliset testausresurssit saatetaan kohdistaa väärin. Toteuttajien ja testaajien välillä ei kulje riittävästi informaatiota, vaan toteutus ja testaus mielletään erillisiksi kokonaisuuksiksi jo projektinhallintatasolla.
  • Testauksen dokumentointi on heikkoa. Usein saatetaan vasta jälkikäteen listata, mitä on testattu, vailla mitään yhteyttä koko järjestelmän ominaisuuslistaan.

Huonosti hoidetun testauksen seurauksena järjestelmään jää bugeja ja ristiriitaisista ja väärinymmärretyistä määrittelyistä mitenkuten kasattuja häkkyröitä, joiden korjaaminen jälkikäteen on paitsi kallista, myös erittäin vaikeaa kasaantuneen teknisen velan vuoksi.

Testaus pitää siis hoitaa paremmin! Ratkaisuna on ketterä testaus.

Ketterä kehitys (tuttavien kesken agile) on kokoelma ohjelmistokehityksen periaatteita, joista on kirjoitettu valtavan paljon äärimmäisen hyödyllistä asiaa sekä valitettavan paljon höttöä. Tässä yhteydessä näiden periaatteiden selvittämiseksi riittänee yleisen tason viittaus Agile Manifestoon. Ketterät periaatteet tarkoittavat myös testauksen osalta suurta muutosta perinteiseen ajattelu- ja projektimalliin.

Ketterässä testauksessa olennaisinta on, että testaus on osa jokaisen yksittäisen toiminnon toteutusta. Riippumatta nyt siitä onko projekti scrum-muotoinen, käytetäänkö siinä kanban-periaatteita tai onko käytössä kenties jokin koko organisaation laajuinen agile-metodologia, testausta tapahtuu koko projektin ajan sitä mukaa kun koodia valmistuu.

Tämä edellyttää selkeää kehittämisen prosessia, johon on kiinteästi upotettu erityyppiset testauksen vaiheet. Testauksen huomioiminen alkaa jo määrittelyitä tehtäessä, jolloin yhdessä toteuttajan ja tilaajan kesken sovitaan jo, kuinka määriteltävä toiminto tullaan hyväksymään eli mitkä ovat hyväksymistestit. Koodausvaiheessa koodari huolehtii yksikkötestien kirjaamisesta ja mahdollisimman pitkälle viedystä automatisoinnista. Hyvin tehdyt yksikkötestit pysäyttävät valtaosan bugeista jo ennen kuin mitään pääsee koodarin työpöydältä eteenpäin, vähentäen näin korjaamatta jääneistä bugeista johtuvan teknisen velan minimiinsä. Yksikkötesteistä läpi päässeitä toimintoja integraatiotestataan yhdessä, niille tehdään aina muutosten jälkeen regressiotestejä joilla todetaan että aiemmin toteutetut osiot eivät menneet rikki, koko järjestelmää pyöritetään uusien toimintojen kanssa systeemitesteissä, ja kaikki bugit korjataan saman tien (jonka jälkeen toiminnot testataan uudestaan). Kaikki tämä tapahtuu jo ennen kuin jokin toiminto tai osakokonaisuus edes toimitetaan varsinaiseen hyväksymistestaukseen. Kun kaikki toteutettavat toiminnot käyvät aina saman prosessin läpi, minkään asian testaus ei voi unohtua.

Ketterä testaus säästää aikaa

Vaikka edellä kuvattu prosessi tarkoittaakin, että yksittäisen toiminnon läpimenoaika määrittelystä hyväksymistestaukseen hieman kasvaakin, pystytään koko projektin tasolla säästämään merkittävästi aikaa ja vaivaa samalla kun tuotettavan järjestelmän laatu paranee. Hyväksymistestaukseen asti päätyy vähemmän bugeja, ja bugikorjaukset eivät enää tule yhtenä könttänä kiireisessä projektin loppuvaiheessa vaan ne hajaantuvat ajallisesti kaikkialle projektiin jolloin pitävämpien estimaattien tekeminen hankkeen valmistumisesta on helpompaa.

Ketterän testauksen onnistumisen yksi edellytys on siis selkeä työprosessi, mutta vielä olennaisempaa on että kaikki prosessin osalliset tietävät omat vastuunsa ja pystyvät työskentelemään tiiviisti yhdessä koko hankkeen ajan. Koodarin tehtävänä ei ole vain määrittelyjen lukeminen ja niiden toteuttaminen; liiketoiminnan edustaja ei voi vain jättää dokumentaationippua tiskille hankkeen alussa ja tulla kokeilemaan valmista järjestelmää hankkeen lopussa. Testaushavaintoja satelee pitkin projektia, ja näillä voi olla nopeita vaikutuksia toteutuksessa tai vielä määrittelyssä oleviin asioihin. Koko projektitiimin täytyy olla hereillä ja sitoutuneena jatkuvasti.

Ketterä testaus, kuten ketterä kehitys yleensäkin, tekeekin työstä intensiivisempää. Se mitä tällä voitetaan, on merkittävä parannus lopputuotteen laadussa, aikatauluarvioiden pysyvyydessä, ja parhaimmillaan koko tiimiä yhteen sitovassa innostuksessa.

Periaatteen tasolla tässä ei ole mitään kummallista magiaa. Kun sovitaan että ”valmis” tarkoittaa tiettyjen testausvaiheiden läpäisemistä, ja kun asioita tehdään valmiiksi asti pitkin projektia tärkeysjärjestyksessä, päädytään väkisinkin enempi vähempi ketterään toimintaan. Laatu paranee ja kaikilla on kivempaa. Verrattain yksinkertaista, eikö totta!

Jaa tämä artikkeli