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

Liiketoiminnan suorittama hyväksymistestaus

Liiketoiminnalle kriittisissä projekteissa hyväksymistestaajina ovat henkilöt, jotka tuntevat hyvin liiketoiminnan. Testauksen osaamisen taso taas voi vaihdella paljonkin. Joukkoon mahtuu henkilöitä, joilla on vahva kokemus mutta myös ensikertalaisia. Tämä aiheuttaa haasteita testauksen ohjeistukselle ja dokumentaatiolle. Varsinkin kun testataan kokonaisia prosesseja, eli End to End (E2E).

Kaksi huomioitavaa asiaa:

1. Testaaminen ei ole koulutusta, vaikka testatessa paljon oppiikin.
2. Testidokumentti ei ole käyttöohje, vaan testaajan tulee osata käyttää järjestelmä.

Optimaalinen testitapaus liiketoiminnan testaajalle?

Aikaisemmin tuli usein vastaan toimittajan ohjeen mukaan luotuja testitapauksia, jossa oli erittäin tarkat testausohjeet. Oli prosessi sitten minkälainen pujottelurata vain, niin testaaja sai testin läpi seuraamalla testitapauksen steppejä. Tällaisiin yksityiskohtaisiin testitapauksiin liittyy muutamia ongelmia

• Niiden kirjoittaminen on työlästä ja käytettävissä pitää olla lähes valmis järjestelmä.
• Testitapausten ylläpito on työlästä.
• Testitapaus ohjaa testaamaan teknistä toteutusta eikä ratkaisun soveltuvuutta liiketoimintaan.

Nykyisin raskaasta testausdokumentaatiosta ollaan siirtymässä kevyempään, esimerkiksi vain listaukseen testattavista asioista. Itsekin suosin omissa testauksissa kevyttä mallia, mutta kevyt testausdokumentaatio vaatii hyvää ammattitaitoa testaajalta. Testaajan tulee osata tutkia laadukkaasti ratkaisua eri näkökulmista. Eli ei amatööreille ;-)

E2E testitapaus, jolla varmistetaan ratkaisun soveltuvuus liiketoimintaan

Kokonaisia prosessiketjuja testatessa testiä suorittaa usein useampi henkilö.

Esimerkiksi: Myynti myy - Varasto toimittaa - Laskutus laskuttaa - Kirjanpito tarkistaa kirjanpidon tapahtumat.

E2E testitapauksessa testaajalle tulee kertoa selkeästi:

• Minkälainen toiminto tulee suorittaa ja mitä parametreja käytetään.
• Kuka jatkaa testiä seuraavaksi.
• Mitä toimintoja ja tapahtumia on tehty edellisessä vaiheissa.

Suosin seuraavanlaista rakennetta E2E testitapaukselle:

Testitapauksen otsikkotiedot

• Ne auttavat testauksen suunnittelussa valitsemaan oikeat testitapaukset.
• Aikataulutus ohjaa tekemään oikeat testit oikeaan aikaan.
• Ryhmittelyt ja statukset raportoinnin datana.
• Testauksen aloituksessa, testaaja saa kuvan testistä kokonaisuutena.
• Vastuuhenkilönä testaaja, joka testaa seuraavaksi.
• Testauksen validoinnissa saadaan kuva testauksen laajuudesta.

Esimerkki

Testitapauksen stepit

Alla esimerkkikuva kirjoittamastani E2E testitapauksesta.

Muutama huomio testitapauksesta:

• Väliotsikot ryhmittelevät testausta. Yksi kokonaisuus otsikon alle.
• Function -sarakkeessa kerrotaan millä ohjelmalla/transaktiolla testi suoritetaan. Tätä tietoa voidaan käyttää, kun validoidaan mitkä toiminnot on testattu.
• Description -sarakkeessa kerrotaan mikä toiminto pitää suorittaa.
• Tester/role -sarakkeessa kerrotaan testaajan rooli, kuka testaa.
• Expected Result -sarakkeessa kerrotaan parametrit toiminnolle tai odotettu lopputulos.
• Check -riveillä pyydän testaajaa tarkistamaan prosessin kannalta tärkeitä kohtia, jotka saattaisivat jäädä huomioimatta.

Testitapauksen Check-rivit

Edellä mainituilla testitapauksen Check -riveillä on kaksi funktiota

1. Liiketoiminnan henkilöiden on usein helppo löytää virheet, jotka ovat näkyvillä. Vaikeaa on löytää puutteita. Esimerkiksi, jos tulosteella on välisumma väärin, niin se yleensä huomataan. Vaikeampaa on huomata välisumman puuttuminen kokonaan. Samoin tapahtumat, jotka pitää tarkistaa toiselta näytöltä, saattavat jäädä tarkistamatta.

2. Riskianalyysin perusteella luodut tarkastettavat kohdat. Tästä kirjoitinkin postauksessa Osa 4/11: 3 vinkkiä, kuinka vältät käyttöönoton viivästymisen

Näiden esimerkkien taustalla oli tapaus, jossa oli Asiakkaan henkilöstö liiketoiminnasta testaamassa. Testaajat olivat liiketoiminnan ammattilaisia, eivät ohjelmistotestauksen. Esimerkin mukaiset testitapaukset ovat sellaisia, joita ko. henkilöt osasivat myös itse kirjoittaa. Ja samalla varmistivat, että ratkaisu tuki liiketoiminnan vaatimuksia.