Hei, me mobattiin!

Tänään teimme vihdoin sen mistä on silloin tällöin varovasti keskusteltu: kokeilimme mob-koodausta. Olin kesällä lukaissut Maaret Pyhäjärven ja Llewellyn Falcon kirjan mobbauksesta, ja syksyni on alkanut testiautomaatiopainotteisesti. Oma ohjelmointiosaamiseni on hieman hataraa siihen, että saisin itsekseni aikaan ylläpidettävää ja helposti laajennettavaa automaatiota työkaluksi valitsemallamme Canopylla. Se on vieras myös suurimmalle osalle tiimistä. Koska automaatio on meidän kaikkien yhteinen asia, tuntui luontevalta kokeilla mobbausta aiheen tiimoilta.

Olin ehtinyt rakentaa omaan käyttööni jonkin verran ei-niin-kovin-kaunista automaatiokoodia testidatan luomiseen, ja samalla jäsentää ajatuksiani sen suhteen, mitä tavoitteita minulla on automaation suhteen. Lisäksi Canopyn paremmin tunteva kehittäjä oli rakentanut jonkin verran automaatiota. Näiden pohjalta lähdimme liikkeelle tavoitteena oppia käyttämään Canopya sekä tietenkin luoda sitä ylläpidettävää automaatiota.

Mobbaus on meille kaikille käytännössä uutta, eikä se vielä ensimmäisellä sessiolla muodostunut täysin luontevaksi. Tehtävän yksinkertaisuus ja suuret erot osaamisessa Canopyn käyttöön näkyivät myös eroina siinä, miten paljon kukakin oli äänessä. Vaikutelmaksi jäi, että kehittäjät kokivat tekemisen hieman hitaaksi tällä tekniikalla, ja muutaman minuutin välein vaihtuva kirjurinpesti tuntui myös oudolta jo ihan kerralla käytettävissä olevan ajan lyhyyden vuoksi. Tämä ei selvästikään ollut rakkautta ensi silmäyksellä. Toisaalta loppukeskustelumme perusteella sessiossa oli paljon hyvää.

Positiivista oli paitsi minun automaatiotavoitteideni eteneminen, myös se, että Canopyn opettelu selvästi toi kehittäjille paljon ajatuksia siitä, miten he voisivat hyödyntää sitä omassa työssään. Todettiin, että mobbaus sopii hyvin uuden opetteluun yhdessä, ja saatiin aikaan hyvää keskustelua siitä, miten automaatiota lähdetään kehittämään ja mihin kaikkeen sitä voisi käyttää. Vaikka en edelleenkään kutsuisi itseäni automaatio-osaajaksi, kokemus lisäsi paljon myös omaa ymmärrystäni juuri niistä automaatiokoodin rakentamisen periaatteista, joista koin vielä aamulla olevani hyvin pitkälti pihalla. Keskustelu sekä ajattelun ja kirjoittamisen irrottaminen toisistaan tekee työskentelystä helpommin seurattavaa verrattuna tilanteeseen, jossa yksi perehdyttäjä tekee ja selittää tekemistään. Lisäksi oma muistijälki tulee vahvemmaksi kun saa ihan itse konkreettisesti tehdä sitä opeteltavaa asiaa.

Tällaisena suht lyhyenä sessiona mobbaus oli kuulemma myös ihan kivaa (ja sitä se oli minustakin). Ns. oikeiden töiden tekemiseen parikoodaus ja yksilötyöskentely ovat selvästi edelleen suositumpia lähestymistapoja. Nähtiin kuitenkin, että mobbaus voisi olla hyvinkin toimiva lähestymistapa erityisesti refaktorointiin, ja backlogilta löytyikin jo yksi lappu jonka tiimoilta tekniikkaa harkittiin kokeiltavan. Nyt kun ensimmäinen askel on otettu ja mobbausta on kokeiltu, kynnys seuraavan session järjestämiseen on varmasti jo matalampi.

Mobattavien tehtävien valinta tälle porukalle vaikuttaa kuitenkin haasteelliselta. Kun mobbaus itsessään on uutta ja ihmeellistä, tekniikan opettelun kannalta olisi hyvä että käsillä oleva tehtävä ei olisi kovin monimutkainen. Tämän päivän perusteella tuntuu kuitenkin siltä, että yhteisen ajan käyttäminen helppojen tehtävien parissa aiheuttaa monilla meistä jonkinasteista turhautumista. Tämän ongelman voittamiseen ei liene muuta lääkettä kuin pitää sessiot suhteellisen lyhyinä niin kauan kuin tekniikka ei ole luontevaa. Lienee myös parasta silmäillä mobbauksesta kertova kirja läpi uudelleen nyt kun aihe on itselle hieman konkreettisempi.

Kuka vaan osaa testata - tai puhua kiinaa

Testaajana törmää hyvin monenlaisiin käsityksiin omasta ammatistaan. Toki moniin muihinkin ammatteihin yhdistetään eri tavoin hupaisia kuvitelmia siitä, mitä niiden taitajat työkseen tekevät, mutta itse en ole aikaisemmin työskennellyt tehtävässä, jonka sisällön samassa työpaikassa työskentelevät ihmiset näkisivät niin eri tavoin.

Kaikki osaavat testata

Yksi yleinen testaukseen liittyvä ajatus on, että kuka tahansa osaa testata. Tämä pitää ehdottomasti paikkansa, jokainen joka osaa käyttää tietokonetta, osaa myös jossain määrin testata siinä käyttämiään ohjelmia.

Osaamisen tasoissa on kuitenkin eroja. Kuka tahansa ei osaa käydä systemaattisesti läpi ohjelmistoa, keksiä erilaisia tapoja koetella sen tarjoamien toiminnallisuuksien rajoja ja väärinkäyttää sitä. Kuka tahansa ei osaa kertoa kohtaamistaan ongelmista tavalla, joka auttaa kehittäjää virheen löytämisessä. Hyvä testaus vaatii opiskelua, harjoitusta ja ajatustyötä.

Vähän niin kuin melkein kuka tahansa osaa ranskaa, jos kielitaidoksi riittää lukea ääneen ruokalistaa. Kuitenkaan ranskankielisen tekstin analysointi tai luontevan keskustelun käyminen ei luonnistu opettelematta.

Testaajat osaavat mm. suorituskykytestausta, käytettävyystestausta ja tietoturvatestausta

Moni testaaja varmasti hallitsee useampia testaustyyppejä. Niiden oppiminen ei kuitenkaan ole testaajalle sen helpompaa kuin ranskalaiselle on oppia portugalia, kiinaa tai arabiaa. Jos on kiinnostunut kielistä, niitä voi hallita useita. Jos osaa jo jotakin opeteltavan kielen sukulaiskieltä, helpottaa se niin kieliopin kuin sanastojenkin sisäistämistä, mutta silloinkin vaatii paljon harjoitusta ennen kuin voi sanoa olevansa hyvä siinä.

Jos et ole valmis palkkaamaan .NET-kehittäjäksi henkilöä, joka kertoo osaavansa html:ää, miksi luottaisit tietoturvatestauksen sellaisen henkilön käsiin, joka ei ole perehtynyt siihen kunnolla?

Laatuongelmista päästään, jos testaus suunnitellaan tarkemmin, automatisoidaan ja raportoidaan tarkemmin

Testaaja ei valitettavasti voi tehdä ohjelmistosta laadukasta, siihen tarvitaan kehittäjä. Testaajan toimilla toki voi olla paljonkin merkitystä siinä, miten laadukas lopputuloksesta tulee, vähän niin kuin kustannustoimittajan palautteella voi olla paljonkin merkitystä julkaistavan kirjan laadulle. Kirjailija on kuitenkin vastuussa syntyvästä tekstistä, samoin kuin kehittäjä on vastuussa toteutuksensa tuloksesta.

Testauksen suunnittelu on tärkeää testaamisen suuntaamiseksi oikeisiin asioihin, testauksen automatisointi on oiva työkalu joihinkin tilanteisiin, ja laadukas raportointi on korvaamatonta haluttaessa tietoa siitä, onko testaus ollut riittävän kattavaa ja onko järjestelmä riittävän valmis. Nämä ovat kuitenkin kaikki tehtäviä, joihin lisäpanosten laittaminen saattaa nostaa kustannuksia ja laskea laatua.

Testauksen yksityiskohtainen suunnittelu voi sokeuttaa testauskattavuuden puutteille. Jos testaaja keskittyy testitapausten täsmälliseen suorittamiseen, on hänen vaikea huomata niiden ulkopuolelle jääviä asioita. Myös itse suunnittelu saattaa kohdistua kapeammalle alueelle, jos sitä tehdessä keskitytään yksityiskohtiin eikä karkeamman tason näkökulmien etsimiseen.

Automatisointi on korvaamaton apu tilanteissa, joissa testataan asioita joita ei ole mielekästä tai mahdollista käsin testata, tai haluttaessa välttyä toistamasta käsin joitakin muuttumattomia tapahtumakulkuja. Sen rakentaminen ja ylläpitäminen vie kuitenkin paljon aikaa. Tämä voi tarkoittaa joko merkittävää kustannusten nousua tai merkittävää testauskattavuuden pienenemistä. Automatisointi voi myös johtaa prosessien läpiviemiseen aina keskenään identtisillä testisyötteillä. Ne, jotka saavat henkilökohtaista tyydytystä testien täydellisestä toistettavuudesta, voivat kokea tämän hyvänä tilanteena. Me, joille kokemus on osoittanut mitä ihmeellisimpien bugien nousevan esiin sattumanvaraisella testisyötteiden varioinnilla, pidämme tätä testauksen luotettavuutta heikentävänä tekijänä.

Mitä testauksen raportointiin tulee, siihen on pääpiirteissään kolme vaihtoehtoa.

Ajankäytöllisesti yksinkertaisin tapa raportoida on tarjota tilastoja bugeista ja testitapausten läpäisyprosenteista. Voidaan tarjota myös testitapauslista PASS/FAIL-tiedoin. Jos testitapaukset ovat kovin yksityiskohtaisia, niitä on todennäköisesti melko paljon, jolloin tällaisen listan informatiivisuus on hyvin kyseenalaista.

Toiseksi kevyin tapa raportointiin on sopia muutamia seurattavia asioita, joista tiimi saa antaa fiilispohjaisia arvioitaan, kuinka vakuuttavalla tolalla asiat ovat.

Jos raportilta halutaan jotain enemmän, täytyy huolella miettiä, mitä tietoa siitä olisi tarkoitus saada ulos. On myös hyväksyttävä se, että yksityiskohtaisen, eksaktin, luettavan ja relevantteja asioita esiin nostavan raportin koostamiseen saa helposti päivänkin aikaa kulumaan. Tämä aika on lisäkustannus, ja usein myös pois jostakin muusta.

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

Regressiojumppaa

Silloin tällöin peruslaiskalle iskee tarve kuntokuurille. Eihän kroppa pysy kunnossa, jollei siitä pidä vähän huolta. Silloin saattaa löytää itsensä surffaamasta kuntokeskusten tarjontaa tai ohjeita treeniohjelman rakentamiseen itse. Yksi vaihtoehto on miettiä, mitkä osat kehosta kipeimmin kaipaavat kohennusta, ja rakentaa sitten joogaohjelma, joka parhaiten tukee juuri näiden alueiden ylläpitoa.

Hathajooga tarjoaa runsaan valikoiman erilaisia liikkeitä, joilla jokaisella on omat positiiviset vaikutuksensa. Ohjelma koostetaan keräämällä joukko liikkeitä ja laittamalla ne sopivaan järjestykseen. Suunnittelussa huomioon otettavia asioita ovat ainakin:

• Mikä on treenauksen tavoite, eli millaisia asioita on tarpeen sisällyttää treeniin.
• Mitkä liikkeet sopivat lämmittelyyn, mitkä taas vaativat lämmittelyä ennen kuin niitä voi tehdä.
• Vastaliikkeet. Monien voimakkaiden venytysten jälkeen on hyvä tehdä vastaliike, jotta keho saa optimaalisella tavalla kuormitusta.
• Flow, missä järjestyksessä liikkeiden suorittaminen tuntuu mahdollisimman luontevalta.
• Harjoitukseen kerralla käytettävissä oleva aika, sekä kuinka usein se on tarkoitus suorittaa.
• Harjoitukseen käytettävissä oleva tila.
• Henkilökohtaiset mieltymykset, eli mikä on kivaa.

Kun ohjelma sitten on rakennettu, sitä suoritetaan suunnitelman mukaisella tahdilla. Jos käy niin hyvin, että kunto pääsee kohenemaan, tai tavoitteita on jostain muusta syystä tarpeen tarkastella uudelleen, ohjelmaa kehitetään lisäämällä, poistamalla tai muokkaamalla siihen kuuluvia liikkeitä.

Prosessi on yllättävän lähellä regressiotestauksen suunnittelua. Myös siinä mietitään tavoitteet, eli mitkä ovat ne asiat, joiden toimivuus on tarpeen varmistaa. Lisäksi on tarpeen pohtia, missä vaiheissa regressiotestit suoritetaan. Ylläpitovaiheessa pitäisi olla selvää, että regressiotestikierros tehdään ennen jokaista julkaisua. Testattavan järjestelmän muuttuessa myös regressiotestien sisältöä voi joutua tarkastelemaan kriittisesti. Regressiotestaukseen sisällytettävien testien laajuuteen vaikuttaa testaukseen käytettävissä oleva aika sekä budjetti. Nämä asiat vaikuttavat myös silloin, kun regressiotestausta automatisoidaan, sillä myös automatisointi vie aikaa, ja automaattitestauksenkin tulokset on analysoitava. Jos taas testit suoritetaan käsityönä, tehtävän mielekkyyden ylläpitämisen kannalta on hyvä sisällyttää suunnitteluun myös ajatus siitä, miten siitä saisi jollain tapaa kiinnostavaa testaajalle. Tehokkuutta ja mielekkyyttä lisää myös testien järjestäminen tavalla, jolla edeltävät testitapaukset mahdollisimman luontevasti valmistelevat seuraavien testitapausten alkuehdot. Joskus voi olla tarkoituksenmukaista sisällyttää suunnitelmaan myös luodun testimateriaalin poistaminen.

Korkean tason tavoitteena joogaajalla on kehon toimintakunnon ylläpito, regressiotestaajalla taas testattavan järjestelmän toimivuuden ylläpito. Testi ei toki itsessään toimivuutta paranna, vaan se vain paljastaa ne paikat, jotka ovat ajan myötä päässeet rupsahtamaan ja kaipaavat nyt tarkempaa huomiota. Vähän niin kuin aloittelevan kuntoilijan lihaskipu paljastaa paikat, jotka ovat päässeet liian vähällä sohvaperunan elämässä.

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