Kävin keskustelua kursseista, opetustavoista ja opetussisällöistä osana työpajamme jälkipyykkiä. Keskustelu oli varsin lyhyttä ja lähtökohdiltaan varsin erimielistä. Toisaalta tavoitteena tuskin onkaan saavuttaa yhtenäistä näkökulmaa.
Olen kritisoinut taustalla erään kurssitoimittajan ketterän testauksen kurssimateriaalia. Julkaisen lähiaikoina kritiikkini tarkasteltavaksi, ja vastaavasti minulla on käynnissä oma analyysi omien materiaalieni parantamiseksi että saisin pois osan omista vähintään yhtä räikeistä virheistäni.
Voisin varmaan hoitaa palautteen antamisen helpommin omaksuttavassa muodossa, mutta uskon että ihmiset huomaavat johdattelun. Jos on sanottavaa, sen voisi sanoa, ja jos toinen osapuoli on tuttu, asian voisi ottaa asiana eikä henkilökohtaisena.
Olen kiitollinen saamastani lyhyestä palautteesta oman opetustyylini osalta: minulle on jonkin kuulijajoukon osalta muodostunut maine että minulle on olemassa vain yksi tapa tehdä asioita, esim. ketterässä testauksessa.
Jäin miettimään tätä, ja totesin parannettavaa. Minun on entisestään tarpeen korostaa materiaalieni case-pohjaisuutta. En usko prosesseihin ja ohjeisiin, vaan esimerkkeihin ja ristiriitaisuuksiin niissä. Kuvittelen puhuessani sanovani että minun kokemissani tilanteissa näin, ja olen jopa toistuvasti muuttanut materiaaliani ketterän testauksen suhteen erottaakseni "näin sanotaan yleisissä ohjeissa" ja "tälläisessa maailmassa minä olen kokenut tälläista".
Esitystilanteessa sanominen ei ole sama kuin kuuleminen. Tarkoitukset ja merkitykset värittyvät puolin ja toisin aina viestintätilanteessa. Erityisen keskeisten ja vaikeiden asioiden kanssa dialogiin on varattava aikaa ja tukea. Sama pätee lukemisen suhteen: saatan tulkita liikaa esim. siihen että kalvolla otsikolla Scrum kerrotaan olevan kolme backlogia: product, sprint ja test. Ehkä siinä tosiaan tarkoitetaan että jos testaus on erillinen tiimi, heillä voi olla oma sprint backloginsa. Teksti ei kerro.
Kaikenlainen viestintä on kaksisuuntaista, paitsi jos tyydytään siihen että todetaan erimielisyys ilmaistun muodon kanssa. Itse tavoittelen muutosta parempaan, joka viime kädessä vaatii dialogia.
Kun luette kirjoittamaani tai olette eri mieltä sanomani kanssa, antakaa minulle tilaisuus muuttaa mieltäni tai selittää mitä itse asiassa tarkoitan.
Niin tai näin, taustalla tässä pohdinnassa on perusolettama omista kokemuksistani: ketterässä kehityksessä testauksella voidaan saada aikaan jotain hyvää, mutta toisaalta sen perinteisillä muodoilla voidaan syödä merkittävästi hyötyjä kokonaisuudelta.
maanantai 9. marraskuuta 2009
Ketterän testauksen työpaja, tuoreita ajatuksia
Tänään oli ketterän testauksen työpaja, jossa edustettuna varsin monenlaista ketterän kehityksen, testauksen ja perinteisen testauksen osaamista. Porukassa ei kukaan ollut täydellinen juniori kaikkien suhteen, mutta matkaa yhteiseen ymmärrykseen on aika paljon.
Minulle korostui keskusteluissa että joukosta löytyi kolmenlaista "ketterää kehitystä ja testausta":
- "ketteryys koska niin päätettiin"
- "ketteryys koettuna, mutta puolimatkassa"
- "ketteryys koettuna, aika pitkällä"
Joukostamme löytyi jokunen joka katseli organisaationsa ketterän kehityksen pyrkimyksiä vielä isona kokoelmana haasteita, joka tuntui pitkälti estävältä. Oltiin huolissaan laadusta joka pitää selvittää vasta lopussa (ei kovin ketterää), dokumentoinnin puutteesta tässä tilanteessa, testauksen mukanaolosta ja mahdollisuuksista yleensäkin. Kokonaisuus yksittäisen tiimin ulkopuolelta kuulosti lähinnä vesiputoukselta, jossa jokainen vaihe oli muotoiltu scrum-pakettiin. Yleisesti nämä olivat erilaisia Scrummerfall ja ScrumBut -toteutuksia.
Toinen korostunut joukko oli niitä joilla ei ole laajamittaista automatisoitua testausta eikä varsinkaan hyväksymistestiohjattua kehitystapaa, mutta joiden osalta kuitenkin kokemus oli merkittävän, ja hyödyllisen eron omaaminen perinteiseen kehitykseen ja testaukseen. Laatuvastuu on tiimeillä, ja tiimit ovat ehkä jossain komponenttitiimin ja ominaisuustiimin puolessa välissä.
Kolmas korostunut joukko olivat nk. aidot agilistit. Korostuneesti minulle jäi vaikutelma että tässä porukassa oli varsin vähän pitkään testausta - manuaalista sellaista - tehneitä ihmisiä, joskin kohtuullisen pitkään mukana olleita oli. Tämän porukan testausedustusto oli järjestäin ohjelmointitaitoisia.
Jään hauduttelemaan ajatuksiani, mutta pidin erityisen yllättävänä omaa reaktiotani siihen että testaaja ei olisi sovellusalueen osaaja. Toki, asiakas-toimittaja-tilanteissa tulee vastaan minullekin paljon tilanteita, joissa en tunne sovellusaluetta. Testaajana minulla, ainakin omasta mielestäni, keskeisenä taitona on oppia nopeasti vähän kerrallaan ja sitä kautta vaikka en koskaan varmasti muotoudu esim. asiakashallintasovellusten supersovellusalueosaajaksi, kohtuullinen osaaja ja tehokas testaaja voin olla.
Pitäisi varmaan työstää ajatuksella niitä testauksellisia osaamisia, mitä Microsoft-kirja jota juuri luin kuvasti tittelillä "tester dna".
Ja käytäntöjen osalta, tuo kolmijaottelu voisi olla varsin hyödyllinen pohja koulutusmateriaaleissani. Siinäkin on vielä paljon vaihtelua, mutta voisi edes vähän saada otteen että missä skaalalla oikein mennään.
Minulle korostui keskusteluissa että joukosta löytyi kolmenlaista "ketterää kehitystä ja testausta":
- "ketteryys koska niin päätettiin"
- "ketteryys koettuna, mutta puolimatkassa"
- "ketteryys koettuna, aika pitkällä"
Joukostamme löytyi jokunen joka katseli organisaationsa ketterän kehityksen pyrkimyksiä vielä isona kokoelmana haasteita, joka tuntui pitkälti estävältä. Oltiin huolissaan laadusta joka pitää selvittää vasta lopussa (ei kovin ketterää), dokumentoinnin puutteesta tässä tilanteessa, testauksen mukanaolosta ja mahdollisuuksista yleensäkin. Kokonaisuus yksittäisen tiimin ulkopuolelta kuulosti lähinnä vesiputoukselta, jossa jokainen vaihe oli muotoiltu scrum-pakettiin. Yleisesti nämä olivat erilaisia Scrummerfall ja ScrumBut -toteutuksia.
Toinen korostunut joukko oli niitä joilla ei ole laajamittaista automatisoitua testausta eikä varsinkaan hyväksymistestiohjattua kehitystapaa, mutta joiden osalta kuitenkin kokemus oli merkittävän, ja hyödyllisen eron omaaminen perinteiseen kehitykseen ja testaukseen. Laatuvastuu on tiimeillä, ja tiimit ovat ehkä jossain komponenttitiimin ja ominaisuustiimin puolessa välissä.
Kolmas korostunut joukko olivat nk. aidot agilistit. Korostuneesti minulle jäi vaikutelma että tässä porukassa oli varsin vähän pitkään testausta - manuaalista sellaista - tehneitä ihmisiä, joskin kohtuullisen pitkään mukana olleita oli. Tämän porukan testausedustusto oli järjestäin ohjelmointitaitoisia.
Jään hauduttelemaan ajatuksiani, mutta pidin erityisen yllättävänä omaa reaktiotani siihen että testaaja ei olisi sovellusalueen osaaja. Toki, asiakas-toimittaja-tilanteissa tulee vastaan minullekin paljon tilanteita, joissa en tunne sovellusaluetta. Testaajana minulla, ainakin omasta mielestäni, keskeisenä taitona on oppia nopeasti vähän kerrallaan ja sitä kautta vaikka en koskaan varmasti muotoudu esim. asiakashallintasovellusten supersovellusalueosaajaksi, kohtuullinen osaaja ja tehokas testaaja voin olla.
Pitäisi varmaan työstää ajatuksella niitä testauksellisia osaamisia, mitä Microsoft-kirja jota juuri luin kuvasti tittelillä "tester dna".
Ja käytäntöjen osalta, tuo kolmijaottelu voisi olla varsin hyödyllinen pohja koulutusmateriaaleissani. Siinäkin on vielä paljon vaihtelua, mutta voisi edes vähän saada otteen että missä skaalalla oikein mennään.
Tilaa:
Blogitekstit (Atom)