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.