Välitätkö informaatiota vai ylläpidätkö illuusiota?

Ihmismieli on siitä mielenkiintoinen, että se haluaa miellyttää. Tähän sillä on kaksi mitä nerokkainta tapaa: petos ja itsepetos.

Petoksella viittaan tilanteeseen, jossa toiselle ei haluta aiheuttaa pahaa mieltä kertomalla epämiellyttäviä tosiasioita. Projektipäällikkö saa kamppailla tätä tarvetta vastaan esimerkiksi kertoessaan asiakkaalle, mitkä toivotut asiat sisältyvät projektin laajuuteen ja mitkä eivät.

Itsepetos taas on sitä, kun eletään kuvitelmassa, että jostain saapuu maaginen pelastus ja tilanne ratkeaa parhain päin, vähän niin kuin elokuvissa, vaikka kaikki tosiasiat viittaavat siihen, että näin ei tule tapahtumaan. Siis esimerkiksi ajatellaan, että raportoidut sata bugia ovat niin yksinkertaisia korjata, että homma hoituu päivässä muiden töiden ohessa, ja kun ne on korjattu niin uusia ei enää löydy.

Testauksen tärkeimpiä tehtäviä on horjuttaa projektiin liittyvien petoksen ja itsepetoksen perustuksia organisaation sisällä. Siis tehdä lähes mahdottomaksi kenenkään ylläpitää epärealistisen positiivisia kuvitelmia toteutettavan järjestelmän tilasta.

Siksi on tärkeää miettiä, mikä on mielekkäin tapa testausraportointiin. Raportin tulee olla tarpeeksi lyhyt, että se luetaan, tarpeeksi selkeä, että sen viesti hahmotetaan, ja tarpeeksi jäsennelty, että sitä voidaan käyttää apuna resursoinnin suunnitteluun sekä tehtävien priorisoinnin ohjaamiseen. Jos sitä voi vieläpä vähällä työllä (tai jopa sellaisenaan) hyödyntää raportoitaessa asiakkaalle projektin tilasta, testaajan panos projektille on entistä helpompi nähdä positiivisena.

Asiakasta ei oikeasti kiinnosta bugien määrä tai laatu, vaan se, onko järjestelmässä jotain, mikä toimii luotettavasti, ja miten pian voi odottaa että muutkin asiat toimivat. Näistä ensimmäiseen testausraportin pitäisi pystyä antamaan suhteellisen luotettava vastaus. Jälkimmäisen arvioinnissa testausraportti on yksi keskeinen väline, vaikkakin riittämätön yksinään.

Skarpin testausraportin tärkeimpiä piirteitä on sen kyky konkretisoida tilanne. Testaaja nähdään helposti pessimistisenä valittajana, jolle mikään ei kelpaa, ja tällöin hänen mielipiteensä on myös helppo sivuuttaa - onhan itsepetoksen jatkaminen mukavampaa kuin tunnustaa ikävät tosiasiat. Jos testaaja voi konkreettisesti listata, kuinka suurta osaa käyttötapauksista ei voida suorittaa määrityksen mukaisesti, kuinka suurta osaa testitapauksista ei ole pystytty bugien tai keskeneräisyyden vuoksi testaamaan, ja kuinka paljon minkäkin prioriteettitason bugeja odottaa korjausta, hänen viestiinsä on vaikeampi suhtautua välinpitämättömästi.

Sisällön jäsentelyn lisäksi selkeyttä voi lisätä myös värien käytöllä. Esimerkiksi, vakaviin bugeihin liittyvät FAIL-rivit voi korostaa punaisella ja pienempiin liittyvät keltaisella. Yksittäiset vihreät PASS-rivit niiden seassa kertovat kenties selkeämmin tilanteen lohduttomuudesta kuin lukumäärät tai prosentit.

Project piparkakkutalo

Launch

Isä: Hei, otin piparitaikinan sulamaan, nyt tehdään piparkakkutalo!
Lapset: Jee!
Äiti: Ostitko sellasen valmiin setin?
Isä: Ei tässä millään talopaketeilla pelata, tehdään ihan oma. Saadaan just sellanen kun halutaan.
Lapset: Jee!

Määritys

Tyttö: Mä haluun Muumitalon!
Poika: Eikun tehdään traktori!
Isä: Mä olin ajatellut että tehtäisiin linna.
Äiti: Eikö ihan tavallinen talo kävisi?
Isä: Tehdään sellainen prinsessalinna.
Tyttö: Joo!
Poika: Höh!
Isä: Sinne vois tehdä vaikka lohikäärmeenkin...
Poika: Mä en ala jos ei tuu traktoria!
Isä: No tehdään siihen pihalle traktori.
Poika: Okei!
Äiti: Kuulostaa aika hankalalta.
Isä: Älä nyt, hyvä siitä tulee.

Suunnittelu

Äiti: Pitäiskö meidän tehdä siitä pahviproto tai jotain?
Isä: Ei tää oo niin vaikeeta, ja taikinakin alkaa olla sula. Mä piirrän kaavat tähän leivinpaperille ja leikataan niiden avulla.
Lapset: Mä haluun kans piirtää!
Isä: No piirtäkää te niitä prinsessoja ja traktoreita.
Tyttö: Ja sit tähän tulee kukkia ja Muumeja.
Poika: Ei linnaan voi tulla Muumeja!
Tyttö: Kyllä voi jos tulee traktoreitakin!
Äiti: Paljonko meillä on taikinaa, riittääkö se kaikkeen?
Isä: On sitä aika paljon. Eiköhän sillä pärjätä.

Toteutus

Isä: Nyt leikataan nää kaavat ja sitten sen mukaan palat.
Lapset: Jee!
Äiti: Mä laitan uunin päälle ja alan jo kaulita tuota taikinaa.
Tyttö: Toi leikkas mun Muumipeikolta pään!
Isä: Teipataan ne palat yhteen, ihan hyvä tulee.
Tyttö: Ei ei ei, aaaaaaaaaaaa, nyt mä leikkasin vinoon!
Isä: Se on vasta se paperimalli, jonka perusteella leikataan sitä piparkakkutaikinaa. Voit korjata sen sitten kun leikkaat sitä taikinaa. Ja jos taikinan kanssa epäonnistuu, niin voi kaulita ja leikata uudelleen.
Tyttö: Okei...
Äiti: No niin, kaikille on kaulittu tänne oma taikina. Ja tässä vieressä on näitä peltejä ja leivinarkkeja, mihin voi nostaa valmiit.
Isä: Sitten otetaan näitä veitsiä millä voi leikata. Tää kaava laitetaan tällä tavalla tähän taikinan päälle, ja sitten leikataan näin, kaavan reunaa pitkin.
Poika: Joko saa syödä taikinaa?
Äiti: Jos tekisit ensin vähän niitä traktoreita.
Poika: Mutta tää on vaikeeta!
Äiti: Otanko mä sulle noita valmiita muotteja esiin, näillä voi tehdä possuja ja tähtiä ja joulukuusia...
Poika: Eikun mä haluun traktoreita!
Äiti: No jos minä autan vähän...
Tyttö: Mulla on jo näin paljon Muumeja!
Äiti: Tulipa hienoja! Laitetaanpas jo eka pelti uuniin.
Isä: Saanko mä lainata vähän taikinaa? Tää ei riitäkään koko linnaan.
Tyttö: Ota tolta!
Poika: Eikä!
Äiti: Jos molemmat antais vähän, niin saadaan hienompi linna?
Lapset: *nurinaa*
Isä: Jos mä asettelen nää nyt näin, niin varmaan riittää... Ääh, ei näitä saa tähän kaikkia mahtumaan. Saisinko mä vielä vähän taikinaa?
Poika: Mä söin jo kaiken.
Tyttö: Saat tosta vähän.
Isä: Kiitos, kulta! Kaulitaas vielä kerran... Voi hitsi, kyllä tää jää vähän vajaaksi...
Äiti: Jos yhdestä tornista tulis vähän matalampi?
Isä: Niin tässä on varmaan pakko tehdä.
Tyttö: Mikä täällä haisee?
Äiti: Hups, ekat piparit!
Poika: Onpa mustia!
Isä: No, voi noita vielä käyttää rakentamiseen.
Äiti: Ollaan tarkempana seuraavien kanssa. Laitan nyt kellon soimaan.
Isä: Nostellaan näitä paistettuja tänne lautaselle jäähtymään, niin saadaan pelti seuraaville pipareille.
Äiti: Eikö sen pellin kannattaisi antaa ensin jäähtyä?
Isä: Mitä turhia, tuupataan se samoin tein takas uuniin, niin tulee valmista nopeammin.
Tyttö: Mä koristelen tän ensin.
Äiti: Voi kulta, sen pitäisi antaa ensin jäähtyä!
Poika: *mums*
Isä: Voi ei, älä syö sitä!
Poika: Mut eikö piparit oo tarkoitettu syötäväksi?
Isä: Meidän piti rakentaa näistä linna!
Äiti: No nyt on ekat varmaan jäähtyneet tarpeeksi että voi aloittaa kokoamisen tai koristelun. Kumpi tehdään ensin?
Isä: Hyvä kysymys... Koristelut sotkeentuu helposti kootessa, mutta kootun koristelu voi olla vaikeaa...
Tyttö: Mä haluun koristella!
Isä: Entä jos tehdään niin, että koristellaan osa etukäteen? Sä voit aloittaa koristelun ja mä aloitan kokoamisen.
Äiti: Tarviitko apua?
Isä: No on tää vähän vaikeeta itekseen. Miten näistä on tullut näin vänkyröitä? Ja näähän on ihan eri pituisia keskenään!
Äiti: Ootko varma että just noiden pitää tulla yhteen tuolla tavalla? Jos joku muu sopis paremmin?
Isä: Äh, mä unohdin että näistä tulee näin paksuja, miten näistä nyt saa oikean kokosia?
Äiti: Pitäiskö leikata pala reunasta?
Isä: Nää mustuneet kyllä varmasti murtuu jos yrittää.
Poika: Mihin mun traktorit tulee?
Isä: Ootas kun saadaan tää koottua. Pidätkö tosta vähän kiinni, ettei se pääse liikkumaan kun mä liimaan tätä toista kohtaa?
Tyttö: Se on ihan vino.
Isä: Hei, eikö näitä torneja pitänyt olla neljä? Mä löydän palat vain kolmeen?
Poika: Ei se mitään, laitetaan seinät yhteen tälleen, ja tehdään tästä tornista tunneli tohon sisäänkäyntiin.
Isä: Tunneli?
Äiti: Vaikuttaa minusta toimivalta idealta.
Tyttö: Ja sen voi sit koristella kukilla.

Stabilointi

Poika: Maistuu hyvältä.
Isä: Joo, mutta älä riko sitä nyt enempää, syödään se vasta jouluna.
Äiti: Tää sauma hajoo täällä. Seinä putoaa kohta.
Isä: Nostetaan pystyyn ja laitetaan lisää sokeria. Ja mä varmaan pidän tästä nyt kiinni kunnes se on kuiva.
Äiti: Aika kiva siitä tuli, vaikka vähän erilainen kuin kuvittelin.
Isä: No joo, kyllä mä toivoin vähän hienompaa. Voiskohan tähän tehdä ne puuttuvat tornit ens viikonloppuna?
Äiti: Miten ajattelit silloin irrottaa nuo vinoon liimatut seinät?
Isä: Ehkä ne tornit vois vaan kiinnittää tähän ulkopuolelle.
Äiti: Onneksi sä et työskentele rakennusalalla.
Isä: Mitä vihjaat?

Älä turhaan suunnittele testausta

Testauksen voi suunnitella monella tavalla. Testitapauksia voi kirjoittaa hyvin yksityiskohtaisesti, tai ne voi rakentaa vain otsikkotasolla, muistilistanomaisesti. Itse testauksen organisointia voi suunnitella enemmän tai vähemmän perusteellisesti. Testaussuunnitelma voi kertoa mm. kuinka paljon työaikaa ja kalenteriaikaa käytetään mihinkin testikierrokseen, miten paljon aikaa varataan niihin liittyviin korjauksiin verifiointeineen, kuinka usein testikierroksia toistetaan, ja mitkä ovat kriteerit testauksen lopettamiseen.

Joskus on hyvä pysähtyä hetkeksi miettimään, millä tarkkuustasolla nämä asiat kannattaa tehdä projektin suunnnitteluvaiheen aikana.

Perusteellinen testaussuunnittelu liittyy usein siihen, että asiakkaalle on luvattu tiettyjä dokumentteja tietyssä vaiheessa projektia. Jos asiakkaan kanssa sovitaan, että he saavat toimittajan testitapaukset sisältöineen kaikkineen käytettäväksi omassa hyväksymistestauksessaan, ne on rakennettava paljon huolellisemmin ja paljon enemmän aikaa käyttäen kuin jos luodaan vain alustava testitapausluettelo, jota muokataan ja täydennetään tarpeen mukaan testausvaiheessa. Jos asiakas haluaa lukea testaussuunnitelman, siinä ei oikein voi lukea että testataan sitä mukaa kun jotain on likipitäen testattavissa, testaajana se joka sattuu silloin parhaiten ehtimään. Joskus tämä kuitenkin olisi tarkoituksenmukaisempi suunnitteludokumentti kuin sellainen, joka ottaa kantaa kaikkeen mahdolliseen testaamisen aloitus- ja keskeytyskriteereistä testikierrosten organisointiin. Kenties keskeisin hyvän testaussuunnitteludokumentin piirre voisi olla se, että se on riittävän lyhyt jotta projektin kulkua ohjaavat henkilöt lukevat ja sisäistävät sen.

Jos oikeastaan mikään ei todellisuudessa tapahdu suunnitteludokumentaation mukaisesti, eikä sitä tosiasiallisesti edes yritetä noudattaa (olipa syy tähän sitten piittaamattomuus tai projektielämän realiteetit), kuinka paljon aikaa tällaisen dokumentin kirjoittamiseen kannattaa käyttää?

Jos projektia edistetään vähän miten nyt kukakin sattuu ehtimään, on testauksessakaan turha pyrkiä tämän suurempaan kurinalaisuuteen. Klassinen testaus perusteellisine testitapausluetteloineen ja huolella ennalta suunniteltuine testikierroksineen on mielekästä vain, jos myös projektin edeltävät vaiheet viedään läpi vastaavaa kurinalaisuutta noudattaen. Eli määritysvaiheessa todella määritetään ja kiinnitetään määritykset, suunnitteluvaiheessa ihan oikeasti suunnitellaan määrityksen pohjalta, ja toteutusvaiheessa nämä suunnitelmat viedään läpi aikataulussa.

Kaikissa projekteissa tämä ei kuitenkaan ole mahdollista. Eikä kyse ole vain toteuttavan projektihenkilöstön osaamisesta ja viitseliäisyydestä. Tilanteeseen vaikuttaa myös esimerkiksi asiakkaan määritysosaaminen, eli pystyvätkö he kertomaan, mitä haluavat, ja kuinka paljon projektin aikatauluun sisällytettäviä muutoksia he keksivät suunnittelu- ja toteutusvaiheiden aikana, Ja tähän taas vaikuttaa paitsi asiakkaan projektiryhmän IT- ja substanssiosaamisen riittävyys, myös asiakkaan tarpeiden selkeys.

Lisäksi, ihmiset ovat erehtyväisiä. Paraskin projektipäällikkö voi unohtaa jotakin, ja paraskin tekninen vastuuhenkilö ymmärtää jotain väärin. On vain hyvä asia, jos nämä unohdukset ja väärinymmärrykset jäävät kiinni ennen stabilointivaihetta, koska silloin niiden vaikutukset aikatauluihin ja työmääriin ovat vähäisemmät. 

Jokainen projektiin tuleva muutos kuitenkin syö etukäteen tehdyn perusteellisen testaussuunnittelun arvoa. Mitä enemmän asioita on kirjoitettu auki testitapauksiin, sitä enemmän niitä on pakko muokata muutosten mukaisesti, ja sitä suurempi riski on sille että testaus raportoi vääriä asioita bugeina. Mitä enemmän projektin käytännöt ja järjestelyt poikkeavat testaussuunnitelmasta ehdotetuista, sitä vähemmän arvoa on sen kirjoittamiseksi tehdyllä työllä. Kun tämän päälle tulee vielä testaussuunnittelun itsensä epätäydellisyys, on selvää että määritysvaiheen perusteella tehdyt testitapaukset on vähintään katsottava läpi kriittisellä silmällä testauksen alkaessa.

Testaussuunnittelu on mahdollista tehdä myös toisin. Määritys- ja suunnitteluvaiheessa testauksen rooli voi keskittyä enemmänkin katselmointiin ja konsultointiin. Testaussuunnitteludokumentaation keskeisin rooli voi olla tiedon kerääminen siitä, mihin dokumentteihin nojaten testaus on tehtävä, sekä millaisia riskejä projektiin liittyy testaamisen näkökulmasta ja miten niihin varaudutaan. Riskitarkastelussa käsitellään niin testaukseen ulkopuolelta vaikuttavat riskit kuin riskit joihin testaaja voi itse vaikuttaa, muistaen erityisesti asiakkaan toiminnan kannalta keskeisimmät toimitettavaan järjestelmään liittyvät riskit, joiden tulisi vaikuttaa testauksen sisällölliseen painotukseen. Varsinaiset testitapaukset voidaan luoda tutkivan testauksen ohessa, tosin tällöin on muistettava että testaukseen tarvittavaan aikaan on lisättävä myös dokumentaation vaatima aika.

Mikä siis on päivän opetus? 

Klassisella, kurinalaisella testauksella on oma arvonsa ja paikkansa, mutta kaikkialle se ei sovi. Jos tiedät, ettet aikuisten oikeasti pysty viemään projektia läpi tiukasti vesiputousmallin mukaisesti, älä tee myöskään testaussuunnittelua niin kuin mentäisiin vesiputousmallilla. Älä silloin myöskään lupaa asiakkaalle testitapauksia (paitsi korkeintaan otsikkotasolla) suunnitteluvaiheessa. Tosiasiat voi tunnustaa jo etukäteen, ja ammattimainen testaaja pystyy kyllä luovimaan tiensä myös vähän epämääräisemmässä projektiympäristössä. Säästytään puolin jos toisin paljolta pahalta mieleltä ja turhalta työltä, jos projektin toimintatavoista sovitaan avoimesti etsien ne tavat, joilla tieto parhaiten löytää tarvitsijansa, ja testaus voidaan suunnitella tavalla jolla se todennäköisesti voidaan myös toteuttaa.

Mikä on testauksesi tavoite?

Testata voi monella tavalla. Harvassa ovat järjestelmät, jotka ovat niin yksinkertaisia, että niiden täydellinen bugittomuus kannattaa varmistaa - ainakaan kaikissa projektin testausta sisältävissä vaiheissa. Riippuu jossain määrin myös testattavan järjestelmän kypsyydestä, mistä näkökulmasta ja millaisin tavoittein testausta kannattaa tehdä. Siksi testauksen tavoitteitakin on syytä arvioida testauskierrosten välillä uudelleen.

Tavoitteiden järkevään asettamiseen vaikuttaa mm. testaukseen käytettävissä oleva aikataulu, testaajien määrä ja osaaminen, sekä se, miten valmis testattava järjestelmä on. Tärkeä näkökulma on myös se, minkälaista tietoa testaamisella halutaan saada. Onko tavoitteena jonkin toiminnallisuuden määrityksenmukaisuuden verifioiminen, yleiskuvan muodostaminen koko järjestelmän tai jonkin tietyn moduulin kunnosta, vai jotain ihan muuta? Kaikkea ei välttämättä kannata tavoitella kerralla.

Yksi lähestymistapa on ad hoc testaus, jonka tarkoituksena on nopeasti ja sen kummemmin suunnittelematta löytää bugeja. Itse tykkään aloittaa uuden toiminnallisuuden testauksen näin, ikään kuin kokemattomana käyttäjänä selvittäen, miten rakennelma toimii. Samaa näkökulmaa tulee usein käytettyä silloin kun on tarve kevyelle regressiotestaukselle. Tämä on suhteellisen tehokas tapa löytää server errorit ja muut isot mokat, joiden vastaantuleminen on myös vähemmän turhauttavaa ad hoc-tyylillä kuin yritettäessä kurinalaisesti kahlata läpi testitapauksia. Kovin pitkälle tällä tyylillä ei kuitenkaan päästä.

Järjestelmän käyttäjien kannalta keskeisintä lienee prosessin mukainen testaus, mikä tarkoittaa käytännössä sitä, että käydään läpi toiminnallisuuden kuvaavat käyttötapaukset. Yhteen käyttötapaukseen voi liittyä useampia testitapauksia, mutta periaate on kuitenkin sen tarkistaminen, että käyttäjän toimiessa oikein myös järjestelmä toimii oikein.

Tätä on kuitenkin syytä laajentaa myös sen tarkistamiseen, että järjestelmä osaa toimia myös tilanteissa, joissa käyttäjä ei toimi oikein - esimerkiksi julkista verkkokauppaa käyttävän asiakkaan ei voida olettaa ymmärtävän selaimensa teknisiä ominaisuuksia tai selaavan manuaalia samalla kun asioi.

Hyvä testaaja yrittää välillä myös rikkoa testattavan järjestelmän. Siis esimerkiksi syöttää kenttiin vääränlaisia arvoja, luoda liian paljon uusia kohteita massaluontitoiminnoilla, kulkea edestakaisin kuin ei ihan tietäisi mihin haluaa mennä, palauttaa muokattuja arvoja oletusasetuksiin, ja tehdä kaikkea mahdollista kiellettyä, mihin käyttöliittymä antaa mahdollisuuden.

Yleensä näitä mahdollisia väärin toimimisen tapoja on niin monia, ettei kaikkia ole mahdollista käydä läpi. Hyvään testaussuunnitteluun kuuluukin miettiä, mitkä ovat niitä oleellisimpia kokeiltavia asioita. Jos vielä suunnitelmat tehdään riittävän väljästi mahdollistamaan se, että negatiivinen testaus tehdään jokaisella testikierroksella vähän eri tavalla (toki tekemiset huolella dokumentoiden, jos bugeja tulee vastaan), testauksen kattavuutta saadaan tavallaan kasvatettua kierros kierrokselta.

Käyttötapauksien ympärille rakennettavaan testaukseen saa lisäväriä saippuaoopperatekniikalla. Testaussuunnittelu voidaan tehdä vähän kuin käsikirjoitettaisiin näytelmää, joka on täynnä värikkäitä henkilöitä ja yllättäviä juonenkäänteitä.

Oma inhokkini testauksessa lienee testaaminen vaatimusluetteloa vastaan. Pahimmillaan eteen lyödään satoja rivejä pitkä excel, jonka sisällöstä ei aina oikein edes selviä, mihin asiaan mikäkin esitetty vaatimus liittyy. Osa riveistä kuvaa hyvin nopeasti tarkistettavia asioita (esim. "järjestelmä sisältää kalenterin"), osan läpikäynti vaatii paljonkin aikaa (esim. kieliversioiden toiminnan vastaavuus toisiinsa nähden, tai pitkän prosessin loppupään toiminnallisuus, johon liittyvä testiaineisto on ensin luotava käsin). Vaatimuksien järjestys ei yleensä ole mitenkään looginen suhteessa järjestelmän normaaliin käyttöön. Ja joukossa on ehkä myös yleisiä ei-toiminnallisia vaatimuksia, joiden testaamista ei oikein ole mahdollista upottaa järjestelmätestaukseen.

Silti vaatimusluetteloa ei voi vain unohtaa, sillä kaikkien vaatimuksien upottaminen käyttötapauksiin ei aina ole mielekästä. Niistä muodostettavat testitapaukset voidaan kuitenkin usein linkittää käyttötapauksiin luoden niiden testaamiselle mielekkäämmän asiakokonaisuuden.

Tärkeää on myös toteutettavan järjestelmän ulkoasun testaaminen visuaalista ilmettä ja rautalankamalleja vasten. Selainkäyttöisissä ohjelmistoissa tähän liittyy myös selainriippumattomuuden testaaminen, eli sen tarkistaminen, että kokonaisuus toimii kaikilla sovituilla selaimilla. Yhä useammin järjestelmiä käytetään myös mobiililaitteilla. Riippuen sovitusta tukitasosta testaaminen eri selaimilla ja laitteilla voi viedä paljonkin aikaa.

Usein järjestelmätestaaminen alkaa käytännössä kun testattavat toiminnallisuudet ovat vielä kovin raakileita. Tämä asettaa myös omat haasteensa testaamiselle, vaikka sinällään testauksen aloittaminen mahdollisimman varhaisessa vaiheessa on hyvä asia.

Toteutusvaihetta tukeva erillisen testaajan tekemä testaus voi vähentää turhaa työtä kun virheitä löydetään ennen kuin niiden päälle rakennettavia kokonaisuuksia ehditään viimeistellä. Joskus se myös voi vähentää kehittäjän työtaakkaa, kun testimateriaalin luomiseen ja rakentuvan kokonaisuuden testaamiseen saa reaaliaikaista apua.

Toisaalta kommunikaatiokatkokset voivat johtaa turhaan työhön, jos testaaja päätyy raportoimaan bugeina asioita joita ei ole vielä toteutettu, tai asioita jotka aiheutuvat niistä jännyyksistä, joita kehittäjän yhtäaikainen tekeminen järjestelmässä aiheuttaa.

Ihanteellisimmillaan yhtäaikainen toteutus ja testaus tapahtuukin niin, että testaajat ja kehittäjät työskentelevät vierekkäin, jolloin kysyminen on helppoa ja myös hiljainen tieto välittyy kaikille. Jos tämä ei ole mahdollista, voidaan projektiviestintään käyttää myös sähköisiä välineitä. Tämä kuitenkin vaatii kaikilta osapuolilta tietynlaista aktiivisuutta - ei esimerkiksi voida olettaa, että testaaja pystyy aina arvaamaan, milloin hänelle annettu tieto tavoitetilasta tai testattavuudesta on riittämätöntä.

Elämäni mutteriapinana ja muita motivaatiokokemuksia

Kenties turhauttavinta testaustyössä on säätäminen.

Siis se, miten pahimmillaan parikin kertaa päivässä joutuu kyselemään projektien vastuuhenkilöiltä, joko olisi testattavaa, miten aikataulu elää, missä testataan, milloin ympäristö päivitetään, mitä ja miten on testattavissa. Mitkä ovat juuri nyt testauksen prioriteetit ja tavoitteet.

Miten viime hetken kiireellisen tilauksen vuoksi joutuu keskeyttämään juuri vauhtiin päässeen työskentelyn tehdäkseen taas uuden syöksyn tuntemattomaan. Tai kyselemään, voisiko jonossa seuraavan projektin aloittaa sovittua aikaisemmin, kun se ensimmäinen ei olekaan vielä testattavissa. Järjestelemään testauksen jakamista tai siirtämistä toiselle testaajalle, kun projektien toteutuvat aikataulut vaativat suurempaa työpanosta kuin mihin on kohtuullista yksin venyä.

Kysymään useampaan otteeseen, ennen kuin saa riittävät tiedot jonkin asian testaamiseen, vain löytääkseen itsensä tilanteesta, jossa joku tuhoaa varoittamatta vaivalla rakennetun testiaineiston, tai selviää että sovittua päivitystä ei sitten ollutkaan tehty. Tai päivitettiin epästabiiliksi tiedettyyn versioon, ja nyt päästään testaamaan samoja bugeja useammassa ympäristössä yhtäaikaa.

Tähän kaikkeen liittyy piinallinen tuntuma siitä, ettei saa mahdollisuutta tehdä työtään niin hyvin kuin haluaisi, olla niin hyödyllinen kuin omasta mielestään osaisi olla.

Jonkin verran epävarmuutta, inhimillisiä erehdyksiä ja niihin liittyvää säätämistä on pakko hyväksyä. Testaajan työn aikataulu ja työmäärä riippuvat siitä, miten kehittäjät tekevät työnsä, eikä sitä ole täysin mahdollista ennakoida. Kun vielä testaajan työn idea on enemmän tai vähemmän keskeneräisen kanssa työskentely - sen tarkistaminen, miten tukeva rakennelmasta tulikaan - virheisiin törmääminen vähän niin kuin kuuluu toimenkuvaan.

Siksi välillä on pakko joustaa ja järjestellä. Joskus on myös pakko hyväksyä se, että juuri nyt ei ole tarjolla mielekästä testaustyötä. Tai että aika ei riitä tekemään asioita oikeasti perusteellisesti. Työ on lopulta vain työtä, ei sen takia kannata yöuniaan menettää, eikä sen tarvitse olla tärkein elämään sisältöä tuova asia.

Joskus kuitenkin on vaikea välttää ajatusta, olisiko asiat kuitenkin mahdollista tehdä edes vähän paremmin.

Yksi vaihtoehto olisi tehdä projekteja ketterämmin, jolloin testattavaa syntyisi tasaisempaa tahtia ja pienempiä määriä kerrallaan. Tämäkään vaihtoehto ei kuitenkaan yksin tuo pelastusta, sillä monia vesiputousmallia rampauttavia toimintatapoja (tai tapoja olla toimimatta) on mahdollista käyttää myös projekteissa, joita periaatteessa edistetään ketterästi - häröilyhän ei sellaisenaan kuulu mihinkään prosessimalliin. Eikä järjesteltävien palikoiden pienentäminen itsessään poista järjestelyn tarvetta, vaan lopputulos voi olla jopa päinvastainen.

Yllättävän paljolta turhalta työltä ja mielipahalta säästyttäisiin ihan vain skarppaamalla projektien sisäisen tiedonkulun kanssa. Siis esimerkiksi sillä, että aina kun tapahtuu jotain aikatauluun tai sisältöön vaikuttavaa, myös testaaja saisi kuulla asiasta. Tai jos kehitetään ja testataan yhtäaikaisesti, saman projektin parissa painivilla olisi tieto siitä, mitä muut ovat tekemässä, ja keihin kaikkiin omat tekemiset voivat vaikuttaa. Että saisi senkin tiedon, jota ei ole helppoa keksiä itse kysyä. Monet näistä asioista varmaankin helpottaisivat myös kehittäjien työtä.

Pitäisikö testaajan istua kehittäjien luona jo toteutusvaiheessa? Pitäisikö hänen osallistua projektipalavereihin alusta alkaen? Ainakin osaan niistä? Pitäisikö projektien tiedotus hoitaa spämmäämällä aina sähköpostilistaa, jolle myös testaaja kuuluu?

Ratkaisuvaihtoehtoja voi olla useampia. Ehkä lopulta tärkeintä on, että projektin sisäinen viestintä ylipäätään nähdään panostamisen arvoisena, tapana ehkäistä ongelmia. Esimerkiksi, että palaverit suunnitellaan jollain tasolla, niistä jaetaan etukäteen jonkinlainen agenda, ja niihin pääsevät tavalla tai toisella osallistumaan kaikki, joita käsiteltävä asia jotenkin koskee, tietäen mitä heidän osallistumiseltaan odotetaan. Että niiden ensisijainen tarkoitus ei ole raportointi, vaan tiedon jakaminen kaikille niille jotka siitä hyötyvät.

Testaus on enemmän

Testaamisesta on monenlaisia käsityksiä. Meillä joskus puhutaan testaamisesta ja testailusta, missä testaaminen tarkoittaa päämäärätietoista, suunnitelmallista ja jokseenkin järjestelmällistä tapaa testata, testailu taas, no, ajan kuluttamista softaa läpi kliksutellen ja bugeja raportoiden. Minun ei ehkä tarvitse vääntää rautalangasta, kumpi on yleensä parempi tapa niin kustannusnäkökulmasta kuin yritettäessä muodostaa käsitystä siitä, onko järjestelmä käyttöönottokunnossa vai ei.

Kävin eilen kuuntelemassa James Bachin esitelmää testattavuudesta, ja siinä yksi hänen teeseistään oli käsitteiden "testaaminen" ja "tarkistaminen" erottaminen toisistaan. Ideana oli, että tarkistaminen on toimintaa, joka voidaan ja usein myös kannattaa automatisoida. Testaaminen on kuitenkin enemmän. Tekoälyn kehittämisessä on otettava vielä monta pitkää harppausta, ennen kuin ihminen voidaan testaustehtävissä täysin korvata tietokoneella.

Järjestelmällisyyttä ja standardoitavuutta rakastaville voi olla hieman hankalaa hyväksyä se, että se missä ihminen voittaa koneen, on henkilöriippuvaista. Riippuu testaajan kokemuksesta, tuotetuntemuksesta, teknisestä ajattelutavasta ja monesta muusta henkilökohtaisesta ominaisuudesta, millaisia asioita hän huomaa.

Esimerkiksi, mitä laajempi kokemus sinulla on julkaisujärjestelmistä, ja mitä enemmän olet testannut juuri nyt testattavana olevaa julkaisujärjestelmää, sitä parempi intuitio sinulla on siitä, miten järjestelmän pitäisi toimia, ja mistä bugeja todennäköisimmin löytyy. Toisaalta joskus etua on siitä, ettet ole eläissäsi nähnyt yhtä ainutta julkaisujärjestelmää. Tällöin pystyt parhaiten löytämään niitä bugeja ja epäloogisuuksia, joita harjaantumattomat, pari kertaa vuodessa järjestelmän kanssa työskentelevät ei-niin-kovin-tekniset päivittäjät löytävät työssään.

Vastaavasti testaajalle on tietyissä tilanteissa apua koodaritaustasta, toisissa tilanteissa se vaikeuttaa käyttäjän kannalta ongelmallisten asioiden huomaamista. Tätä kautta löytyy arvo sille, että testaustiimi koostuu erilaisista ihmisistä, joiden taustat ja tavat työskennellä poikkeavat jollain tapaa toisistaan.

Itse huomaan hakevani testaukseeni lisätehoja valitsemalla itselleni jonkin roolin, näkökulman tai tavoitteen testauksen alkaessa, ja vaihtamalla sitä kun koen saaneeni siitä kaiken oleellisen irti. Testauksen kattavuutta voi parantaa vielä enemmän vaihtelemalla saman tuotteen kimpussa painivaa testaajaa. Mielenkiintoista kyllä, testaukseen saa entisestään tehoja tekemällä sitä parityöskentelynä, jolloin testaajien välinen vuorovaikutus tavallaan kuroo umpeen heidän väliltään löytyviä sokeita pisteitä.

Testaaminen ei ole vain ennalta määrättyjen tehtävien suorittamista. Se on myös uteliaisuutta ja ennakkoluulottomuutta vaativa oppimisprosessi. Lisäksi se on vuorovaikutusta: yhdessä oppimista, sekä pyrkimystä ymmärtää niin käyttäjää kuin kehittäjää.

Miten saada paras hyöty irti testaajasta?

Työpanoksen mittaaminen on vaikeaa. Jollain tavalla työntekijöiden suoriutumista pitäisi seurata, mutta mittareilla on paha tapa vaikuttaa ihmisten suoriutumiseen paitsi hyvässä myös pahassa.

Testaajan työn arviointia hankaloittaa se, että se on niin riippuvaista muiden työskentelystä. Samoin helpoiten muodostettavat testaajan työssä onnistumisen mittarit ovat kaikki omalla tavallaan ongelmallisia.

Löytyvät bugit riippuvat paitsi testaajasta myös kehittäjästä, joten tietyssä aikavälissä löytyvien bugien määrä tai laatu ei välttämättä kerro kovin paljoa siitä, miten hyvin testaaja on aikansa käyttänyt. Jos testaajan työtä arvioidaan mittaamalla löytyvien bugien määrää, se kannustaa testaajaa tehokkaaksi löytämään virheitä, mutta ei suuntaamaan tekemistään oleellisimpiin asioihin - näin bugikanta saadaan helposti täyttymään pienen prioriteetin virheistä. Bugien merkittävyyden arvioiminen statistiikkaa varten taas on työlästä, ellei luoteta testaajan tai hänen kanssaan työkentelevän kehittäjän omaan arvioon bugien prioriteeteistä. Toisaalta tarkkakaan tieto bugien vakavuudesta ei anna tietoa testauksen tehokkuudesta, jos testaaja käyttää paljon aikaa sellaisten asioiden manuaaliseen läpikäymiseen, joiden testaaminen kannattaisi automatisoida.

Testauksen tehokkuutta voidaan mitata myös esimerkiksi sillä, miten suuri osa raportoiduista bugeista saadaan ratkaistua kerralla, kysymättä lisätietoja bugin toistamiseksi. Tämä vaatii kuitenkin suhteellisen huolellista bugiraportointijärjestelmän käyttöä, jotta statistiikkaa saadaan helposti kerättyä, ja siten mahdollistaa myös huijaamisen. Asiakkaan löytämien bugien määrä ja laatu kertoo paljon sisäisesti tehdyn testauksen onnistumisesta, mutta tämän mittarin käyttäminen on monella tavalla hankalaa: miten tieto asiakkaan löydöistä raportoidaan ja luokitellaan, ja miten hallitaan tieto järjestelmään tehtävien päivitysten vaikutuksesta sekä niihin liittyvien testikierrosten vastuista.

Testaajan mahdollisuudet käyttää aikansa hyödyllisesti riippuvat myös siitä, mihin tahtiin testattavaa valmistuu. Hänellä ei ole valtaa vaikuttaa siihen, tuleeko asiakasprojekteista hommia tasaiseen tahtiin, vai joudutaanko vuoroin käyttämään aikaa toissijaisiin tehtäviin ja vuoroin priorisoimaan projekteja. Jos siis mitataan sitä, miten suuri osa ajasta kuluu laskutettavien projektien parissa, kannustaa se toki priorisoimaan ajankäytössä asiakasprojekteja, mutta myös käyttämään näihin projekteihin tarpeettoman paljon aikaa silloin kun asiakasprojekteja ei ole tarjolla täysipäiväisesti. Jos taas mitataan sitä, miten hyvä tuntihinta saadaan tehtävästä työstä, kipeimmin testausta kaipaavat katastrofiprojektit päätyvät testaajan ajankäytön priorisoinnissa viimeiseksi. Entä miten pitäisi huomioida tuotekehityksen tukeminen, tämä työ kun hyödyttää useita asiakasprojekteja?

Asiakastyytyväisyyttäkään ei saavuteta pelkällä testauksella, vaan siihen vaikuttavat mm. projektipäällikön kommunikointitaidot ja määrityksen tekemiseen osallistuvien kyky ymmärtää asiakkaan tarpeet ja muotoilla ne ymmärrettävästi. Jos järjestelmää ei ole onnistuttu määrittämään ja suunnittelemaan täyttämään asiakkaan tarvetta, timanttinenkaan testaus ei tilannetta pelasta. Asiakkaan löytämillä bugeilla kun on merkitystä vain, jos ne ovat syy joka estää järjestelmää täyttämästä sitä tarvetta, jota varten se hankittiin. Jos tärkeimmät valituksen aiheet ovat luonteeltaan muutospyyntöjä, liikutaan alueella jolla testaajien rooli on usein tarkoituksenmukaisinta pitää melko pienenä - ellei häntä sitten tuoda jo määritysvaiheesta alkaen asiakasrajapintaan niin, että hänellä on aidosti mahdollisuus arvioida toteutuksen soveltumista asiakkaan liiketoimintatarpeisiin.

Voidaan myös yksinkertaisesti kysyä projektihenkilöstöltä rivikoodarista projektipäällikköön, onko yhteistyö testaajan kanssa koettu hyödylliseksi, ja millaisia puutteita siinä nähdään. Tällaisten kartoitusten kompastuskiveksi vain koituu helposti se, että kenelläkään ei ole aikaa paneutua ylimääräisiksi koettuihin asioihin, kun seuraavat projektit painavat jo päälle. Lisäksi subjektiivisiin arviointeihin liittyy myös persoonallisuuksiin liittyviä piirteitä, jotka tekevät arvioinnista ylipäätään epämääräistä.


Toisaalta, onko testaajan työn mittaamisella edes merkitystä, jos organisaatio ei osaa täysin hyödyntää testaajan työpanosta?

Pystytäänkö tekeminen projekteissa aikatauluttamaan niin, että testaajan työaika saataisiin mahdollisimman tehokkaasti hyödynnettyä, eli testattavaa saataisiin eri projekteista valmistumaan mahdollisimman tasaiseen tahtiin? Mahdollistavatko projektien aikataulut sellaisen testaamisen, että ammattitestaajista on oikeasti hyötyä?

Onko organisaation sisäiset laskutuskäytännöt muodostettu niin, että projektien kannattaa hyödyntää ammattitestaajia?

Miten testaajan työaikaa hyödynnetään parhaiten silloin, kun testattavaa ei ole? Onko sisäisiä kehitysprojekteja, jotka tuovat hyötyä asiakasprojekteille, tai muita aikataulultaan väljiä tehtäviä, joihin voi käydä käsiksi, jos ei testaamalla pysty olemaan oikeasti avuksi? Tuetaanko testaajien mahdollisuuksia kouluttautua suoriutumaan paremmin työssään? Onko kehittäjien mahdollista itsenäisesti pyytää tukea testaajalta, jos he kokevat sen hyödylliseksi jotakin toiminnallisuutta rakentaessaan?

Entä mitä testaukselta ylipäätään halutaan? Onko tarkoituksena vain etsiä bugeja niin pitkään kuin projektin aikataulu ja budjetti antavat myöten, vai onko tavoitteena esimerkiksi antaa projektipäällikölle mahdollisuus keskittyä työssään olennaiseen, helpottaa kehittäjien työtä, tai saada tieto ohjelmiston laadusta tietyllä ajanhetkellä?

Kun näihin kysymyksiin löytyy vastauksia, on myös relevanttien mittareiden rakentaminen varmasti helpompaa.

Kehittäjät Marsista, testaajat Venuksesta

Pari vuotta sitten osallistuin testaajana poikkeuksellisen haasteelliseen projektiin, jossa bugipingiksen pahimpina aikoina projektia tekevät koodarit eivät voineet irvistelemättä tulla kanssani samaan hissiin. Kun projektin tilanne rauhoittui, minut kutsuttiin kakulle, varoittaen toki että tarjolla olevat herkut saattavat olla myrkytettyjä.

Tapaus tuli taas mieleen, kun osallistuin keskusteluun, jossa kehittäjät kertoivat käsityksensä luomustensa sisäisestä kauneudesta ja testaajien pinnallisesta tavasta löytää aina jotain valittamista.

Optimistina uskon että nämä jutut esitettiin kaikki vähän pilke silmäkulmassa (ja niitä voi joskus jopa ottaa jonkinlaisena kehuna) mutta jotain ne kuitenkin kertovat testaajan ja kehittäjän välisen suhteen kompleksisuudesta.

Kehittäjä on se joka luo, ja sitten tulee testaaja ja lyttää lopputuloksen maanrakoon (ehkä jopa nauraa sille hieman, anteeksi vaan). Ymmärrettävästi kehittäjän voi joskus olla vaikeaa suhtautua asiaan niin, että me teemme tässä yhteistyötä, kun oma osa on se tekeminen ja toisen osa on pelkkä virheistä nipottaminen. Sitä kuvittelee saaneensa jotain valmiiksi, kunnes seuraavana päivänä edessä on kymmenien kohtien lista ongelmista, joiden syyt pitäisi etsiä ja korjata.

Ehkä jollain tavalla tilanne tuo mieleen 80-luvun stereotyyppiset parisuhdesketsit, joissa mies on se eteenpäinvievä järjen ääni, kun taas nainen esittää kohtuuttomia vaatimuksia eikä ole ikinä tyytyväinen.

Vertauksen tekee entistäkin herkullisemmaksi se, että siinä missä kehittäjistä valitettavan harvat ovat naisia, testaajien joukossa taas miehet ovat yllättävän harvinaisia.

Testaajan ammattitaidon keskeisimpiä puolia onkin palautteen antaminen kehittäjille tavalla, joka kannustaa yhteistyön ilmapiiriä. Täysin asiallinenkin palaute saatetaan ottaa henkilökohtaisesti (vaikka kuinka ollaan rationaalisia miehiä!) jos se esitetään väärin. Riippuu myös henkilöstä, voiko tunnelmaa esimerkiksi keventää vai kiristää huumorilla tai kehumalla onnistumisia ("hei, kolme bugia oli sentään ihan oikeasti korjaantunut!"), tai vaikuttaako puhtaan asiallinen palaute tylyltä. Toiset arvostavat mahdollisimman rautalangasta väännettyjä bugikuvauksia ja korjausehdotuksia, toiset haluavat pitää asioiden selvittelyt ja suunnittelut enemmän omana reviirinään.

Siksi testaajalle on tärkeää saada tavata kasvokkain niitä ihmisiä, joiden kanssa tekee töitä. Se ei yleensä ole välttämätöntä projekteihin liittyvän informaation välittämisen kannalta (vaikka usein auttaakin myös siinä), mutta se auttaa ymmärtämään niin kehittäjien kuin projektipäälliköidenkin persoonallisuuksia, sekä antamaan myös näille kuvaa testaajasta ihmisenä eikä pelkkänä bugiraportoijana. Tämä helpottaa yhteistyön sujumista suuresti.

Isossa yrityksessä näiden tapaamismahdollisuuksien järjestäminen voi olla haasteellista. Eri toimipisteissä työskentelevät ihmiset eivät kenties koskaan pääse työnsä puitteissa tapaamaan toisiaan, ja jos toimipiste on kovin iso, sen sisälläkin tapaaminen voi olla yllättävän harvinaista. Silloin on tärkeää, että edes joskus järjestetään koulutus-, kehitys- ja virkistyspäiviä, joiden lomaan voi ujuttaa aikaa siihen, että käy tutustumassa ihmisiin, joiden kanssa tekee töitä. Erilaiset projektien aloitus- ja lopetustapahtumat voivat nekin tarjota tärkeitä tutustumismahdollisuuksia.

Lisäksi sähköinenkin kommunikaatio muuttuu yllättävän paljon inhimillisemmäksi, kun siihen käytetyt sovellukset osaavat näyttää toisen osapuolen valokuvan.

Mistä laatu tulee?

Testaajan työ on laadunvarmistusta. Joskus vastaan tulee käsitystä, että testaajan mukaan ottaminen takaisi lopputuloksen laadun.

Näin ei kuitenkaan ole. Testaajan tehtävä on laadun mittaaminen ja arviointi, sen parantaminen taas on pohjimmiltaan ihan muiden heiniä.

Laatu ei muutenkaan ole erillinen palikka, jonka voisi lisätä projektiin ihan vain jonkin dokumentin tai yksittäisen henkilön muodossa. Laatu on kaikkien yhteinen asia.

Laadun syntyminen vaatii tarkoituksenmukaista määritystä ja suunnittelua. Nykymaailmassa käytettävyys ja visuaalinen miellyttävyys ovat keskeisessä asemassa laadun kokemisessa, mutta tärkeää on tietenkin myös se että tuote vastaa toiminnallisuuksiltaan käyttäjien tarpeilta.

Laadun tuottamista helpottaa mahdollisuus seurata tarkoituksenmukaista prosessimallia, hyödyntäen sen tarjoamia työvälineitä.

Testausosaamisesta on apua laadun tuottamisessa niin järjestelmän määrittelijöille, suunnittelijoille kuin toteuttajille. Oma etunsa on kuitenkin myös siitä, että testaajalla ei ole vastuuta minkään näiden osa-alueiden tekemisestä. Näin siksi, että ihminen on sokea omille virheilleen, eikä testausosaaminen itsessään suojele ihmistä erehdyksiltä. Sen sijaan testausosaaminen antaa välineitä sen arviointiin, antaako määritys riittävät tiedot ohjelmiston toteuttamiseen tai vastaako toteutus määritystä.

Keskeisimpään kysymykseen, eli vastaako järjestelmä asiakkaan tarpeita, testaus voi vastata vain silloin kun asiakas itse testaa. Toimittajan testaajalla harvoin on mahdollisuutta verrata määritystä asiakkaan tarpeisiin, koska hän ei osallistu määrityksen tekemiseen eikä siksi pääse käsiksi tietoon joka voisi osoittaa määrityksen puutteet tarpeisiin nähden.

Erityisesti isojen asiakasorganisaatioiden kanssa työskennellessä ongelma on myös se, ettei asiakkaankaan projektiryhmällä välttämättä ole riittävää tietoa kaikkien tulevien käyttäjien tarpeista.

Lisäksi järjestelmän määrittäminen on helposti liian abstraktia henkilölle, joka ei ole määritysammattilainen. Todelliset tarpeet saattavat tulla tästä syystä esiin vasta testausvaiheessa.

Tämä nostaa haasteeksi sellaisten työvälineiden ja työskentelytapojen löytämisen, jotka konkretisoivat, mistä projektissa on kysymys.

Erilaiset demoympäristöt tai vaikka paperille hahmoteltu käyttöliittymä jota saa ihan itse "klikata" voivat auttaa konkretian luomisessa. Ketterät menetelmät taas antavat mahdollisuuden tarkentaa määrittelyä sitä mukaa kuin asiat konkretisoituvat.

Joskus voi olla myös tarpeen opettaa asiakasta testaamaan, tai esimerkiksi kysyä, pääsevätkö kaikkien tulevien käyttäjäryhmien edustajat arvioimaan määrityksen onnistumista.

Miten testaus voi auttaa asiakastyytyväisyyden parantamisessa

Asiakastyytyväisyys on hankala suure. Sen mittaaminen on usein hieman epämääräistä, ja siihen vaikuttavien asioiden perusteellinen analysointi kenties vieläkin haasteellisempaa.

Asiakkaalle ihanteellista olisi saada hyvää halvalla nopeasti, vieläpä hyvällä palvelulla ryyditettynä. Mutta asiakkaan etu on myös se, että yhteistyökumppanien toiminta on kannattavaa, koska nappiin mennyt toteutusprojekti ei kauheasti lämmitä, jos ylläpidosta huolehtiva organisaatio katoaa.

Laadun tekeminen halvalla kannattavasti on haasteellista. Tämä pätee niin huonekaluostoksilla, ravintolassa kuin ohjelmistokehityksessäkin. Näiden tekijöiden optimointi asiakkaan parhaaksi - laatu, hinta, aikataulu, palvelutaso ja kannattavuus - ei ole ihan yksinkertaista. 

Testaus (hyvin hoidettuna) on yksi tapa vaikuttaa positiivisesti näihin kaikkiin.

Laatu

Testauksen vaikutus laatuun on kenties helpointa nähdä, puhutaanhan testaamisesta usein laadunvarmistuksena. Testaus ei kuitenkaan itse tuota laatua, vaan ennemminkin mittaa sitä, antaen laadun tekijöille eli järjestelmän määrittelijöille, suunnittelijoille ja toteuttajille informaatiota, jonka avulla lopputuloksesta voi tulla laadukas.

Järjestelmän käyttöönoton kannalta ohjelmiston laatu on usein keskeisempi asia kuin toteutusprojektiin liittyvät kommellukset, ja siksi laadunvarmistus on keskeinen tekijä asiakastyytyväisyydessä.

Muissa asioissa arkiajattelussa testauksen rooli ei ehkä ole yhtä ilmeinen.

Hinta

Testaus nähdään usein asiana, joka kasvattaa hintalappua. Näin asia onkin, jos testausta ei tehdä oikein, sillä kaikkien bugien kaivaminen esiin monimutkaisesta ohjelmistosta on ikuisuusprojekti. Päämäärätön ohjelmiston läpikliksuttelu ei myöskään välttämättä löydä oleellisimpia virheitä, vaikka aikaa siihen saa kulumaan ihan niin paljon kuin aikaa käytettävissä on.

Ammattitaitoisesti suunniteltu testaus ei kuitenkaan välttämättä kasvata kokonaishintaa verrattuna tilanteeseen jossa vain ollaan testaavinaan, vaan voi toimia jopa päinvastoin.

Testaajan osallistuminen jo määritysvaiheeseen dokumenttien katselmoinneilla sekä alustavien testitapauksien luominen ennen ohjelmiston toteutusta voi tehostaa muiden projektiin osallistuvien työskentelyä ja ehkäistä virheitä, vähentäen kokonaistyömäärää. Testaajan ammattitaitoa on myös mm. testitapauksien priorisointi, eli sen arviointi miten perusteellisesti mitäkin kannattaa tehdä, ja tätä kautta pystytään yhtä aikaa minimoimaan testaukseen kuluvaa aikaa ja maksimoimaan testauksen kykyä löytää merkittävät virheet.

Aikataulu

Toinen testauksen perusongelma on se, että siihen ei jää aikaa kun toteutus venyy.

Todellisuudessa asiantunteva testaaminen ei kuitenkaan viivästä projektia, koska järjestelmän käyttökelpoisuus ei riipu siitä, miten paljon testaajat ovat löytäneet bugeja, vaan siitä, miten paljon niitä oikeasti on. Testauksesta nipistäminen aikataulun nimissä johtaa helposti tilanteeseen, jossa stabilointivaihe venyy ja kuormittaa niin projektipäällikköä kuin kehittäjiä kohtuuttomasti, koska aikaa kuluu paljon asiakkaan löytämien bugien perkaamiseen, selittelemiseen ja hyvittelemiseen. Sen sijaan asiantuntevan sisäisen testauksen avulla on mahdollista siirtää projektin aikataulua hallitusti, kun ammattitestaaja pystyy auttamaan järjestelmän valmiusasteen ja stabilointivaiheen vaatiman aikataulun arvioinnissa.

Palvelu

Testauksen tuki aikataulun arvioimiseen, sekä tarvittaessa käyttöohjeiden luomiseen ja asiakkaan hyväksymistestauksen ja käyttönoton tukemiseen paitsi helpottaa projektipäällikön työtä, voi myös parantaa asiakkaan kokemusta saamansa palvelun laadusta. Näin jo siksikin, että testaajan avulla projektipäällikön on helpompaa keskittyä olennaiseen. Lisäksi testaajan tuominen asiakasrajapintaan voi parantaa asiakkaan kokemusta siitä, että hänen kokemansa haasteet ohjelmiston käyttöönotossa otetaan vakavasti.

Kannattavuus

Mitä toiminnan kannattavuuteen tulee, yksi näkökulma on tuotantokäytössä löytyvien bugien määrä ja laatu. Asiakkaan tai hänen asiakkaansa löytämän bugin korjaaminen on paljon kalliimpaa kuin bugin korjaaminen toimittajan itse tekemän stabiloinnin aikana. Ongelman selvittelyyn osallistuu silloin vähemmän osapuolia, kehittäjät ovat orientoituneet kyseiseen projektiin kun tekevät sitä muutenkin, ja lisäksi bugiraportti tarjoaa tyypillisesti paljon paremmat eväät ongelman syyn löytymiseen.

Tuotantokäytössä löytyviä virheitä ei välttämättä tarkastella yrityksen kustannuslaskennassa projektien kannattavuuden näkökulmasta, koska itse toteutusprojekti on ehtinyt jo päättyä. Yrityksen kannattavuuteen ja mahdollisuuksiin jakaa työ tekijöilleen tehokkaasti ne kuitenkin vaikuttavat. Merkittävien tuotantokäytössä löytyvien bugien pr-arvo on myös korkea, ja osa asiakkaista osaa myös vaatia ylläpitosopimuksia, joissa ongelmatilanteisiin liittyy sanktioita.

Muutoshallintaa v-käyrällä

Projektipäällikkö raahusti hiuksiaan haroen ja raskaasti huokaillen testaajan työpisteelle.

"Istuhan alas", testaaja kehotti. "Mitäs meidän projektille kuuluu? Stabilointivaiheen piti muistaakseni alkaa pari viikkoa sitten, joko nyt vihdoin alkaisi olla jotain testattavaa?"

Projektipäällikkö huokaisi taas syvään.

"Ei ole vielä tarpeeksi valmista," hän vastasi. "Ja itse asiassa nyt on sellainen tilanne, että pitäisi keskustella testauksen määrästä."

"Niin, arvioin silloin projektin alkaessa, että riittävä testaus voisi onnistua kolmen viikon työllä. Se todettiin jo silloin hieman optimistiseksi arvioksi, mutta haluttiin minimoida kustanuksia. Projektin ongelmat tietysti indikoivat, että se ei välttämättä riitä."

Projektipäällikön ilme muuttui entistä tuskaisemmaksi.

"Mutta kun projektin aikataulu ei jousta! Etkö voisi testata vähän nopeammin?"

"No tietysti voidaan vielä priorisoida testitapauksia ja karsia pikkuisen eri päätelaitteilla ja selaimilla tehtävää testausta, mutta se tietysti kasvattaa riskejä. Varmaan kahdessa ja puolessa viikossa saisi jo kohtuullisen käsityksen riskitasosta, vaikka laadun takaaminen voikin olla mahdotonta. Ja aikatauluhan riippuu pitkälti myös siitä, miten nopeasti korjaukset etenevät."

"Minä ajattelin ennemminkin, että jos kuitenkin vaan ottaisit pari päivää ja kliksuttelisit sen läpi? Ei mentäisi niin virallisesti."

"Oletko tosissasi? Meillä on testattavana kymmenkunta prosessikulkua variaatioineen viidellä eri selaimella, tabletilla ja älypuhelimella. Jo siihen kolmen viikon työmäärään liittyy tietyn riskitason hyväksyminen. Ja miten se aikataulu nyt voi olla noin tiukka, kun testaussuunnitelmaa tehtäessä sen kolmen viikon työn jakaminen kuuden viikon jaksolle ei ollut mikään ongelma? Nyt ollaan vasta kaksi viikkoa myöhässä, tai kohta siis kolme viikkoa. Eikö sitä testausaikaa pitäisi olla vielä kolme viikkoa jäljellä?"

"Unohdin kertoa sinulle, että koulutuksia piti aikaistaa kahdella viikolla. Eräillä avainhenkilöillä osui lomat siihen hankalasti, ja sitten oli seminaarimatkoja. Pitäisi saada valmista sitä ennen."

Testaaja veti syvään henkeä ja nojautui tuolissaan taaksepäin.

"Yritätkö siis sanoa, että softa ei ole vielä tarpeeksi valmis testattavaksi, mutta ensimmäiset koulutukset ovat jo kahden viikon kuluttua?"

"Niin."

Hetken aikaa kuului vain ilmastoinnin vaimea humina.

"No, periaatteessa tilanne saattaa olla pelastettavissa, jos voin valjastaa koko testaustiimin työhön, ja pääsemme aloittamaan vielä tällä viikolla. Täytyyhän siellä joku kokonaisuus kohta olla testattavissa, ette kai te kaikkea ole tehneet yhtä aikaa."

Projektipäällikkö vinkaisi hiljaa, muttei sanonut mitään.

"Mutta korjausten pitäisi sitten edetä tosi nopeasti, tai muuten me vain dokumentoimme syyt, joihin koulutus tulee kaatumaan. Ja tietysti sen pitää olla hyvin koodattu, että se saadaan käytännössä yhdellä korjauskierroksella kuntoon. Aika ei mitenkään riitä nyt bugi-pingikseen."

"Ei onnistu, budjetti ei anna myöten."

"Miten niin ei anna myöten? Piti olla mahdollisuus käyttää testaamiseen kolme viikkoa työaikaa."

"Mutta tässä on nyt ollut vähän kaikenlaista, on tullut yllättäviä kustannuksia. Muista projekteista aiheutuvien resursointiongelmien vuoksi tätä on nyt tehty aika takapainotteisesti, ja siksi projektiin piti ottaa mukaan odotettua suurempi joukko kehittäjiä. Osa on ollut vähän kokemattomia, työ on edennyt hitaasti ja ovat tarvinneet suunniteltua enemmän ohjausta. Hommia on myös jouduttu vaihtamaan tekijältä toiselle, kun on pitänyt priorisoida työskentelyä eri projektien välillä. Yksi päivä meni hukkaan, kun integraatioympäristö asennettiin ensin väärin. Pari päivää meni kun piti kaivaa yhden sairaslomalle jääneen kehittäjän koneelta, mitä hän oli ehtinyt tehdä. Ja sitten yksi kone hajosi, eikä ollut varmuuskopiota. Ja..."

"Eli kun koodarit säätävät, testaus maksaa?"

"Maksaa ja maksaa, asiakashan se tästä maksaa. Tai meidän firma, asiakas ei suostu maksamaan enää yhtään enempää."

"Tiedätkö, miten kalliiksi tuotantokäytössä löytyvät bugit tulevat? Tai miten paljon työläämpää on tulkita ja hallita keskivertoasiakkaan bugiraportteja kuin meidän omien ammattitestaajien bugiraportteja? Mitä tulee koulutuksesta, kun softa ei toimi? Tai miten vaikuttaa asiakastyytyväisyyteen tai käyttäjien muutosvastarintaan, jos aloitetaan keskeneräisellä järjestelmällä?"

"No en minä voi kehittäjiltäkään sitä työaikaa nipistää, kun ei siitä järjestelmästä tule valmista ilman heidän työtään."

"Ja mikä saa sinut kuvittelemaan, että he saavat sen käyttökuntoon ilman että sitä testataan? Kuule maailmassa on aika paljon hyvää tuotekehitystä mennyt hukkaan, kun puutteellisen testauksen takia softaa ei ole saatu riittävään kuntoon, että sitä oikeasti voisi käyttää."

"Noh, tuskin tästä nyt sen luokan katastrofi on tulossa."

"Minusta kuulostaa, että sinulla on tässä projektissa toteutunut aika merkittävä määrä riskeistä. Sillä on väistämättä aikataulu- tai kustannusvaikutuksia, usein molempia."

"Mutta kun asiakas ei tule hyväksymään korkeampaa hintaa eikä viivästettyä aikataulua!"

"Ei se järjestelmä tunne projektin aikataulua, se valmistuu tekemällä ja testaamalla. Jos hintaa ja aikataulua ei voi venyttää, niin ominaisuuslistaa tulee pienentää."

"Sinä et tunne tätä asiakasta, eivät ne tule suostumaan... Eikä se tällä aikataululla onnistuisikaan. Sitä paitsi kaikki on melkein valmista, joten olisi tyhmää jättää mitään kesken."

Laskeutui hiljaisuus. Ilmastoinnin humina tuntui painostavana. Projektipäällikkö painoi päänsä käsiinsä ja huokaisi syvään.

"Mitä tässä sitten sinun mielestäsi tulisi tehdä?"

Testaaja katsoi ulos ikkunasta. Aurinko paistoi.

"Lähdetään kaljalle."

"Mitä, nyt on keskiviikkoiltapäivä?"

"Joo joo. Sulla on varmasti jo viikon tunnit täynnä, etkä pysty nyt edistämään mitään. Mennään kaljalle."

"Mutta eihän se käy!"

"No tietysti se käy. Otetaan mukaan kynää ja paperia ja suunnitellaan yhdessä kriisiviestintä. Kun sitten aamukrapulassa soitat asiakkaalle, kuulostat niin autenttisen katuvalta ja uupuneelta, että ne kyllä leppyvät."

Hetken hiljaisuus.

"Absurdia, mutta tuossa saattaa olla järkeä..."

"Joo joo. Enemmän kuin monessa asiassa, mitä tänään on tullut vastaan."

Hupaisia bugeja

Testaajana saa välillä käyttää luovuutta etsiessään mielekkyyttä omasta työstään. On hirveän masentavaa etsiä virheitä muiden luomuksista, vääntää kättä siitä että nämä ongelmat ovat ihan oikeasti ongelmia, ja esiintyä pessimistinä kun arvioidaan projektin mahdollisuuksia päästä maaliin sovitussa aikataulussa.

Työssään voi kokea aidosti onnistuvansa, kun löytää aikaisessa vaiheessa vakavia virheitä, joiden korjaamiseksi palaveerataan, järjestellään töitä, huokaillaan raskaasti ja tehdään pitkää päivää. Silloin voi riemuita siitä, että mitä varhaisemmassa vaiheessa virhe löytyy, sitä pienempi sen vaikutus on työmäärään ja projektin aikatauluun, jos se vain osataan käsitellä tilanteen vaatimalla tavalla. Ja jos projektin aikataulu viivästyykin, niin sen kanssa on kuitenkin sitä helpompi elää, mitä aikaisemmin tieto asiasta saadaan.

Bugit kun eivät häviä silmät ummistamalla. Tuotantoympäristössä sama virhe voisi aiheuttaa pr-katastrofin niin järjestelmän tilanneelle asiakkaalle kuin sen toteuttaneelle ohjelmistotalollekin.

Toisaalta on kuitenkin hirveän hyvä asia, että tällaisia isoja show stoppereita ei tule ihan joka projektissa vastaan ollenkaan. Silloin voi iloita siitä, että määrityksessä ja suunnittelussa on onnistuttu riittävän hyvin, ja koodarit ovat saaneet keskittyä työhönsä. Testaajan rooliksi jää motkottaa pikkuasioista. Vaikka käyttäjän kannalta monet niistäkin ovat oikeastaan melko isoja asioita.

Joskus ohjelmistovirheistä on helppo löytää myös oma huumoriarvonsa. Usein nämä liittyvät bugeihin, jotka eivät varsinaisesti häritse itse prosessin läpi viemistä, mutta tarkkasilmäinen huomaa että jotain tapahtuu toisin kuin pitäisi. Nauraminen on tietysti sitä helpompaa, mitä kauempana tulevaisuudessa julkaisuajankohta siintää, mutta toisaalta epätoivon hetkilläkin nauraminen saattaa tehdä hyvää.

Kieliversiot ovat perinteisesti asia, jossa jotain pientä unohtuu, ja lopputulos voi näyttääkin sitten yllättävän hassulta. Myös esimerkiksi aikaleimat ja muut automaattisesti luotavat tiedot saattavat elää aivan omaa elämäänsä, samoin kuin vaikkapa tilaisuuksiin liittyvät kellonajat tilaisuuksia siirreltäessä ja kopioitaessa. Joskus kaikkien kenttien sisällöt eivät tallennu oikein, tai tekstissä olevat skandit hajoavat yllättäen.

Yksi hupaisimmista koskaan kuulemistani bugeista oli tapaus, jossa rajapintahaku tyhjensi tietokannan joka yö, mutta haki uudet tiedot vain arkipäiviksi. (Tosin tämän bugin löytyminen tai syyn jäljittäminen tuskin oli hupaisaa kenestäkään prosessiin osallistuneesta.) Myös testattavan ohjelmiston hitaus ja sitkeät sovellusvirheet herättävät joskus ajatuksen, että pitäisikö brändätä slow-food-henkinen ajatus hitaista ohjelmistoista, jotka kannustavat ihmisiä irrottautumaan tietokoneistaan ja kännyköistään, nauttimaan rauhassa aamukahvit, käymään lenkillä ja kohtaamaan toisensa kasvokkain. Parantaisiko se meidän elämänlaatuamme enemmän kuin jatkuva toiminnan tehostaminen?

Testaamisen mielekkyydestä

Joskus kuulee ihmettelyä, miten kukaan voi haluta olla ohjelmistotestaaja. Sellaiselle, joka on joutunut muun työn ohessa kliksuttelemaan läpi liudan jonkun muun naputtelemia testitapauksia testaus varmasti näyttäytyykin tylsänä ja aikaavievänä tehtävänä, josta on vaikea sanoa, turhauttaako enemmän jos kaikki menee läpi, vai jos mikään ei toimi kunnolla.

Tämä on kuitenkin hyvin kapea näkökulma testaukseen. Hyvin tehty ohjelmistotestaus saattaa alkaa jo myyntivaiheessa kun mietitään, kuinka työläitä asiakkaan toiveet ovat täyttää. Testausnäkökulma on avuksi myös luotaessa ohjelmistomääritystä, sillä yksi keskeisimpiä hyvän määrityksen ominaisuuksista on että sen perusteella voi testata, täyttääkö ohjelmisto sille asetetut vaatimukset. Testaussuunnittelua on mahdollista käyttää myös toteutuksen tukena, sillä testitapaukset saattavat tarjota paitsi konkreettisen ja selkeästi jäsennellyn tavan lähestyä määritystä, myös eräänlaisen muistilistan poikkeustilanteista, joista ohjelmiston on selviydyttävä vaikka määritys ei niitä käsittelekään.

Toki testaustehtävien suorittaminen on välillä myös suunnattoman tylsää. Mutta harva työnkuva on pelkkää hupia. Siksi kai meille työstä maksetaan, että olemme hetkittäin valmiita tinkimään omasta mukavuudestamme saadaksemme jonkin tärkeän tehtävän tehdyksi. Testauksen tehtävä on suojella liiketoimintaa niiltä katastrofeilta, joita bugit voivat aiheuttaa, eikä sankaritekojenkaan tekeminen ole pelkkää riemua.

Testaamisen mielekkyyteen voi myös vaikuttaa. Testitapauksia voi suunnitella niin, että niiden läpikäynti on ennemminkin uteliaisuutta herättelevä kuin uneliaisuutta aiheuttava kokemus. Automatisointi saattaa joskus pelastaa tekemästä niitä puuduttavimpia tehtäviä. Mielekkyyden luominen ja ylläpitäminen testauksessa lieneekin yksi niistä testauksen tehtävistä, joilla ammattilaiset erotellaan harrastelijoista, ja joissa kovimmallakin asiantuntijalla on aina mahdollisuuksia kehittyä vielä paremmaksi.