Blogisarja Kehitysprojektin testauksesta, Osa 6/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.

Onko varaa olla kouluttamatta?

Useammankin kerran olen kuullut heittoja koulutuksen hinnasta: Onko meillä varaa kouluttaa <–> Onko meillä varaa olla kouluttamatta. Tässä konkreettinen esimerkki kouluttamattomuuden hinnasta.

Uuden ohjelmiston käyttöönottoprojektin määrittelyssä on usein seuraavanlainen tilanne:

• Toimittajan konsultit eivät ymmärrä asiakkaan liiketoiminnan prosesseja.
• Asiakkaan määrittelijät eivät tunne uutta ohjelmistoa riittävän hyvin.

Syy tähän on se, että ei ole tehty riittävää perehdytystä ennen määrittelyvaiheen aloittamista. Ehkä jotain esittelyjä on pidetty, mutta ei riittävän konkreettisella tasolla.

Kouluttamattomuuden hinta:

• Toimittajan konsultit valittavat, että asiakas ei ymmärrä. He haluavat määritellä nykyisen järjestelmän uuteen ohjelmistoon.
• Asiakkaan henkilöt valittavat, että toimittajan konsultit eivät ymmärrä heidän liiketoimintaansa. Eikä se ohjelmistokaan toimi kuin pitäisi.
• Tehdään turhia muutospyyntöjä, koska uuden ohjelmiston erilainen logiikka hämää asiakasta.
• Tehdään vääriä päätöksiä, koska ei ymmärretä päätöksien vaikutuksia ->Kun päästään testausvaiheeseen, niin joudutaan tekemään isoja korjauksia.

Jos haastatellaan isojen ohjelmistouudistuksien jälkeen henkilöitä, niin aika usein kuullaan lause: ”Jos olisin silloin alussa ymmärtänyt, niin…”
Kaikki haluavat tehdä työnsä hyvin. Kouluttamalla annat heille siihen mahdollisuuden.

Ketä pitäisi kouluttaa ja koska?

Mielestäni testauspäällikön pitää kehitysprojektissa määritellä koulutuksen tarve!

Perustelut: Jos projektiryhmä ei saa koulutusta, niin testaus on suurin kärsijä.

• Turhia muutospyyntöjä
• Testaus ei etene
• Testaus ei ole laadukasta
• Perustietojen laatu ei ole riittävää
• Henkilöiden motivaatio kärsii.

Toinen syy, miksi koulutuksesta vastaavan ja testauspäällikön pitää tehdä yhteistyötä, on yhteiset resurssit. Usein liiketoiminnan henkilöistä parhaiten osaisivat kouluttaa ihmiset, jotka osaavat myös testata parhaiten. Jotta ei tule päällekkäisiä resurssivarauksia, niin suunnitelma pitäisi tehdä yhdessä. Tavoitteet ovat kuitenkin yhteiset.

Jokaisen uuden henkilön tulisi saada aina ensin perehdytys ennen testauksen aloitusta.

Mitä kouluttaa hyväksymistestaajalle, kun aikaa on vähän?

Tämän blogisarjan yksi näkökulmista on: Asiakkaan henkilöstö liiketoiminnasta testaamassa. Ovat liiketoiminnan ammattilaisia, eivät ohjelmistotestauksen.

Kun aloitetaan hyväksymistestaus, niin testaukseen perehdytys pitää usein toteuttaa kevyesti. Henkilöt osaavat nykyisen liiketoiminnan hyvin, mutta testaamisen osaamistaso vaihtelee. Jotkut ovat tehneet sitä aikaisemmin, jotkut eivät koskaan. Muutamia lausahduksia matkan varrelta

• ”Sehän on valmisohjelmisto, miks pitää testata?”
• ”Käskettiin tulla etsimään kaikki bugit siitä järjestelmästä!”
• ”Ai arvioit että 157 havaintoa pitäis löytää? Miksi ette korjaa niitä eka? Testataan sitten kun on valmista. ”
• ”Mulla on ainakin niin kiire töissä, että en kerkee täällä paljon istuskelee”

Kun aikaa on vähän ja asiaa on paljon, tulevien testaajien koulutukseen tulisi vähintäänkin sisällyttää seuraavat asiat:

• Motivoida testaamaan – Kertoa miksi testataan.
• Miten testataan ja millä tekniikoilla.
• Testauksen tekninen suoritus + testauksen työkalut.
• Virheiden kirjaaminen.
• Virheiden priorisointi ja käsittely.
• Kehitysehdotusten, muutospyyntöjen prosessi.

Blogisarjan osassa 1/11 käsiteltiin aihetta: Kuinka arvioida virheiden määrä?

Käytän usein tätä arviota työkaluna motivoinnissa testaukseen: Ongelmamme ei ole havaintojen määrä eikä koodauksen laatu, vaan se, jos olemme itse määritelleet väärin tai jättäneet asioita huomioimatta.