Kuuntelin eilen ihmisiä Tampere Goes Agile -tapahtumassa ja mietin. Useammassakin kohdassa testaajan korvaani särehteli se mitä luulin kuulevani: pohdintaa siitä miten "perinteisistä testaajista" saataisiin tehtyä testauksen automatisoijia, vaikka sellaisia jotka osaa "copypasteta keywordeja"; miten näistä saataisiin tehtyä määrittelijöitä - yleensäkin jotain mitä he eivät nyt ole.
Toinen särähtelevä viesti oli ajatus siitä että jos testaajat olisivat mukana tekemässä määrittelyä esimerkein, he pystyisivät ennakkoon kertomaan kaikki ne asiat jotka kertoisivat havaintoina testatessaan. Kuunnellessani tämän suunnan viestejä muistin, miksi ensi kertaa koin kykeneväni itse hyväksymään tätä kehitysmallia paremmin kun se sai Gojko Adjicin tekstien lueskelun myötä oikean nimensä: määrittely esimerkein. Ei tämä mitään hyväksymistestiohjattua kehitystä ole, korkeintaan esimerkkiohjattua. Ja esimerkit eivät ole kaikki mitä hyväksyntään vaaditaan. Tämä usko esimerkkien täydellisyyteen henki jotenkin monen toteuttajataustaisen agilistin viesteissä ja onhan se kivan vapauttava ajatus että toteutetaan mitä on määritelty ja muu jää muualle.
Juttelin pitkään erään arvostamani kolleegaan kanssa. Keskustelu muistutti, että osana kokeilujani tehdäksemme hyvää määrittelyä esimerkein, minulla on hypoteesi testattavana. Minä uskon, että ohjelmisto puhuu minulle testaajana, olen oppinut kuuntelemaan sitä tavoilla joita on välillä vaikea eritelläkin. Se vihjaa mihin kiinnittää huomiota, antaa vinkkejä siitä kuinka moneen kertaan asiaa kannattaa eri silmälasein tarkastella. Esitän sille kysymyksiä ja se vastaa. Vastausten perusteella opin jotain mitä en tiennyt ennestään, ja käytän oppimaani rajallisen ajan suuntaamiseen sellaisiin asioihin joilla on merkitystä.
Puhun toki myös ihmisille, ja hekin vastaavat minulle sillä suoralla vastauksella, mutta olen aina testaajana kuunnellut myös vastauksen sivuviestejä: epävarmuuksia, selittämisen vaikeutta, välttelyä, hienojakoisia eroja toisten sanomisiin. Näistäkin opin, ja tarkastelen mitä ne käytännössä tarkoittavat keskustellen jälleen sen ohjelmistoversion kanssa.
Esimerkein määrittelyssä uskon, että inkrementin pienuus auttaa monessa asiassa. Minulla on edelleen se tuotekonteksti, tämänhetkinen ohjelmistoversio. Puhumme esimerkein siitä, mitä siihen lisätään. Mutta oletan, ja tätä aion myös osaltani testata, että avainesimerkit vangitsevat joitain juttuja jotka nostaisin esiin normaalisti testatessani mutta jättävät osan vangitsematta. Määrittely ja mielikuvitus ilman konkreettista herätettä testattavasta ongelmasta ei vain ole yhtä monipuolinen lähde testaajan osaamisten pohjaksi. Uskon toki että se on riittävä. Mutta, korvaani tulee vielä pitkään särähtämään, kun tutkivan testauksen roolia kuviossa ei ymmärretä. Mikään ei estä meitä varaamasta aikaa tutkivalle testaukselle, oppimisille ja reagoinnille - paitsi me itse ja uskomuksemme siitä mitä sprinteissä pitää tapahtua.
Olin muutaman vuoden poissa agilekentältä, kun minusta aiheesta puhujan tulee harjoittaa jotain puhumisensa suuntaista: Ilmarinen ei juurikaan harjoittanut ja käsiteltäväksi jäi lähinnä perinteiseen paluun aikaansaamat opit. Eilinen muistutti, että testausmielessä tällä kentällä on ammattikuntani kannalta tärkeää työtä tehtävänä. On se sääli jos testaajien osaamista ei nimikkeen ja ymmärryksen puutteiden vuoksi osata hyödyntää ja ketterän kentän tarvitsee kantapään kautta oppia monimuotoisen palautteen tekokkaan tuottamisen asiat. Automaatio on osa, mutta se ei ole näin iso fokus. Ja tietystihän on helppoa sanoa että se tuoteomistaja tekee tän tyyppiset jutut, ja harjoittelee ne taidot joita testausihmiset ovat nk. perinteisessä maailmassa hioneet.
Ja muuten, testauskentällä on testaajia, jotka suorittavat muiden suunnittelemia testejä rutiininomaisesti tarkistellen "automaation korvikkeita". Niitä jotka uskovat että vastaukset tulevat spekseistä, ajattelematta, itse oppimatta ja yhdistelemättä. Laitan sen luokan työn samaan laariin sen avainsanojen leikkaa-liimaa -ajatuksen kanssa. Kummastakin voisi kokonaan luopua.
Toinen särähtelevä viesti oli ajatus siitä että jos testaajat olisivat mukana tekemässä määrittelyä esimerkein, he pystyisivät ennakkoon kertomaan kaikki ne asiat jotka kertoisivat havaintoina testatessaan. Kuunnellessani tämän suunnan viestejä muistin, miksi ensi kertaa koin kykeneväni itse hyväksymään tätä kehitysmallia paremmin kun se sai Gojko Adjicin tekstien lueskelun myötä oikean nimensä: määrittely esimerkein. Ei tämä mitään hyväksymistestiohjattua kehitystä ole, korkeintaan esimerkkiohjattua. Ja esimerkit eivät ole kaikki mitä hyväksyntään vaaditaan. Tämä usko esimerkkien täydellisyyteen henki jotenkin monen toteuttajataustaisen agilistin viesteissä ja onhan se kivan vapauttava ajatus että toteutetaan mitä on määritelty ja muu jää muualle.
Juttelin pitkään erään arvostamani kolleegaan kanssa. Keskustelu muistutti, että osana kokeilujani tehdäksemme hyvää määrittelyä esimerkein, minulla on hypoteesi testattavana. Minä uskon, että ohjelmisto puhuu minulle testaajana, olen oppinut kuuntelemaan sitä tavoilla joita on välillä vaikea eritelläkin. Se vihjaa mihin kiinnittää huomiota, antaa vinkkejä siitä kuinka moneen kertaan asiaa kannattaa eri silmälasein tarkastella. Esitän sille kysymyksiä ja se vastaa. Vastausten perusteella opin jotain mitä en tiennyt ennestään, ja käytän oppimaani rajallisen ajan suuntaamiseen sellaisiin asioihin joilla on merkitystä.
Puhun toki myös ihmisille, ja hekin vastaavat minulle sillä suoralla vastauksella, mutta olen aina testaajana kuunnellut myös vastauksen sivuviestejä: epävarmuuksia, selittämisen vaikeutta, välttelyä, hienojakoisia eroja toisten sanomisiin. Näistäkin opin, ja tarkastelen mitä ne käytännössä tarkoittavat keskustellen jälleen sen ohjelmistoversion kanssa.
Esimerkein määrittelyssä uskon, että inkrementin pienuus auttaa monessa asiassa. Minulla on edelleen se tuotekonteksti, tämänhetkinen ohjelmistoversio. Puhumme esimerkein siitä, mitä siihen lisätään. Mutta oletan, ja tätä aion myös osaltani testata, että avainesimerkit vangitsevat joitain juttuja jotka nostaisin esiin normaalisti testatessani mutta jättävät osan vangitsematta. Määrittely ja mielikuvitus ilman konkreettista herätettä testattavasta ongelmasta ei vain ole yhtä monipuolinen lähde testaajan osaamisten pohjaksi. Uskon toki että se on riittävä. Mutta, korvaani tulee vielä pitkään särähtämään, kun tutkivan testauksen roolia kuviossa ei ymmärretä. Mikään ei estä meitä varaamasta aikaa tutkivalle testaukselle, oppimisille ja reagoinnille - paitsi me itse ja uskomuksemme siitä mitä sprinteissä pitää tapahtua.
Olin muutaman vuoden poissa agilekentältä, kun minusta aiheesta puhujan tulee harjoittaa jotain puhumisensa suuntaista: Ilmarinen ei juurikaan harjoittanut ja käsiteltäväksi jäi lähinnä perinteiseen paluun aikaansaamat opit. Eilinen muistutti, että testausmielessä tällä kentällä on ammattikuntani kannalta tärkeää työtä tehtävänä. On se sääli jos testaajien osaamista ei nimikkeen ja ymmärryksen puutteiden vuoksi osata hyödyntää ja ketterän kentän tarvitsee kantapään kautta oppia monimuotoisen palautteen tekokkaan tuottamisen asiat. Automaatio on osa, mutta se ei ole näin iso fokus. Ja tietystihän on helppoa sanoa että se tuoteomistaja tekee tän tyyppiset jutut, ja harjoittelee ne taidot joita testausihmiset ovat nk. perinteisessä maailmassa hioneet.
Ja muuten, testauskentällä on testaajia, jotka suorittavat muiden suunnittelemia testejä rutiininomaisesti tarkistellen "automaation korvikkeita". Niitä jotka uskovat että vastaukset tulevat spekseistä, ajattelematta, itse oppimatta ja yhdistelemättä. Laitan sen luokan työn samaan laariin sen avainsanojen leikkaa-liimaa -ajatuksen kanssa. Kummastakin voisi kokonaan luopua.
Ei kommentteja:
Lähetä kommentti
Huomaa: vain tämän blogin jäsen voi lisätä kommentin.