Koskaan ei ole hyvä hetki

Yksi tärkeimmistä opetuksista, joka tarttui matkaani opinnoista TKK:lla, oli Esa Saarisen luennolta. Se kuului: jos odotat täydellistä hetkeä tarttuaksesi toimeen, et koskaan tule tekemään sitä mitä suunnittelet. Muutama vuosi sitten romaania kirjoittava ja taidenäyttelyä valmisteleva työkaverini muotoili saman ajatuksen hieman toisin: kun nainen tulee tiettyyn ikään, sitä ymmärtää että unelmien ei voi antaa enää odottaa jos ne joskus haluaa toteuttaa.

Tämän opin mukaan olen pyrkinyt elämään manageroidessani viisihenkisen perheeni aikatauluja ja sovitellessani siihen itselleni tärkeitä asioita. Koskaan ei ole täydellistä hetkeä, joten tärkeitä asioita on edistettävä aina kun siihen saa tilaisuuden.

Niinpä bussimatkani kuluvat kieliä opiskellen, kirjoja tai testausaiheisia artikkeleita lukien ja silloin tällöin myös blogia kirjoittaen. Tiskatessani saatan seurata youtubesta esim. BBST-luentoa. Kun valmistaudun puheeseen, harjoittelen sitä imuroidessani tai vaikka uidessani.

Moniajossa ja pätkittäin tekemisessä on tietysti huonotkin puolensa. Oppimateriaaleista saisi enemmän irti keskittymällä niihin täysillä. Kokonaisuudessaan aikaa menee enemmän tavoitteen saavuttamiseen kuin jos asian tekisi kerralla. Ja on asioita jotka eivät koskaan valmistu.

Kuitenkin, jos vaihtoehtona on olla tekemättä ollenkaan, oleellinen kysymys ei ole, oliko tämä paras tapa tehdä, vaan oliko tästä iloa.

Edes lopullisesti kesken jääminen ei aina ole pahasta. Esim. blogin kanssa ideaa täytyy alkaa jalostamaan tekstiksi ennen kuin voi tietää, tuleeko siitä jotain julkaisemisen arvoista. Ja se kirjoittamiseen liittyvä ajatustyö voi olla itselle arvokasta riippumatta siitä, julkaiseeko vai ei. Jos alkuperäiset tavoitteet eivät enää vaikuta mielekkäiltä, tavoitteet voi asettaa uudelleen.

Blogin kirjoittaminen ei vaadi erityistä nerokkuutta, se vaatii vain aloittamisen, ja sen että sinnikkäästi löytää hetkiä kirjoittamiseen. Eikä konferenssipuhujaksi tulla odottamalla täydellistä hetkeä ja täydellistä aihetta ja täydellistä uraa, vaan etsimällä aiheita jotka itse kokee jakamisen arvoisiksi ja tarjoamalla niistä puhetta tapahtumiin joihin haluaisi osallistua. Pahin, mitä yrittämisestä voi seurata, on että ei tule valituksi, ja silloinkin prosessista on voinut oppia jotakin.

Toinen pelottava skenaario on tietenkin, että tulee valituksi. Siksi onkin tärkeää valita aihe johon itse uskoo, ja johon ehtii käytettävissä olevan ajan puitteissa valmistautua. On myös tärkeää muistaa, että unelmia ei saavuteta muuten kuin yrittämällä uusia asioita, asioita jotka ovat oman mukavuusalueen ulkopuolella tai vähintään sen ulkoreunalla.

Jonglöörauksen keskellä on hyvä käyttää ajoittain hieman aikaa oman tekemisensä analysoimiseen. Tähän hyvän työkalun tarjoaa PROOF-malli, jota voi soveltaa tähän tapaan:

Past 

Kuinka käytit ajan, mitä teit ja edistikö se asiaa? Millaiset asiat ehkä häiritsivät keskittymistäsi?

Results

Mitä löysit tai sait aikaan? Voitko jakaa tämän jonkun kanssa jäsentääksesi ajatuksiasi aiheesta paremmin?

Obstacles 

Tarvitsetko apua tai työkaluja? Uusien asioiden opetteluun voi löytyä mobiilisovelluksia tai online-kursseja. Blogin kirjoittamiseen on oppaita, puhumiseen kursseja, hakemusten tekemiseen mentorointia.

Outlook 

Miten tästä eteenpäin, mitä vielä pitäisi tehdä? Voiko ajanhallinnallisesti jatkaa näin, vai onko asioiden prioriteetteja tarkasteltava jotta tärkeimmät asiat tulisivat tehdyksi?

Feelings 

Oliko tämä mielekästä? Onko tästä hyötyä tai iloa? Uskotko tähän? Kun kymmenen vuoden kuluttua katsot elämääsi taaksepäin, ovatko nämä niitä asioita joista voit olla ylpeä? Asioita joilla olet muokannut itseäsi positiivisella tavalla, tai luonut jotain hyvää tähän maailmaan? Mitä pidemmän tähtäimen tavoitteita tämä palvelee? 

Elämä on liian lyhyt pelkkään ajelehtimiseen ja valittamiseen.

Testaajan rooli muutoksessa - ajatuksia Ohjelmistotestaus 2016 -tapahtumasta

Osallistuin tänään Ohjelmistotestaus 2016 -tapahtumaan, tällä kertaa vain kuulijana. Puhujat olivat kaikki omalla tavallaan kiinnostavia ja tällä kertaa ohjelmassa oli aikataulutettuna myös keskustelua pareittain ja kaikkien kesken, mikä ehdottomasti auttoi jäsentämään puheita ja saamaan päivästä enemmän irti.

Yksi päivän suurista teemoista oli testaajan roolin muuttuminen. Aiheesta keskusteltiin hieman jo etukäteen facebookin puolella, ja puheenvuorot kiteyttivät asiaa hienosti muutamastakin näkökulmasta. Anssi Lehtelä toi esiin eri roolien välisen kommunikaation, luottamuksen ja yhteisen päämäärän merkitystä, sekä käytössä olevan julkaisumallin vaikutusta testaukseen kohdistuviin vaatimuksiin. Keskeinen viesti oli että testaajalla on mahdollisuus vaikuttaa näihin asioihin mm. testattavuuden parantamiseksi. Sami Söderblom esitteli ajatuksia liittyen antihaurauteen, testauksen toimintaympäristön haasteisiin ja testauskulttuurin luomiseen, tuoden esiin mm. yhteistyön ja kaaoksen sietämisen merkitystä. Maaret Pyhäjärvi kertoi mm. testiautomaatioon liittyvästä roolituksesta ja roolien välisestä yhteistyöstä. Erkki Pöyhönen puhui alihankintaan ja monitoimittajaympäristöön liittyvistä haasteista, ja Antti Niittyviita palvelukokemuksen (miten toinen osapuoli kokee kohtaamisen) merkityksestä arvon luomisessa. Päivän kruunasi Helena Jeret-Mäen puheenvuoro siitä miten kasvetaan testausasiantuntijaksi tai kasvatetaan aloittelevista testaajista sellaisia.

Keskusteluissa testaajan roolin kehityksestä keskeisenä nähtiin automaation merkityksen kasvu, kommunikointitaitojen merkityksen kasvu, sekä tarve integroida testausta paremmin kehitystiimeihin ja tuoda testausajattelua myös sellaisiin asioihin kuin tarjouspyyntöihin ja arkkitehtuurivalintoihin. Puhuttiin siitä, miten tärkeää on löytää itse oma roolinsa (siihen liittyvät vaatimukset ovat kuitenkin osin organisaatiokohtaisia), olla valmis poistumaan mukavuusalueeltaan, oppimaan uutta, etsimään tietoa ja toimimaan myös aktiivisesti muutoksen luomisessa ja ohjaamisessa. Liiketoiminnan ymmärtäminen, tavoitteiden asettaminen sekä kyky palastella unelmia tavoitettavissa oleviin askeliin nähtiin myös taitoina joista on testaajalle paljon hyötyä pyrittäessä ohjaamaan muutosta tavalla jolla testauksen merkitys softaprojekteissa ennemmin kasvaisi kuin pienenisi. Oma aktiivisuus, joustavuus sekä uskallus kysyä ja ehdottaa vievät asioita eteenpäin.

Jäin itse vielä miettimään, miksi ja miten pitkään me testaajat pohdimme omaa rooliamme. Testaus on muuttunut viime vuosien kuluessa paljon, ja oletettavasti se on muuttunut myös aikaisempina vuosina. Esimerkiksi mobiilikäyttöliittymät ja IoT tuovat tällä hetkellä monen testaajankin työhön uudenlaisia haasteita, ja tällaisten asioiden kimpussa painivien testaajien määrä lienee kasvussa. Tänään lopulta lähinnä katsoimme yhdessä taaksepäin, koska puheenvuorot liittyivät esittäjiensä omiin kokemuksiin, eivät tulevaisuudenvisioihin. Toki esitetyt ajatukset olivat paikoin melko radikaalejakin ja monissa organisaatioissa edelleen utopiaa kaukaisesta tulevaisuudesta. 

Kuitenkin, muutos toimintaympäristössämme jatkuu, ja sitä myötä jatkunee myös testaajan roolin muutoksen pohtiminen. Uutta tulee nopeasti, samalla vanha muuttuu hitaasti. Ehkä testauksen kenttä entisestään fragmentoituu tehden entistä vaikeammaksi puhua testauksesta yhtä aikaa konkreettisesti, yleistajuisesti ja koko yleisöä palvellen.

Keitä lienevät he jotka toivovat testausaiheisilta tapahtumilta puheenvuoroja testaajan roolin muutoksesta? Etsivätkö he tukea toiminnalleen aallonharjalla, uudenlaisissa toimintaympäristöissä? Hakevatko he uutta suuntaa vanhoja toimintamalleja noudattavissa yrityksissä? Vertaistukea muuttuvassa maailmassa luovimiseen? Tapoja nostaa arvoaan potentiaalisten työnantajien silmissä? Keinoja muuttaa itse maailmaa? Mitä he tavoittelevat toivoessaan tämän aiheen käsittelyä, vai toivovatko he tavoitetta?

Testaajan muuttuva rooli ja Ohjelmistotestaus 2016

Tänä vuonna sain tilaisuuden puhua Ohjelmistotestaus 2016 tapahtumassa, ja hyödynsin samalla mahdollisuuden osallistua tapahtumaan kokonaisuudessaan. Päivistä jäi hyvä fiilis, oikeastaan kaikki esiintyjät onnistuivat tarjoamaan jotakin pohdittavaa, vaikka kaikkien aiheet eivät tietenkään omaan tilanteeseeni verraten olleet niin relevantteja. Koin tilaisuuden myös mukavan kokoiseksi: kun porukkaa ei ollut valtavaa määrää, juttuseuraa oli jotenkin luontevampaa etsiä, ja taukokeskustelut olivatkin antoisia. Ekstraohjelmana pääsin vielä kuuntelemaan Anssi Lehtelän harjoituspuhetta testattavuudesta Nordic Testing Daysin esitystä varten. Nyt pääni viliseekin uusia ajatuksia, jotka toivottavasti ehdin jalostaa itselleni läheisempään muotoon ennen kuin ne pääsevät liikaa haalistumaan.

Oma puheenvuoroni liittyi testaajan roolin muuttumiseen ja perustelemiseen tilanteessa jossa kenties perinteiset vesiputousmallilla toimivat testaustiimit maastamme vähenevät, rekrytointia tehdään kenties aikaisempaa enemmän yrityksiin joissa testausta ei niin hyvin ymmärretä, ja ketterät toimintatavat vaativat muutenkin vähän toisenlaisia taitoja. (Tauolla sain kuitenkin palautetta että puhumani asiat olivat ajankohtaisia myös ainakin yhdessä yrityksessä, jossa testauksella oli pitkät perinteet ja vakiintunut asema, koska testaajien on esimerkiksi ansaittava erikseen jokaisen uuden kehittäjän luottamus.) Samaa aihepiiriä eri näkökulmista käsitteli muutama muukin esiintyjä, ja sitä pohdittiin myös paneelikeskustelussa.

Yksi ajatus esityksessäni liittyi siihen, miten testaaminen ja testaajan rooli voidaan nähdä monella tavalla, erityisesti sellaisten silmin jotka eivät itse ole testaajia. Muiden esityksiä kuunnellessa vahvistui entisestään ajatus, miten erilaisia asioita testaus ja testaajan rooli voivat tarkoittaa myös meille testaajille. Tämä tekee haasteelliseksi puhua seminaareissa testauksesta tavalla, jossa konkretia yhdistyisi kaikkien kuulijoiden kannalta relevanttiin asiaan. Toisaalta moni nykypäivän IT-osaaja vaihtaa työpaikkaa suht tiuhaan, ja sitä kautta hyötyy myös tarinoista jotka eivät itselle ole juuri nyt ajankohtaisia. Jotenkin konkreettisten aiheiden löytäminen tuntuu kuitenkin esiintyjille vaikealta - tässä täytyy itsekin jatkoa ajatellen pohtia tapoja parantaa tilannetta. 

Tällä kertaa konkretian puolesta itselleni antoisin esitys oli Maaret Pyhäjärven esitys ryhmäohjelmoinnista (mob programming), josta sain vihjeitä joiden pohjalta kokeilla tekniikkaa myös omassa tiimissä (plus kirjavinkki jonka kautta hakea lisää ymmärrystä aiheesta). Hyvin konkretiaan menivät myös Katri Halla-Ahon esitys riskipohjaisesta testauksesta, jossa käytiin esimerkein läpi riskianalyysia ja miten sitä voidaan hyödyntää testauksen suunnittelussa ja seurannassa, sekä Karla Niemisen esitys testaajan keskustelutaidoista. Lisäksi testiautomaatioon liittyen käsiteltiin melko konkreettisiakin asioita sekä Jari Mäkeläisen että Disa Kakon esityksissä, joista ensimmäinen tarjosi sekä vinkkejä (kuten automaattitestien liittäminen samaan versiohallintaan missä varsinainen koodikin on) että sitä tuskaa mitä tiedon lisäämisestä tässä maailmassa yleensäkin seuraa (kuten automaatiotyökalujen valtava määrä ja monet tekijät jotka vaikuttavat työkalujen soveltuvuuteen eri käyttötarkoituksiin), jälkimmäinen enemmänkin näkymää niihin kipukohtiin, joita liittyy jokseenkin täydellisen erilaiseen toimintaympäristöön kuin missä itse työskentelen.

Osa esityksistä toi esiin hajautetun tuotannon haasteita. Kotimaisen monitoimittajaympäristön ongelmiin tarjottiin ratkaisuksi eri firmoista tulevien tekijöiden tuomista samaan tilaan tekemään yhteistyötä (joko muodostamaan yhteisen projektitiimin kokoaikaisesti, tai sitten erillisessä integraatiovaiheessa), mikä omien kokemusteni perusteella kuulosti mainiolta idealta. Kansainvälisessä toimintaympäristössä tämä ei ole niin helppoa, esimerkkinä kuitenkin kerrottiin myös tarina siitä, miten scrum on saatu toimimaan tilanteessa jossa tuoteomistaja, projektipäällikkö ja scrum masterit olivat Suomessa, kehittäjät ja testaajat taas Intiassa. Pidän itse melkoisena saavutuksena, että tällaisista lähtökohdista voidaan tulla kertomaan onnistumisista, kun ei se agileen siirtyminen aina ole ihan helppoa niissäkään organisaatioissa, joissa kaikki työskentelevät saman katon alla.

Testaukseen kohdistuvat vaatimukset riippuvat paljon myös toimialasta, esim. nettiviihdealalla AB-testaus ja virheiden päästäminen tietoisesti päiväksi tuotantoon (silloin kun lätkän MM-kisat eivät ole käynnissä) voi olla järkevä toimintatapa, toisena ääripäänä esimerkiksi potilasturvallisuus saattaa jättää niukemmin liikkumavaraa sen suhteen, miten lähellä täydellistä tuotantoon vietävän softan tulee olla. Mobiilitestauksen haasteet kasvavat hiljaksiin jokaisen uuden Android-laitteen myötä, ja esimerkiksi IoT nostaa esiin uudenlaisia kysymyksiä, joita myös testauksen kehittämisessä on tarpeen perusteellisesti pohtia. Maailma muuttuu vauhdilla, ja niin myös se, millaisia taitoja testaamiseen voi tarvita. Testauksen tulevaisuudennäkymistä tuntuikin olevan yhteisymmärrys siitä, että vaatimustaso testaajan osaamista kohtaan on kasvamaan päin.

Renessanssi-nerous alkaa siis olla mahdotonta ohjelmistotestauksen kentällä. Puhtaasti testaustekniikoiden näkökulmasta erilaisten mahdollisten taitojen kirjo on valtava, ja lisäksi monella toimialalla on tarpeen erikoistua juuri tuon alan haasteisiin pärjätäkseen itsenäisenä testaajana. Vaikka ei olisikaan innostunut tilannetekijäohjatusta testauksesta, testaus on väistämättä monella tavalla kontekstisidonnaista, ja vaihtoehtoisia konteksteja on valtava määrä.

Testauksen tulevaisuuden kannalta onkin tärkeää, miten me testaajat itse osaamme tehdä näkyväksi toimintakenttämme kompleksisuutta. Käytyjen keskustelujen perustella testiautomaation valtava tarve liittyy osin ohjelmistotuotannon valtavaan määrään, jossa vain pieneen osaan maailman projekteja riittää niitä teräsmies-kehittäjiä, joiden koodi on niin kaunista ja virheetöntä ettei sen jatkokehittäminen vaadi kummoistakaan regressiotestiarsenaalia. Keskinkertaisten, kelvollisten ja kehnompien kehittäjien jälkien paikkailu taas vaatii melkoisia batman-testaajia, mutta heitäkään ei joka firmaan riitä. 

Kysymys kuuluukin, onko automaation auvoisuutta rummuttavassa maailmassamme ymmärretty riittävän hyvin testaajan arvo, se kuinka paljon yksilön oppimiseen on oltava valmis sijoittamaan jotta hänestä voisi kehittyä batman-testaaja, ja ollaanko hänelle tuon tason saavutettuaan valmiita maksamaan vastaavia summia kuin teräsmies-kehittäjälle? Kuinka me testaajat voisimme paremmin näyttää tekemisemme arvon ja ne mahdollisuudet, joiden tavoittamiseen tarvitsemme lisää pelimerkkejä? Ja kuinka mahdollistamme jatkossakin keltanokka-testaajien pääsyn alalle, että heidän tuleva arvonsa nähtäisiin riittävän suureksi, jotta heidänkin työssäoppimiseensa ja kouluttamiseensa kannattaa panostaa?

Testattavuudesta ja omien rajojen tunnustamisesta

Testaajan rooli nähdään helposti puutteiden etsimisenä muiden tekemisistä. Kun koodi on kehittäjän mielestä riittävän hyvä ollakseen valmis, testaajan tehtävä on tavallaan löytää kaikki merkitykselliset kysymykset, joita ei ole vielä esitetty tai joihin ei ainakaan ole vielä löydetty vastauksia. Tyypillisesti ajatellaan kysymyksen olevan siitä, toimiiko ominaisuus ja vastaako se speksejä. Näkökulmia on kuitenkin monia muitakin. Löytääkö käyttäjä toiminnallisuuden? Ymmärtääkö hän, mitä se tekee? Eteneekö prosessi riittävän sujuvasti? Selviääkö järjestelmä riittävän hyvin raskaista operaatioista? Mitä muutokset tarkoittavat testattavuuden, ylläpidettävyyden tai tietoturvallisuuden näkökulmasta?

Yhden ihmisen voi olla vaikea löytää kaikkia kulmia, joista kysymyksiä voi esittää. Oma osaaminenkaan ei välttämättä riitä kaikkeen. Siksi on tärkeää tunnistaa omat rajansa ja puutteensa ja miettiä, miten niiden yli on mahdollista päästä. Joskus vastaus voi olla tiedon etsiminen, jotta oma näkemys ja osaaminen laajenisi. Joskus vastaus voi olla avun pyytäminen.

Minä kokeilin pari viikkoa sitten esittää tiimille testaukseen liittyvän ongelman, jota en itse pystynyt ratkaisemaan. Saimme aikaan mainion keskustelun testattavuudesta, sekä tavoista mahdollistaa nykyistä paremmin testiautomaation rakentaminen. Suunnittelupöydällä on nyt jo aikaisemminkin pohdittu mutta keskustelumme jälkeen prioriteetiltään noussut muutos, joka toivottavasti parantaisi yhden keskeisen toiminnon käytettävyyttä, sekä vähentäisi testausta vaativien prosessikulkujen määrää. Automaation rakentamiseen liittyviä ongelmia on ratkottu yhdessä, työ on vielä kesken, mutta se kaikkein perustavanlaatuisin este on jo saatu purettua.

On mahtavaa saada työskennellä ympäristössä, jossa ongelmista ollaan valmiita tekemään yhteisiä, ja jossa niihin myös halutaan löytää ratkaisut.

Minä näen testaajan työn keskeisenä tarkoituksena auttaa kehittäjiä työssään. Tärkeää on myös muistaa, miten monin tavoin kehittäjät voivat auttaa testaajaa tekemään työnsä paremmin.

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.

Dokumentointia ja raportointia - ajatuksia tutkivan testauksen työkurssilta vol 3

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, joista tämä on kolmas. 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 ja kokemuksiani.


Dokumentaatiota voi tehdä monella tavalla ja monesta syystä. Byrokraattisten asiakasorganisaatioiden kanssa työskennellessä saattaa mieleen hiipiä ajatus, että dokumentaatiota tehdään koska asiakas haluaa sellaista. Myös laatujärjestelmät saattavat asettaa vaatimuksia dokumentaatiolle, jota sitten tehdään laatujärjestelmän itsensä takia. Joskus dokumentointi saatetaan kokea uuvuttavana ja turhana, ja tällöin helposti käy niin, että dokumentti tehdään vain jonkun muun toiveen täyttämiseksi arkistoihin pölyyntymään.

Toisaalta dokumentointiin voi ottaa myös toisenlaisen näkökulman. Millaisia asioita on tarpeen kirjata muistiin, jotta en unohtaisi, mitä on sovittu? Millaisia asioita on tarpeen kirjata muistiin, jos joku muu joutuukin yllättäen ottamaan projektista kopin? Millaisia asioita on tarpeen kirjata muistiin, jos asiakkaan kanssa täytyy jälkikäteen vääntää kättä siitä, onko sovitut asiat tehty vai ei? Entä kun sovitaan muutoksista, miten dokumentaatio saadaan pysymään ajantasalla?

Suunnitteludokumentaatio

Esimerkiksi testaussuunnitelman tarkoitus voi olla kuvata asiakkaalle käytettävä testausprosessi, tai asettaa reunaehdot muille projektin osapuolille siitä, millaisten asioiden on toteuduttava jotta testaaja voisi tehdä työnsä. Itse olen kuitenkin kokenut, että ellei joku näitä asioita erikseen pyydä, on turha odottaa että kukaan muu kuin testaaja itse koskaan lukisi koko dokumenttia. Siksi se kannattaa pitää kevyenä ja kirjoittaa siitä näkökulmasta, että se parhaalla mahdollisella tavalla tukee testaajan työskentelyä.

Testaussuunnitelma voisi siis sisältää seuraavanlaisia tietoja:

• Mistä löytyy oleellinen dokumentaatio (vaatimukset, käyttötapaukset, visuaaliset suunnitelmat yms.) johon testauksen on perustuttava? Jos dokumentaatiota ei ole, se voi kertoa lyhyesti, millaista tuotetta ollaan tekemässä, kenelle ja miksi. Dokumentissa voi olla myös listaus projektin vastuuhenkilöistä, joilta kysyä apua ongelmatilanteissa tai mielipidettä asioiden merkittävyydestä, mikäli nämä asiat eivät ole muuten ilmeisiä. 
• Hahmotelma testauksen strategiasta, hyödyllisistä menetelmistä ja työkaluista. 
• Pohdintaa riskeistä, joiden realisoitumisen mahdollisuuksia testauksella on syytä minimoida, sekä korkean tason jaottelua näkökulmista, joista testausta on tarpeen tehdä. Ideoita testauksen suunnitteluun löytyy esim. James Bachin ja Michael Boltonin kehitelemästä FEW HICCUPPS-mallista ja James Bachin heuristisesta testausstrategiamallista. 

Erilaiset tarkistuslistat ovat hyödyllistä testaussuunnitteludokumentaatiota, mutta niiden ei itsessään tarvitse olla projektikohtaisia eikä osa testaussuunnitelmaa.

Tärkeää testauksen suunnittelussa on tavoitteiden asettaminen testaukselle. Tavoitteita on hyvä tarkastella uudelleen projektin edetessä, ja sitä kautta tarvittaessa myös päivittää testaussuunnitelmaa. Tekemistä on suunnattava prioriteettien ja riskien näkökulmasta paitsi testauksen alkaessa myös matkan varrella.

Testausvaiheen dokumentaatio

Testauksen aikana syntyvästä dokumentaatiosta keskeisimpiä ovat bugiraportit. Aina niitäkään ei kaikkia tarvitse dokumentoida, vaan jotkut asiat voi hoitaa esim. suullisesti. Käytännössä monet bugit ovat kuitenkin sellaisia ettei niitä ole mahdollista heti korjata, ja silloin huolellinen dokumentointi on tarpeen jotta kehittäjä osaisi vaikkapa viikon kuluttua korjata ongelman ja mahdollisesti toinen testaaja tarkistaa korjauksen onnistumisen. Neuvoja bugiraportointiin löytyy esim. Cem Kanerin Bug Advocacy-mallista.

Bugiraporttien lisäksi voi olla tarpeen tehdä muistiinpanoja tai pieniä ohjeita hankalista asioista. Ne voivat olla esim. uusia checklistejä, lyhyitä käyttöohjeita asioihin jotka ovat itselle olleet vaikeita, huomioita toiminnoista jotka kaipaavat erityistä huomiota testaajalta esim. siksi että tuntuvat erityisen herkiltä hajoamaan muiden muutosten myötä, tai uusia ajatuksia alueista, joita testaajan olisi tarpeen tutkia enemmän kuin testaussuunnitteluvaiheessa on tullut ajateltua.

Näiden dokumenttien ensimmäinen hyöty on se, että testaajana voit antaa dokumentoitavan ajatuksen unohtua ja keskittyä siihen tehtävään, joka sinulla oli oikeasti työn alla. Kun sinulla on taas aikaa miettiä, mitä lähtisit tutkimaan seuraavaksi, tai joudut välillä siirtymään toisen projektin pariin ja sitten palaamaan taas nyt käsillä olevaan, kaivat vain esiin muistiinpanosi ja käyt hommiin käsiksi.

Toinen hyöty on se, että joskus voit joutua siirtämään projektisi toiselle henkilölle. Ei ole mahdollista luoda sellaista dokumentaatiota, jonka joku toinen pystyisi lukemaan ja sisäistämään, ja joka täydellisesti korvaisi kokemuksen tuotteesta ja projektista, mutta on paljon asioita, joiden löytyminen dokumentaatiosta helpottaa merkittävästi kärryille pääsemistä.

Lisäksi joskus asioiden merkitystä on helpompi arvioida, kun niihin ottaa vähän etäisyyttä. Kiinnostava bugi on aina hauskaa päästä raportoimaan, mutta joskus kysymys on asioista, joilla ei oikeasti ole merkitystä loppukäyttäjien kannalta, ja silloin voi olla parempi olla käyttämättä kehittäjän aikaa asiasta keskustelemiseen. Havainnon voi silloin vain kirjata itselleen ylös ja antaa asian hautua jonkin aikaa, onko tässä asia jonka tarkempaan tutkimiseen on syytä panostaa, ja miten se suhtautuu merkittävyydessään muihin tarjolla oleviin tehtäviin.

Testausvaiheen materiaali muodostuu tehtävänannoista, testaukseen käytettävistä aineistoista, työkaluista, sekä matkan varrella opituista asioista.

Analysointi

Jotta tekemistä voisi suunnata uudelleen ja lopputuloksista antaa relevantteja raportteja, on omaa työtä analysoitava jollain tapaa. Tähän voi käyttää esimerkiksi nk. proof-menetelmää, jota voi käyttää jokaisen testisession päätteeksi oman työn suuntaamiseen, mutta myös apuna siirrettäessä vastuu testauksesta toiselle. Menetelmässä arvioidaan testausta viidestä näkökulmasta: kuinka käytit ajan, mitä löysit, tarvitsetko apua tai työkaluja, onko vielä lisää tehtävää ja oliko tehtävänanto järkevä,

Raportointi

Suhteellisen yksinkertainen mutta vaikuttava ja informatiivinen tapa raportoida testausta on jaotella testauksen kohde muutamiin toiminnallisiin ja ei-toiminnallisiin osa-alueisiin, joihin liittyen testaaja tai projektitiimi antaa omat laatuarvionsa. Ei-toiminnallisia osa-alueita voivat olla esim. yleinen toimivuus, käytettävyys, luotettavuus, suorituskyky, turvallisuus ja ylläpidettävyys.

Laatuarvioita annetaan kolmiportaisin asteikoin, joita voidaan käyttää useampia yhtä aikaa arvion parantamiseksi. Laadun (hyvä / ei hyvä muttei kelvotonkaan / selkeästi keskeneräinen) lisäksi arvioidaan esitettävien käsityksien perusteluja (olenko varma väitteestä testattuani hyvin / olenko testaillut jonkin verran / oletanko vain) sekä tarvittaessa mielikuvaa ko. kokonaisuuden stabiiliudesta (eli kuinka luotettava nyt annettu laatuarvio olisi huomenna tai viikon päästä).

Testikattavuutta kannattaa pohtia siitä näkökulmasta, minkä tyyppiset asiat ovat merkityksellisiä, ja mistä raportointi on tärkeää. Ihmiset ovat erehtyväisiä, joten aina on riski että jokin testausta vaativa osa-alue on unohtunut kokonaan tarkastelusta.

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?

Testaaja - koodarin vihollinen vai puolustaja?

Testaajien ja kehittäjien yhteistyö ei ole aina ihan kitkatonta.

Kun testaajan eteen tuodaan jotain valmiiksi väitettyä, jonka testaaminen on hidasta koska koko ajan löytyy raportoitavaa, on haasteellista tuoda löydöksiä esiin tavalla, jota hiukankin herkkähipiäinen kehittäjä ei kokisi osin henkilökohtaisuuksiin menevänä nipottamisena. Aikataulu- ja budjettipaineet kiristävät molempien pinnaa, samoin kaikenlaiset "tyhmät" virheet.

Erityisesti kun kyse on valmisohjelmistoon tehtävistä muutoksista, vastaan voi myös tulla vanhaan koodiin liittyviä ongelmia, joiden kiertämisen haasteellisuus siirtää helposti keskustelun korjaustavan etsinnästä bugin merkityksen vähäisyyden perusteluun. Näissä tilanteissa osapuolten voi olla vaikea nähdä tekevänsä yhteistyötä, ennemminkin tuntemukset molemmin puolin risteilevät ärtymyksessä, miksi muutenkin niukkaa aikaa on käytettävä johonkin näin turhauttavaan.

Testaajan tehtävä ei kuitenkaan ole mollata kehittäjää väärin tehdystä työstä, vaan auttaa tätä tekemään työnsä hyvin.

Erityisesti silloin kun testauksesta puhutaan laadunvarmistuksena, testaajan tehtävä on merkittäviä virheitä löytäessään viedä projektin johtoon viestiä, että kehittäjien mahdollisuudet tehdä työnsä hyvin on taattava.

Laatua kun on vaikea saada aikaan, jos sen tekijöillä ei ole tarpeeksi aikaa, tarpeeksi mahdollisuuksia keskittyä, tai tarpeeksi ohjausta.

Harva koodari tekee ihan vaan piittaamattomuuttaan virheitä, ja kokonaisuuden kannalta edullisinta olisi, jos mahdollisimman moni toimintalogiikkaan liittyvä tai muuten merkittävä virhe jäisi kiinni jo silloin kun niitä ollaan kirjoittamassa.

Tässä mielessä olisi myös hienoa, jos testausta ei nähtäisi vain valmiin tuotteen toiminnan verifiointina.

Testaaja voi auttaa ehkäisemään virheitä mm. katselmoimalla määritys- ja suunnitteludokumentteja, esittämällä kysymyksiä sprinttipalavereissa, keskustelemalla rakenteilla olevasta toiminnallisuudesta kehittäjien kanssa, käymällä kehittäjän kanssa demoluonteisesti läpi toteutettua toiminnallisuutta, ja testaamalla hyvinkin keskeneräistä (kunhan hänellä on tieto siitä, mitä voi testata ja minkä ei ole tarkoituskaan vielä toimia). Tärkeää on löytää yhteinen tavoite tekemiselle.

Laatu ei parane testaamalla, vaan tekemällä paremmin.

Elämäni mutteriapinana ja muita motivaatiokokemuksia

Kenties turhauttavinta testaustyössä on säätäminen.

Siis se, miten pahimmillaan parikin kertaa päivässä joutuu kyselemään projektien vastuuhenkilöiltä, joko olisi testattavaa, miten aikataulu elää, missä testataan, milloin ympäristö päivitetään, mitä ja miten on testattavissa. Mitkä ovat juuri nyt testauksen prioriteetit ja tavoitteet.

Miten viime hetken kiireellisen tilauksen vuoksi joutuu keskeyttämään juuri vauhtiin päässeen työskentelyn tehdäkseen taas uuden syöksyn tuntemattomaan. Tai kyselemään, voisiko jonossa seuraavan projektin aloittaa sovittua aikaisemmin, kun se ensimmäinen ei olekaan vielä testattavissa. Järjestelemään testauksen jakamista tai siirtämistä toiselle testaajalle, kun projektien toteutuvat aikataulut vaativat suurempaa työpanosta kuin mihin on kohtuullista yksin venyä.

Kysymään useampaan otteeseen, ennen kuin saa riittävät tiedot jonkin asian testaamiseen, vain löytääkseen itsensä tilanteesta, jossa joku tuhoaa varoittamatta vaivalla rakennetun testiaineiston, tai selviää että sovittua päivitystä ei sitten ollutkaan tehty. Tai päivitettiin epästabiiliksi tiedettyyn versioon, ja nyt päästään testaamaan samoja bugeja useammassa ympäristössä yhtäaikaa.

Tähän kaikkeen liittyy piinallinen tuntuma siitä, ettei saa mahdollisuutta tehdä työtään niin hyvin kuin haluaisi, olla niin hyödyllinen kuin omasta mielestään osaisi olla.

Jonkin verran epävarmuutta, inhimillisiä erehdyksiä ja niihin liittyvää säätämistä on pakko hyväksyä. Testaajan työn aikataulu ja työmäärä riippuvat siitä, miten kehittäjät tekevät työnsä, eikä sitä ole täysin mahdollista ennakoida. Kun vielä testaajan työn idea on enemmän tai vähemmän keskeneräisen kanssa työskentely - sen tarkistaminen, miten tukeva rakennelmasta tulikaan - virheisiin törmääminen vähän niin kuin kuuluu toimenkuvaan.

Siksi välillä on pakko joustaa ja järjestellä. Joskus on myös pakko hyväksyä se, että juuri nyt ei ole tarjolla mielekästä testaustyötä. Tai että aika ei riitä tekemään asioita oikeasti perusteellisesti. Työ on lopulta vain työtä, ei sen takia kannata yöuniaan menettää, eikä sen tarvitse olla tärkein elämään sisältöä tuova asia.

Joskus kuitenkin on vaikea välttää ajatusta, olisiko asiat kuitenkin mahdollista tehdä edes vähän paremmin.

Yksi vaihtoehto olisi tehdä projekteja ketterämmin, jolloin testattavaa syntyisi tasaisempaa tahtia ja pienempiä määriä kerrallaan. Tämäkään vaihtoehto ei kuitenkaan yksin tuo pelastusta, sillä monia vesiputousmallia rampauttavia toimintatapoja (tai tapoja olla toimimatta) on mahdollista käyttää myös projekteissa, joita periaatteessa edistetään ketterästi - häröilyhän ei sellaisenaan kuulu mihinkään prosessimalliin. Eikä järjesteltävien palikoiden pienentäminen itsessään poista järjestelyn tarvetta, vaan lopputulos voi olla jopa päinvastainen.

Yllättävän paljolta turhalta työltä ja mielipahalta säästyttäisiin ihan vain skarppaamalla projektien sisäisen tiedonkulun kanssa. Siis esimerkiksi sillä, että aina kun tapahtuu jotain aikatauluun tai sisältöön vaikuttavaa, myös testaaja saisi kuulla asiasta. Tai jos kehitetään ja testataan yhtäaikaisesti, saman projektin parissa painivilla olisi tieto siitä, mitä muut ovat tekemässä, ja keihin kaikkiin omat tekemiset voivat vaikuttaa. Että saisi senkin tiedon, jota ei ole helppoa keksiä itse kysyä. Monet näistä asioista varmaankin helpottaisivat myös kehittäjien työtä.

Pitäisikö testaajan istua kehittäjien luona jo toteutusvaiheessa? Pitäisikö hänen osallistua projektipalavereihin alusta alkaen? Ainakin osaan niistä? Pitäisikö projektien tiedotus hoitaa spämmäämällä aina sähköpostilistaa, jolle myös testaaja kuuluu?

Ratkaisuvaihtoehtoja voi olla useampia. Ehkä lopulta tärkeintä on, että projektin sisäinen viestintä ylipäätään nähdään panostamisen arvoisena, tapana ehkäistä ongelmia. Esimerkiksi, että palaverit suunnitellaan jollain tasolla, niistä jaetaan etukäteen jonkinlainen agenda, ja niihin pääsevät tavalla tai toisella osallistumaan kaikki, joita käsiteltävä asia jotenkin koskee, tietäen mitä heidän osallistumiseltaan odotetaan. Että niiden ensisijainen tarkoitus ei ole raportointi, vaan tiedon jakaminen kaikille niille jotka siitä hyötyvät.