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ää.

Ä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.