tiistai 16. elokuuta 2011

Yksikkötestauksen opettaminen

Yksikkötestaus on hankala aihe kouluttaa. Ei siksi, että testien tekeminen olisi oikeasti hankalaa, mutta siksi, että kyseessä on käytäntö, jota ilmankin pärjää ainakin teoriassa. Samanlaatuisen koodin voi kuvitella saavansa aikaan myös ilman testaukseen hurahtamista ja testikoodin ylläpitoa.

Siis voi ainakin kuvitella pääsevänsä samaan.

Tämä voi olla yksi syy siihen, että useimmat yksikkötestauksesta kirjoittavat ja esitelmöivät joutuvat lähtemään aina samoista perusteista liikkeelle. Ainakin jos yleisönä ovat Microsoftin kehitysympäristöissä työskentelevät. Tämä yleisö ei ehkä ole vielä täysin ottanut asiaa omakseen ja enkä ole varma siitä, onko niin tehnyt edes Microsoft.

Itselläni on sama tuntuma, jonka tämän blogikirjoituksen kommenttiosion kirjoittajat jakavat. Se ei välttämättä ole kovin mairitteleva.

Ilokseni olen huomannut realististen yksikkötestausta käsittelevien artikkelien lisääntyvän netissä. Monet ovat tajunneet, että tiukat yksikkötestauskäytännöt ovat liian fundamentalistisia lähtökohtia ja voivat johtaa turhautumiseen. Yksikkötestauksesta pitää saada jotain hyötyä irti ilman että pitää muuttaa kaikkia koodauskäytäntöjä.

Itse suosittelen loppukesäksi kaikkien luettavaksi Gojko Adzicin kirjaa "Specification by example". Kirja liittyy enemmän hyväksyntätestaukseen kuin yksikkötestaukseen, mutta siitä viis. Itse olen saanut kirjasta enemmän ideoita yksikkötestaukseen kuin monesta virallisesta yksikkötestausoppaasta.

Lisäys 20.8.2011:

Tämän blogijulkaisun tekijän tuntuma tukee omaa näkemystäni :
Is it too much to ask if you can write a unit test?

torstai 9. kesäkuuta 2011

Kuinka paljon panostaa työvälineisiin?

Idea tähän kirjoitukseen heräsi ohjelmistotestaus.fi blogin kirjoituksesta. Kirjoitus oli hyvä ja ajatuksia herättävä. Päätin pohtia myös täällä hiukan sitä kuinka paljon aikaa kannataa käyttää työvälineiden kuntoon saattamiseen.

Yksinkertainen sääntö pätee useimmiten: Jos työn alla olevaa pikkuviritystä (yhtä toimintoa esimerkiksi) käyttää yli 500 henkilöä, sen kuntoon hieronta voi kestää reilusti aikaa ja silti homma maksaa itsensä takaisin säästettynä aikana.

Jos taas työn alla olevaa viritystä käyttää vain 10 henkilöä, niin useimmiten pitäisi päästä nopeasti eteenpäin. Tälläisiä virityksiä ovat useimmat testitapaukset. Niiden käyttäjiä (testaajia) on yleensä vähän.

Tämä yksinkertainen sääntö on kuitenkin vaarallinen, koska se unohtaa tyystin motivaation, käytön intensiteetin/frekvenssin ja sen, että tottuminen saa aikaan isoja harhoja.

Puolinaisilla virityksillä työskentely syö pitemmän päälle motivaatiota. Käytön intensiteetti ja taajuus (frekvenssi) voi taas yksittäisellä käyttäjällä olla joillekin toiminnoille yli 50 kertainen verrattuna muihin. 10 tälläistä käyttäjää vastaa 500 tavallista käyttäjää.

Systeemityötä tekevien joukossa on paljon henkilöitä, jotka nauttivat oman ja muiden systeemityöprosessin hiomisesta. He pitävät sujuvasta harkitusta prosessista, joka alkaa suunnittelusta ja päättyy paketointiin. Heille se, että tehdään vain jotakin äkkiä ja käytetään niitä välineitä, joita on nyt käsillä, voi olla lannistavaa moraalin kannalta.

Ihmiset myös tottuvat uskomattomiin tapoihin tehdä työtä ja tulevat niissä myöskin nopeiksi. Alunperin hätäisesti suunniteltu ja noepasti korvattavaksi ajateltu tapa tehdä työtä vakioituu äkkiä. Tällöin juututaan helposti niin sanottuun "lokaaliin maksimiin", jossa surkea tapa tehdä töitä optimoidaan huippuunsa ja tuon huipun kaikilla puolilla alkaa näkyä vain valtavia pudotuksia, jotka pitäisi ensin ylittää jos parempaa tapaa halutaan etsiä.

tiistai 7. kesäkuuta 2011

Kommentteja Michael Boltonin esityksestä

Lueskelin kommentteja Michael Boltonin RST testauskurssista (esimerkiksi täältä) ja kuulin kollegalta sen mitä tapahtui Boltonin Otaniemen esityksessä.

Olen pikkuisen yllättynyt Boltonin sanojen vaikutuksesta. Herrojen Michael Bolton ja James Bach blogit ovat täynnä samanlaista provosoivaa materiaalia, enkä tiedä miksi tämä suora syyttely tuli kenellekkään yllätyksenä.

Boltonin ISTQB:tä kohtaan esittämä kritiikki, joka monen mielestä oli perusteetonta haukkumista, ei silti saa tässä mitään puolustusta. En kuullut alkuperäistä esitystä, jotenka en voi oikeasti ottaa siihen sen enempää kantaa.

Kuitenkin voisin väittää seuraavaa:
1. ISTQB on koonnut myös suomalaisia testaajia yhteen touhuamaan. ISTQB ei kuitenkaan ole pyhä, jos jotkut ovat sen eteen tehneet kovasti töitä.
2. ISTQB:n käsitys testauksesta ja sen opettamisesta on helposti tulkittavissa tunnepitoisen testauksen vastakohdaksi. ISTQB:n syllabusten tyyli provosoi vastareaktioita ihmisiltä, jotka suhtautuvat testaukseen intohimoja herättävänä ongelmien ratkaisutieteenä, missä kyseenalaistetaan ja käännetään asiat ylösalaisin.
3. ISTQB opettaa faktoja, tekniikoita ja periaatteita, jotka jollain lailla liittyvät testaukseen ja jotka on valinnut joukko testauksen ammattilaisia omien näkemystensä perusteella. Enempää ISTQB:n tuottamasta oppisisällöstä ei voi sanoa perustellusti.
4. ISTQB tenteillä tehdään rahaa. Siinä yksi syy siihen miksi niitä ei joissain piireissä arvostella ollenkaan. Itse olen pitänyt ISTQB kursseja ja arvostellut niitä samalla. Minusta se oli tärkeää, jotta kurssilaisille tulisi selvä kuva siitä mitä he voivat kurssilla oppia.

Kommentit Boltonin esityksestä ovat tervetulleita. Lähettäkää myös linkkejä, jos olette jo pohtineet asiaa omissa blogeissanne.

torstai 14. huhtikuuta 2011

Uusi blogi englanniksi

Tein rinnakkaisen blogin englanniksi. Ensimmäinen aihe käsittelee Virossa pidettävää RST kurssia. Linkki blogiin.

maanantai 31. tammikuuta 2011

Impostor syndrome

Tähän kirjoitukseen minut innoitti hyvä ja paljon kommentoitu blogikirjoitus . Kirjoittaja (Jean Hsu) puhuu monesta, ja osittain myös ilmiöstä nimeltä Impostor syndrome, jolla on varmasti myös suomenkielinen nimi.

Impostor syndroomassa potilas ei usko niin millään omiin kykyihinsä. Kaikki on esimerkiksi aina jollain lailla tuurin tai olosuhteiden tuotosta. Mikään ei myöskään tunnu vahvistavan potilaalle positiivisempaa mielikuvaa. Tämä syndrooma ei ole mitenkään virallisesti tunnustettu psykologinen ilmiö, mutta osittain varmasti kaikille tuttu.

Blogikirjoitus puhui naisten kokemuksista, mutta mainittu taudin kuvaus on tietysti yleisempi ongelma. Uskon itse, että esimerkiksi ammattialoista tietojenkäsittely ruokkii tätä ongelmaa ihan työkseen. Systeemityön parissa on erittäin helppoa sairastua itsensä aliarvioijaksi ja jäädä tilanteeseen vangiksi loppu-uran ajaksi. Useiden ohjelmistokehitys organisaatioiden sisäiset ja tosiasialliset rakenteet perustuvat tähän syndroomaan.

Tietojenkäsittelyn ammattilainen voi tuntea itsensä herkästi täysin tietämättömäksi alastaan, vaikka takana olisi vuosikymmenten ura ja kouluttautuminen. Jos et omaa vahvaa ammatillista itsetuntoa, olosi voidaan saada hetkessä epävarmaksi. Se mitä nippelitietoa sinun oletetaan tietävän tai mistä sinun oletetaan olevan perillä voi olla jatkuvasti edestäsi karkaava tavoite. Myöskin se minkä verran sinulle kerrotaan tietoa, ennen kuin sinulta odotetaan jo soveltamista tai arviota, voi olla aina tarkoituksellisen niukkaa.

Testaajat eivät ole immuuneja tälle ammatillisen epäpätevyyden jatkuvan tuntemisen syndroomalle. Testaajalla pitäisi olla oikeus kysyä niitä tyhmiä kysymyksiä, mutta ympäristön oletus saattaa olla, että tiettyjä asioita ei silti selitetä auki. Saatat esimerkiksi tehdä töitä vuosikausia koodaajan kanssa, joka ei vaivaudu selittämään koodinsa yksityiskohdista mitään, mutta pitää etäisyyttä sinuun puhumalla vain täysin aukipurkamattomilla ammattitermeillä omasta työstään.

Alalta löytyy tietysti myös oikeaa epäpätevyyttä. On paljon sitä, että oletetaan, että koko systeemityöala on jo opittu muutamassa vuodessa ja loput onkin sitten vain kiinni siitä kuinka verbaalisen akrobaattisesti osaa oman niukkatietoisuutesi kätkeä, eli kuinka hyvin selviää puhumalla. Useat asiakasrajapinnassa kiinni olevat konsultit ja kenttäinsinöörit ovat hyvin nuoria, innokkaita ja valitettavasti alttiilta tälle toiselle ansalle.

Mikä siis neuvoksi? Millä nostaa omaa ammatillista itsetuntoa terveesti ja taistella varsinkin suurten ohjelmistoyritysten tasapäistämistaipumuksia vastaan? Suurille yrityksille kun sopii se, että sinä et koe itseäsi kyvykkääksi yksin, vain vain osana heitä. Et ole mitään verrattuna talon suuriin guruihin, eikä osaamisesi ole mitään sinänsä tuotteistettavaa. Kun lähdet ulos talosta sinusta saattaa tuntua, että jäljelle ei jäänyt mitään omaa, koska yhtiön viitekehys alkoi ajan saatossa ulottua myös henkiselle puolelle. Sairastuit ehkä impostoriksi.

Lääke Impostor syndroomasta ulos voisi olla se, että tietojenkäsittelyn koulutuksessa kiinnitettäisiin entistä enemmän huomiota omasta osaamisesta puhumiseen. Tästä kirjoitan myöhemmin lisää.

Ps. Viimeinen vuosi on kulunut ahkerasti kehittäjän testauksen ja kehityksen parissa. Kouluttajan on hyvä välillä lähteä pitempikestoisiin kehitysprojekteihin mukaan

perjantai 8. tammikuuta 2010

Suomalainen testaustutkimus on harhapolulla?

Ohjelmistotestauksen suomalainen tutkimus on yleensä pitkälle teknillisten oppilaitosten tuottamaa. Tämä näkyy tutkimusten näkökulmassa ja loppupäätelmissä.

Michael Bolton blogissa oli mielenkiintoisen kirjoitus, jonka pohjana oli TKK:lla tuotettu tutkivaa testausta käsittelevä tutkimus vuodelta 2007.

Boltonin yhteenvetokommentti tutkimuksesta oli "Testing is a qualitative evaluation of a product; this study is a quantitative evaluation of testing.". Olen pitkälti samaa mieltä.

Teknillisten tutkimusten tarkoituksena on löytää teknillisiä, määrällisiä (kvantitatiivisia) mittareita tutkimustensa kohteista. Testauksessa on kuitenkin paljon tarpeellisempaa huomioida tilannekohtaiset, sosiaaliset ja oppimiseen liittyvät mittarit, joita ei voida niputtaa teknisen käsitteistön avulla.

Tekninen korkeakoulu on huono paikka lähteä tutkimaan testausta laajemmin. Suomalaisessa teknisessä tutkimuskentässä on perinteisesti totuttu hyvin tekniseen maailmankuvaan ja tekniikan valtaan. Tilannekohtaisen oppimisen roolin myöntäminen siirtäisi vallan pois tekniikan guruilta toisille tiedealueille ja vaatisi aivan toisenlaista näkökulmaa.

Pitäisi myöntää seuraava: Ruohonjuuritason testaajat saavat testauksen aikana tietoonsa asioita ja muodostavat kohteestaan malleja, joista tekniset gurut eivät tiedä etukäteen mitään, eivätkä osaa niitä millään lailla etukäteen mallintaa.

Jos tämä myönnettäisiin se tarkoittaisi testaajien arvostuksen nousua ja myös sitä, että testaajien täytyisi itsekin herätä huomaamaan olevansa tässä ainutlaatuisessa asemassa.

tiistai 8. joulukuuta 2009

Vuoden testaaja 2010

Vuoden testaajan nimittäminen ja valinta on tullut taas ajankohtaiseksi. Ohjeet ja lomakkeet löytyvät täältä.

Miksi valita vuoden testaaja?
Syy 1: Mainosarvo. Sitä tarvitaan, jotta testaustyö edes jotenkin näkyisi mediassa.
Syy 2: Valintaperusteiden mietintä. Mistä syistä arvostamme muita testaajia ja millä perusteella nostamme joitakuita esille?

Ketkä yleensä puhuvat testauksesta, jos on tarve nostaa testaajia esille? Kuinka usein kyseessä on oikeasti testausta ruohonjuuritasolla tehneet ammattilaiset?