Hyväksymistestauksen epäonnistuminen johtuu 90 % todennäköisyydellä tekemisistä ennen hyväksymistestauksen aloittamista. Jos huomioit alla olevat kohdat jo kehitysprojektin käynnistyksessä, todennäköisyys onnistua moninkertaistuu.

30 % Toteutus + Systeemitestaus ei ole valmis kaikilta osin.

Olen kirjoittanut useampia postauksia tästä aiheesta. Esim. “Kaikki on valmista, paitsi pari pikku juttua.” Aika usein hyväksymistestaus aloitetaan ennen kuin kriteerit sen aloittamiseen ovat täyttyneet. Juurisyy: Projekti on asetettu siten, että hyväksymistestauksen aloituspäätöstä tehdessä ei ole näkyvyyttä oikeaan valmiusasteeseen. Siis kokonaisuutena: Tehtävät, valmistelut, perustiedot, toteutus, muutospyynnöt, avoimet asiat.

20 % Projektin ratkaisukyky on huono

Ennen testauksen aloitusta, pitää muutoksenhallinnan ja virheiden käsittelyn prosessi olla kunnossa. Virheiden käsittelyn palaverit varattuna etukäteen, resurssivaraukset toimittajalle tehtynä yms. Ongelma: Jos “korjaustehdas” ei toimi, avointen havaintojen määrä kasvaa nopeasti. Tästä seuraa testauksen hidastuminen, laadun huonontuminen ja aikataulupaineita.

10 % Testaajat eivät osaa käyttää uutta sovellusta

Hyväksymistestaus ei ole koulutustilaisuus, vaikka testatessa paljon oppiikin. Perehdyttämisestä tehdyt säästöt maksetaan takaisin testauksen myöhästymisenä, erikseen ostettuna tukena sekä turhina muutospyyntöinä.

10 % Testauksen resurssivaraukset alimitoitettu

Kun olen katselmoinut testaussuunnitelmia, niin usein testauksen resurssit ovat vain 30 % tarvittavasta määrästä. Tässä muutama yleisin syy:

• Lasketaan, että liiketoiminnasta tulevat testaajat testaavat 7,5 h/päivä, tehokkaasti. Oikeampi luku on 5,5 h/päivä, koska aikaa kuluu palavereihin ja omien töiden hoitamiseen.
• Unohdetaan laskelmasta havaintojen käsittelyyn ja uudelleentestaukseen kuluva aika. Jos prosessit ja työkalut ovat kunnossa, niin sadan havainnon käsittely ja uudelleentestaus vie 250 tuntia. Jos käytetään Exceleitä ja sähköpostia, niin työmäärä on yli 300 h.
• Suunnitelma on enemmänkin toive, kuin laskelma. “Ei meillä ole varaa enempää testata” tai “Eihän nyt yhden ohjelman testaus voi kauaa viedä”

Kun alimitoitukseen lisätään vielä tilanne, että kalenteriavarauksia ei ole tehty ajoissa, niin peli on menetetty.

5 % Testauksen valmistelut on tehty huonosti

Testausdokumentaation tekeminen ja testauksen valmistelu koetaan usein liian raskaaksi. Jos toteutusvaiheen kanssa on vaikeuksia, niin valmistelut jäävät puutteelliseksi. Ongelma: Testaajia on vaikea saada toimimaan tehokkaasti, jos et voi antaa heille yksiselitteisiä tehtäviä. Tällöin testauksen laadun sekä edistymisen valvominen on vaikeaa.

Testausdokumentaation voi valmistella ketterästikin. Kun valitsee oikean tarkkuustason, työmäärä pysyy kohtuullisena.

5 % Perustiedot eivät ole kunnossa

Testaus ei vaan onnistu, jos perustiedot eivät ole kunnossa. Aku Ankka -datalla testaaminen ei ole laadukasta. Onneksi nykyään perustietojen tärkeys on aika hyvin jo ymmärretty.

10 % Testauksen vetäjällä ei ole aikaa johtaa

Jos testauksen vetäjä ei ole varannut aikaa johtamiselle, niin testauksen tehokkuus kärsii. Hiljalleen alkaa kasaantua ongelmia, jotka hidastuttavat testausta. Hyväksymistestauksessa on kolme vaikeaa kohtaa:

• Aloittaminen: Miten saada testaajat heti ensimmäisestä hetkestä lähtien testaamaan tehokkaasti.
• Havaintojen käsittely: Kuinka saada korjaustehdas ja muutoksenhallinta toimimaan tehokkaasti.
• Testauksen saaminen valmiiksi (85% → 100%): Ratkaistaan ongelmia, jotka estävät testauksen saamisen valmiiksi.

Jos et ole varannut aikaa johtamiseen, niin teet projektista kalliin. Joukot toimivat tehottomasti, koska olet priorisoinut muut hommat tärkeämmiksi.

Usein projekteissa yritetään säästää karsimalla testauksesta. Mutta säästöjä ei synny sillä, että testaus asetetaan huonosti. Jos haluaa testata ketterästi, pitää osaaminen ja valmistelut olla jämptisti hoidettuna. Asioiden tekeminen oikeaan aikaan on aina halvempaa, kuin jälkeenpäin virheiden korjaaminen.