Mene meetupiin!

Osallistuin viime torstaina testausaiheiseen meetupiin. Tapahtuman otsikkona oli Exploring Allure. Googlaamattakin oli selvää, että kyse tuskin olisi työkalusta, jonka ottaisin ensi viikolla käyttöön työssäni. Tämä olisi sitä toisenlaista testaamista, jota en koe osaavani.

Vielä samana päivänä mielessä risteili ristiriitaisia ajatuksia: Siitä ei varmaan ole suoraa hyötyä työni kannalta. Siellä on vieraita ihmisiä. En tiedä, mitä siellä tapahtuu. Se vie matkoineen ihan koko illan. En oikeastaan edes tiedä, mihin olen menossa. Entä jos en ymmärrä siitä yhtään mitään?

Menin kuitenkin, koska tässä oli tarjolla helppo tapa päästä juttelemaan muiden testaajien kanssa, ja ajattelemaan jotain vähän uudenlaista. Jos ei koskaan poistu mukavuusalueeltaan, on kovin vaikea oppia mitään uutta.

Löysin itseni tutkimasta testausraportointityökalun käyttöä mob-koodauksen keinoin. 

Ryhmä toimi tosi hyvin yhteen siihen nähden, että olimme aika vieraita toisillemme. Omaa epävarmuutta helpotti kovasti, ettei kukaan muukaan osannut asiaa täydellisesti. Ratkaisut löytyivät keskustellen, ja lopulta tuntui ettei ollut juuri väliä, kuka oli navigaattorin tai driverin roolissa. Tehtävänasettelu oli riittävän kapea, ettei päämääristä tarvinnut vääntää kättä, ja päämäärät riittävän yksinkertaisia, että niiden toteutuksessa pysyi varsin hyvin kärryillä, vaikka asia oli alkuun vierasta.

Kun tekee jotain uutta, oppii jotain uutta, jos vain antaa itselleen mahdollisuuden oppia. Joskus opit liittyvät yllättäviin asioihin, tai niistä saavuttaa hyötyjä yllättävissä yhteyksissä. Mitä enemmän ymmärtää itselleen vieraiden roolien tekemistä, sitä helpompaa on luoda siltoja niitä kohti, osallistua keskusteluihin, esittää kysymyksiä, tuoda ymmärrettävästi esiin omia näkökulmiaan, saada rakennettua jotain uudenlaista. Siksi hyötyjä saa myös sellaisten asioiden oppimisesta, joille ei heti keksi käytännön sovelluksia omassa tekemisessään. Ja pitkällä tähtäimellä omakin rooli voi muuttua tavoilla joita ei juuri nyt näe mahdolliseksi.

Oppiminen myös tapahtuu tavallaan portaittain, aina aikaisemman tiedon päälle, ja sitä kautta samojenkin asioiden läpikäynnistä voi eri kerroilla oppia eri asioita. Vieraat asiat muuttuvat vähin erin tutummiksi. Askel kerrallaan, vaikka ne askelet olisivat ajallisesti kaukanakin toisistaan.

Session jälkeen istahdimme osalla porukkaa vielä yksille juttelemaan. Ilmeni, että joukossa oli yksi kehittäjä joka ei edes asunut Suomessa, sekä yksi matkaopas. Että ehkä testaajana on turha tuntea itseään ulkopuoliseksi testaajien meetupissa, vaikka käsiteltävä aihe ei osuisi ollenkaan omalle osaamisalueelle.

Konferenssimuistiinpanoja - ETC2017

Sain ensimmäistä kertaa elämässäni mahdollisuuden osallistua kansainväliseen testausalan konferenssiin, kun European Testing Conference 2017 järjestettiin Helsingissä. Kiertävä konferenssi on mainio konsepti, koska se tarjoaa mahdollisimman monelle joskus mahdollisuuden osallistua murehtimatta matkabudjettia, ja koska tämän tilaisuuden ainutlaatuisuus on hyvä perustelu osallistua silloin kun konferenssi on lähellä. Syrjäisestä sijainnista huolimatta niin puhujia, osallistujia kuin vapaaehtoisiakin oli saatu houkuteltua mukaan eri puolilta maailmaa. Huonoin puoli tapahtumassa olikin oikeastaan se, miten kiinnostava ohjelmasta oli saatu rakennettua. Useampaankin otteeseen olisi ollut mukavaa pystyä jakautumaan useampaan tilaan yhtä aikaisesti. Nyt jäi monta lupaavalta vaikuttanutta esitystä kuulematta.

Hienoa tapahtumassa oli myös se, että siihen oli tuotu mukaan voimakas kehittäjänäkökulma. Minulle henkilökohtaisesti tässä kiinostavinta oli Kevlin Henneyn keynote, joka oli monitahoisuudessaan, tärkeydessään ja viihdyttävyydessään kenties paras puhe mitä olen ikinä ollut kuuntelemassa. Sain myös tilaisuuden poistua hetkittäin mukavuusalueeltani kuuntelemalla puheita testiautomaatiosta kehittäjänäkökulmasta, mikä auttoi jäsentämään omia ajatuksia aiheesta. Positiivista oli luonnollisesti myös se, että kehittäjät pääsivät kuulemaan testaajien ajatuksia. Kun puolin ja toisin ymmärrämme toisiamme paremmin, kenties myös yhteistyö sujuu entistä paremmin. Tästä lisääntyvästä ymmärryksestä pysäyttävä esimerkki oli Alastair Smithin twitter-purkaus Fiona Charlesin keynoten myötä tulleesta oivalluksesta, miten erilainen testaajan asema on ohjelmistoalalla kehittäjän asemaan verrattuna.

Omaan työhöni liittyen hyödyllisintä olivat epäformaalimmat osuudet ohjelmassa. Lean Coffee tarjosi mahdollisuuden käydä lyhyitä keskusteluja pöytäkunnan mieltä kaihertavista asioista, ja tässä sain ihan konkreettisia ideoita, mitä kokeilla ja miten kehittää osaamistani. Open Space kului mobtestaten, tarkkaillen paritestausta, sekä keskustellen testaajan roolista osana mobkehittämistä. Myös virallisempaan ohjelmaan kuului monta hyödyllistä sessiota. Huib Schootsin tutkivan testauksen demo ja Sami Söderblomin työpaja samasta aiheesta muistuttelivat mieleen tärkeitä asioita, joilla ylläpitää kurinalaisuutta ja suunnitelmallisuutta omassa tekemisessä. Dragan Spiridonov esitteli opiskelutekniikoita (mindmap, pomodoro-tekniikka sekä focused/diffused moodit) ja miten niitä voi käyttää testaajan työn jäsentämisessä ja tehostamisessa.

Tärkeitä teemoja, jotka jäivät mieleen pyörimään:

Epätäydellisyyden hyväksyminen. Kevlin Henney muistutti, että ihmiset tekevät virheitä. Siksi on tärkeää, että ainakin tärkeimmissä asioissa mikään ei ole vain yhden ihmisen tekemisten varassa, vaan joku muu tarkistaa, että asiat on tehty oikein. Kuitenkin siitä huolimatta virheitä tapahtuu, ja siksi täytyy myös varautua katastrofeihin. Liz Keogh jatkoi aiheesta tuomalla esiin, että työmme luo eniten arvoa silloin kun teemme uusia ja monimutkaisia asioita, joihin liittyy aina myös suuria riskejä.

Etiikka ja vastuu. Kevlin Henney tarjosi muutamia esimerkkejä, miten merkittäviä seurauksia virheillä voi olla. Ajallemme keskeistä on valtavien datamäärien analysointi, ja siinä tehdyt virheet esimerkiksi arvioitaessa valtion velan merkitystä talouden kehittymisessä voivat vaikuttaa poliittisiin päätöksiin ja sitä kautta negatiivisesti miljoonien ihmisten elämään. Eettisiä ongelmia ei myöskään synny vain virheiden kautta. Esimerkiksi facebookin algoritmit muovaavat meitä ihmisinä, ja siksi ohjelmistokehityksessä on syytä pohtia oman työn eettisyyttä: mitkä ratkaisut parantavat maailmaa, mitkä toimivat päinvastoin. Fiona Charles ja Gitte Klitgaard jatkoivat aiheesta omissa keynoteissaan. Fiona Charles toi esiin, että meidän tulisi aina ajatella niitä ihmisiä, joiden elämään rakentamamme ratkaisut vaikuttavat. Nämä ihmiset ovat paitsi asiakkaita ja käyttäjiä, myös ihmisiä joiden asioihin järjestelmät liittyvät - vaikkapa potilaita, oppilaita tai kansalaisia. On tärkeää huomata, että he ovat olemassa, ja tuntea empatiaa heitä kohtaan. Gitte Klitgaard puhui rohkeuden ja aitouden puolesta, kehottaen taistelemaan itselle tärkeiden asioiden puolesta. Hän kertoi myös siitä, miten aitous, oman haavoittuvuuden näyttäminen ja toisten ihmisten näkeminen rohkaisee ja voimauttaa myös muita olemaan aidompia. Tällä on vaikutusta paitsi kykyymme käsitellä ongelmatilanteita työssämme, myös työyhteisöömme ja elämänlaatuumme yleisesti.

Verkostoituminen. Sain tilaisuuden keskustella monen mahtavan tyypin kanssa, ja twitterin seurattavien listani kasvoi monella nimellä. Pari käyntikorttiakin tarttui matkaan. Pääosin kohtaamiset jäivät kuitenkin aika lyhyiksi ja pinnallisiksi. Kahvitauolla esiin tullut kommentti pienimuotoisempien meetuppien hyödyllisyydestä jäi myös mieleen. Pitänee siis ryhtyä pohtimaan, minkä aiheen tiimoilta voisi itse joskus alustaa illanistujaisia.

Löydä se mitä on vaikea nähdä

Tiimillämme on pyrkimyksenä pitää kahden viikon välein retroja. Jokainen valitsee vuorollaan aihepiirin, jonka puitteissa laittaa muut täyttämään post-it-lappuja, joita ryhmitellään etsien työskentelyn kipukohtia.

Tällä viikolla pääsimme isojen kysymyksien äärelle etsimällä asioita, jotka eri vaiheissa prosessia tuottavat arvoa, hämmennystä tai ajanhukkaa. Iso tussitaulu peittyi post-it-lapuilla minulle ennennäkemättömällä tavalla.

Suurimmaksi ongelmaksi keskustelussa nousivat isot muutostyöt, joissa usein speksauskin on hieman epämääräinen. Niitä on vaikea edistää, ne vievät paljon aikaa, ja niissä on tavanomaista suurempi riski päätyä tekemään vääriä asioita.

Se, minkä itse koin erityisen mielenkiintoiseksi, oli että puhuimme tavallaan ihan samoista asioista, joilla vain pari viikkoa aikaisemmin olin perustellut testausstrategian luomista: hyödyllistä puuhasteltavaa riittää aina, joten ikäviin tai hankaliin hommiin ei välttämättä koskaan tule tartuttua ainakaan riittävällä tarmolla, jos ei ole tiettyä kurinalaisuutta omassa tekemisessä. 

Siinä missä minä testaajana tarvitsen strategista ajattelua edes nähdäkseni ne kokonaisuudet, jotka eivät mukavuusalueella pysytellen tule testatuksi, kehittäjä tarvitsee kurinalaisuutta ja strategista ajattelua jotta nuo isot ja vaikeat kokonaisuudet saataisiin pilkottua ja tehtyä pois alta. Vaihtoehto on, että niitä joko vältellään, tai edistetään vastahakoisesti mitenkuten milloin ehditään. Ja kun ympärillä tapahtuu koko ajan, rakennettava tuote saa jatkuvasti uusia ominisuuksia, pieniä parannuksia tai vähintään bugifiksejä, vältellen ja nitkutellen edistettävät kokonaisuudet helposti kasvavat, muuttuen yhä vaikeammiksi toteuttaa loppuun asti. 

Ja lopulta aika usein ne hankalimmin edistettävät asiat ovat kuitenkin tärkeitä.

Keskustelimme tavoista, joilla näiden isojen asioiden edistymistä voisi nopeuttaa, ja pohdimme syitä jotka ovat estäneet tässä onnistumista. (Ja vain pari päivää myöhemmin kävimmekin yhteistuumin pilkkomaan yhtä elefanttia.)

Jälkikäteen aloin muistella asioita, joita olen pitänyt testaajan urani suurimpina saavutuksina. Niistä lopulta aika harvat liittyvät tilanteisiin, joissa olen löytänyt bugin toteutetusta järjestelmästä. Parhaita ovat olleet hetket, kun olen keksinyt esittää kysymyksen, joka on paljastanut vältellyn aiheen. Usein ne ovat olleet asioita, jotka ovat selvästi vaivanneet kehittäjiä itseäänkin, mutta kissaa ei ole tullut nostettua pöydälle koska ei ole ollut pakko, ja muita, akuutimpia asioita on riittänyt enemmän kuin omiksi tarpeiksi. Joskus kyse on ollut asioista, jotka vain on ymmärretty eri tavoin, eikä kukaan ole pysähtynyt ajattelemaan asiaa huomatakseen ongelman laajuutta.

Kun puhutaan laadunvarmistuksesta, softan testaaminen on vain pieni osa kokonaisuutta. Vaikutuksiltaan merkittävintä on löytää niitä asioita, joita vältellään tai ei edes nähdä. Vaikeaa tästä tekee se, että testaajan näkökulmasta ne kaikki saattavat olla näkymättömiä. Kehittäjän taas voi olla vaikea nähdä juuri näiden asioiden esiin nostamista oleellisena, ne voivat tuntua joko vähäpätöisiltä tai kaikkien tuntemilta kollektiivisesti vaietuilta asioilta, mikäli niiden olemassaoloon edes kiinnitetään huomiota.

Tässä mielessä retrot ovat loistavia. Loistavia ovat myös hetket, kun löytää paljastavia kysymyksiä. Hyvä alku ovat "miten tämän voi testata", "kuka tätä käyttää", "mihin tämä vaikuttaa" ja "miksi tämä asia ei ole edennyt".

Testaajien ja kehittäjien välillä on joskus melko voimakastakin vastakkainasettelua. Itse pidän enemmän yhteistyömeiningistä. Toivon, että kehittäjät voivat nähdä minun ongelmani yhteisinä ongelminamme. Tämän viikkoinen retro konkretisoi itselleni myös sitä sinänsä aika itsestäänselvää asiaa, että myös kehittäjien ongelmat ovat minun ongelmiani. Lopultahan ne testaajan turhauttavimmat pulmat liittyvät usein juuri asioihin, joista myös kehittäjä on ollut epävarma. Meistä jokainen tekee osansa löytääkseen ja selkiyttääkseen epämääräisiä asioita. Myös minun tehtäväni on tarttua tähän työhön mahdollisimman varhaisessa vaiheessa.

Testausstrategiaa luomassa osa 1

Aloitin hiljattain uudessa työpaikassa. Siinä missä aikaisemmin olin yksi testausasiantuntija testaustiimissä, osana satojen henkien kokoista organisaatiota, nyt olen ainoa testaaja, ja muut työntekijät ovat kaikki kehittäjiä. Aikaisemmin työskentelin käytännössä vesiputousmallilla, nyt tarkoitus olisi päästä osaksi ketterää tekemistä. Ennen testasin useita tuotteita, nyt keskityn vain yhteen. Monet asiat ovat siis hyvin eri tavalla kuin edellisessä työssäni.

Testauksen näkökulmasta monet asiat ovat hyvin. Käytössä on TDD, kaikki koodi katselmoidaan, ja normaaliin työskentelyrytmiin on varattu aikaa vapaamuotoiselle toiminnan kehittämiselle sekä yhteisille retrospektiiveille. Organisaatio on testausmyönteinen, vaikka osaaminen sen suhteen on ollut jossain määrin rajoittunut tekniseen näkökulmaan. Tätä olisi nyt tarkoitus laajentaa.

Viime viikolla aloitin testausstrategian muodostamisen. Pidimme tiimin kanssa session, jossa kerroin lyhyesti, mitä testausstrategia tarkoittaa, ja sitten pureuduimme pohtimaan testauksen nykytilaa ja kehitystarpeita käyttäen työkaluna Sami Söderblomin FIT(Q)CODES-mallia. 

Selvitin jokaisen näkökulman osalta, minkä tyyppisiä asioita siihen liittyy (käyttäen pitkälti lähteenä James Bachin heuristista testausstrategiaa). Sitten tiimi sai äänestää, ovatko nämä asiat oleellisia lasilaatikko- vai mustalaatikkonäkökulmasta vai molemmista, kuinka tärkeästä kokonaisuudesta on kyse tuotteemme kannalta, ja kuinka hyvin pärjäämme siihen liittyvien piirteiden testauksessa. Sitten keskustelimme siitä, mitkä asiat ovat tästä näkökulmasta tärkeitä, ja mitkä vaatisivat enemmän huomiota. (Mustalaatikkopuolelta olin jo itse listannut näitä asioita.)

Vaikka tiimi ei ollut osannut odottaa ihan näin interaktiivista sessiota, keskustelu oli vilkasta, ja paikoin sen ohjaaminen tarkkaan suunnitelmani mukaan tuntui turhalta, niin luontevasti pohdinta eteni. Sain uusia eväitä oman testaustyöni suunnitteluun, ja esiin nousi myös joitakin tuotteen kipukohtia, joiden ratkaiseminen ei ole kiinni minun testauksestani.

Kirjasin parhaani mukaan muistiinpanot esiin nostetuista havainnoista ja listasin muutamia asioita, jotka vaativat erityistä huomiota sekä ideoita testauksen parantamiseen prosessin eri vaiheissa. Tällä mennään nyt muutama viikko, ja sitten jatkamme aiheesta etsien konkreettisempia tavoitteita ja vastuita. Sitä ennen minun olisi toki hyvä keksiä jotain uutta ajatuksia herättämään.

Tämä on varmasti hidas tapa luoda testausstrategia, mutta itse näen tärkeämmäksi tiimin yhteisen pohdinnan ja tavoitteiden etsinnän kuin nopean lopputuloksen. En myöskään näe mielekkäänä luoda testausstrategiaa vain oman työni lähtökohdista, ja vielä oudommalta tuntuisi lähteä suoraan ohjeistamaan kehittäjiä heidän työnsä tekemisessä, kun asiat ovat kuitenkin pääpiirteissään hyvin. Koen myös, että minulle yksi syy testausstrategian muodostamiseen on nimenomaan hakea eväitä yhteiseen keskusteluun. Ainoana testaajana joudun näkemään hieman vaivaa löytääkseni tiimistä tukea oman työni kehittämiseen, strategian muodostaminen ja myöhemmin sen arviointi ja eteenpäin kehittäminen tarjoaa tähän yhden työkalun.

Miten vanhemmuus kouluttaa testaajaksi

Lapset ovat pohjimmiltaan aika mainiota juttuseuraa. Parasta on päästä mukaan erilaisiin ongelmanratkaisusessioihin, joko osallistuen tai ihan vain seuraillen: miten vuosikas etsii paikkaa josta ylettyisi pinnasängyn kaiteen toisella puolella olevaan leluun, mistä kaikesta taapero voi esittää "miksi"-kysymyksen, millaisiin teknisiin pohdintoihin eskarilainen voi yltää, tai mistä löytyvät leikkiin ne tärkeät asiat, joita ei (aikuisen mielestä) löydy lelulaatikosta.

Lapset ovat taitavia muistuttamaan testaajalle tärkeistä asioista: mikään ei ole itsestäänselvää, ja aina voi löytää jonkin uuden tavan käyttää tuttuja esineitä.

Äitiydessä itsessään on myös paljon samaa kuin testaamisessa. Toisessa opitut ajattelutavat ja toimintamallit voivat tukea toista. Tässä muutamia asioita, joissa näen yhtymäkohtia:

1) Kun työt alkavat, et tiedä, mikä ongelma vaatii korjaamista. On kuitenkin muutama vaihtoehto, joiden tiimoilta kannattaa aloittaa asian selvittely. 

2) Ajan myötä arvauksesi tutuissa tilanteissa paranevat, mutta vastaan tulee uusia, monimutkaisempia ongelmia. Asioiden merkitykset muuttuvat.

3) Kirjallisuutta aiheesta on paljon. Suurin osa siitä ei ole sinulle erityisen hyödyllistä. Oikeiden kirjojen löytäminen voi olla aluksi vaikeaa. Kaikki vastaan tulevat ratkaisumallit eivät sovi omaan kontekstiisi, eivätkä kaikki omat ratkaisusi toimi muualla.

4) Vertaistuki on tärkeää. Jos et ole tarpeeksi onnekas elääksesi muiden samassa elämäntilanteessa olevien keskellä, tukea löytää helpoiten sosiaalisen median kautta. 

5) Pidemmän päälle yksi keskeisimmistä menestyksen avaimista on siinä, miten hyvin saat muut näkemään, miksi tietyt asiat ovat tärkeitä, miksi toiset ongelmia. Joskus on kärsivällisesti etsittävä parempia tapoja selittää ja havainnollistaa asioita uudella tavalla. 

6) Tärkeää on myös saada toiset tekemään kanssasi yhteistyötä. Jos haluat tulla kuunnelluksi ja otetuksi vakavasti, älä ole se joka aina vain valittaa. Älä ole ilkeä äläkä ylimielinen.

7) Älä jätä tärkeitä asioita sanomatta silloinkaan kun tiedät niiden herättävän vastustusta. Ole valmis kohtaamaan muiden negatiivisia tunteita ottamatta niistä itseesi. Ymmärrä, että roolisi on erityisellä tavalla vastuullinen, mutta parhaiten onnistut myös ristiriitatilanteissa olemalla myös osa tiimiä.

8) Kuuntele tiimiäsi. Myös he opettavat sinua. Paras tapa löytää oman ajattelun puutteet on ottaa harkintaan asioita, joita joku eri tavalla maailmaa katsova nostaa esiin.

9) Joskus paras tapa edistää asioita on esittää kysymyksiä.

10) Jos haluat olla oikeasti hyvä, ymmärrä oma epätäydellisyytesi ja pyri jatkuvasti parempaan. Jokainen epäonnistuminen on tilaisuus oppia tekemään asiat ensi kerralla paremmin. Oman mielenrauhan nimissä kannattaa myös oppia hyväksymään epätäydellisyys sekä tietty määrä elämän yleistä kaoottisuutta.

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.

Olenko hyvä testaaja

Minulle esitettiin hiljattain suora kysymys: oletko hyvä testaaja?

Kysymys on hyvä, mutta siihen on vaikea vastata. Mistä tunnistaa hyvän testaajan? Miten voi arvioida omaa hyvyyttään testaajana, jos ei pääse juurikaan tekemään töitä hyvien testaajien kanssa, joiden tekemisiin voisi omaa puuhasteluaan verrata? Ja toisaalta, hyvätkin testaajat ovat erilaisia. Jos saisin työskennellä gurun kanssa, joka saisi minut tuntemaan itseni jollain testauksen osa-alueella kädettömäksi, silti saattaisi olla jokin toinen osa-alue, jolla hänellä olisi opittavaa minulta.

Kehittäjiltä saatu palaute on tietenkin yksi mittari. Esim. "keksii luovia tapoja rikkoa asioita" on luonnehdinta, jonka otan kehuna. Myös kysymykset kuten "miten tämän sinun mielestäsi pitäisi toimia" ja "tiedätkö, onko tämä android-puhelinten yleinen virhe" luovat vaikutelmaa, että ammattitaitooni luotetaan. Samoin tuoteomistajilta, projektipäälliköiltä ja asiakkailta tuleva palaute kertoo paljon siitä, miten hyvin työssään onnistuu.

Pohjimmiltaan he ovat kuitenkin kaikki ihmisiä, joiden oma osaaminen kohdistuu johonkin muuhun kuin testaamiseen - ehkä he eivät vain tiedä paremmasta?

Ehkä hyvän testaajan on hyväkin olla hieman epävarma omasta ammattitaidostaan. Olemme kaikki vain ihmisiä. Kuka tahansa saattaa tehdä virhearvioita, olla keksimättä jotain oleellista tapaa väärinkäyttää järjestelmää tai jopa olla tunnistamatta jotakin testauksen osa-aluetta, joka olisi juuri käsillä olevan projektin kannalta äärimmäisen tärkeä. Tästä syystä testaaja ei voi eristäytyä yksin omaan kammioonsa, vaan hänen tulee jatkuvasti löytää uusia näkökulmia työhönsä. Tähän tärkeä väline on keskusteleminen muiden projektin osapuolten kanssa. Joskus yksinkertainen kysymys voi olla vaikuttavampi kuin päivän testausrupeama.

Niin kauan kuin on pienikin epäilys oman osaamisen riittämisestä, mieli etsii aukkoja omasta päättelystä. Ilman tätä uusia oivalluksia ei tule. Olisi vaarallista kuvitella osaavansa ja ymmärtävänsä jo kaiken.

Testausta on monenlaista. Kurinalaisuuden ja järjestelmällisyyden yhdistäminen luovuuteen ja jatkuvaan oppimisprosessiin on haasteellinen kokonaisuus, jossa minkä tahansa kulman laiminlyöminen voi johtaa kalliisiin epäonnistumisiin.

Siksi ei ole yhdentekevää, kuka tuotettasi testaa.

Ninjakin tarvitsee mestaria

Testaus on käsityöläisammatti, jonka oppimiseen on vain yksi tie: harjoitus. Työn tekeminen ja tulosten kriittinen analysointi ovat edellytys sille, että voi osata testausta.

Käsityöläisammatit eivät kuitenkaan ole kehittyneet vain yksittäisten ihmisten kekseliäisyyden varassa. Ammattilaiseksi kehitytään mestarin ohjauksessa, ja mestareista parhaat ovat hakeneet oppia useammaltakin mestarilta, tyypillisesti myös ulkomailta.

Tavallaan testausta voidaan verrata myös kamppailulajien harjoittelemiseen. Opetellaan uusia tekniikoita, hiotaan niitä, opetellaan tunnistamaan tilanteita joissa niitä käytetään, ja opetellaan käyttämään niitä tehokkaasti. Hyvät harjoitukset rakennetaan vastaamaan mahdollisimman realistisia todellisia tilanteita.

Myös jokaisella dojolla on oma mestarinsa, jonka oppeja seurataan, vaikka opetuksesta tyypillisesti huolehtiikin joku muu.

Nykypäivänä emme ole täysin suullisen tiedon varassa. Kirjastoista ja netistä löytää tietoa niin käsitöistä, kamppailulajeista kuin testauksestakin. Pyörää ei tarvitse keksiä kokonaan itse, vaikka ei mestarin ohjauksesta saisikaan nauttia.

Silti, ilman ohjausta voi olla vaikea löytää tietään parhaan tiedon luo. Tarvitaan myös mahdollisuuksia kysymiseen ja keskustelemiseen. Näihinkin netti tarjoaa onneksi mahdollisuuksia.

Netin kautta mestari ei kuitenkaan voi korjata virheellistä ranteen asentoa tai jalan väärää liikerataa. Tekniikan hioutumiseen on mahdollisuuksia vain siellä, missä oppija itse näkee tarpeen kehittymiselle.

Voiko myöskään testauksessa koskaan toteuttaa täyttä potentiaaliaan, jos ei saa tilaisuuksia harjoitella yhdessä mestarin kanssa?

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