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

Käyttöönoton viivästyminen

Jos projektin käyttöönottoa joudutaan siirtämään testauksen takia, on usein syynä kaksi asiaa

1. Testaus ei valmistunut aikataulussa
2. Kriittisiä tai vakavia havaintoja on jäänyt ratkaisematta (Virheitä, muutospyyntöjä, avoimia asioita)

Usein testaus ei valmistunut aikataulussa, koska on löydetty virheitä, jotka estävät testauksen finalisoinnin.

Eli tästä voidaan vetää seuraava johtopäätös: On tärkeää löytää käyttöönottoa estävät virheet mahdollisimman ajoissa, jotta niiden korjaamiseen jää riittävästi aikaa. Tässä 3 vinkkiä virheiden metsästykseen.

1) Riskianalyysi

Ennen testauksen aloittamista on hyvä tehdä riskianalyysi

• Selvitä, mitkä ovat toiminnot ovat liiketoiminnalle kriittisiä. Näiden pitää toimia moitteettomasti.
• Selvitä, mitkä avoimet virheet estävät myönteisen käyttöönottopäätöksen tekemisen. Tarkoituksena on löytää ihan konkreettisia asioita. Esimerkiksi Virheet hinnoittelussa, jotka näkyvät asiakkaille.
• Tee suunnitelma, kuinka löydätte nämä käyttöönottoa estävät virheet mahdollisimman aikaisessa vaiheessa.

Riskianalyysin tulokset on hyvä kommunikoida testaajille. Testauksen aloituksen kick off on siihen hyvä paikka. Tarkoitus on auttaa testaajia ymmärtämään, miksi heidän testauksensa on tärkeää, ja miksi osa heidän havainnoistaan saa alhaisen prioriteetin.

2) Tutkiva testausjärjestys

Kuvaan yksinkertaisella esimerkillä, miten testausjärjestys nopeuttaa läpimenoaikaa.

Pohjana edellisissä jaksoissa kuvattu hyväksymistestaus. Kuvitellaan, että projektiin on luotu 80 käyttötapausta. Näistä 40 koskettaa riskianalyysin perusteella liiketoiminnalle kriittisiä toimintoja. Yhteen käyttötapaukseen liittyy aina 5 testitapausta. Eli 200 testitapausta pitää saada testattua OK, jotta kriittiset toiminnot on varmistettu.

Eli kysymys kuuluu, kuinka testata 200 testitapausta siten, että löydät käyttöönoton estävät virheet ensimmäiseksi.

Ehdotukseni testausjärjestykseksi

1. Valitaan jokaisesta 40 käyttötapauksesta 1 testitapaus, joka kuvaa käyttötapauksen perustoiminnallisuutta.
   Testataan ensimmäisinä päivinä nämä 40 testitapausta. Tutkitaan, toimivatko kriittiset prosessit perustapauksilla.
   -> Eli tehdään kriittisiä, käyttöönottoa estäviä havaintoja.

2. Seuraavina päivinä laajennetaan testausta. Jatketaan niiden käyttötapausten testaamista, joissa ei ole avoimia havaintoja.

Osassa 3/11 oli testauskalenteriin ensimmäisten päivien kohdalle merkattuna ”Testataan yhdessä konsulttien tukemana”
Jos tehdään testaus yllä mainitulla tavalla, niin se vaatii toimittajalta vahvan tuen testauksen aloitukseen. Muuten suuri osa testeistä jää kesken.

Itse suunnittelen tarkalla tasolla vain tulevat 2-3 päivän testaukset. Näiden päivien havaintojen pohjalta suunnittelen lopputestaukset. Esimerkiksi jos ensimmäisten testauspäivien tuloksena 15 käyttötapausta sisältää avoimia, testausta haittaavia havaintoja, niin ei testata niitä. Keskitytään edistämään testausta osa-alueille, joissa voimme edetä normaalisti.

3) Tarkista -stepit

Liiketoiminnasta tulevat testaajat löytävät ihan kohtuullisen hyvin virheelliset asiat. Puuttuvat ja ”näkymättömät” asiat jäävät sen sijaan monesti huomioimatta. Tämän johdosta olen alkanut lisätä testitapauksiin Tarkista -steppejä. Vaikka testitapaus sisältää odotetun lopputuloksen, aina on hyvä tehdä lisäksi kattavat tarkastukset.

Riskianalyysissä olemme selvittäneet, mitkä asiat pitää toimia. Käyttöönottopäätöstä tehdessä testauspäällikön tulee pystyä todistamaan, että olemme testanneet luotettavasti. Lisään riskianalyysin perusteella Tarkista-stepit testitapauksiin. Saan kriittisistä kohdista omat, selkeät kuittaukset päätöksenteon tueksi, ja usein noista tarkistuksista löytyy myös virheitä.

Havainto vai virhe?

Käytän kirjoituksissani hieman sekalaisesti sanoja havainto ja virhe, koska kaikki havainnot, joita testaaja tekee, eivät ole virheitä. Ne voivat olla muutospyyntöjä, avoimia asioita, kehitysehdotuksia jne. Esimerkiksi määrittelystä unohtunut asia, joka on liiketoiminnalle kriittinen. Nämä muut havainnot ovat usein vaikeampia asioita kuin selkeät virheet.