Kuinka testaus kannattaa rakentaa - oppeja tutkivan testauksen työkurssilta vol 1

Minulla oli ilo päästä osallistumaan Maaret Pyhäjärven järjestämälle Tutkivan testauksen työkurssille. Kerään päivästä käteen jääneitä ajatuksia muutamaankin blogipostaukseen, joita toivoakseni saan puhtaaksikirjoitettua vielä lähipäivinä. Tarkoitus ei ole referoida koulutusta vaan jäsentää omia ajatuksia aiheen tiimoilta, eli tekstit ovat pitkälti omaa tulkintaani ja sen ympärille kietoutuvia ajatuksiani.

Kurssi oli rytmitetty niin, että lyhyitä teoriasessioita seurasi aina lyhyt paritestaussessio, jonka tulokset purettiin lyhyesti ennen siirtymistä seuraavaan teoriasessioon. Työskentelytapana tämä oli erinomainen, vaihtelu piti hyvin hereillä ja tekeminen konkretisoi läpikäytyjä asioita. Lisäksi paritestaus soi mahdollisuuden oppia parin tapaa testata, mikä toi mainion lisän kurssin antiin. Suosittelenkin lämpimästi kurssia kenelle tahansa testauksesta kiinnostuneelle.

Testasimme FreeMind-sovellusta, joka on ilmainen Java-pohjainen ideakarttatyökalu. Kukaan kurssille osallistunut ei ollut käyttänyt sitä aikaisemmin, mutta osalla oli kokemusta muista vastaavista sovelluksista.

Ad hoc -testaus

Ensimmäinen testisessiomme oli ad hoc -testausta. Saimme 25 minuuttia aikaa tutustua sovellukseen parhaaksi katsomallamme tavalla. Koska käytettävissä olevan ajan puitteissa ei ollut mielekästä lähteä tutustumaan dokumentaatioon, lähdimme yksinkertaisesti kokeilemaan, miten järjestelmä toimii. Tähän on oleellisesti kaksi mahdollista lähestymistapaa.

• Miettiä, mihin sovellusta on tarkoitus käyttää, ja lähteä kokeilemaan, kuinka hyvin se tämän tarpeen täyttää
• Katsoa, mitä toimintoja käyttöliittymästä löytyy, ja lähteä kokeilemaan, mitä ne tekevät

Ad hoc -testaus on hyvä tapa lähteä tutustumaan uuteen testauskohteeseen. Kun testaajalla ei ole juurikaan tietoa testattavasta toiminnallisuudesta, hän on vapaampi tekemään havaintoja. Esimerkiksi käytettävyyteen liittyvät omituisuudet jäävät ehkä helpommin kiinni, jos käyttäjän näkökyky ei ole ohjeiden ja määritysten tuomien odotusten rajoittama - useinhan loppukäyttäjäkään ei ole speksiä koskaan nähnyt. (Tämä ei tietenkään varsinaista käytettävyystestausta korvaa, mutta voi silti olla yksi kustannustehokas tapa parantaa käytettävyyttä.) Myös määrityksen lukeminen testausnäkökulmasta on helpompaa, jos on saanut jo hieman pyöritellä testattavaa järjestelmää.

Huono puoli ad hoc -testauksessa on, että kun toimintaa ei fokusoida millään tavalla, ei ole mitään takeita siitä, että sillä saavutettasiin relevantteja havaintoja. Keskeisiä toiminnallisuuksia saattaa jäädä testaamatta kokonaan, jos ne eivät ole käyttöliittymässä riittävän ilmeisesti tyrkyllä, ja testauksesta raportointi (muuten kuin löytyneiden bugien osalta) on vaikeaa. Lisäksi riski sille, että bugiraporttien joukosta löytyy käyttäjän virheestä tai ymmärtämättömyydestä johtuvia ihmeellisyyksiä, on suurimmillaan kun järjestelmää vain käydään summittaisesti läpi.

Myös käyntiin pääseminen uuden järjestelmän kanssa kestää jonkin aikaa, kun testaaja joutuu pohtimaan, mitä sen kanssa voisi yrittää tehdä ja mihin sitä voisi haluta käyttää, mutta tätä pidän itse väistämättömänä osana testausta. Oppiminen on prosessi joka vie aikaa, ja tehdäkseen hyvin testausta on opittava ja havainnoitava testattavaa kokonaisuutta. Ad hoc -testaus on siis parhaimmillaan testaukseen valmistautumista, ensivaikutelman hakemista testauksen kohteeseen, sekä ajatusten keräämistä testauksen suunnittelun tueksi.

Tavoitteellinen tutkiva testaus

Toiseen testisessioomme saimme tehtäväksi tietyn kokonaisuuden testaamisen. Ohjeena oli puolen sivun kuvaus kokonaisuudesta, joka kertoi, miten siihen pääsi käsiksi, mihin tarkoitukseen se oli rakennettu, sekä listasi siihen kuuluvat keskeisimmät toiminnallisuudet.

25 minuuttia kului nopeasti, ja vaikka toiminnallisuus oli meille uusi, pääsimme heti täysipainoisesti käsiksi työhön. Toki ohjelman toimintalogiikka oli tullut jo edellisen testisession yhteydessä hieman tutuksi.

Toiminnallisuus oli sen verran keskeneräinen, että paritestaus sujui varsin jouhevasti toisen testatessa ja toisen kirjoittaessa ylös havaintoja. Bugeja löydettiin lähes kaksinkertainen määrä edelliseen testisessioon verrattuna, ja tuntuma oli että ne myös olivat käytön kannalta relevantimpia.

Tutkivan testauksen etuja on useita. Tekniikkana se minimoi testaussuunnitteludokumentaation tarpeen viemättä kuitenkaan testaukselta suunnitelmallisuutta ja kurinalaisuutta. Näin vähäinen käytettävissä aika saadaan käytettyä mahdollisimman tehokkaasti, painottaen testausta eikä testausta ohjaavan dokumentaation luomista ja ylläpitämistä. Tutkiva testaus on myös hauskaa, se auttaa testaajaa pysymään valppaana ja tekemään siten myös sellaisia huomioita, joita suunnitteluvaiheessa ei ole osattu ennakoida.

Testaus käyttötapauksia (tai testitapauksia) vasten

Kolmanteen testisessioon saimme taas uuden rajatun kokonaisuuden testattavaksi. Tällä kertaa testauksen tueksi annettiin kahden sivun mittainen vaatimusmääritys, joka oli kirjoitettu luettelemalla kokonaisuuden keskeiset toiminnallisuudet sekä kuvaamalla askeleittain niistä jokaisen käyttö.

Kuten odottaa saattoi, mitä orjallisemmin testaajat seurasivat määritystä, sitä vähemmän bugeja löytyi. Määrityksessä kuvatut toiminnot pystyi kaikki viemään läpi virheittä. Kuitenkin niiden ympärille oli rakennettu käyttöliittymään yhtä jos toista, jonka käyttötarkoitus ei ollut käyttäjän näkökulmasta ollenkaan itsestäänselvä, eikä niiden kokeileminen vakuuttanut siitä että toiminnot olisivat valmiita. Kaiken lisäksi listan loppupäässä kuvattiin toiminnallisuuksia, joiden käyttäminen teki testimateriaalista oleellisesti monimutkaisempaa, ja täten tiettyjä listassa aikaisemmin kuvattuja toimintoja olisi syytä testata uudelleen listan läpikäymisen jälkeen. Tähän ei kuitenkaan testisession antaman ajan puitteissa ollut mahdollisuutta. Kenties testaus olisikin kannattanut tehdä takaperoisessa järjestyksessä.

Todettiin, että tällaista dokumettia voi käyttää testauksessa hyödyksi muutamallakin tavalla

• Dokumentti kuvasi keskeisten toimintojen käytön, joten se toimi tapana perehdyttää testaaja testattavaan kokonaisuuteen.
• Tällaista dokumenttia voisi jopa käyttää rajaamaan testauksesta pois dokumentin kuvaamat toiminnot. Työnsä vakavasti ottava kehittäjä on todennäköisesti testannut ne jo. (Pidemmän määrityksen kanssa näin ei luonnollisestikaan voida toimia. Tässä tapauksessa dokumentti näytti siltä kuin se olisi kirjoitettu pintapuolisen testauksen ohessa ikään kuin käyttöohjeeksi toiminnoille.)
• Mikäli dokumentti kuvasi korkeimman prioriteetin toiminnallisuudet, sitä voisi käyttää eräänlaisena muistilistana, johon palata myöhemmässä testauksen vaiheessa sen tarkistamiseksi, onko oleellisimmat toiminnallisuudet testattu riittävän perusteellisesti ja riittävän myöhäisessä vaiheessa. Esim. regressiotestauksen suunnitteluun se voisi olla toimiva työkalu.

Samat hyödyt voitaisiin kuitenkin saavuttaa muillakin tavoin. Esimerkiksi demosessiossa, jossa kehittäjä esittelee testaajalle rakentamansa toiminnallisuuden, testaaja saa sekä perehdytyksen toiminnallisuuteen että käsityksen siitä, mitä toimintoja kehittäjä on testannut. Tällaisen istunnon lisäetuna olisi testaajan mahdollisuus esittää kysymyksiä, jotka voisivat johtaa joko testaajan entistä parempaan testaukseen, tai siihen että kehittäjä löytäisi toteutuksestaan korjattavaa jo ennen varsinaisen testauksen alkua.

Mitä jäi käteen

Sekä päivän aikana käyty keskustelu että käytännön harjoitukset tukivat käsitystäni, että tehokkain tapa löytää bugeja on nimenomaan tavoitteellinen tutkiva testaus. Tämä ei kuitenkaan tarkoita, että tutkiva testaus olisi ainoa tekniikka, jota kannattaa käyttää. Ad hoc -testauksella on myös oma arvonsa haluttaessa löytää järjestelmään uusia näkökulmia. Lisäksi määritettyjen toiminnallisuuksien läpikahlaamiseen sekä työn priorisointiin myös rakenteeltaan melko perinteinen testaussuunnittelu puolustaa paikkaansa, kunhan suunnittelu tehdään järkevästi, riittävän karkealla tasolla. Yksityiskohtaiset ohjeet kun toimivat kuin laput silmillä, vaikeuttaen muiden asioiden huomioimista.

Myös paritestaus sekä testauksen jakaminen eri teeman ympärillä pyöriviin sessioihin vaikuttivat toimivilta tavoilta hakea tehoja testaukseen.

Myös testauksen automatisoinnista keskusteltiin lyhyesti. Erityisesti yksikkötestipuolella automatisointi on erinomainen väline, mutta järjestelmätestauspuolella sen käyttö on jossain määrin kyseenalaista. Automaation rakentaminen vie moninkertaisen ajan verrattuna manuaaliseen testaukseen, ja automaattitestien ylläpitäminen järjestelmän muuttuessa on työlästä. Tämä ei kuitenkaan tarkoita, etteikö automaattitesteilläkin voisi olla paikkansa myös järjestelmätestausvaiheessa. Kaikkea ei aina ole edes mahdollista testata käsin käyttöliittymästä, ja lisäksi joskus testiautomaatiota on mahdollista pienin variaatioin monistaa tavalla, joka parantaa testikattavuutta tai helpottaa testimateriaalin luomista niin, että testien kirjoittamiseen käytetty aika saadaan ainakin osin kompensoitua niiden ajamisen nopeudella. Lisäksi suhteellisen muuttumattomien kokonaisuuksien testauksen automatisointi voi tuoda regressiotestaukseen merkittävän avun. Oleellista automatisoinnissa onkin analysoida, missä siitä saavutetaan suurin hyöty, sekä tietenkin ymmärtää, ettei se yksin riitä testattaessa järjestelmiä, joita ihmisten on tarkoitus käyttää.

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.