Yritykset haluavat saada käyttöönsä mahdollisimman hyvin toimivia ja käyttötarkoitukseen soveltuvia työkaluja – olivat ne sitten järjestelmiä tai ohjelmistoja. Toisinaan yritykset kuitenkin jättävät palveluiden testaamisen vähäiseksi – tai jopa kokonaan tekemättä. Silloin lopputulos saattaa kärsiä pahemman kerran.
Haastattelu: Vilma Mikkonen
Haastattelimme aiheesta Visma Consultingilla työskentelevää Minna Aaltosta. Hän kertoo, miksi asiakkaan tekemä ohjelmistotestaus on tärkeää ja listaa hyödyllisiä keinoja testauksen toteuttamiseen tilanteessa, jossa testaajalla ei ole aikaisempaa kokemusta testauksesta.
Aaltonen on tehnyt urallaan IT-alan työtehtäviä laidasta laitaan: hän on auttanut asiakkaita suunnittelemaan hyväksymistestausta, tehnyt testauksen suunnittelua ja suoritusta, suunnitellut ja toteuttanut testiautomaatiota, toiminut scrum masterina ja tehnyt järjestelmäsuunnittelua. Viimeiset 10 vuotta Aaltonen on työskennellyt asiakkaille räätälöitävien web-sovellusten parissa.
Tilaajan tekemä testaus on ensiarvoisen tärkeää
Aaltosen mukaan tilaajan tekemä ohjelmistotestaus on hyvin tärkeää, sillä tilaaja on ainoa taho, jolla on täysi ymmärrys siitä toimintaympäristöstä, johon ohjelmistoa tai järjestelmää ollaan ottamassa käyttöön. Ohjelmiston tilaaja tuntee organisaationsa toimialan ja tietää, mihin tarpeeseen ja minkälaisia ongelmia ratkaisemaan ohjelmisto on kehitetty.
“Koska kukaan ei ymmärrä tilaajan tarpeita niin hyvin kuin tilaaja itse”
“Koska kukaan ei ymmärrä tilaajan tarpeita niin hyvin kuin tilaaja itse, heidän näkökulmaansa testaamiseen tarvitaan aivan erityisesti”, Aaltonen toteaa.
Testauksen esteenä voi toisinaan olla tilaajan pelko siitä, että hän sotkee tai rikkoo työkalun omalla testaamisellaan. Aaltosen mukaan ohjelmistokehittäjien tarjoamat testiympäristöt ovat kuitenkin sellaisia, että niitä ei saa helposti sotkettua.
“Ei ne testiympäristöt mene helposti rikki”, Aaltonen toteaa, ja jatkaa: “Voi ihan rohkeasti tehdä mitä vaan keksiikään ja uskaltaa kokeilla ilman pelkoa epäonnistumisesta.”
Aaltosen mukaan pelko onkin suuri este asiakkaiden oman testauksen tiellä.
Toinen asia, joka voi olla testaamisen esteenä on ajan puute. Aaltosen mukaan testaukselle täytyy varata kunnolla aikaa. Kun testaukseen lähtee, siihen syventyminen vie aikaa. Parhaan lopputuloksen saavuttamiseksi Aaltonen suosittelee testaajia varaamaan kalenteristaan kerralla pidemmät ajanjaksot työlle. Tämä auttaa testaajia pääsemään testauksen ytimeen.
“Toisaalta järjestelmän oikeat käyttäjät huomaavat ohjelmiston käyttöliittymässä vikoja joskus jo yhdellä vilkaisulla, minkä vuoksi tilaajan käyttämä pienikin testausaika on aina parempi kuin ei mitään”, Aaltonen toteaa.
Kolme lähestymistapaa testaamiseen
Ihmiset kokevat ja hahmottavat asiat eri tavalla, minkä vuoksi täytyy löytää erilaisia tapoja lähestyä ohjelmistotestausta. Aaltonen listaa kolme näkökulmaa, jotka voivat auttaa testauksessa kokemattomia asiakkaita pääsemään alkuun testaamisen kanssa.
Määrittelyjen kautta testaaminen
Ensimmäinen tapa on testata työkalua sen määrittelyjä vasten. Määrittely on mikä tahansa kirjallinen dokumentti, joka kuvaa sitä, miten työkalun on tarkoitus toimia. Tämä voi olla esimerkiksi vaatimusmäärittely tai tarjouspyyntöön kirjoitettu toiminnallinen kuvaus.
Kun testaamiseen lähdetään määrittelyn kautta, dokumentti käydään läpi lause lauseelta. Tämän jälkeen pohditaan, mitä järjestelmän pitäisi tehdä, jotta lause toteutuisi, minkä jälkeen kokeillaan, toteutuuko määrittelyn kuvaama asia järjestelmässä.
“Jos määrittelyssä sanotaan esimerkiksi: Kun käsittelijä ottaa asian työn alle, asia siirtyy tilaan “Käsittelyssä”, haluaisin testaajana kirjautua järjestelmään käsittelijän roolissa, käydä ottamassa asian työn alle ja katsoa, että suunniteltu tilasiirtymä tapahtuu”, Aaltonen kuvailee määrittelyn prosessia.
Tämän jälkeen määrittelyssä voi myös miettiä vaihtoehtoisia lopputulemia, joista Aaltonen antaa esimerkin: “Voiko työn alle ottamisen peruuttaa, ja miten tämä näkyy tilassa? Entä miltä asia näyttää minulle silloin, kun joku toinen käsittelijä on ottanut sen työn alle?”
Jos järjestelmään liittyy erilaisia käyttäjärooleja, on tärkeää testatessa käyttää järjestelmää kaikissa näissä rooleissa. Ellei määrittelyyn sisälly listaa käyttäjäroolien sallituista toiminnoista, sen voi pyytää toimittajalta. Tämä lista on hyvä käydä läpi kirjautuen järjestelmään kunkin käyttäjäroolin käyttäjänä. Samalla on hyvä miettiä, näkevätkö kaikille käyttäjäryhmille juuri ne asiat, jotka heidän kuuluu nähdä.
“Määrittelyjä vasten testaaminen on lopulta tilaajan ainoa keino varmistaa, että toimittaja on todella toimittanut sen, mitä tilaaja on tilannut”, Aaltonen kuvaa tämäntyyppisen testauksen tärkeyttä, ja jatkaa: “Mikäli määrittely on kovin laaja, ja aikaa on käytössä vain vähän, kaikkien lauseiden läpikäynti ei ole aina mahdollista. Tällöin määrittelystä voidaan valita testattavaksi vain tärkeimpiä osia.”
Toimintolistojen kautta testaaminen
Toinen tapa testata ohjelmistoa on käydä läpi kaikki ohjelmiston toiminnot tai käyttötapaukset. Testauksen lähtökohtana on kirjoitettu lista järjestelmän toiminnoista tai käyttötapauksista. Lista voidaan kirjoittaa esimerkiksi järjestelmän määrittelyn tai käyttöohjeen perusteella.
Useimmiten tietojärjestelmät voidaan kiteyttää ajatukseen siitä, että järjestelmässä käsitellään erilaisia asioita, joita voidaan luoda, etsiä ja listata, avata ja lukea, muokata sekä lopulta poistaa. Lisäksi asioilla voi olla muitakin toimintoja: ne voidaan esimerkiksi tulostaa tai niiden perusteella voidaan suorittaa laskentaa.
Toisinaan järjestelmässä käsiteltävä asia voi olla vuorovaikutuksessa johonkin toiseen asiaan, toimintoon tai tietojärjestelmään – tällöin olisi tärkeää varmistaa myös, että kaikkien toimintojen sivuvaikutukset ovat oikeat. Kun jokainen toiminto on käyty näin läpi, järjestelmässä on tehty jo hyvin kattava kierros.
Esimerkiksi:
- Asian toiminnot
- Luo uusi asia (luo)
- Etsi ja listaa asiat (etsi ja listaa)
- Avaa ja lue asian tiedot (avaa ja lue)
- Muokkaa asian tietoja (muokkaa)
- Poista asia (poista)
- Tulosta asia (muu toiminto)
- Kunkin asian toiminnon sivuvaikutus
- Henkilörekisterin tiedot päivittyvät sen mukaan, miten henkilön tietoja päivitetään asialla (liittyvä asia)
- Asialle tehdyt toiminnot näkyvä järjestelmän käyttö raportilla (liittyvä työkalu)
- Asian tiedot siirtyvät nähtäväksi toiseen tietojärjestelmään (liittyvä toinen tietojärjestelmä)
“Testaamista ei tarvitse nähdä suurena teknisenä haasteena, vaan sen voi tehdä myös leikin kautta”
Leikin tai draaman kautta testaaminen
Aaltonen muistuttaa myös, että testaukseen ei tarvitse suhtautua suurena, teknisenä haasteena, vaan siihen voi suhtautua myös hyvin rennolla otteella. Kolmatta testaustapaa Aaltonen kutsuu testaamiseksi “leikin tai draaman kautta”. Tällä tavoin tehtävä testaus toteutetaan niin, että asiakas miettii ensin järjestelmän tärkeimmät käyttötapaukset. Tämän jälkeen hän käy skenaariot läpi eläytyen siihen, mitä kukin järjestelmän käyttäjä tekee käyttötapauksen aikana ja katsoo, toimiiko järjestelmä käyttötarkoitukseen sopivalla tavalla.
Vielä hauskempaa ja tehokkaampaa tällainen testaus on, jos se tehdään paritestauksena. Tällöin toinen testaaja katsoo järjestelmää tilaajan asiakkaan roolista, ja toinen testaaja toimii tilaajan oman käyttäjän roolissa.
“Mitä tapahtuu, jos teen näin, miten tämä näkyy asiakkaan näkymässä, jos kokeilen toteuttaa tämän taas näin”, Aaltonen kuvailee testausta leikin kautta. Tällaisella leikillisellä testaustavalla asiakas pääsee helpoiten irti testaamisen pelosta.
“Leikkimielinen suhtautuminen auttaa käyttäjää tarttumaan rohkeasti järjestelmään ja kokeilemaan uusia asioita”, Aaltonen päättää.
