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 :)
sunnuntai 25. syyskuuta 2016
torstai 15. syyskuuta 2016
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.
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.
Tilaa:
Blogitekstit
(
Atom
)