Blogisarja Kehitysprojektin testauksesta, Osa 1/11

Kirjoituksia ohjelmistotestauksen suunnittelusta ja johtamisesta.

Näkökulmana:

• Liiketoiminnalle kriittiset kehitysprojektit, joissa IT vahvasti mukana.
• Yksi tai useampia ulkoisia toimittajia.
• Asiakkaan henkilöstö liiketoiminnasta testaamassa. Ovat liiketoiminnan ammattilaisia, eivät ohjelmistotestauksen.
• Testauksen tavoitteet: 1. Varmistaa, että käyttöönotettava ratkaisu tukee liiketoiminnan tarpeita 2. Varmistaa, että käyttöönotto ei vaaranna liiketoimintaa.

Havainnot, joita luodaan testauksessa

Testauksen aikana kirjataan erilaisia havaintoja. Esimerkiksi:

• Virheitä ohjelmistossa
• Virheitä perustiedoissa
• Määrittelyvirheitä
• Testaaja ei osaa testata -> käyttäjävirhe
• Kehitysehdotuksia
• Muutospyyntöjä
• Avoimia asioita

Jokaisen havainnon kirjaaminen, käsittelyt, päätöksenteko ja uudelleentestaus kuluttaa aikaa noin 2 – 3,5 h, riippuen menettelytavoista. Jos prosessit ja työkalut ovat kehittyneet, on käsittelyaika lähempänä kahta tuntia. Jos käytät Exceleitä ja sähköpostia, aikaa kuluu n. 3,5 h.
Nyt puhutaan siis vain asiakkaan päässä tehtävistä toimista. Itse koodaus ja korjaavat toimenpiteethän vievät aina oman aikansa.

Paljonko budjetoida havaintojen käsittelyyn?

Testauksen suunnitteluun havainnointi aiheuttaa ongelman: Paljonko budjetoida aikaa ja resursseja havaintojen käsittelyyn?

Havaintojen määrän arviointi on melko vaikeaa. Jos käytössä on historiatietoa, niin sen avulla voi tehdä ennusteita. Jos käytettävissä ei ole historiaa, niin määrää voi arvioida yhdessä toimittajan kanssa.

Kun menen toimeksiantoon uudelle asiakkaalle, käytän arvion pohjana seuraavia kaavoja:

• 1,3 havaintoa / koodauspäivä
• 2,2 havaintoa / Käyttötapaus, räätälöinti
• 15 hengen, neljän viikon testauksessa löytyy keskimäärin 157 havaintoa.

Projektin monimutkaisuuden, luonteen ja johtamisen laadun arvioinnin perusteella annan kertoimia arvioinnille. Esimerkiksi jos projektissa on useampi toimittaja ja paljon integraatioita, niin silloin havaintojenkin määrä on isompi.

Esimerkki:

ERP-projekti, jossa laajennettiin uuden toiminnanohjausjärjestelmän käyttöä uudelle liiketoiminta-alueelle. Arvioin ennen testauksen alkua, että tulemme luomaan n. 157 havaintoa testauksen aikana.

-> Asiakkaan ja toimittajan projektipäällikön kommentti: ”Tämä on valmis ohjelmisto, ei millään voi löytyä noin paljon havaintoja”.

Lopputulos: Loimme testauksien aikana 204 havaintoa:

• 5 muutospyyntöä
• 185 virhettä
• 14 Avointa asiaa, muutoksia liiketoimintaan.

Olin budjetoinut havaintojen käsittelyaikaa 390 tuntia. Laskennallinen toteutuma oli 500 tuntia. Syy ylitykseen: Yhden alueen toteutus ei oikeasti ollut valmis, kun toimittaja luovutti sen testaukseen.

Havaintojen määrän kerroin

Isoimman havaintojen määrän kertoimen annan projekteille, joiden projektipäällikkö hehkuttaa, että ”hyvin menee”, ilman että statuksesta on esittää mitään statistiikkaa. “Kaikki on valmista, paitsi pari pikku juttua” Jos määrittelyjä ja toteutuksen seurantaa ei ole tehty määrämuotoisena, niin silloin ei tarkasti tiedetä mikä on valmista ja mikä ei -> Osa testauksen havainnoista on löydöksiä keskeneräisestä toteutuksesta.

Toisena kertoimen kohottajana on säästöt koulutuksissa, kun projektissa otetaan käyttöön uusi ohjelmisto. Jos asiakkaan projektiryhmä ei tunne testattavaa järjestelmää, niin testauksen laatukaan ei voi olla hyvä.

Aina havaintojen määrä ei ole huono asia. Kun tehdään ketterää kehittämistä, jossa asiakas on lähellä tekijää, niin ratkaisua ”pallotellaan” tekijän ja asiakkaan välillä. Mutta luetaanko tämä vaihe osaksi testausta vai toteutusta, on sitten projektin sisäinen asia.