perjantai 10. helmikuuta 2017

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.

tiistai 8. marraskuuta 2016

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?

maanantai 17. lokakuuta 2016

Kuka maksaa ja kenen kortilla?

Minulla on ikävä taipumus toivoa softilta ominaisuuksia joita niiden speksaajat eivät ole nähneet tarpeellisiksi toteuttaa. Yksi alue, jolla olen erityisen hämmästynyt valtavasta kuilusta omien toiveitteni ja vakiintuneiden toteutusten välillä liittyy verkkomaksamiseen.

Netissähän on äärimmäisen helppoa maksaa. Ei tarvitse kuin syöttää luottokorttitietonsa lomakkeelle voidakseen tehdä ostoksia mistä päin maailmaa tahansa. Monet palvelut käyttävät vakiintuneita maksamissovelluksia kuten PayPalia, mikä lisää luotettavuuden tunnetta ja helpottaa elämää kun niitä luottokorttitietoja ei tarvitse joka kerta syöttää erikseen. Myös älypuhelinten sovelluskauppoihin voi helposti tallentaa luottokorttitietonsa, minkä jälkeen ostosten tekeminen on äärimmäisen helppoa.

Mikä minua sitten riepoo?

Käyttötapaus 1: Mainosajan ostaminen yhdistykselle


Harrastan yhdistystoimintaa ja siihen liittyen osallistun yhdistyksemme Facebook-sivun ylläpitämiseen. Silloin tällöin meillä on tapahtumia, joita on tarpeen mainostaa, ja tällä hetkellä tähän järkevin kanava on Facebook. Se tarjoaakin helpon työkalun tapahtumien maksulliseen promoamiseen PayPalin avulla.

Se mikä itseäni toteutuksessa korpeaa on, että minun oletetaan yksinkertaisesti syöttävän maksutietoni ja jäävän tyytyväisenä odottelemaan kampanjan etenemistä.

Kun ensimmäisen kerran syötän Facebookiin PayPal-tunnuksiani, minulle ei millään tavalla kerrota, edellytetäänkö minulta myös seuraavalla kerralla kirjautumista PayPal-tunnuksilla (ei edellytetä). Minulle ei myöskään kerrota, liitetäänkö PayPal-tunnukseni henkilökohtaiseen tiliini vai promottavan yhdistyksen tietoihin. Jälkimmäinen vaihtoehto toki tuntuu epätodennäköiseltä, mutta kun kuitenkin suoritan maksua yhdistyksen profiilin kautta, ja tuohon samaan profiiliin on liitetty useita henkilökohtaisia facebook-tunnuksia, minun mieleni olisi aika paljon kevyempi jos minulle ihan eksplisiittisesti kerrottaisiin, että muilla tunnuksilla kirjautuneet eivät pääse tekemään yhdistyksemme nimissä ostoksia minun luottokortillani. Toki voi olla että Facebook ei tiedä vastausta tähän kysymykseen. Joskus vähemmän tärkeät asiat vain toimivat niin kuin ne sattuvat toimimaan kenenkään ottamatta kantaa siihen miten niiden pitäisi toimia.

Sinänsä koen hieman hermostuttavaksi myös sen, että omalta facebook-tililtäni voi koska vaan tehdä PayPal-maksuja kirjautumatta erikseen PayPaliin. Olisi naiivia ajatella, että kukaan muu ei voisi koskaan kirjautua facebookiin minun käyttäjätunnuksellani. Eikä salasanaani edes tarvitse saada selville, jos vie kännykkäni. Yksi suuria pettymyksiäni iPhonen kanssa oli se että puhelimen lukituskoodiin ei saanut kuin neljä merkkiä, mikä tekee sen luvattoman avaamisen ihan mahdolliseksi. Ja jos sen saa auki, pääsee kirjautumatta käsiksi niin sähköposteihini kuin sosiaalisen median tileihini. Toki jos näin käy, facebook-mainosten ostaminen luottokorttitiedoillani on todennäköisesti huolistani vähäisin. Silti, ihan periaatteen vuoksi, nukkuisin yöni paremmin jos jokainen maksutapahtuma luottokortiltani vaatisi erikseen kirjautumisen PayPaliin. Nyt saan tämän toteutumaan vain vaihtamalla PayPal-tilini salasanaa jokaisen facebook-maksun jälkeen. Kuinka käytännöllistä!

Käyttötapaus 2: Lapsen mobiilipelit


Meidänkin talouteemme on saatu erilaisia mobiililaitteita, joihin voi ladata jos jonkinlaista peliä. Monet pelit maksavat vähän rahaa, ja ilmaispeleissäkin pelaaminen usein muuttuu mielekkäämmäksi jos ostaa siihen vähän jotain ihan oikealla rahalla. Tämä on ihan fine, olen oikein tyytyväinen jos lasteni kulutustottumukset muuttuvat aineettomampaan suuntaan, sanotaanko vaikka että taloudessamme on jo ihan riittävä määrä Lego-palikoita.

Se mikä minua riepoo, on taas kerran se, että lasteni käyttämät mobiililaitteet ottavat auliisti vastaan luottokorttitunnukseni, mutta eivät kerro, miten helppo niillä on tehdä uusia ostoksia.

Surfacen sovelluskaupan sain aikanaan toimimaan niin, että lapset kirjautuivat laitteelle omilla tunnuksillaan mutta sovelluskauppa vaati minun tunnukseni, ja tällöin maksamisen yhteydessä vaadittiin aina kirjautumista erikseen. Kännyköihin en ole löytänyt tällaista vaihtoehtoa. Oletusarvoisesti luottokorttitiedot syötetään laitteeseen suoraan, minkä jälkeen lapsi saa omilla tunnuksillaan tehdä ostoksia vapaasti.

Esimerkiksi Momio kertoo rajoittavansa käyttäjien ostoksien euromäärää jättilaskujen ehkäisemiseksi, mutta itse koen että jättilaskut eivät ole se suurin ongelma. Ne huomataan, ja niistä voi saada rahansa takaisin. Sen sijaan pienemmät ostokset voivat jäädä luottokorttilaskulta huomaamatta, ja niistäkin voi ajan mittaan kertyä melkoiset summat. Haluaisin tietää ennen kuin ostan nyt alennuksessa olevan Momio Plussan lapselleni, onko minulla tuon ostoksen jälkeen muuta tapaa estää lastani tekemästä lisää ostoksia luottokortillani kuin pyytää pankkiani mitätöimään korttini ja lähettämään minulle uuden.

Tykkään siitä perinteisestä toimintatavasta, jossa lapsen viikkorahan suuruuden päättävät vanhemmat. Avoin piikki luottokortilleni on aivan tolkuton ajatus. Sitä paitsi eikö toisen henkilön luottokortilla maksaminen ole luvatontakin, saati sitten luottokortin antaminen alaikäiselle? Vai voinko yhtä hyvin antaa lapselleni sirukorttini PIN-koodin ja pyytää häntä käymään itse sen kanssa vaikkapa vaateostoksilla?

Olenko vanhanaikainen?


Maksamiseen liittyen on helppo keksiä muitakin potentiaalisia ongelmia. Itse kuitenkin näen keskeisimpänä sen, miten varmaankin käytettävyyttä kovasti ajatellen tällaiset workflowt tehdään mahdollisimman helpoiksi. Käyttäjää ei häiritä asioilla jotka voisivat saada hänet kyseenalaistamaan, kannattaako luottokorttitietojaan tuupata ihan joka paikkaan. Onko tämä alennus todella sen arvoinen, että jätän taas kerran luottokorttipiikkini jossakin auki?

Ennen aikaan kirjautumistietoihin suhtauduttiin vakavasti, nykyään monilla on niin valtava määrä kirjautumista vaativia järjestelmiä että sitä helposti huokaisee helpotuksesta kun uuteen järjestelmään voikin kirjautua suoraan Google-tilin tai Facebook-tilin avulla, tai tunnukset voi tallentaa selaimen muistiin.

Olisi kuitenkin hyvä, jos järjestelmät aina mahdollistaisivat myös vanhanaikaisen, varovaisen käyttötavan.

En näe kovin vaarallisena, jos joku saa selville tunnukseni vaikkapa verkko-Hesariin tai johonkin nettikauppaan, josta tilaaminen onnistuu vain maksamalla ostokset verkkopankissa. Koen hyvin huolestuttavana, että nuo tunnukseni ovat paremmin suojassa kuin luottokorttitietoni.

Ja tästä syystä olen se natsimutsi jonka lapset jäävät paitsi monesta sellaisesta, joka "kaikilla muilla" kuulemma on.

sunnuntai 2. lokakuuta 2016

Mixed thoughts about context and diversity

This is a strange post in many ways. First of all I usually blog in Finnish because I feel the English speaking testing blogosphere is quite well populated without me unlike the Finnish one, and that's why my intention is to stick with Finnish. Only this time it's not an option because my thoughts are related to a conversation conducted in English. Secondly, my goal in this blog has been to mainly stick with subjects that are quite concretely related to work and this time I'm definitely not doing that. Third, this is a subject that is actually none of my business, I'm just having difficulties keeping my mouth shut. It's about the slide incident, which I did not witness as it happened, I've just been reading about in twitter and in many blog posts, the most relevant ones being from the people who are the actual parties of the incident, Maaret Pyhäjärvi and James Bach.

I'm one of those nice people who like to try to see good in other people even when they behave badly. So I'm not going to speculate on anyones intentions on this issue. I really don't know about that, I'm just under impression that the interpretation of the slide may have been influenced by older incidents. That's what we humans do, we interpret other peoples intentions by how they make us feel and how we see their behavior in respect to our current view of the world and our impression of the person who we are observing. (If you are interested to read more about these phenomena, google Correspondent inference theory.) And this affects on both sides of the incident.

All I'm saying about what happened is that in my opinion the slide would have been ok if it had been given another title not mentioning Maaret. The contents of the slide may tell a lot about the presenter himself and with that title it also gives impressions about his views on Maaret as a person. But even after reading James' explanation on it I find it really hard to see how it tells anything about Maaret, who explains the misinterpretations in her most recent blog post about the incident.

So what makes me curious is how come it is possible to make such big misinterpretations about another persons point of view.

I can't help but to take a rather feminist approach on the subject. There are three clear aspects in the incident that bring to mind the concept of priviledge.

I understand that this is an approach that easily raises difficult emotions so I start by a disclaimer that I fully understand that there may be aspects by which the situation is quite the opposite or by which the situation can be viewed as an argument between two equals. But I find these three aspects quite crucial when considering how the testing community is shaping it self. Who will feel priviledged to be included and who will feel safe to contribute. So these thoughts go beyond Maaret and James and the slide. They are questions to the community on what should be the role of diversity in the future of testing.

The gender talk


When a woman is accused by a man of avoiding debate and valuing niceness over facing facts we are pretty much in the heart of gender stereotypes. It could be that the accuser makes his interpretations through lenses of gender stereotypes, or it is possible that he fails to see how the world works differently for a woman than for a man.

When it comes to how you can build your role in a work environment, the gender issue can actually make a huge deal on how you can get your ideas through. Men may need to have a role of a strong and fearless leader to be taken seriously when raising surprising issues. But a woman is expected to treat people nicely and support men. We are supposed to let men take the leaders role, and when we feel that they are leading us in wrong direction, we are not supposed to speak out about that but rather feed hints to let them realize the situation and make right conclusions themselves. A woman talking like a man is pretty easily stigmatized as a bitch and after that it becomes difficult to get any type of interaction to proceed like things should proceed between adults.

Of course there are huge differences between people and workplaces, most people I've had the pleasure to work with have treated me more as a person (or as a tester) than as a woman, but when facing a new team you always have to be aware that there may be someone who has issues with getting feedback from a woman.

So when we talk about building a testers role as a person who gives feedback that should lead to someone changing the code or changing specifications or expectations or anything, we need to have views from both genders.

But I don't see a reason to highlight that difference. Taking how much we talk about being context driven, it should be obvious that when listening to conference talks we all choose the advice that suit us best. And the more diverse the presented views are, the more chances that everyone will find something useful.


The culture talk


In twitter the conversation has been quite much about whether nice and authentic are contradictory or not. This brings us to the culture talk.

We Finns are raised to value honesty and straight talk. Traditionally we don't do small talk and we don't say polite things unless we really mean them. Finnish writer Jari Tervo has compared us to autistic people, arguing that many things that are related to the spectrum of autism are pretty normal for us Finns.

A story tells about a Finnish manager who delivered a speech in Italy about the situation of their company. Understanding that the Italian employees were not used to such straight words about negative issues he ended his speech saying "I know this didn't sound nice but at least I was being honest." The Italians found this hilarious.

The social rules are very culture specific, and when a Finn talks about growing to being a kinder person towards others, you should interpret it from a perspective that it's a Finn speaking. Naturally you have to know some Finnish people to be aware of this. It is understandable that an American does not know about the peculiarities of the Finnish culture, after all we are an extremely small minority in the global perspective.

But when interpreting another persons intentions it would be good to understand that their cultural context may be very different and that affects on their views. The point where they started their journey was different, and therefore even if their direction is different than yours they may actually be coming closer to you. And if they are actually diverted away from you it may be because that's the only reasonable direction in their culture. A tester from India probably sees niceness quite differently than Finns or Americans.

So I would claim that some important aspects of a testers role are culture specific. Though we all have some idea about American culture we don't all live in it. If conferences are supposed to serve the needs of all testers, there should also be cultural diversity. This is not nourished by emphasizing the interpreted defectiveness of another persons views but concentrating in sharing what are the key points in each speakers own perspective.

The language talk


One more aspect is our mutual language. The most commonly spoken language in the world is probably bad English, as most of us speak some other language as our native tongues.

Language gives us the building blocks of thinking. It forms how we experience emotions, what phonems we are able to distinguish and how we comprehend the world around us. When you switch to another language, you also need to switch to another way of categorizing things. There are surprisingly few words for which the translation is not context specific, which is quite well demonstrated in the nine meanings of "kuusi palaa".

The fact that not all of us are communicating in our native languages emphasizes the importance of explaining our most essential words. It is important to be specific and to discuss the differences of concepts. But it also makes it important to understand that a careless choice of words does not always mean that the other person is deliberately choosing the meaning that comes to your mind. With Maaret this is not a big issue as she speaks and writes very fluently in English, but nevertheless she does not have the priviledge to express herself on her native tongue. How she is treated affects on other peoples willingness to open their mouths.

If we want to support diversity, we need to be able to do the refinement of words in a kind manner. Picking on a person for single words is one way to make sure that the pool of people sharing their thoughts publicly does not get new members easily.

So where are we heading?


To me one of the most fascinating things about testing is diversity. There are so many contexts to which to apply the empirical approach of a tester. So many ways of working and so many ways to position oneself in respect to other roles. So much to learn and so many views to take to sharpen ones mind. And even though the software industry is very male dominant, in testing we have many women both doing the silent work and leading the way.

One of the most revolutional ideas of the industry has been stating that there are no best practices. Another mind blower for me has been "QA stands for Question Asker" which I learned at a Janet Gregory workshop last year. We are working on a craft where discipline and systematic thinking meet curiosity, creativity and intuition.

So the question is, is the testing community willing to live up to these ideas? To accept that what's best for me may not work for you but we can still learn from one another. To question rather than suppress. To convince by sharing ones best, not by judging what feels difficult to understand. To cherrish diversity instead of letting only the priviledged speak for the industry.

And if it is, are there actions to be taken to achieve this?

sunnuntai 25. syyskuuta 2016

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 :)

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.

keskiviikko 25. toukokuuta 2016

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?