tag:blogger.com,1999:blog-83080968081577905612024-02-19T08:20:00.969+02:00SavutestiAjatuksia ohjelmistotestauksesta ja sen liepeiltä.Unknownnoreply@blogger.comBlogger48125tag:blogger.com,1999:blog-8308096808157790561.post-21591855247972256612020-01-19T21:54:00.000+02:002020-01-19T21:54:21.235+02:00Mene meetupiin!Osallistuin viime torstaina testausaiheiseen <a href="https://www.meetup.com/helsinki-software-testing/">meetup</a>iin. Tapahtuman otsikkona oli Exploring Allure. Googlaamattakin oli selvää, että kyse tuskin olisi työkalusta, jonka ottaisin ensi viikolla käyttöön työssäni. Tämä olisi sitä <i>toisenlaista</i> testaamista, jota en koe osaavani.<br />
<div>
<br /></div>
<div>
Vielä samana päivänä mielessä risteili ristiriitaisia ajatuksia: Siitä ei varmaan ole suoraa hyötyä työni kannalta. Siellä on vieraita ihmisiä. En tiedä, mitä siellä tapahtuu. Se vie matkoineen ihan koko illan. En oikeastaan edes tiedä, mihin olen menossa. Entä jos en ymmärrä siitä yhtään mitään?</div>
<div>
<br /></div>
<div>
Menin kuitenkin, koska tässä oli tarjolla helppo tapa päästä juttelemaan muiden testaajien kanssa, ja ajattelemaan jotain vähän uudenlaista. Jos ei koskaan poistu mukavuusalueeltaan, on kovin vaikea oppia mitään uutta.</div>
<div>
<br /></div>
<div>
Löysin itseni tutkimasta testausraportointityökalun käyttöä mob-koodauksen keinoin. </div>
<div>
<br /></div>
<div>
Ryhmä toimi tosi hyvin yhteen siihen nähden, että olimme aika vieraita toisillemme. Omaa epävarmuutta helpotti kovasti, ettei kukaan muukaan osannut asiaa täydellisesti. Ratkaisut löytyivät keskustellen, ja lopulta tuntui ettei ollut juuri väliä, kuka oli navigaattorin tai driverin roolissa. Tehtävänasettelu oli riittävän kapea, ettei päämääristä tarvinnut vääntää kättä, ja päämäärät riittävän yksinkertaisia, että niiden toteutuksessa pysyi varsin hyvin kärryillä, vaikka asia oli alkuun vierasta.</div>
<div>
<br /></div>
<div>
Kun tekee jotain uutta, oppii jotain uutta, jos vain antaa itselleen mahdollisuuden oppia. Joskus opit liittyvät yllättäviin asioihin, tai niistä saavuttaa hyötyjä yllättävissä yhteyksissä. Mitä enemmän ymmärtää itselleen vieraiden roolien tekemistä, sitä helpompaa on luoda siltoja niitä kohti, osallistua keskusteluihin, esittää kysymyksiä, tuoda ymmärrettävästi esiin omia näkökulmiaan, saada rakennettua jotain uudenlaista. Siksi hyötyjä saa myös sellaisten asioiden oppimisesta, joille ei heti keksi käytännön sovelluksia omassa tekemisessään. Ja pitkällä tähtäimellä omakin rooli voi muuttua tavoilla joita ei juuri nyt näe mahdolliseksi.</div>
<div>
<br /></div>
<div>
Oppiminen myös tapahtuu tavallaan portaittain, aina aikaisemman tiedon päälle, ja sitä kautta samojenkin asioiden läpikäynnistä voi eri kerroilla oppia eri asioita. Vieraat asiat muuttuvat vähin erin tutummiksi. Askel kerrallaan, vaikka ne askelet olisivat ajallisesti kaukanakin toisistaan.</div>
<div>
<br /></div>
<div>
Session jälkeen istahdimme osalla porukkaa vielä yksille juttelemaan. Ilmeni, että joukossa oli yksi kehittäjä joka ei edes asunut Suomessa, sekä yksi matkaopas. Että ehkä testaajana on turha tuntea itseään ulkopuoliseksi testaajien meetupissa, vaikka käsiteltävä aihe ei osuisi ollenkaan omalle osaamisalueelle.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-13404535426697653172018-05-06T11:50:00.000+03:002018-05-06T11:50:35.345+03:00Kukaan ei halua käyttää softaasiKipeä totuus, jota joidenkin ohjelmistotaloissa työskentelevien tuntuu olevan vaikea ymmärtää, on että kukaan ei oikeasti halua käyttää sitä softaa jota teemme.<br />
<br />
Jos mielesi tekee nyt väittää vastaan, mietipä hetki, miksi some- ja pelimaailmassa käytetään niin paljon keinoja, jotka luovat käyttäjille addiktioita. Ne tarjoavat käyttäjilleen mukavaa ajanvietettä, mutta joutuvat silti itse luomaan käyttäjille tarpeen palata.<br />
<br />
Käyttäjän tarpeet ovatkin keskeinen syy siihen, miksi ohjelmistoja käytetään. Jos ohjelmiston avulla pystyy tekemään työnsä nopeammin, helpommin ja laadukkaammin kuin ilman, todennäköisesti ihmiset käyttävät tuota ohjelmistoa työssään, jos siihen vain on mahdollisuus.<br />
<br />
Se ei kuitenkaan tarkoita, että he haluaisivat käyttää sitä ohjelmistoa. Ei, he haluavat saada työnsä vaivattomasti tehtyä.<br />
<br />
Miksikö tämä on oleellista ymmärtää?<br />
<br />
Siinä missä rakentamamme softa on meille itsellemme koko elämä, asiakkaillemme se on vain pieni osa heidän työtään, yksi työkalu muiden joukossa. Meidän täytyy ymmärtää sitä ympäristöä, jossa tuotetta käytetään, jotta voisimme ymmärtää, millainen tuote palvelisi asiakkaitamme parhaiten. Testaaja, joka ei ymmärrä todellisten käyttäjien toimintaympäristön haasteita, saattaa hyvinkin priorisoida aivan vääriä asioita tehdessään valintoja, mitä osa-alueita tarkastella kriittisesti ja mitä havaintoja raportoida.<br />
<div>
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-19386261093937195792017-11-05T13:29:00.000+02:002017-11-06T17:27:01.138+02:00Lahja, joka maksoi asiakkuudenYleinen vitsi on, että testaajan käsittelyssä kaikki vain hajoaa. Näin näyttää käyvän silloinkin, kun testaukseen käytettävä rajapinta on yrityksen asiakaspalvelu.<br />
<br />
<br />
Minulla on täti, joka on jo vuosia kantanut huolta siitä, että meille ei kanneta aamuisin lehteä. Olen koittanut rauhoitella häntä kertomalla, että luemme kyllä uutiset netistä, mutta tämä on sen verran kaukana hänen kokemusmaailmastaan että viestiä on ollut vaikea saada perille.<br />
<br />
Viime keväänä hän soitti minulle ja kertoi tilanneensa minulle ystävänpäivätarjouksena viikonlopun lehdet kotiin kannettuna. Innoissaan hän selitti, että siihen pakettiin kuuluvat myös tunnukset digilehteen, niin voin lukea arkilehdet sieltä netistä.<br />
<br />
Muuten hyvä, mutta en oikeastaan halunnut lisää keräyspaperia ulos kannettavaksi, ja itse asiassa minulla oli jo tilaus ko. lehden digilehdestä. Jäin vain pohtimaan, voisiko mediatalolla olla riittävän fiksut tietojärjestelmät, että oman tilaukseni laskutuskautta muutettaisiin automaattisesti niin, että minun ei tarvitsisi maksaa digilehdestäni samaan aikaan kun tätini maksaa minulle sitä.<br />
<br />
<h3>
1) Sopimuksen sisältöä voi muuttaa kertomatta tilaajalle</h3>
<br />
Kun sitten sain lehdeltä kortin, jossa kerrottiin lahjatilauksestani, selvisi, että he aikoivat kantaa lehdet edelliseen osoitteeseeni. Tämä johtui siitä, että heillä oli entuudestaan olemassa osoitetietoni, koska vielä muutamia vuosia sitten meille tuli lehti kotiin kannettuna. Olin muuttanut hiljattain, ja koska luin vain digilehteä ja sain laskuni sähköisesti, olin unohtanut ilmoittaa osoitteenmuutoksesta. Tätini oli kyllä tilaukseen ilmoittanut uuden osoitteeni, mutta tällä ei ollut merkitystä, koska tätini ei voi muuttaa minun asiakastietojani.<br />
<br />
Ymmärrän hyvin, että tätini ei voi muuttaa asiakasjärjestelmän tietoja, jotka koskevat omia tilauksiani. Olen kuitenkin aika hämmästynyt, jos lehti, jonka voi kesälomalla kääntää mökille, ei ole osannut rakentaa asiakastietojärjestelmäänsä tavalla, joka mahdollistaisi sen että lahjatilaukseni kannetaan eri osoitteeseen kuin minkä olen itse heille joskus muinoin ilmoittanut. Voihan myös lahjatilaus kohdistua vaikka loma-asuntoon tai putkiremonttievakon aikaiseen asuntoon.<br />
<br />
Tai osoiteristiriidan huomatessaan he olisivat ehkä voineet soittaa minulle. Tekee lahjan saamisesta melko monimutkaista, että lahjan saajan on itse otettava yhteyttä asiakaspalveluun selvittääkseen osoiteasiansa.<br />
<br />
Sitäpaitsi, mistä he tiesivät yhdistää tilauksen minun asiakastietoihini?<br />
<br />
<h3>
2) Voit laskuttaa tuotteesta "kahvi ja pulla" vaikka asiakas saisi vain pullan</h3>
<br />
Koska minulla ei ollut erityistä halua saada paperilehtiä, ja päivissäni on ihan riittävästi tekemistä ilmankin että joudun selvittelemään, mitä kautta ko. lehti suvaitsee ottaa vastaan asiakkaidensa yhteydenottoja, en heti tehnyt mitään asialle. Mutta kun sitten oman tilaukseni laskutuskausi päättyi kesken lahjatilauskauden, ja sain laskun seuraavasta laskutuskaudesta joka alkaisi kesken lahjatilauksen, ajattelin että en kyllä lähde maksamaan uutta laskua palvelusta jonka saan jo lahjana. Niinpä soitin asiakaspalveluun.<br />
<br />
Asiakaspalvelussa minulle ystävällisesti kerrottiin, että todellakin, koska viikonloppulehdet+digilehti on eri tuote kuin digilehti, niistä voidaan tehdä päällekkäiset tilaukset. Uuden laskun hyvittäminen onnistui kuitenkin helposti, joten en viitsinyt ruveta kyselemään, mahtaisiko ko. lehtitalon kahviossa olla ok. toimintatapa myydä tarjouksella tuotetta "kahvi ja pulla", antaen pelkkä pulla niille joiden kahvimuki sattuu tarjoushetkellä olemaan täynnä. Veikkaan että tällaisessa tilanteessa moni kahvion pitäjä lupaisi ihan oma-aloitteisesti että santsikupin saa hakea ilmaiseksi, mutta lehtitilauksissa tällainen järjestely vaatii siis sitä että asiakas itse ottaa yhteyttä asiakaspalveluun. Entä miten olisi mahdettu menetellä tilanteessa, jossa oma tilaukseni olisi sisältänyt digilehden lisäksi kaikki paperilehdet? Tuote olisi silloinkin ollut eri kuin digi+viikonlopun lehdet, olisinko silloin hyötynyt lahjasta muuta kuin kortin, jolla minulle ilmoitettiin lahjan saamisesta?<br />
<br />
Kerroin myös uuden osoitteeni, mutta sanoin että en oikeastaan halua sitä paperilehteä, vaan nauttisin ihan mielelläni vain siitä digilehti-osuudesta saamaani lahjaa. Ja esitin myös vienon toiveen, että oma jatkuva tilaukseni laitettaisiin jatkumaan automaattisesti lahjatilauksen päättymisen jälkeen, ettei minun itseni tarvitsisi ottaa heihin enää yhteyttä saadakseni digitilaukseni jatkumaan. Asiakaspalvelijan äänensävy saattoi tässä kohtaa muuttua hieman epävarmemmaksi, mutta mikään ei viitannut siihen että tämä ei onnistuisi.<br />
<br />
<h3>
3) Toisen henkilön puolesta voi tehdä sopimuksen puhelimitse</h3>
<br />
Muutama viikko sitten tätini soitti ja kysyi, mitä me oikein sovimme siitä minun lehtitilauksestani. Ilmeni, että noheva asakaspalvelija oli tehnyt digilehdestäni puolen vuoden jaksoissa laskutettavan jatkuvan tilauksen, joka laskutettiin tädiltäni. Tätini oli siis lahjatilaukseni jälkeen maksanut jo yhden laskun puolestani, mutta nyt toisen laskun saatuaan hän alkoi ihmetellä asiaa.<br />
<br />
Tätini oli asiasta soittanut lehden asiakaspalveluun, jossa oli kerrottu että lasku tuli koska hänellä on tällainen tilaus. Alkava tilausjakso toki voitaisiin perua, mutta koska tädilläni oli käytössä suoramaksusopimus, lehti ei voisi estää laskun maksua, vaan tätini pitäisi pyytää pankkiaan poistamaan maksu.<br />
<br />
Tätini oli ollut käsityksessä, että hänen laskutussopimuksensa toimisi niin, että laskun saatuaan hän voisi tarvittaessa ottaa yhteyttä lehden asiakaspalveluun laskun muuttamiseksi. Hän oli aika tuohtunut kun asiakaspalvelu ei suostunutkaan perumaan hänen laskuaan, ja pyysi minua hoitamaan asian siellä internetissä, kun puhelimitse ei näemmä enää palvelua saa. Hänellä itsellään ei ole tietokonetta tai kännykkää, joten pankkiasioiden hoitaminen kätevästi netissä ei ole hänelle kovin kätevää.<br />
<h3>
<br />3) Toisen henkilön puolesta voi perua tilauksen, mutta ei sopia rahojen palauttamisesta</h3>
<br />
En heti ehtinyt tehdä mitään asialle, mutta muutamaa päivää myöhemmin otin yhteyttä asiakaspalveluun, kerroin mielipiteeni tästä palvelukokemuksesta, ja pyysin vaihtamaan tilaukseni taas minulta laskutettavaksi. Asiakaspalvelusta kerrattiin, mitä heidän näkökulmastaan oli tapahtunut, ja ilmoitettiin, että tätini lasku oli nyt mitätöity ja minulle oli luotu uusi tilaus 3kk laskutusjaksolla. Tätini olisi kuitenkin itse oltava heihin yhteydessä ylimääräisen maksun palauttamiseksi.<br />
<br />
Soitin tädilleni, joka ei ilahtunut uutisista. Hän oli tahollaan tullut siihen tulokseen, että hänelle olisi helpointa vain maksaa saamansa lasku. Niinpä hän kuulemma oli ilmoittanut lehdelle, että hän lopettaa kyseisen tilauksen tämän laskun jälkeen, siis puolen vuoden päähän, ja siinä vaiheessa minun olisi itse tilattava lehti uudelleen itselleni. Hän ei enää halunnut olla asian tiimoilta yhteydessä sen kummemmin lehteen kuin pankkiinkaan.<br />
<br />
Siispä otin uudestaan yhteyttä asiakaspalveluun. Pyysin, että he joko hyvittäisivät tätini maksaman laskun hänen oman lehtitilauksensa seuraavasta maksusta, tai vaihtoehtoisesti poistaisivat minun laskuni, jotta voisin lukea lehteä tätini laskuun seuraavat puoli vuotta sen sijaan että molemmat maksamme samasta palvelusta yhtä aikaa.<br />
<br />
Ensimmäinen vaihtoehto ei kuulemma ollut mahdollinen. Minulla oli siis lehden käytäntöjen mukaan oikeus tehdä tätini puolesta sopimus oman lehteni tilauksesta hänen laskuunsa, sekä oikeus päättää hänen puolestaan tuo tilaus ja mitätöidä siihen liittyvä lasku, mutta "toisen henkilön laskutusta ei voida käsitellä", ja siksi minun pyynnöstäni ei ollut mahdollista hoitaa maksun hyvittämistä. Luonnollisesti asiakaspalvelusta ei myöskään ehdotettu vaihtoehtoa, että he itse olisivat tätiini yhteydessä asian tiimoilta, vaan minun tulisi houkutella hänet soittamaan heille.<br />
<br />
Pian keskustelu asiakaspalvelun kanssa alkoi käydä hyvinkin mielenkiintoiseksi.<br />
<h3>
<br />4) Jos laskuihin tehdään muutoksia, laskutustiedot voi sotkea ja siirtää vastuun asiakkaalle</h3>
<br />
Asiakaspalvelu ilmoitti, että tädiltäni veloitettua laskua ei itse asiassa ollut olemassa. Tilaus oli peruttu ja lasku mitätöity. Asiakkaalla ei ollut avoimia laskuja eikä hänen tiedoissaan näkynyt ylimääräisiä suorituksia.<br />
<br />
Jotta asiassa päästäisiin eteenpäin, ilmoitin ko. laskun numeron ja viitenumeron siinä toivossa, että näiden tietojen perusteella maksu löytyisi, suoramaksu oli kuitenkin laskun tietojen mukaan lähtenyt tätini tililtä jo muutamia päiviä aikasemmin. Asiakaspalvelun mukaan kuitenkin kyse oli hyvityslaskusta, joka mitätöi aikaisemmin avoinna olleen laskun, eikä maksua asiakkuudelle ollut tullut. Maksutapahtuman tietoja vastaan raha voitaisiin kuitenkin etsiä ja palauttaa. Siispä otin valokuvan tätini saamasta suoramaksuilmoituksesta ja lähetin sen asiakaspalveluun, siinä kuitenkin näkyi maksusta kaikki se tieto, mitä laskusta oli saatavilla ottamatta yhteyttä tätini pankkiin tai odottelematta tiliotetta.<br />
<br />
Tämä ei kuitenkaan asiakaspalvelulle kelvannut. Heidän mukaansa tätini pitäisi toimittaa heille kaikki maksun tiedot, siis asiakasnumero, tilinhaltijan nimi, maksupäivä, maksettu summa, arkistointitunnus, tilinumero jolle maksu on maksettu, käytetty viitenumero sekä maksukanava. Arkistointitunnusta lukuunottamatta kaikki tämä tieto toki olisi löytynyt heille toimittamastani kuvasta, mutta koska ilman pankin arkistointitunnusta se ei ollut "riittävä todiste" laskun maksamisesta, kaikki nuo tiedot pitäisi erikseen ilmoittaa heille, jotta he voisivat pyytää laskutuspuolta etsimään kadonneet rahat.<br />
<br />
Tässä vaiheessa irtisanoin tilaukseni.<br />
<br />
Tämän pyynnön asiakaspalvelu ystävällisesti toteuttikin. Sain ilmoituksen, että tilaukseni on irtisanottu päättymään maksetun tilausjakson loppuun 13.1.2018.<br />
<br />
Jännittävää tässä on se, että en koskaan ehtinyt maksaa saamaani laskua, jonka tilausjakso loppuu 13.1.2018. Ainoa reitti, jota pitkin raha oli voinut tilaustietoihini tulla, on tätini mitätöity lasku, jolla hän maksoi tilaukseni 13.4.2018 asti.<br />
<h3>
<br />5) Asiakasta saa hyppyyttää vapaasti</h3>
<br />
On kovin vaikeaa ymmärtää, miksi yritys haluaa markkinoida lahjatuotteita, joita se ei osaa toimittaa lahjan saajalle ilman että tämän on nähtävä näin paljon vaivaa asian eteen. On todella vaikeaa ymmärtää, miksi tieto laskutukseen liittyvästä ongelmasta ei riitä siihen, että asiakaspalvelusta oltaisiin suoraan yhteydessä siihen henkilöön, jolta he tarvitsevat tietoa ongelman selvittämiseen. Tuntuu täysin käsittämättömältä, että suoramaksuun liittyvien tietojen yksilöiminen ei riitä siihen että ko. maksusuoritusta voitaisiin yrittää etsiä. Miksi laskuissa on viitenumerot, ja laskun numerot, jos nämä yksilöintitiedot eivät riitä maksujen löytämiseen?<br />
<br />
Eläissäni en ole saanut toista lahjaa, josta olisi koitunut minulle yhtä paljon vaivaa ja harmia. En muista törmänneeni toiseen yritykseen, jossa yhtä yksiselitteisesti olisi siirretty vastuu ongelmatilanteiden selvittämisestä asiakkaalle. Minun mielipahaani pahoiteltiin vasta, kun pyysin irtisanomaan tilaukseni.<br />
<br />
<h3>
6) Virheitä ei tarvitse myöntää</h3>
<br />
Teen töitä softan parissa ja osallistun myös asiakastuen pyörittämiseen. Ymmärrän, että inhimillisiä virheitä sattuu, että tietojärjestelmät voivat joskus toimia väärin, ja että välillä viesteihin vastaavat ihmiset eivät ole tarpeeksi perehtyneitä käsillä olevaan ongelmaan ostakseen olla asiakkaalle avuksi.<br />
<br />
Se mitä en ymmärrä, on että kun asiakas esittää kysymyksen liittyen ongelmaan ko. firman prosesseissa, asia ohitetaan tai väitetään ettei mitään ongelmaa ole. En ymmärrä sitä että asiakkaalle lähdetään inttämään vastaan. Ainoa asia, jossa lehden puolelta myönnettiin heidän tehneen virheen, oli asiakaspalvelun tulkinta että laskuni olisi ollut maksettu.<br />
<br />
Kaikenkaikkiaan tästä palvelukokemuksesta jäi kovin samanlainen maku kuin joskus 90-luvulla sukulaisten kertoessa lehtimyyjistä, jotka soittelivat eläkeläisille ja tekivät erilaisia lahjatilauksia lapsenlapsille ja serkun kummin kaimoille riippumatta siitä, halusiko asiakas ostaa lehden vai ei. Mutta ne lehdet kai sentään kannettiin perille ilman että lahjan saajan tarvitsi lähteä selvittelemään asiaa asiakaspalvelun kanssa.<br />
<br />
<br />
Ehkä kontrasti vain on liian suuri verrattuna omaan työhöni, jossa keskeistä on miettiä, miten asiat saataisiin sujumaan asiakkaan näkökulmasta helposti ja sujuvasti? Asiakaskokemus on kuitenkin paljon muutakin kuin käytettävän softan toiminta, tätä meidän ohjelmistoinsinöörien on joskus vaikea muistaa.<br /><br /><br /><br />----------<br /><i>Edit: Tätini soitti ja kertoi, että hänen tiliotteensa mukaan laskua ei ollutkaan veloitettu. Lehden asiakaspalvelusta oli väitetty sekä hänelle että minulle, ettei maksua voinut lehden päässä perua, mutta ilmeisesti se sitten kuitenkin laskun mitätöinnillä peruuntui. Mukavaa, että asiakaspalvelussa ollaan näin hyvin kärryillä asioista, joissa heidän pitäisi asiakkaita palvella.</i>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-34719480852439512952017-08-28T23:00:00.002+03:002017-08-28T23:50:42.939+03:00Koskaan ei ole hyvä hetki<div style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<div dir="auto">
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.</div>
</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
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.</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
Niinpä bussimatkani kuluvat kieliä opiskellen, kirjoja tai testausaiheisia artikkeleita lukien ja silloin tällöin myös blogia kirjoittaen. Tiskatessani saatan seurata youtubesta esim. <a href="https://www.youtube.com/user/TestingEducation">BBST</a>-luentoa. Kun valmistaudun puheeseen, harjoittelen sitä imuroidessani tai vaikka uidessani.</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
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.</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
Kuitenkin, jos vaihtoehtona on olla tekemättä ollenkaan, oleellinen kysymys ei ole, oliko tämä paras tapa tehdä, vaan oliko tästä iloa.</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
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.<br />
<br />
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.<br />
<br />
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.</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
Jonglöörauksen keskellä on hyvä käyttää ajoittain hieman aikaa oman tekemisensä analysoimiseen. Tähän hyvän työkalun tarjoaa <a href="http://www.satisfice.com/presentations/htmaht.pdf">PROOF</a>-malli, jota voi soveltaa tähän tapaan:</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<b>Past </b></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
Kuinka käytit ajan, mitä teit ja edistikö se asiaa? Millaiset asiat ehkä häiritsivät keskittymistäsi?</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<b>Results</b></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
Mitä löysit tai sait aikaan? Voitko jakaa tämän jonkun kanssa jäsentääksesi ajatuksiasi aiheesta paremmin?</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<b>Obstacles </b></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
Tarvitsetko apua tai työkaluja? Uusien asioiden opetteluun voi löytyä mobiilisovelluksia tai online-kursseja. Blogin kirjoittamiseen on oppaita, puhumiseen kursseja, hakemusten tekemiseen mentorointia.</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<b>Outlook </b></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
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?</div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<b>Feelings </b></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
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? </div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
<br /></div>
<div dir="auto" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0); font-family: -apple-system, HelveticaNeue; font-size: 16px;">
Elämä on liian lyhyt pelkkään ajelehtimiseen ja valittamiseen.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-1205783525110249752017-08-09T22:22:00.000+03:002017-08-09T22:22:22.636+03:00Muodolla on väliäVietämme erityisesti kesäisin paljon aikaa appivanhempieni kesämökillä. Jos siellä arkipäivänä ajoittaa kaupassa käymisen oikein, voi ostaa paikallisen leipomon ruisleipää. Meistä tuo leipä on poikkeuksellisen hyvää ruisleipää, joten silloin tällöin tulee ääneen harmiteltua, että vietämme mökillä lähinnä viikonloppuja, jolloin tuota leipää ei voi ostaa.<br />
<br />
Tänä kesänä ensimmäistä kertaa kävi niin, että kaikki lapsemme viettivät kokonaisen lomaviikon isovanhempiensa kanssa mökillä minun ja mieheni ollessa töissä. Kun sitten viikonloppuna saavuimme mökille, appivanhemmat kertoivat ostaneensa juuri tuota ruisleipää, mutta lapset eivät kuulemma olleet syöneet sitä ollenkaan.<br />
<br />
Aluksi ajattelin kysymyksen olevan siitä, että pöydässä kenties on vain ollut muutakin tarjolla. Meillä ei ole tapana syödä leipää lämpimän ruuan kanssa, ja muilla aterioilla jos on mahdollisuus ottaa muroja tai pullaa tms. niin yllättäen lapset eivät juuri leipää syö. Tuntui silti oudolta, ettei leipää ollut kulunut ollenkaan.<br />
<br />
Myöhemmin kuitenkin sain oivalluksen, miksi leipä ei ollut heille maistunut.<br />
<br />
Anoppi oli leikannut sitä sektoreittain ja halkaissut nämä palat keskeltä. Tämä ruisleipä on ohutta, joten näin leikaten palat ovat melkein pelkkää kuorta. Kuori on todella kovaa (tai hieman kostuneena sitkeää), joten tällaisia paloja on todella vaikea syödä.<br />
<br />
Siksi meillä onkin tapana leikata leivästä ohuita siivuja tai pikemminkin suikaleita. Silloin hampaiden tarvitsee yhdellä haukkauksella selvitä vain pienestä määrästä kuorta. Näin leikatut leivät eivät oikein toimi perinteisinä voileipinä koska niiden päälle ei juuri mahdu täytteitä, mutta syömme näitä siivuja vähän niin kuin sipsejä. Menekkikin on sen mukainen.<br />
<br />
Anoppi ei siis osannut kyseenalaistaa konventionaalista tapaa leikata leipää. Lapset taas eivät tunnistaneet leipäkorissa tarjolla ollutta ruisleipää. Kummallekaan osapuolelle ei tullut mieleen, että keskustelemalla leivän leikkaamisen tavoista olisi ollut löydettävissä ratkaisu, joka olisi tehnyt molemmat osapuolet tyytyväisemmiksi.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5D4YeJl1-wyVpIFoGiw5efQIulvG73vAHUCOegdp8V6nTjbMRylVTNxOCPxADdst9oL4QMGlrLD1Dl0No3BVrMunlR1htR_0hY9VIgJjhsBj7vNvd3fjY2kWOzYLPoZsB_6NHDmgU7SY/s1600/IMG_2501.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1200" data-original-width="1600" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5D4YeJl1-wyVpIFoGiw5efQIulvG73vAHUCOegdp8V6nTjbMRylVTNxOCPxADdst9oL4QMGlrLD1Dl0No3BVrMunlR1htR_0hY9VIgJjhsBj7vNvd3fjY2kWOzYLPoZsB_6NHDmgU7SY/s320/IMG_2501.JPG" width="320" /></a></div>
<br />
<span id="goog_2081772169"></span>
Tapa, jolla tarjoilemme asiat, vaikuttaa dramaattisesti siihen, löydetäänkö niitä, halutaanko niitä käyttää, miltä ne tuntuvat ja miten niiden oletetaan toimivan. Tämä on hyvä muistaa muuallakin kuin ruokapöydässä.<br />
<br />
Töissä sama asia voi tulla vastaan esimerkiksi tilanteessa jossa olemassaolevan toiminnallisuuden käyttöliittymää muutetaan. Lopputulos voi nostaa ihan uudella tavalla esiin vanhan toiminnallisuuden puutteita, ja saada aikaisemmin hyvältäkin vaikuttaneet asiat tuntumaan epäloogisilta.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-8627435741003348862017-02-10T21:31:00.000+02:002017-02-10T21:31:10.004+02:00Konferenssimuistiinpanoja - ETC2017Sain ensimmäistä kertaa elämässäni mahdollisuuden osallistua kansainväliseen testausalan konferenssiin, kun <a href="http://europeantestingconference.eu/2017/">European Testing Conference 2017</a> 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.<br />
<br />
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 <a href="https://twitter.com/alastairs/status/830066081733697536">twitter-purkaus</a> Fiona Charlesin keynoten myötä tulleesta oivalluksesta, miten erilainen testaajan asema on ohjelmistoalalla kehittäjän asemaan verrattuna.<br />
<br />
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.<br />
<br />
Tärkeitä teemoja, jotka jäivät mieleen pyörimään:<br />
<br />
<b>Epätäydellisyyden hyväksyminen.</b> 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ä.<br />
<br />
<b>Etiikka ja vastuu.</b> 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.<br />
<br />
<b>Verkostoituminen. </b>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.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-76498628367393272552016-11-08T22:07:00.000+02:002016-11-08T22:07:03.128+02:00Testaajan rooli muutoksessa - ajatuksia Ohjelmistotestaus 2016 -tapahtumastaOsallistuin tänään <a href="http://events.almatalent.fi/testaus/">Ohjelmistotestaus 2016</a> -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.<div>
<br /></div>
<div>
Yksi päivän suurista teemoista oli testaajan roolin muuttuminen. Aiheesta keskusteltiin hieman jo etukäteen <a href="https://www.facebook.com/groups/1406534256285868/permalink/1785948468344443/">facebookin </a>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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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?</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-55867840446766402382016-10-17T18:46:00.000+03:002016-10-17T18:50:30.075+03:00Kuka 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.<br />
<br />
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.<br />
<br />
Mikä minua sitten riepoo?<br />
<br />
<h3>
Käyttötapaus 1: Mainosajan ostaminen yhdistykselle</h3>
<br />
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.<br />
<br />
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ä.<br />
<br />
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.<br />
<br />
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ä!<br />
<br />
<h3>
Käyttötapaus 2: Lapsen mobiilipelit</h3>
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Esimerkiksi Momio kertoo rajoittavansa käyttäjien ostoksien euromäärää jättilaskujen ehkäisemiseksi, mutta itse koen että <a href="https://www.uusisuomi.fi/kotimaa/72562-lapsi-aiheutti-6000-eun-yllatyslaskun-varoitus-piikki-jaa-auki">jättilaskut </a>eivät ole se suurin ongelma. Ne <a href="http://yle.fi/aihe/artikkeli/2015/10/01/lapset-pelasivat-26000-euroa-clash-clansissa-google-palautti-rahat">huomataan</a>, 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.<br />
<br />
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?<br />
<br />
<h3>
Olenko vanhanaikainen?</h3>
<br />
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?<br />
<br />
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.<br />
<br />
Olisi kuitenkin hyvä, jos järjestelmät aina mahdollistaisivat myös vanhanaikaisen, varovaisen käyttötavan.<br />
<br />
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.<br />
<br />
Ja tästä syystä olen se natsimutsi jonka lapset jäävät paitsi monesta sellaisesta, joka "kaikilla muilla" kuulemma on.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-48859142647696210892016-10-02T23:06:00.000+03:002016-10-02T23:57:59.367+03:00Mixed thoughts about context and diversityThis 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 <a href="https://twitter.com/maaretp/status/780879661094072325">twitter </a>and in many blog posts, the most relevant ones being from the people who are the actual parties of the incident, <a href="http://visible-quality.blogspot.fi/2016/09/slide-incident-long-version.html">Maaret Pyhäjärvi</a> and <a href="http://www.satisfice.com/blog/archives/1649">James Bach</a>.<br />
<br />
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.<br />
<br />
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 <a href="http://visible-quality.blogspot.fi/2016/10/my-response-to-james-bachs-explanation.html">blog post</a> about the incident.<br />
<br />
So what makes me curious is how come it is possible to make such big misinterpretations about another persons point of view.<br />
<br />
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 <a href="https://twitter.com/geekygirlsarah/status/782364672804532225">priviledge</a>.<br />
<br />
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.<br />
<br />
<h3>
The gender talk</h3>
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<h3>
<br />The culture talk</h3>
<br />
In twitter the conversation has been quite much about whether nice and authentic are contradictory or not. This brings us to the culture talk.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<h3>
The language talk</h3>
<br />
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.<br />
<br />
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 "<a href="http://www.puhutaan-suomea.net/kuusi-palaa-9-meanings-in-finnish/">kuusi palaa</a>".<br />
<br />
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.<br />
<br />
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.<br />
<br />
<h3>
So where are we heading?</h3>
<br />
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.<br />
<br />
One of the most revolutional ideas of the industry has been stating that <a href="http://www.satisfice.com/blog/archives/27">there are no best practices</a>. 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.<br />
<br />
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.<br />
<br />
And if it is, are there actions to be taken to achieve this?Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-8308096808157790561.post-1855900332400954452016-09-25T08:55:00.000+03:002016-09-25T08:55:25.035+03:00Tunnelmia Testing Assemblyn jälkeenOsallistuin tällä viikolla Helsingissä järjestettyyn <a href="http://testingassembly.fistb.fi/">Testing Assembly</a> -tapahtumaan. Tiistaina vietin päiväni James Lyndsayn workshopissa opettelemassa tutkivaa testausta ja keskiviikkona olin yksi seminaaripäivän puhujista.<br />
<br />
Mitä jäi käteen?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ja kenties ensi kerralla voisin sitten puhua ihan oikeasti testauksesta :)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-4882449374165997402016-09-15T23:55:00.001+03:002016-09-15T23:55:08.295+03:00Hei, 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 <a href="https://leanpub.com/mobprogrammingguidebook">kirjan </a>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.<br />
<br />
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.<br />
<br />
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ää.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8308096808157790561.post-74041769366874704952016-05-25T23:17:00.000+03:002016-05-25T23:32:46.552+03:00Testaajan muuttuva rooli ja Ohjelmistotestaus 2016Tänä vuonna sain tilaisuuden puhua <a href="http://talentumevents.fi/tivi-ohjelmistotestaus/">Ohjelmistotestaus 2016</a> 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 <a href="http://nordictestingdays.eu/events/tracks/test-hard-or-then-just-aim-better-testability">Nordic Testing Daysin</a> 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.<br />
<div>
<br /></div>
<div>
<div>
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.</div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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 <a href="https://leanpub.com/mobprogrammingguidebook">kirjavinkki </a>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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
</div>
<div>
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ä.</div>
<div>
<br /></div>
<div>
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ä. </div>
<div>
<br /></div>
<div>
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?</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-4973761515486864642016-05-15T09:33:00.000+03:002016-05-15T09:33:56.775+03:00KieliversiotMuutama 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Tässä listattuna muutamia asioita, joita kannattaa miettiä kieliversioita testattaessa:<br />
<ul>
<li>Löytääkö käyttäjä kielenvaihtotoiminnon?</li>
<li>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?</li>
<li>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? </li>
<li>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ä?</li>
<li>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ä?</li>
<li>Löytyykö palvelusta kokonaisuuksia, joihin mennessä kielivalinta nollautuu?</li>
<li>Näkyvätkö kielikohtaiset erikoismerkit (å, á jne) oikein?</li>
<li>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?</li>
<li>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ää.</li>
</ul>
<div>
Tuleeko mieleen muuta olennaista?</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-8804163632149546802016-04-17T22:59:00.000+03:002016-04-17T22:59:06.975+03:00Testattavuudesta ja omien rajojen tunnustamisestaTestaajan 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?<br />
<br />
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.<br />
<br />
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.<br />
<br />
On mahtavaa saada työskennellä ympäristössä, jossa ongelmista ollaan valmiita tekemään yhteisiä, ja jossa niihin myös halutaan löytää ratkaisut.<br />
<br />
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.<br />
<br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-64119320901215768922016-04-04T15:36:00.000+03:002016-04-04T15:36:24.575+03:00Kun aika ei vain riitä - hajanaisia ajatuksiaTalvi 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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?<br />
<br />
Nämä pohdinnat saivat yllättävää vauhtia, kun minut kutsuttiin puhujaksi <a href="http://talentumevents.fi/tivi-ohjelmistotestaus/">Ohjelmistotestaus 2016</a> -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.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-667876078837273612016-01-10T23:27:00.003+02:002016-01-10T23:30:50.106+02:00Priorisointia, tavoitteita ja tehtävänhallintaaJoulukuu 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.<br />
<div>
<br /></div>
<div>
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.<br />
<div>
<br /></div>
<div>
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.<br />
<br />
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.<br />
<br />
Sen sijaan haasteita syntyy ajankäytön priorisoinnista, tekemisen fokuksoimisesta ja tehtävänhallinnasta.<br />
<br />
<br />
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.<br />
<div>
<br /></div>
<div>
Tällaista toimintatapaa voi perustella useammallakin tavalla.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br />
<br /></div>
<div>
Priorisoinnissa on kuitenkin riskinsä.</div>
<div>
<br /></div>
<div>
Yksi riski on vääränlainen priorisointi, eli se että keskitytään kuitenkin vääriin asioihin, tai ainakin jotain tärkeää jää huomaamatta.</div>
<div>
<br /></div>
<div>
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?</div>
<div>
<br /></div>
<div>
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.<br />
<br />
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?<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
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.</div>
</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-51114883314829837052015-11-20T22:49:00.002+02:002015-11-20T22:49:52.438+02:00Löydä se mitä on vaikea nähdäTiimillämme on pyrkimyksenä pitää kahden viikon välein retroja. Jokainen valitsee vuorollaan aihepiirin, jonka puitteissa laittaa muut täyttämään post-it-lappuja, joita ryhmitellään etsien työskentelyn kipukohtia.<br />
<div>
<br /></div>
<div>
Tällä viikolla pääsimme isojen kysymyksien äärelle etsimällä asioita, jotka eri vaiheissa prosessia tuottavat arvoa, hämmennystä tai ajanhukkaa. Iso tussitaulu peittyi post-it-lapuilla minulle ennennäkemättömällä tavalla.</div>
<div>
<br /></div>
<div>
Suurimmaksi ongelmaksi keskustelussa nousivat isot muutostyöt, joissa usein speksauskin on hieman epämääräinen. Niitä on vaikea edistää, ne vievät paljon aikaa, ja niissä on tavanomaista suurempi riski päätyä tekemään vääriä asioita.</div>
<div>
<br /></div>
<div>
Se, minkä itse koin erityisen mielenkiintoiseksi, oli että puhuimme tavallaan ihan samoista asioista, joilla vain pari viikkoa aikaisemmin olin perustellut testausstrategian luomista: hyödyllistä puuhasteltavaa riittää aina, joten ikäviin tai hankaliin hommiin ei välttämättä koskaan tule tartuttua ainakaan riittävällä tarmolla, jos ei ole tiettyä kurinalaisuutta omassa tekemisessä. </div>
<div>
<br /></div>
<div>
Siinä missä minä testaajana tarvitsen strategista ajattelua edes nähdäkseni ne kokonaisuudet, jotka eivät mukavuusalueella pysytellen tule testatuksi, kehittäjä tarvitsee kurinalaisuutta ja strategista ajattelua jotta nuo isot ja vaikeat kokonaisuudet saataisiin pilkottua ja tehtyä pois alta. Vaihtoehto on, että niitä joko vältellään, tai edistetään vastahakoisesti mitenkuten milloin ehditään. Ja kun ympärillä tapahtuu koko ajan, rakennettava tuote saa jatkuvasti uusia ominisuuksia, pieniä parannuksia tai vähintään bugifiksejä, vältellen ja nitkutellen edistettävät kokonaisuudet helposti kasvavat, muuttuen yhä vaikeammiksi toteuttaa loppuun asti. </div>
<div>
<br /></div>
<div>
Ja lopulta aika usein ne hankalimmin edistettävät asiat ovat kuitenkin tärkeitä.</div>
<div>
<br /></div>
<div>
Keskustelimme tavoista, joilla näiden isojen asioiden edistymistä voisi nopeuttaa, ja pohdimme syitä jotka ovat estäneet tässä onnistumista. (Ja vain pari päivää myöhemmin kävimmekin yhteistuumin pilkkomaan yhtä elefanttia.)</div>
<div>
<br />
<br /></div>
<div>
Jälkikäteen aloin muistella asioita, joita olen pitänyt testaajan urani suurimpina saavutuksina. Niistä lopulta aika harvat liittyvät tilanteisiin, joissa olen löytänyt bugin toteutetusta järjestelmästä. Parhaita ovat olleet hetket, kun olen keksinyt esittää kysymyksen, joka on paljastanut vältellyn aiheen. <span style="font-family: "helvetica neue light" , , "helvetica" , "arial" , sans-serif;">Usein ne ovat olleet asioita, jotka ovat selvästi vaivanneet kehittäjiä itseäänkin, mutta kissaa ei ole tullut nostettua pöydälle koska ei ole ollut pakko, ja muita, akuutimpia asioita on riittänyt enemmän kuin omiksi tarpeiksi. Joskus kyse on ollut asioista, jotka vain on ymmärretty eri tavoin, eikä kukaan ole pysähtynyt ajattelemaan asiaa huomatakseen ongelman laajuutta.</span></div>
<div>
<br /></div>
<div>
<span style="font-family: "helvetica neue light" , , "helvetica" , "arial" , sans-serif;">Kun puhutaan laadunvarmistuksesta, softan testaaminen on vain pieni osa kokonaisuutta. Vaikutuksiltaan merkittävintä on löytää niitä asioita, joita vältellään tai ei edes nähdä. Vaikeaa tästä tekee se, että testaajan näkökulmasta ne kaikki saattavat olla näkymättömiä. Kehittäjän taas voi olla vaikea nähdä juuri näiden asioiden esiin nostamista oleellisena, ne voivat tuntua joko vähäpätöisiltä tai kaikkien tuntemilta kollektiivisesti vaietuilta asioilta, mikäli niiden olemassaoloon edes kiinnitetään huomiota.</span></div>
<div>
<span style="font-family: "helvetica neue light" , , "helvetica" , "arial" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue light" , , "helvetica" , "arial" , sans-serif;">Tässä mielessä retrot ovat loistavia. Loistavia ovat myös hetket, kun löytää paljastavia kysymyksiä. Hyvä alku ovat "miten tämän voi testata", "kuka tätä käyttää", "mihin tämä vaikuttaa" ja "miksi tämä asia ei ole edennyt".</span></div>
<div>
<span style="font-family: "helvetica neue light" , , "helvetica" , "arial" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue light" , , "helvetica" , "arial" , sans-serif;"><br /></span></div>
<div>
<span style="font-family: "helvetica neue light" , , "helvetica" , "arial" , sans-serif;">Testaajien ja kehittäjien välillä on joskus melko voimakastakin vastakkainasettelua. Itse pidän enemmän yhteistyömeiningistä. Toivon, että kehittäjät voivat nähdä minun ongelmani yhteisinä ongelminamme. Tämän viikkoinen retro konkretisoi itselleni myös sitä sinänsä aika itsestäänselvää asiaa, että myös kehittäjien ongelmat ovat minun ongelmiani. Lopultahan ne testaajan turhauttavimmat pulmat liittyvät usein juuri asioihin, joista myös kehittäjä on ollut epävarma. Meistä jokainen tekee osansa löytääkseen ja selkiyttääkseen epämääräisiä asioita. Myös minun tehtäväni on tarttua tähän työhön mahdollisimman varhaisessa vaiheessa.</span></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-27652437519992044062015-11-08T16:09:00.000+02:002015-11-19T17:09:01.053+02:00Testausstrategiaa luomassa osa 1Aloitin 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.<br />
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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 <a href="http://theadventuresofaspacemonkey.blogspot.fi/2013/12/fitqcodes.html">FIT(Q)CODES</a>-mallia. </div>
<div>
<br /></div>
<div>
Selvitin jokaisen näkökulman osalta, minkä tyyppisiä asioita siihen liittyy (käyttäen pitkälti lähteenä James Bachin heuristista <a href="http://www.satisfice.com/tools/htsm.pdf">testausstrategiaa</a>). 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.)</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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.</div>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-8308096808157790561.post-2251525328446992682015-10-30T21:57:00.000+02:002015-10-30T22:02:15.897+02:00Miten vanhemmuus kouluttaa testaajaksiLapset ovat pohjimmiltaan aika mainiota juttuseuraa. Parasta on päästä mukaan erilaisiin ongelmanratkaisusessioihin, joko osallistuen tai ihan vain seuraillen: miten vuosikas etsii paikkaa josta ylettyisi pinnasängyn kaiteen toisella puolella olevaan leluun, mistä kaikesta taapero voi esittää "miksi"-kysymyksen, millaisiin teknisiin pohdintoihin eskarilainen voi yltää, tai mistä löytyvät leikkiin ne tärkeät asiat, joita ei (aikuisen mielestä) löydy lelulaatikosta.<br />
<div>
<br /></div>
<div>
Lapset ovat taitavia muistuttamaan testaajalle tärkeistä asioista: mikään ei ole itsestäänselvää, ja aina voi löytää jonkin uuden tavan käyttää tuttuja esineitä.<br />
<br /></div>
<div>
<div>
<br /></div>
<div>
Äitiydessä itsessään on myös paljon samaa kuin testaamisessa. Toisessa opitut ajattelutavat ja toimintamallit voivat tukea toista. Tässä muutamia asioita, joissa näen yhtymäkohtia:<br />
<div>
<br /></div>
<div>
1) Kun työt alkavat, et tiedä, mikä ongelma vaatii korjaamista. On kuitenkin muutama vaihtoehto, joiden tiimoilta kannattaa aloittaa asian selvittely. </div>
<div>
<br /></div>
<div>
2) Ajan myötä arvauksesi tutuissa tilanteissa paranevat, mutta vastaan tulee uusia, monimutkaisempia ongelmia. Asioiden merkitykset muuttuvat.</div>
<div>
<br /></div>
<div>
3) Kirjallisuutta aiheesta on paljon. Suurin osa siitä ei ole sinulle erityisen hyödyllistä. Oikeiden kirjojen löytäminen voi olla aluksi vaikeaa. Kaikki vastaan tulevat ratkaisumallit eivät sovi omaan kontekstiisi, eivätkä kaikki omat ratkaisusi toimi muualla.</div>
<div>
<br /></div>
<div>
4) Vertaistuki on tärkeää. Jos et ole tarpeeksi onnekas elääksesi muiden samassa elämäntilanteessa olevien keskellä, tukea löytää helpoiten sosiaalisen median kautta. </div>
<div>
<br /></div>
<div>
5) Pidemmän päälle yksi keskeisimmistä menestyksen avaimista on siinä, miten hyvin saat muut näkemään, miksi tietyt asiat ovat tärkeitä, miksi toiset ongelmia. Joskus on kärsivällisesti etsittävä parempia tapoja selittää ja havainnollistaa asioita uudella tavalla. </div>
<div>
<br /></div>
<div>
6) Tärkeää on myös saada toiset tekemään kanssasi yhteistyötä. Jos haluat tulla kuunnelluksi ja otetuksi vakavasti, älä ole se joka aina vain valittaa. Älä ole ilkeä äläkä ylimielinen.</div>
<div>
<br /></div>
<div>
7) Älä jätä tärkeitä asioita sanomatta silloinkaan kun tiedät niiden herättävän vastustusta. Ole valmis kohtaamaan muiden negatiivisia tunteita ottamatta niistä itseesi. Ymmärrä, että roolisi on erityisellä tavalla vastuullinen, mutta parhaiten onnistut myös ristiriitatilanteissa olemalla myös osa tiimiä.</div>
<div>
<br /></div>
<div>
8) Kuuntele tiimiäsi. Myös he opettavat sinua. Paras tapa löytää oman ajattelun puutteet on ottaa harkintaan asioita, joita joku eri tavalla maailmaa katsova nostaa esiin.</div>
<div>
<br /></div>
<div>
9) Joskus paras tapa edistää asioita on esittää kysymyksiä.</div>
<div>
<br /></div>
<div>
10) Jos haluat olla oikeasti hyvä, ymmärrä oma epätäydellisyytesi ja pyri jatkuvasti parempaan. Jokainen epäonnistuminen on tilaisuus oppia tekemään asiat ensi kerralla paremmin. Oman mielenrauhan nimissä kannattaa myös oppia hyväksymään epätäydellisyys sekä tietty määrä elämän yleistä kaoottisuutta.</div>
</div>
</div>
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-8308096808157790561.post-3766734505602508812015-06-27T16:26:00.001+03:002015-06-27T16:26:20.232+03:00Toistettavuus vs. varioitavuusKeskusteltaessa siitä, mitkä ovat suunnitelmallisen, ammattimaisen testauksen keskeisimpiä etuja, joskus nousee ajatus testien toistettavuudesta. Kun testitapaukset suunnitellaan riittävän yksityiskohtaisesti, tiedetään täsmälleen, mitä testaaja on testannut, ja samat testit ovat suoritettavissa täsmälleen samanlaisina kierroksesta toiseen, jolloin saadaan eksaktia dataa siitä, milloin jokin toiminto hajonnut. Testit voidaan myös automatisoida.<div>
<br /></div>
<div>
Toistettavuus on kyllä tärkeää siinä mielessä, että bugiraportoinnissa keskeisimmässä roolissa on tarjota riittävät tiedot virhetilanteeseen johtaneesta toimenpideketjusta, jotta korjauksen tekevä kehittäjä voisi löytää virheen koodista ja korjata sen. Sen sijaan on kyseenalaista, kuinka tarkkaan on tarpeen dokumentoida ne polut, joiden varrelta virheitä ei jollakin testikierroksella löytynyt.</div>
<div>
<br /></div>
<div>
Huomionarvoista on kuitenkin myös se, että yksikään testikierros ei voi testata kaikkia mahdollisia polkuja, joita pitkin todellinen käyttäjä voi järjestelmää käyttää. Myös testauksessa käytetty testidata on vajavaista verrattuna todellisten tilanteiden aikana mahdollisesti tarvittavaan dataan. </div>
<div>
<br /></div>
<div>
Suunnitelmalliseen testaukseen toki kuuluu miettiä, mitkä ovat sellaisia rajatapauksia, joissa virheet todennäköisimmin ilmenevät jos niitä on, mutta ovelimmat virheet ovat sellaisia, joita ei voi ennakoida. Siksi testauksen kokonaiskattavuuden parantamiseksi testaajan on hyvä varioida toimintaansa kierrokselta toiseen siirryttäessä.</div>
<div>
<br /></div>
<div>
Sattuma on testaajan paras ystävä.</div>
<div>
<br /></div>
<div>
Esimerkiksi, jos prosessin B läpivienti ennen prosessia A aiheuttaa virhetilanteen prosessissa A, asia ei koskaan selviä testaajalle joka testaa prosessin A aina ennen prosessia B. Samoin jos hakutoiminnossa jokin tietty hakutermien yhdistelmä aiheuttaa virhetilanteen, sitä tuskin löydetään miettimällä etukäteen, millaisia yhdistelmiä testaajan tulisi testata.</div>
<div>
<br /></div>
<div>
On myös vaikea nähdä, mitä haittaa testien varioimisesta olisi. Koska yksittäistä testikierrosta ei voida suunnitella niin, että se olisi varmasti se kaikkein tehokkain löytämään virheitä, vaihtaminen toiseen yhtä hyvään seuraavalla kierroksella ei heikennä testauksen laatua lainkaan. </div>
<div>
<br /></div>
<div>
Lisäksi testauksessa puhutaan hyönteismyrkkyparadoksista, jonka mukaan toistettaessa täsmälleen samaa testijoukkoa, sen kyky löytää virheitä vähitellen heikkenee. Kehittäjät ikään kuin oppivat välttämään niitä virheitä, joita joutuvat toistuvasti korjaamaan.</div>
<div>
<br /></div>
<div>
Toki variaatiot testauksessa asettavat korkeammat vaatimukset bugiraportoinnille, koska tällöin muuta informaatiota virhetilanteeseen johtaneista syistä ei ole käytettävissä. Yksityiskohtainen bugiraportointi on kuitenkin niitä perustaitoja, jotka erottavat hyvän testaajan huonosta testaajasta.</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-70113208544204323652015-06-16T22:28:00.000+03:002015-06-16T22:28:37.187+03:00Dokumentointia ja raportointia - ajatuksia tutkivan testauksen työkurssilta vol 3Minulla 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.<br />
<br />
<br />
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.<br />
<br />
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?<br />
<br />
<h3>
Suunnitteludokumentaatio</h3>
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ä.<br />
<br />
Testaussuunnitelma voisi siis sisältää seuraavanlaisia tietoja:<br />
<br />
<ul>
<li>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ä. </li>
<li>Hahmotelma testauksen strategiasta, hyödyllisistä menetelmistä ja työkaluista. </li>
<li>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ä <a href="http://www.developsense.com/blog/2012/07/few-hiccupps/">FEW HICCUPPS</a>-mallista ja James Bachin <a href="http://www.satisfice.com/tools/htsm.pdf">heuristisesta testausstrategiamallista</a>. </li>
</ul>
Erilaiset tarkistuslistat ovat hyödyllistä testaussuunnitteludokumentaatiota, mutta niiden ei itsessään tarvitse olla projektikohtaisia eikä osa testaussuunnitelmaa.<br />
<br />
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.<br />
<br />
<h3>
Testausvaiheen dokumentaatio</h3>
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 <a href="http://www.kaner.com/pdfs/bugadvoc.pdf">Bug Advocacy</a>-mallista.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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ä.<br />
<br />
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.<br />
<br />
Testausvaiheen materiaali muodostuu tehtävänannoista, testaukseen käytettävistä aineistoista, työkaluista, sekä matkan varrella opituista asioista.<br />
<br />
<h3>
Analysointi</h3>
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ä,<br />
<h3>
Raportointi</h3>
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.<br />
<br />
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ä).<br />
<br />
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.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-71443469437787394542015-06-16T20:46:00.001+03:002015-06-16T20:46:45.293+03:00Kuka vaan osaa testata - tai puhua kiinaaTestaajana törmää hyvin monenlaisiin käsityksiin omasta ammatistaan. Toki moniin muihinkin ammatteihin yhdistetään eri tavoin hupaisia kuvitelmia siitä, mitä niiden taitajat työkseen tekevät, mutta itse en ole aikaisemmin työskennellyt tehtävässä, jonka sisällön samassa työpaikassa työskentelevät ihmiset näkisivät niin eri tavoin.<br />
<br />
<h3>
Kaikki osaavat testata</h3>
Yksi yleinen testaukseen liittyvä ajatus on, että kuka tahansa osaa testata. Tämä pitää ehdottomasti paikkansa, jokainen joka osaa käyttää tietokonetta, osaa myös jossain määrin testata siinä käyttämiään ohjelmia.<br />
<br />
Osaamisen tasoissa on kuitenkin eroja. Kuka tahansa ei osaa käydä systemaattisesti läpi ohjelmistoa, keksiä erilaisia tapoja koetella sen tarjoamien toiminnallisuuksien rajoja ja väärinkäyttää sitä. Kuka tahansa ei osaa kertoa kohtaamistaan ongelmista tavalla, joka auttaa kehittäjää virheen löytämisessä. Hyvä testaus vaatii opiskelua, harjoitusta ja ajatustyötä.<br />
<br />
Vähän niin kuin melkein kuka tahansa osaa ranskaa, jos kielitaidoksi riittää lukea ääneen ruokalistaa. Kuitenkaan ranskankielisen tekstin analysointi tai luontevan keskustelun käyminen ei luonnistu opettelematta.<br />
<br />
<h3>
Testaajat osaavat mm. suorituskykytestausta, käytettävyystestausta ja tietoturvatestausta</h3>
Moni testaaja varmasti hallitsee useampia testaustyyppejä. Niiden oppiminen ei kuitenkaan ole testaajalle sen helpompaa kuin ranskalaiselle on oppia portugalia, kiinaa tai arabiaa. Jos on kiinnostunut kielistä, niitä voi hallita useita. Jos osaa jo jotakin opeteltavan kielen sukulaiskieltä, helpottaa se niin kieliopin kuin sanastojenkin sisäistämistä, mutta silloinkin vaatii paljon harjoitusta ennen kuin voi sanoa olevansa hyvä siinä.<br />
<br />
Jos et ole valmis palkkaamaan .NET-kehittäjäksi henkilöä, joka kertoo osaavansa html:ää, miksi luottaisit tietoturvatestauksen sellaisen henkilön käsiin, joka ei ole perehtynyt siihen kunnolla?<br />
<br />
<h3>
Laatuongelmista päästään, jos testaus suunnitellaan tarkemmin, automatisoidaan ja raportoidaan tarkemmin</h3>
Testaaja ei valitettavasti voi tehdä ohjelmistosta laadukasta, siihen tarvitaan kehittäjä. Testaajan toimilla toki voi olla paljonkin merkitystä siinä, miten laadukas lopputuloksesta tulee, vähän niin kuin kustannustoimittajan palautteella voi olla paljonkin merkitystä julkaistavan kirjan laadulle. Kirjailija on kuitenkin vastuussa syntyvästä tekstistä, samoin kuin kehittäjä on vastuussa toteutuksensa tuloksesta.<br />
<br />
Testauksen suunnittelu on tärkeää testaamisen suuntaamiseksi oikeisiin asioihin, testauksen automatisointi on oiva työkalu joihinkin tilanteisiin, ja laadukas raportointi on korvaamatonta haluttaessa tietoa siitä, onko testaus ollut riittävän kattavaa ja onko järjestelmä riittävän valmis. Nämä ovat kuitenkin kaikki tehtäviä, joihin lisäpanosten laittaminen saattaa nostaa kustannuksia ja laskea laatua.<br />
<br />
Testauksen yksityiskohtainen suunnittelu voi sokeuttaa testauskattavuuden puutteille. Jos testaaja keskittyy testitapausten täsmälliseen suorittamiseen, on hänen vaikea huomata niiden ulkopuolelle jääviä asioita. Myös itse suunnittelu saattaa kohdistua kapeammalle alueelle, jos sitä tehdessä keskitytään yksityiskohtiin eikä karkeamman tason näkökulmien etsimiseen.<br />
<br />
Automatisointi on korvaamaton apu tilanteissa, joissa testataan asioita joita ei ole mielekästä tai mahdollista käsin testata, tai haluttaessa välttyä toistamasta käsin joitakin muuttumattomia tapahtumakulkuja. Sen rakentaminen ja ylläpitäminen vie kuitenkin paljon aikaa. Tämä voi tarkoittaa joko merkittävää kustannusten nousua tai merkittävää testauskattavuuden pienenemistä. Automatisointi voi myös johtaa prosessien läpiviemiseen aina keskenään identtisillä testisyötteillä. Ne, jotka saavat henkilökohtaista tyydytystä testien täydellisestä toistettavuudesta, voivat kokea tämän hyvänä tilanteena. Me, joille kokemus on osoittanut mitä ihmeellisimpien bugien nousevan esiin sattumanvaraisella testisyötteiden varioinnilla, pidämme tätä testauksen luotettavuutta heikentävänä tekijänä.<br />
<br />
Mitä testauksen raportointiin tulee, siihen on pääpiirteissään kolme vaihtoehtoa.<br />
<br />
Ajankäytöllisesti yksinkertaisin tapa raportoida on tarjota tilastoja bugeista ja testitapausten läpäisyprosenteista. Voidaan tarjota myös testitapauslista PASS/FAIL-tiedoin. Jos testitapaukset ovat kovin yksityiskohtaisia, niitä on todennäköisesti melko paljon, jolloin tällaisen listan informatiivisuus on hyvin kyseenalaista.<br />
<br />
Toiseksi kevyin tapa raportointiin on sopia muutamia seurattavia asioita, joista tiimi saa antaa fiilispohjaisia arvioitaan, kuinka vakuuttavalla tolalla asiat ovat.<br />
<br />
Jos raportilta halutaan jotain enemmän, täytyy huolella miettiä, mitä tietoa siitä olisi tarkoitus saada ulos. On myös hyväksyttävä se, että yksityiskohtaisen, eksaktin, luettavan ja relevantteja asioita esiin nostavan raportin koostamiseen saa helposti päivänkin aikaa kulumaan. Tämä aika on lisäkustannus, ja usein myös pois jostakin muusta.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-28268697495700622232015-05-27T22:36:00.000+03:002015-05-27T22:37:43.537+03:00Olenko hyvä testaajaMinulle esitettiin hiljattain suora kysymys: oletko hyvä testaaja?<br />
<br />
Kysymys on hyvä, mutta siihen on vaikea vastata. Mistä tunnistaa hyvän testaajan? Miten voi arvioida omaa hyvyyttään testaajana, jos ei pääse juurikaan tekemään töitä hyvien testaajien kanssa, joiden tekemisiin voisi omaa puuhasteluaan verrata? Ja toisaalta, hyvätkin testaajat ovat erilaisia. Jos saisin työskennellä gurun kanssa, joka saisi minut tuntemaan itseni jollain testauksen osa-alueella kädettömäksi, silti saattaisi olla jokin toinen osa-alue, jolla hänellä olisi opittavaa minulta.<br />
<br />
Kehittäjiltä saatu palaute on tietenkin yksi mittari. Esim. "keksii luovia tapoja rikkoa asioita" on luonnehdinta, jonka otan kehuna. Myös kysymykset kuten "miten tämän sinun mielestäsi pitäisi toimia" ja "tiedätkö, onko tämä android-puhelinten yleinen virhe" luovat vaikutelmaa, että ammattitaitooni luotetaan. Samoin tuoteomistajilta, projektipäälliköiltä ja asiakkailta tuleva palaute kertoo paljon siitä, miten hyvin työssään onnistuu.<br />
<br />
Pohjimmiltaan he ovat kuitenkin kaikki ihmisiä, joiden oma osaaminen kohdistuu johonkin muuhun kuin testaamiseen - ehkä he eivät vain tiedä paremmasta?<br />
<br />
Ehkä hyvän testaajan on hyväkin olla hieman epävarma omasta ammattitaidostaan. Olemme kaikki vain ihmisiä. Kuka tahansa saattaa tehdä virhearvioita, olla keksimättä jotain oleellista tapaa väärinkäyttää järjestelmää tai jopa olla tunnistamatta jotakin testauksen osa-aluetta, joka olisi juuri käsillä olevan projektin kannalta äärimmäisen tärkeä. Tästä syystä testaaja ei voi eristäytyä yksin omaan kammioonsa, vaan hänen tulee jatkuvasti löytää uusia näkökulmia työhönsä. Tähän tärkeä väline on keskusteleminen muiden projektin osapuolten kanssa. Joskus yksinkertainen kysymys voi olla vaikuttavampi kuin päivän testausrupeama.<br />
<br />
Niin kauan kuin on pienikin epäilys oman osaamisen riittämisestä, mieli etsii aukkoja omasta päättelystä. Ilman tätä uusia oivalluksia ei tule. Olisi vaarallista kuvitella osaavansa ja ymmärtävänsä jo kaiken.<br />
<br />
Testausta on monenlaista. Kurinalaisuuden ja järjestelmällisyyden yhdistäminen luovuuteen ja jatkuvaan oppimisprosessiin on haasteellinen kokonaisuus, jossa minkä tahansa kulman laiminlyöminen voi johtaa kalliisiin epäonnistumisiin.<br />
<br />
Siksi ei ole yhdentekevää, kuka tuotettasi testaa.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-81931256613736175532015-05-12T17:21:00.001+03:002015-05-12T17:21:26.063+03:00Ryhmässä on voimaa, myös testauksessa - oppeja tutkivan testauksen työkurssilta vol 2Minulla 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 toinen. 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.<br />
<br />
<h3>
Paritestaus</h3>
Yksi parhaista puolista koulutuksessa oli mahdollisuus päästä kokeilemaan paritestausta. Siinä ideana on, että kaksi testaajaa työskentelee yhdessä samalla tietokoneella yhteisen tehtävän parissa. Paritestausta voidaan tehdä monella tavalla:<br />
<ul>
<li>Toinen testaa vieressä istujan ohjeiden mukaan</li>
<li>Toinen testaa ja vieressä istuja esittää kysymyksiä</li>
<li>Testausta ohjataan tasa-arvoisella ideoinnilla (tämä vaatii onnistuakseen melko tasavahvan testaaja-parin, mutta voi onnistuessaan olla hyvinkin hauskaa ja hedelmällistä)</li>
<li>Yksi vaihtoehto on myös käydä testitapauksia läpi yhdessä mutta käyttäen eri laitteita</li>
</ul>
<br />
Paritestauksen etuja on mm.<br />
<ul>
<li>Mahdollisuus oppia toiselta testaajalta, millaisiin asioihin testauksessa voi kiinnittää huomiota</li>
<li>Dialogin myötä testatuksi tulee sellaisiakin alueita, joita kumpikaan ei olisi yksinään keksinyt</li>
<li>Testaamisen flowta ei aina tarvitse keskeyttää bugiraportoinnin takia, kun toinen voi jatkaa toiminnon tutkimista toisen tehdessä muistiinpanoja (tätä kautta tilanteessa, joissa bugeja on suhteellisen paljon, paritestaus ei välttämättä edes vie yhtään sen enempää aikaa kuin jos testaajat testaisivat yhtä aikaa eri asioita)</li>
<li>Pari auttaa myös muuten keskittymään käsillä olevaan tehtävään (ulkoset ärsykkeet helpompi jättää huomiotta)</li>
<li>Hiljaisen tiedon jakaminen niin, että esim. yhden testaajan sairastuessa projektin testaus ei henkilövaihdosten takia hidastu</li>
</ul>
<br />
<h3>
Kun testaajapareja on useita</h3>
Testasimme kolme 25 minuutin sessiota kolmen parin voimin keräten samalla bugihavaintoja. Tuona aikana vain muutamasta kaikkein ilmeisimmästä bugista tuli päällekkäisiä bugiraportteja, yhteensä erilaisia bugeja löytyi kuitenkin kymmeniä. Maaretin mukaan on ihan tyypillistä, että eri parit lähestyvät testattavaa kohdetta niin eri suunnista, ettei päällekkäistä raportointia juurikaan tule. Näin siinäkin tilanteessa, että kaikilla oli yhteinen varsin tarkkaan rajattu testauksen kohde.<br />
<br />
Sessioiden päätteeksi käytiin läpi kaikkien havainnot. Tämä tarjosi taas oppimismahdollisuuksia, kun sai kuulla, mitä kaikkea muut parit olivat keksineet kokeilla. Tulosten yhteinen läpikäynti antaa myös mahdollisuuksia saada laajemman joukon näkemyksiä jatkotestauksen suunnitteluun.<br />
<br />
Jos havainnot kerätään esim. post-it-lapuille ja ryhmitellään, on tätä kautta helppo kerätä myös tietoa siitä, mistä osa-alueista bugeja löytyy, ja mihin testausta kenties kannattaa keskittää seuraavaksi. Tutkivan testauksen sessiomme tuotti yli 20 erillistä bugihavaintoa, mikä tekee miltei yhden bugin minuutissa, joten ryhmätyö selkeästi toimii, jos halutaan lyhyen ajan sisällä saada paljon informaatiota testauksen kohteen tilasta.<br />
<br />
Itselleni jäi vaikutelma, että tällainen useamman parin tekemä tutkiva testaus on hyvinkin tehokas tapa bugien löytämiseen, kun testataan ajallisesti suhteellisen lyhyissä sessioissa. 25 minuuttia oli ehkä vähän liian lyhyt aika, mutta esim. <a href="http://www.satisfice.com/sbtm/">sessiopohjaisen testausmallin</a> mukainen 90 minuuttia voisi tuntua jo turhankin pitkältä tarkoitukseen.<br />
<br />
<br />
Paritestauksen ja ryhmätestauksen eduista sekä mahdollisuuksista ryhmäsessioiden toteuttamiseen voi lukea lisää esim. Klaus Olsenin <a href="http://www.serendipeddy.nl/wp-content/uploads/2012/11/Bug-Hunting-v1.0.pps">Bug Hunt -materiaaleista</a>.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-8308096808157790561.post-9310065840665273692015-05-11T12:19:00.000+03:002015-05-11T12:21:23.143+03:00Kuinka testaus kannattaa rakentaa - oppeja tutkivan testauksen työkurssilta vol 1Minulla 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, joita toivoakseni saan puhtaaksikirjoitettua vielä lähipäivinä. 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.<br />
<br />
Kurssi oli rytmitetty niin, että lyhyitä teoriasessioita seurasi aina lyhyt paritestaussessio, jonka tulokset purettiin lyhyesti ennen siirtymistä seuraavaan teoriasessioon. Työskentelytapana tämä oli erinomainen, vaihtelu piti hyvin hereillä ja tekeminen konkretisoi läpikäytyjä asioita. Lisäksi paritestaus soi mahdollisuuden oppia parin tapaa testata, mikä toi mainion lisän kurssin antiin. Suosittelenkin lämpimästi kurssia kenelle tahansa testauksesta kiinnostuneelle.<br />
<br />
Testasimme FreeMind-sovellusta, joka on ilmainen Java-pohjainen ideakarttatyökalu. Kukaan kurssille osallistunut ei ollut käyttänyt sitä aikaisemmin, mutta osalla oli kokemusta muista vastaavista sovelluksista.<br />
<br />
<h3>
Ad hoc -testaus</h3>
Ensimmäinen testisessiomme oli ad hoc -testausta. Saimme 25 minuuttia aikaa tutustua sovellukseen parhaaksi katsomallamme tavalla. Koska käytettävissä olevan ajan puitteissa ei ollut mielekästä lähteä tutustumaan dokumentaatioon, lähdimme yksinkertaisesti kokeilemaan, miten järjestelmä toimii. Tähän on oleellisesti kaksi mahdollista lähestymistapaa.<br />
<ul>
<li>Miettiä, mihin sovellusta on tarkoitus käyttää, ja lähteä kokeilemaan, kuinka hyvin se tämän tarpeen täyttää</li>
<li>Katsoa, mitä toimintoja käyttöliittymästä löytyy, ja lähteä kokeilemaan, mitä ne tekevät</li>
</ul>
Ad hoc -testaus on hyvä tapa lähteä tutustumaan uuteen testauskohteeseen. Kun testaajalla ei ole juurikaan tietoa testattavasta toiminnallisuudesta, hän on vapaampi tekemään havaintoja. Esimerkiksi käytettävyyteen liittyvät omituisuudet jäävät ehkä helpommin kiinni, jos käyttäjän näkökyky ei ole ohjeiden ja määritysten tuomien odotusten rajoittama - useinhan loppukäyttäjäkään ei ole speksiä koskaan nähnyt. (Tämä ei tietenkään varsinaista käytettävyystestausta korvaa, mutta voi silti olla yksi kustannustehokas tapa parantaa käytettävyyttä.) Myös määrityksen lukeminen testausnäkökulmasta on helpompaa, jos on saanut jo hieman pyöritellä testattavaa järjestelmää.<br />
<br />
Huono puoli ad hoc -testauksessa on, että kun toimintaa ei fokusoida millään tavalla, ei ole mitään takeita siitä, että sillä saavutettasiin relevantteja havaintoja. Keskeisiä toiminnallisuuksia saattaa jäädä testaamatta kokonaan, jos ne eivät ole käyttöliittymässä riittävän ilmeisesti tyrkyllä, ja testauksesta raportointi (muuten kuin löytyneiden bugien osalta) on vaikeaa. Lisäksi riski sille, että bugiraporttien joukosta löytyy käyttäjän virheestä tai ymmärtämättömyydestä johtuvia ihmeellisyyksiä, on suurimmillaan kun järjestelmää vain käydään summittaisesti läpi.<br />
<br />
Myös käyntiin pääseminen uuden järjestelmän kanssa kestää jonkin aikaa, kun testaaja joutuu pohtimaan, mitä sen kanssa voisi yrittää tehdä ja mihin sitä voisi haluta käyttää, mutta tätä pidän itse väistämättömänä osana testausta. Oppiminen on prosessi joka vie aikaa, ja tehdäkseen hyvin testausta on opittava ja havainnoitava testattavaa kokonaisuutta. Ad hoc -testaus on siis parhaimmillaan testaukseen valmistautumista, ensivaikutelman hakemista testauksen kohteeseen, sekä ajatusten keräämistä testauksen suunnittelun tueksi.<br />
<br />
<h3>
Tavoitteellinen tutkiva testaus</h3>
Toiseen testisessioomme saimme tehtäväksi tietyn kokonaisuuden testaamisen. Ohjeena oli puolen sivun kuvaus kokonaisuudesta, joka kertoi, miten siihen pääsi käsiksi, mihin tarkoitukseen se oli rakennettu, sekä listasi siihen kuuluvat keskeisimmät toiminnallisuudet.<br />
<br />
25 minuuttia kului nopeasti, ja vaikka toiminnallisuus oli meille uusi, pääsimme heti täysipainoisesti käsiksi työhön. Toki ohjelman toimintalogiikka oli tullut jo edellisen testisession yhteydessä hieman tutuksi.<br />
<br />
Toiminnallisuus oli sen verran keskeneräinen, että paritestaus sujui varsin jouhevasti toisen testatessa ja toisen kirjoittaessa ylös havaintoja. Bugeja löydettiin lähes kaksinkertainen määrä edelliseen testisessioon verrattuna, ja tuntuma oli että ne myös olivat käytön kannalta relevantimpia.<br />
<br />
Tutkivan testauksen etuja on useita. Tekniikkana se minimoi testaussuunnitteludokumentaation tarpeen viemättä kuitenkaan testaukselta suunnitelmallisuutta ja kurinalaisuutta. Näin vähäinen käytettävissä aika saadaan käytettyä mahdollisimman tehokkaasti, painottaen testausta eikä testausta ohjaavan dokumentaation luomista ja ylläpitämistä. Tutkiva testaus on myös hauskaa, se auttaa testaajaa pysymään valppaana ja tekemään siten myös sellaisia huomioita, joita suunnitteluvaiheessa ei ole osattu ennakoida.<br />
<h3>
Testaus käyttötapauksia (tai testitapauksia) vasten</h3>
Kolmanteen testisessioon saimme taas uuden rajatun kokonaisuuden testattavaksi. Tällä kertaa testauksen tueksi annettiin kahden sivun mittainen vaatimusmääritys, joka oli kirjoitettu luettelemalla kokonaisuuden keskeiset toiminnallisuudet sekä kuvaamalla askeleittain niistä jokaisen käyttö.<br />
<br />
Kuten odottaa saattoi, mitä orjallisemmin testaajat seurasivat määritystä, sitä vähemmän bugeja löytyi. Määrityksessä kuvatut toiminnot pystyi kaikki viemään läpi virheittä. Kuitenkin niiden ympärille oli rakennettu käyttöliittymään yhtä jos toista, jonka käyttötarkoitus ei ollut käyttäjän näkökulmasta ollenkaan itsestäänselvä, eikä niiden kokeileminen vakuuttanut siitä että toiminnot olisivat valmiita. Kaiken lisäksi listan loppupäässä kuvattiin toiminnallisuuksia, joiden käyttäminen teki testimateriaalista oleellisesti monimutkaisempaa, ja täten tiettyjä listassa aikaisemmin kuvattuja toimintoja olisi syytä testata uudelleen listan läpikäymisen jälkeen. Tähän ei kuitenkaan testisession antaman ajan puitteissa ollut mahdollisuutta. Kenties testaus olisikin kannattanut tehdä takaperoisessa järjestyksessä.<br />
<br />
Todettiin, että tällaista dokumettia voi käyttää testauksessa hyödyksi muutamallakin tavalla<br />
<ul>
<li>Dokumentti kuvasi keskeisten toimintojen käytön, joten se toimi tapana perehdyttää testaaja testattavaan kokonaisuuteen.</li>
<li>Tällaista dokumenttia voisi jopa käyttää rajaamaan testauksesta pois dokumentin kuvaamat toiminnot. Työnsä vakavasti ottava kehittäjä on todennäköisesti testannut ne jo. (Pidemmän määrityksen kanssa näin ei luonnollisestikaan voida toimia. Tässä tapauksessa dokumentti näytti siltä kuin se olisi kirjoitettu pintapuolisen testauksen ohessa ikään kuin käyttöohjeeksi toiminnoille.)</li>
<li>Mikäli dokumentti kuvasi korkeimman prioriteetin toiminnallisuudet, sitä voisi käyttää eräänlaisena muistilistana, johon palata myöhemmässä testauksen vaiheessa sen tarkistamiseksi, onko oleellisimmat toiminnallisuudet testattu riittävän perusteellisesti ja riittävän myöhäisessä vaiheessa. Esim. regressiotestauksen suunnitteluun se voisi olla toimiva työkalu.</li>
</ul>
Samat hyödyt voitaisiin kuitenkin saavuttaa muillakin tavoin. Esimerkiksi demosessiossa, jossa kehittäjä esittelee testaajalle rakentamansa toiminnallisuuden, testaaja saa sekä perehdytyksen toiminnallisuuteen että käsityksen siitä, mitä toimintoja kehittäjä on testannut. Tällaisen istunnon lisäetuna olisi testaajan mahdollisuus esittää kysymyksiä, jotka voisivat johtaa joko testaajan entistä parempaan testaukseen, tai siihen että kehittäjä löytäisi toteutuksestaan korjattavaa jo ennen varsinaisen testauksen alkua.<br />
<br />
<h3>
Mitä jäi käteen</h3>
Sekä päivän aikana käyty keskustelu että käytännön harjoitukset tukivat käsitystäni, että tehokkain tapa löytää bugeja on nimenomaan tavoitteellinen tutkiva testaus. Tämä ei kuitenkaan tarkoita, että tutkiva testaus olisi ainoa tekniikka, jota kannattaa käyttää. Ad hoc -testauksella on myös oma arvonsa haluttaessa löytää järjestelmään uusia näkökulmia. Lisäksi määritettyjen toiminnallisuuksien läpikahlaamiseen sekä työn priorisointiin myös rakenteeltaan melko perinteinen testaussuunnittelu puolustaa paikkaansa, kunhan suunnittelu tehdään järkevästi, riittävän karkealla tasolla. Yksityiskohtaiset ohjeet kun toimivat kuin laput silmillä, vaikeuttaen muiden asioiden huomioimista.<br />
<br />
Myös paritestaus sekä testauksen jakaminen eri teeman ympärillä pyöriviin sessioihin vaikuttivat toimivilta tavoilta hakea tehoja testaukseen.<br />
<br />
Myös testauksen automatisoinnista keskusteltiin lyhyesti. Erityisesti yksikkötestipuolella automatisointi on erinomainen väline, mutta järjestelmätestauspuolella sen käyttö on jossain määrin kyseenalaista. Automaation rakentaminen vie moninkertaisen ajan verrattuna manuaaliseen testaukseen, ja automaattitestien ylläpitäminen järjestelmän muuttuessa on työlästä. Tämä ei kuitenkaan tarkoita, etteikö automaattitesteilläkin voisi olla paikkansa myös järjestelmätestausvaiheessa. Kaikkea ei aina ole edes mahdollista testata käsin käyttöliittymästä, ja lisäksi joskus testiautomaatiota on mahdollista pienin variaatioin monistaa tavalla, joka parantaa testikattavuutta tai helpottaa testimateriaalin luomista niin, että testien kirjoittamiseen käytetty aika saadaan ainakin osin kompensoitua niiden ajamisen nopeudella. Lisäksi suhteellisen muuttumattomien kokonaisuuksien testauksen automatisointi voi tuoda regressiotestaukseen merkittävän avun. Oleellista automatisoinnissa onkin analysoida, missä siitä saavutetaan suurin hyöty, sekä tietenkin ymmärtää, ettei se yksin riitä testattaessa järjestelmiä, joita ihmisten on tarkoitus käyttää.Unknownnoreply@blogger.com0