Vesiputouksen ja V-mallin aikakaudella testaus oli viimeisenä vaiheena. Joskus ihmeteltiin ja mietittiin joukolla, missä kunnossa järjestelmän uskaltaa päästää tuotantoon. Kehitykseen kuluvana aikana oli hyvin todennäköistä, että ainakin osa vaatimuksista oli jo muuttunut, joten tuotantoon mennyt järjestelmä ei edes sillä hetkellä vastannut kaikkia loppukäyttäjien tarpeita. Joskus tuntui siltä, että pääasia projektissa oli tuottaa mahdollisimman paljon dokumentaatiota, joka vaati oman aikansa järjestelmän kehityksestä.
Sitten tulivat ketterät menetelmät ja dokumentointi muuttui erilaiseksi tai katosi vallan kokonaan. Testipäälliköt alkoivat kadota projekteista. Testaajista tuli kehitystiimin jäseniä tai sitten tiimi hoiti testauksen omalla tavallaan. Menetelmien ongelmaksi muodostuivat isommat projektit, joissa oli useampi kehitystiimi, koska jonkun tahon piti kuitenkin integroida tiimien tuotokset kokonaisuudeksi ja huolehtia sen toimivuudesta.
Tämän jälkeen on tullut muotiin DevOps, jossa siis tiimi huolehtii järjestelmän ominaisuuksien kehittämisestä ja tuotantoon viemisestä. Kaikki mahdollinen pitäisi automatisoida, mukaan lukien testaus, koska muuten ei pystytä tekemään muutoksia tuotantoon todella nopeasti tilanteen niin vaatiessa. Eli testiautomaation taitajat ovat tässä kuin kotonaan, mutta miten sitten muu testaus ja laadunvarmistus?
Kaikessa tekemisessä on tärkeää, että varsinkin työn tilaajalla on selkeä kokonaisnäkemys siitä, mitä pitää tehdä ja mitä tiimien pitää huomioida omassa tekemisessään. Eli tarvitaan se MM lätkästä tuttu Jalosen pelikirja ja oikein roolitetut tiimit. Monessa hankkeessa olen huomannut, että jos tähän kokonaisuuden hallintaan ei satsata, niin lopputulos riippuu eri tiimien omista kyvykkyyksistä. Ja niissähän tunnetusti riittää eroja, kuten viineissäkin.
