Quality Gate, laatuportti

Liiketoiminnalle kriittisissä kehitysprojekteissa hyväksymistestauksella varmistetaan, että käyttöönotto voidaan tehdä laadukkaasti. Vaiheet ennen hyväksyntää voidaan hyvin tehdä ketterästi. Mutta jos hyväksymistestausvaiheeseen siirrytään ennen kuin kriteerit ovat täyttyneet, aiheutuu ongelmia.

Ongelmia hyväksymistestauksessa, olisiko tässä syy?

Vieläkin liian usein hyväksymistestauksen aikana ajaudutaan ongelmiin.

• Testaus ei edisty – liikaa virheitä
• Koulutuksia ei saada toteutettua
• Käyttöönoton valmistelut myöhästyvät
• Käyttöönotto siirtyy eteenpäin jne.

Aika usein ongelmien syynä on se, että laatuportti on ohitettu ennen kuin kriteerit hyväksymistestaukseen ovat täyttyneet.

• Toteutus on vielä kesken
• Toimintotestaus ei ole valmis
• Käyttöönottoa ei ole suunniteltu liiketoiminnan kannalta
• Avoimia virheitä vakavia ja kriittisiä virheitä
• Hyväksymistestauksen valmistelut puutteellisia.

Oikea avoimien virheiden määrä

Jos avoimia, korjattavia virheitä on 100, on väärin laskea, että ne korjaamalla järjestelmä on valmis. Normaalillakin laadulla 100 virheen uudelleentestaus paljastaa n. 40 uutta virhettä. Joiden testaus paljastaa n. 10 uutta virhettä…. –> Jos avoimia, korjattavia virheitä on nyt 100, niin niitä pitää korjata noin 155, jotta järjestelmä olisi valmis hyväksymistestaukseen. –> 155 virheen käsittely ja uudelleentestaus vie asiakkaan päässä tehokasta työaikaa noin 240 h. (Laskentakaavasta on tulossa pian ihan oma postauksensa!)

Miksi laatuportin pitää olla tiukka

Hyväksymistestauksen idea on varmistaa, että käyttöönotto voidaan tehdä turvallisesti, liiketoimintaa vaarantamatta. Karrikoiden voisi sanoa, että siinä ihastellaan, kuinka hienosti ratkaisu tukee liiketoiminnan tarpeita. Testaajina on usein liiketoiminnan henkilöitä, ei testauksen ammattilaisia.

Alla oleva kuva kuvaa tilannetta, jossa hyväksymistestaus on aloitettu liian aikaisin. Jos projektin prosessit ovat kunnossa, niin testaajalle on etukäteen kommunikoitu, mikä ei ole vielä valmista. Mutta aika usein testaajan pitää löytää ko. toimimattomuus ja saada palautteena kommentti tyyliin ”Toi ei vielä toimi, siitä on muutospyyntö auki”.

Huomioita

• Mitä järkeä on yrittää hyväksyä prosesseja, jotka eivät ole valmiita.
• Useat prosessit pitää testata uudelleen, kun toteutus on valmis.
• ”Pujotteluradan” testaus on selkeästi hitaampaa kuin valmiin prosessin.
• Testaajat vievät negatiivisen viestin työtovereilleen: ”Ei siellä oikein mikään toimi, mitenköhän me tehdään kauppaa käyttöönoton jälkeen”
• Jokainen virhe, joka kirjataan toiminnosta, joka ei ollutkaan valmis, syö noin 2,5 h projektin työaikaa, turhaan.
• Hyväksymistestaus ei anna oikeaa kuvaa käyttöönotettavan ratkaisun laadusta.

”Meidän on pakko aloittaa hyväksymistestaus, koska aikataulu on pakko pitää!”

Vai onkohan kuitenkaan pakko, tai edes järkevää?

Projekti on myöhässä, toteutus ei ole valmis, virheitä ei ole saatu korjattua. Mutta jos siirretään aikataulua, niin pelätään, että ”hanskat tippuu”. Resurssit alkavat tehdä jotain muuta, jolla on tiukempi deadline. Uskotaan ihmeeseen, että kun aloitetaan hyväksymistestaus aikataulussa, niin käyttöönottokin voidaan tehdä aikataulun mukaan.

Kuvaan esimerkillä ongelmaa:

Jos projektisi suunnitelmassa on hyväksymistestaus aikataulutettu vietäväksi läpi 3 viikossa, niin oletko varautunut siihen, että sinä aikana tehdään myös edellisten vaiheiden tekemättömät työt? Onko hyväksymistestaukseen suunniteltu alun perin niin paljon ylimääräisiä resursseja, että velka pystytään maksamaan? Huomioiden vielä, että tekemätön työ hidastaa kaikkea tekemistä.

Vai olisiko järkevämpää maksaa ensin velka pois ja siirtyä hyväksymistestaukseen sitten, kun siihen on valmius? Kumpi myöhästyttää käyttöönottoa vähemmän?

No mut ainahan on mahdollista, että kaikki menee hyvin ;-)