Tunnelmia Testing Assemblyn jälkeen

Osallistuin tällä viikolla Helsingissä järjestettyyn Testing Assembly -tapahtumaan. Tiistaina vietin päiväni James Lyndsayn workshopissa opettelemassa tutkivaa testausta ja keskiviikkona olin yksi seminaaripäivän puhujista.

Mitä jäi käteen?

Workshop paitsi tarjosi viihdyttävän koulutuspäivän ja uusia kontakteja myös syvensi ymmärrystä tutkivasta testauksesta ja antoi kirjavinkkejä sekä joukon kiinnostavia linkkejä joiden takaa hakea työkaluja ja lisää tietoa testauksen tueksi. Kiinnostavaa oli myös oppia, millä tavoin yhdessä testaava testaustiimi voi järjestäytyä ja millaisia rooleja ryhmästä löytyä, sekä tietysti päästä kokeilemaan näitä käytännössä. Pieniä ajatussiemeniä syntyi joiden pohjalta pyrin kirjoittamaan jotain blogiinkin syksyn mittaan.

Myös seminaaripäivästä jäi paljon mieleen. Esimerkiksi Aleksis Tulosen puheenvuoro nosti esiin perustavanlaatuisia kysymyksiä, kuinka paljon oikeasti tiedämme siitä miten ja millaisissa olosuhteissa käyttäjät softaa käyttävät, ja miten tärkeää on ymmärtää, miksi uusia ominaisuuksia tehdään, sekä saada keskustella toteutukseen liittyvistä valinnoista.

Sain keväällä Ohjelmistotestaus 2016-tapahtumassa hieman moitteita siitä että en puhunut puheenvuorossani tarpeeksi paljon testauksesta (puheeni liittyi oman työn myymiseen ja jalansijan luomiseen ympäristössä jossa testauskulttuuria ei välttämättä vielä ole), joten oli jännittävää mennä taas puhumaan vähän niin kuin ohi aiheen, sosiaalipsykologiasta eikä testauksesta. Tästä näkökulmasta olikin aika riemastuttavaa löytää monista päivän puheenvuoroista ihan samoja asioita, joista olin puhunut keväällä tai joista puhuin tällä kertaa.

Kaikenkaikkiaan päivän aikana kuuntelemieni esitysten ajatukset voisi kiteyttää niin, että testaajan tärkeimmät taidot liittyvät itse testaamisen ohella empatiaan, aktiiviseen kuunteluun, kyselemiseen ja kommunikaatiotaitoihin. Täytyy yrittää ymmärtää, mitä ja miksi ollaan rakentamassa. Täytyy osata kyseenalaistaa ja uskaltaa seurata vaistojaan ja empiirisiä havaintojaan vaikka organisaatio ei siihen tukisikaan, Täytyy olla rohkeutta poistua mukavuusalueeltaan ja ottaa vastuu omasta ammatillisesta kehittymisestään, oppia jatkuvasti jotain uutta. Täytyy rakentaa yhteistyötä, jotta testauksesta saadaan aidosti positiivinen voimavara organisaatiossa,  ja täytyy osata esittää asiansa rakentavasti ja täsmällisesti. Tulevaisuudessa nämä taidot ovat entistä tärkeämpiä, kun yhä suurempi osa mekaanisemmasta testauksesta pystytään automatisoimaan. Näihin ajatuksiin toivon että omakin esitykseni osaltaan tarjosi rakennetta ja ideoita miten kehittyä paremmaksi työyhteisön rakentajaksi.

Parasta tapahtumassa oli taas mahdollisuus tavata tuttuja, tutustua uusiin ihmisiin ja keskustella. Erityisesti kun on itse organisaationsa ainoa testaaja, on tärkeää päästä silloin tällöin ympäristöihin joissa on mahdollisuus päivittää ajatteluaan muiden testaajien keskellä. Kohtuuhintainen tutorial-päivä ja seminaaripäivä yhdessä luovat mainion kokonaisuuden tähän. Suuret kiitokset järjestäjille! Open space- keskustelut valitettavasti jäivät minulta tällä kertaa kokematta, toivottavasti ensi vuonna saan mahdollisuuden osallistua niihinkin.

Ja kenties ensi kerralla voisin sitten puhua ihan oikeasti testauksesta :)

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.

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?

Kieliversiot

Muutama vuosi sitten kokeilin lyhyen pätkän kotirouvan elämää Saksassa. Mieheni oli väliaikaisesti töissä Freiburgissa, ja me lasten kanssa vietimme kesän siellä hänen kanssaan. Oma saksankielentaitoni ei ole kovin kaksinen, mutta "lebensmitteldeutch" riitti suhteellisen hyvin arkiseen kaupassa ja torilla asioimiseen, ja kielitaidon loppuessa kesken asiat saatiin käytännössä aina hoidettua niin että minä puhuin englantia ja toinen osapuoli saksaa.

Suurimmat kielellisen turhautumisen hetkeni koinkin erilaisten nettipalveluiden käyttäjänä. Koska olimme Saksassa, jokainen kansainvälinen palvelu jonka sivustolle menin, tarjosi minulle oletuksena saksankielistä sivustoa. Ja koska Saksassa pärjää vain osaamalla saksaa, näistä palveluista ei koskaan löytynyt mahdollisuutta vaihtaa sivuston kieltä englanniksi. Siispä esimerkiksi asensin tietokoneeseeni Spotifyn ymmärtämättä sopimusehtoja. Kun tilasin lapsilleni crocseja, sain mm. selville että ko. merkin saksalaisen verkkokaupan valikoima poikkesi hieman suomalaisen verkkokaupan valikoimasta, mutta kenkien toimitusosoitetta ei ollut kuitenkaan rajoitettu maantieteellisesti.

Kun on itse ollut testaamassa verkkosivustoja, joissa on "tietenkin" vähintään kolme kieliversiota Suomessa asuvien ihmisten tarpeisiin, tuntuu hassulta, että yritykset, joilla täytyy olla olemassa jokaiselle myyntiartikkelilleen lukuisia kieliversioita, eivät tule ajatelleeksi että joku heidän sivustonsa käyttäjä saattaisi haluta asioida muulla kuin saksan kielellä ottaessaan palveluun yhteyttä Saksasta. (Toki tuntuu myös hassulta, että jos nettikaupat on rajattu kieliversioihin sillä ajatuksella, että asiakas saisi aina tuotteensa lähimmästä varastosta, tuo rajaus koskee nimenomaan asiointikieltä eikä toimitusosoitetta.) Toisaalta, kieliversioita testanneena ymmärrän myös, että niiden lisääminen on vähän sama asia kuin tuettujen selainten lisääminen - pienet muutokset lisäävät työmäärää yllättävän paljon.

Tässä listattuna muutamia asioita, joita kannattaa miettiä kieliversioita testattaessa:

• Löytääkö käyttäjä kielenvaihtotoiminnon?
• Mihin käyttäjä ohjautuu vaihtaessaan kieltä? Jos sivun pitäisi pysyä samana millä käyttäjä on kieltä vaihtaessaan (mikä on omasta mielestäni käyttäjäystävällisin vaihtoehto, sisäsivuille kuitenkin yleensä päädytään siksi että ollaan kiinnostuneita juuri sen sivun sisällöstä), mitä tapahtuu jos ko. sivulta puuttuu tuo toinen kieliversio?
• Jos saman sivun eri kieliversiot ovat julkaisujärjestelmän näkökulmasta sama sivu, vaikuttaako pääkieliversion puuttuminen siihen miten ko. sivun muut kieliversiot toimivat? 
• Onko yhteisiä elementtejä, jotka näkyvät samanlaisina kaikissa kieliversioissa? Jopa yhteiset kuvat voivat aiheuttaa ongelmia. Näkyykö käyttöliittymässä väärän kielisiä tekstejä?
• Tehdäänkö käyttäjästä kielen perusteella oletuksia (esim. osoitteen maa-tieto, kansalaisuus), ovatko ne ko. palvelun kannalta mielekkäitä oletuksia, ja ovatko ne käyttäjän vaihdettavissa jos oletukset ovat virheellisiä?
• Löytyykö palvelusta kokonaisuuksia, joihin mennessä kielivalinta nollautuu?
• Näkyvätkö kielikohtaiset erikoismerkit (å, á jne) oikein?
• Miten sanojen pituudet vaikuttavat käyttöliittymän elementteihin? Esim. mahtuvatko nappien tekstit nappeihin, tai hajoaako leiska kun joku elementti on isompi tai pienempi kuin mitä graafikko oli ajatellut? Onko muita ulkoasullisia eroja kieliversioiden välillä, esim. etusivun elementtien käytössä tai navigaatiolinkkien määrässä, ja miten hyvin ne toimivat?
• Yllättävätkin asiat voivat olla hajalla kieliversiokohtaisesti. Kieliversioihin päteekin pitkälti sama asia kuin selaimiin, testaajan ei kannata keskittyä ensisijaisesti samaan kuin mitä kehittäjä käyttää.

Tuleeko mieleen muuta olennaista?

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.

Kun aika ei vain riitä - hajanaisia ajatuksia

Talvi on kulunut töissä vauhdikkaasti. Tuotteemme on ollut poikkeuksellisessa myllerryksessä, jonka myötä sen toimintalogiikka on jatkossa aikaisempaa helpommin yleistettävissä uusiin tarpeisiin. Käyttöliittymän kautta katsoen muutokset ovat suuria, mutta konepellin alla on tapahtunut paljon enemmän. Nyt muutos on vihdoin saatu kokonaisuudessaan tuotantoon, ja tuotekehityksessä voidaan taas palata normaalimmille urille. Kiire ei toki mihinkään ole häviämässä, uutta pitää tehdä koko ajan, ja rosoja viilailla siistimmiksi. Pitää ottaa askel taakse, katsoa kokonaisuutta kriittisesti ja löytää paikat joissa on kenties oiottu liikaa.

Arki vie helposti mennessään, tekeminen taantuu suorittamiseksi. Taustalla kulkee kuitenkin koko ajan ajatus siitä, miten asioita voisi tehdä paremmin, mitä uutta pitäisi oppia. Kiireessä ne ajatukset eivät vain aina pääse kiteytymään niin nopeasti kuin toivoisi. Eikä työ ole ainut, mikä vie. Lapset tarvitsevat aikaa, harrastukset ja vapaaehtoistyö vievät aikaa. Nukkuakin täytyy, nykyään aika paljonkin. Kaikkeen ei vain ehdi.

Omaa ammatillista kehittymistäkin voi miettiä monella tavalla. Mihin suuntiin haluan syventää, mihin laajentaa. Jälkimmäisessä mahdollisuudet tuntuvat nyt lähes rajattomilta, mutta kaikkiin tilaisuuksiin ei voi tarttua kerralla, tai muuten fokus hajoaa ja se perustyö jää retuperälle.

Myös jakamisen tavat mietityttävät. Pitäisikö kirjoittaa muutakin kuin blogia? Riittääkö aika osallistua johonkin, missä on ulkoa annetut aikataulut? Saisinko aikaan enemmän, jos minulla olisi dl? Mistä minulla on tarpeeksi sanottavaa, ja osaanko muotoilla sen kiinnostavasti?

Nämä pohdinnat saivat yllättävää vauhtia, kun minut kutsuttiin puhujaksi Ohjelmistotestaus 2016 -tapahtumaan. Tuntuu aika huikealta saada tällainen tilaisuus, kun listalta myös puuttuu joitakin nimiä joiden esityksiä mielelläni kuulisin. Odotan mielenkiinnolla, mitä tästä tulee.

Priorisointia, tavoitteita ja tehtävänhallintaa

Joulukuu kului joulukiireissä, joten jäi blogin kirjoittaminen taas vähemmälle. Testaukseen liittyviä ajatuksia loppuvuosi herätteli työn lisäksi parinkin testaukseen liittyvän tilaisuuden tiimoilta.

Toinen näistä oli testausyhdistyksen järjestämä teemailta, jonka aiheena oli ajanhallinta. Teemu Vesalan ansiokkaan alustuksen pohjalta keskusteltiin erilaisista haasteista, joita oman työn aikatauluttamiseen liittyy.

Aihetta käsiteltiin monesta kulmasta, erityisesti haasteena nostettiin esiin mahdollisuudet uppoutua keskeytyksettä työhön ja toisaalta myös irtautua siitä. Keskustelu oli kiinnostavaa ja tarjosi hyviä uusia ajatuksia, vaikka monet näkökulmat muistuttivatkin minua lähinnä siitä, miksi olen nauttinut niin paljon mahdollisuudesta siirtyä isosta firmasta pieneen.

Minun ajankäytölliset haasteeni eivät tällä hetkellä liity siihen, että kalenterini täyttyisi turhista palavereista, joihin on vaellettava valtavan rakennuksen toisesta päästä toteamaan, että tapaamisen avainhenkilöt eivät ole edes tulossa paikalle. Työsähköpostini ei täyty kummoistakaan vauhtia, eivätkä työtäni rajoita byrokraattiset käytännöt, joista ei itse työn kannalta ole mitään hyötyä. Organisaation sisäisten siilojen väliset haasteet ovat muisto vain.

Sen sijaan haasteita syntyy ajankäytön priorisoinnista, tekemisen fokuksoimisesta ja tehtävänhallinnasta.


Kun on kiire saada valmista, tekemistä täytyy priorisoida. Se tarkoittaa sitä, että oleellisimmat asiat tehdään mahdollisimman hyvin, ja vähemmän tärkeät unohdetaan väliaikaisesti.

Tällaista toimintatapaa voi perustella useammallakin tavalla.

Ensiksikin, joskus deadlinet ovat ihan aitoja deadlineja. Jos ominaisuus X ei ole vielä ollenkaan käytettävissä kun sitä pitäisi esitellä messuvieraille, tai asiakkaan aikataulukriittinen asia Y pitäisi saada vietyä sillä läpi, aikataulua venyttävä pilkunviilailu tulee kalliiksi.

Toisekseen, joskus asiakkaasta on mahdotonta saada irti riittäviä tietoja jonkin toiminnallisuuden valmiiksisaattamiseksi ennen kuin hänet päästetään koekäyttämään sitä. Silloin ei välttämättä ole tarkoituksenmukaista tehdä sitä kovin pikkutarkasti heti ensimmäisellä kierroksella.

Kolmanneksi, työtä voi sisäisessäkin kehityksessä tehdä ja jaksottaa eri tavoin. Yhden päivän aikana ei voi tehdä kaikkea, eikä testausta ole mielekästä lähestyä joka kerta täsmälleen samalla tavalla. Vain pieni osa tehtävistä on sellaisia, joissa pikaisesta vilkaisusta ennen seuraavaa kontekstin vaihtamista olisi minkäänlaista hyötyä, ja siksi työtä pitäisi saada tehdä riittävän pitkinä sessioina. Toisaalta usein tauon ottaminen on välttämätöntä uusien lähestymistapojen löytämiseksi, ja siksi myös mahdollisuus vaihdella tehtävien välillä on hyvä asia. 

Nämä kaikki asiat vaikuttavat siihen, että kaikkea ei tehdä kerralla täydellisesti, vaan tietyt polut ja tietyt piirteet jäävät perusarjessa vähäisemmälle huomiolle kuin toiset.

Priorisoinnissa on kuitenkin riskinsä.

Yksi riski on vääränlainen priorisointi, eli se että keskitytään kuitenkin vääriin asioihin, tai ainakin jotain tärkeää jää huomaamatta.

Toinen asia on jälkien siivoaminen deadlinen jälkeen. Jääkö tekemisen puutteista riittävät tiedot, että tekemätön työ on mahdollista muistaa dl:n jälkeen? Tuleeko se tehtyä? Onko olemassa jonkinlaista suunnitelmaa, miten epämääräiseksi jääneet asiat saadaan tarkentumaan? Onko analysoitu asiakkaan tarvetta käyttöönottoon liittyvään lähitukeen? Ymmärtävätkö kaikki, että vielä ei ole valmista, vaikka lyhyen tähtäimen tavoite saavutettiin?

Ajanhallinnan kannalta haasteellista on löytää tapa huolehtia aikataulukriittisten asioiden riittävän nopeasta etenemisestä pitäen samalla vähemmän kiireiset asiat aidosti työlistalla, niin että nekin tulevat hoidetuksi. Jatkuvalla kiireellä on tapana pitkällä aikavälillä kostautua. Teknisen velan lisäksi ongelmaksi saattaa muodostua se, että tuotteen kasvaessa pienen prioriteetin asioiden imagovaikutus voi käyttäjän silmissä kasvaa yllättävän merkitykselliseksi.

Samalla omaa tekemistä pitää osata arvioida kriittisesti. Tuliko työ tehtyä riittävän hyvin? Tuliko mieleen asioita, jotka olisi syytä lisätä backlogiin? Oliko tekeminen hyödyllistä? Mikä on oleellista siinä mitä teen, ja miten pian tätä on tarpeen arvioida uudelleen? Mikä minua juuri nyt häiritsee käsillä olevien tehtävien asettamien tavoitteiden ulkopuolella? Mitä minun juuri nyt olisi hyödyllistä opetella? Onko jotain mihin liittyen pitäisi pyytää apua?

Rutiinien keskellä on löydettävä tavat katsoa tilannetta konkreettisten tehtävien ulkopuolelta ja saada palautetta tekemästään työstä. Asettaa pidemmän tähtäimen tavoitteita ja etsiä uutta. Kyseenalaistaa.

Jotta tämä olisi mahdollista, on löydettävä säännöllisesti tilaisuuksia irtautua projektia suoraan edistävistä tehtävistä. Vähän päivittäin, ja silloin tällöin ihan kunnolla.

Näin ruuhkavuosirumban keskellä tuntuu välttämättömältä, että tähän voi varata myös ihan oikeaa työaikaa. Silti sen ajan ottaminen vaatii hieman itsekuria.


Minulle luontevin tapa jäsentää ajatuksiani on kirjoittaminen. Alkavan vuoden tavoitteisiin voisinkin asettaa aktiivisemman blogin kirjoittamisen. Aika näyttää, kuinka moni sepustukseni lopulta tulee julkaistua. Toivottavasti lopputuloksesta on iloa myös muille.