Hajota ja hallitse – laadun varmistuksen ohjaaminen ja johtaminen it-projektissa

Laadunvarmistuksella on aina merkittävä rooli it-projektin tavoitteiden saavuttamisessa. Ei vain järjestelmien toiminallisuuksien osalta mitattuna, vaan myös taloudellisesti sekä aikataulullisesti mitattuna. Silti liian usein sopimusneuvottelut toimitusprojekteissa viedään läpi ilman laadunvarmistuksen ammattilaisen valvovaa silmää ja tämän seurauksena laadunvarmistuksen sekä testauksen osalta sopimuksiin kirjataan usein ympäripyöreästi lupauksia “laadukkaasta testaamisesta”. Kun sanaa ´laadukas´ ei olla määritelty millään muotoa, usein osapuolten mielikuvat eivät kohtaa sopimukseen kirjattua mainintaa laadusta. Tästä johtuen toimittaja ja asiakas ovat vaarassa ajautua konflikteihin toimitusprojektin edetessä.

Ideaalitilanteessa testauspäällikkö tulisi ottaa mukaan mahdollisimman aikaisessa vaiheessa toimitusprojektia, jotta hänelle syntyy riittävä kuva asiakkaan liiketoiminnasta, sekä liiketoiminnan kriittisistä tarpeista. Projektissa käytettävän toimintamallin valinta ei tulisi olla vain projektijohdon päätös. Projektijohdon tulisi valita toimintamalli projektille demokraattisesti laadunvarmistuksen ammattilaisen kanssa, ja näin rakentaa eheä kokonaisuus jolla voidaan luoda edellytykset minimoida riskit turvaten projektin kokonaiskustannukset sekä aikataulu. Testaus ja laadunvarmistus vievät usein ajallisesti toimitusprojektissa noin 2/3, joten valitun projekti-, toimintamallin peilaukset ovat mittavia juuri laadunvarmistukseen liittyen.

Toimitusprojektin laadunvarmistuksen strategian luominen oikea-aikaisesti on asiakkaan sekä toimittajan yhteinen intressi

Toimitusprojektissa päämäärän tulisi olla aina yhteinen, tehokas ja laadukas toimitus, joka palvelee ja tukee asiakkaan liiketoiminnan tarpeita parhaalla mahdollisella tavalla.

Valitettavan usein toimitusprojekteissa törmää tilanteisiin, joissa toimittajan myyntistrategiassa laadunvarmistuksen osuus on huomioitu toimittajalle positiivisilla peilauksilla, mutta vastaavasti asiakkaat unohtavat reagoida strategisesti asiaankuuluvalla tavalla sopimusneuvotteluissa.

On hyvä muistaa, että ohjelmistojen toiminnallinen testaus on vain yksi osa onnistunutta laadunvarmistusta projektissa!

Vesiputousmallia ei tulisi väheksyä

Laadunvarmistuksen etenemisen seuraavat askeleet riippuvat siitä, päädytäänkö projektin toteuttamisessa vesiputousmalliin vai nykyään paljon käytettyyn ketterän kehityksen malliin. Malleista ketterä on tällä hetkellä hallitseva trendi, mutta itse uskon vesiputousmallin sopivan edelleen paremmin suurten, stabiilien liiketoiminnan organisaatioiden projekteihin.

Ketterä malli sopii mielestäni liiketoimintoihin, joissa myös liiketoimintaan liittyy nopeaa reagointia sekä uusia toimintamalleja, palveluita jne. Pankki- ja vakuutusalan core-järjestelmät, terveydenhoitoon liittyvät järjestelmät ja laitteet, lainaamisen palveluihin liittyvät järjestelmät ovat hyviä esimerkkeinä projekteista, joissa vesiputousmalli on todettu erittäin toimivaksi. Lisäksi mallin valinnassa tulisi huomioida se, tehdäänkö kehitystyö sisäisesti vai onko kyseessä toimitusprojekti, vai kenties sekoitus molempia.

Vesiputousmalliin toimitusprojektissa on helppoa rakentaa laatuportit ja kirjata niitä myös sopimukseen. Esimerkiksi toimitusprojektissa toimittajan maksuposteja voidaan liittää tiettyihin laatuportteihin. Näin molemmilla osapuolilla on alusta asti selkeä kuva projektin vaiheista ja etenemisestä. Vesiputousmallissa testauspaineen on perinteisesti nähty kohdistuvan projektin loppupäähän, mutta oikein suunniteltuna ja oikeat laatuportit tunnistettuina painetta voidaan ohjata oikein ja tasaisesti koko projektin läpi. Harvinaisia eivät ole nekään it-projektit, joita on lähdetty viemään läpi ketterän kehityksen mallilla, mutta suurten ongelmien ilmaantuessa turvaudutaan vesiputousmallin työkaluihin korjausliikkeessä, jotta projekti saadaan takaisin ”oikealle raiteelle”.

Meillä ihmisillä on tarve hallita sekä halu lokeroida asioita, mikä on projektityössä positiivinen asioiden jäsentelyn ja ennakoinnin kannalta. Mutta testauksen metodeissa on joskus myös järkevää hyödyntää hybridimallia, jossa vesiputousmallista ja ketterästä toiminnasta poimitaan juuri kyseiseen projektiin parhaiten soveltuvat toimintamallit. Hyvä testauspäällikkö omaa pelisilmän, ja on projektin aikana kykenevä reagoimaan muutoksiin ketterästi vesiputousmallissa, ja taas vastaavasti ketterässä mallissa osaa hyödyntää vesiputousmallista poimittuja työkaluja tarpeen mukaan.

Positiivinen testi voi tuoda negatiivisia lopputuloksia

Valitettavan usein it-projektissa toiminnalliseen testaukseen päätyvät vain ns. happy-skenaariot. Itse pidän nyrkkisääntönä, että jokaista 10 positiivista testitapausta kohden tulisi löytyä vähintään 3 negatiivista testitapausta. Niin kauan, kun järjestelmiä käyttävät ihmiset, niiden käytössä tapahtuu myös virheitä. Virheisiin voidaan varautua testaamalla asioita kulmalla, jossa käyttäjä tekee tietoisia virheitä. Jos järjestelmä ei anna tehdä virheitä, silloin virheitä ei myöskään voida generoida. Täten myös liiketoiminnan prosesseihin ja järjestelmiin ei ajaudu käyttäjästä johtuvia ongelmia.

Hyvä Testauspäällikkö kannustaa tiimiään tietynlaiseen tottelemattomuuteen – hajota ja hallitse. Liiketoiminnan elinkaaret eivät koskaan jää huomiotta, mutta harha-askeleet elinkaaressa usein jäävät. Testauspäällikön tulee saada tiimi ymmärtämään, että jokainen löydetty virhe on voitto, ei tappio. Virheet voivat generoitua dokumentteihin, prosesseihin, sovelluksiin ja järjestelmiin sekä käyttäjiin. Tehokas testaustiimi voi luoda itsestään negatiivisen kuvan muiden projektissa toimivien silmissä, mutta silloin tulisi muistuttaa muita siitä, että testauksessa mikään ei ole kunnossa ja toimivaa ennen kuin se ollaan todennettu. Skeptisyys, tuo testaajien ammattitauti, johon ainoa lääke on hallittu ja hyvin ohjattu testaaminen!