Nyt on 23. Toukokuuta ja istun Hotelli Haagan huoneessa. Olen Michael Boltonin vetämällä Rabid Software Testing -kurssilla. Kurssi on huikea ja palaan siihen vielä kattavammin myöhemmin.
Antti Niittyviita Provelta kommentoi minulle kirjoittamistekniikastani hotellin aulassa. Hänen mielipteensä kirjoittamistyylistäni oli se, että annan kerralla liikaa... Hmmmm... On totta että kirjoitan tunteella ja tunnin, mutta tämänkertainen kirjoitelmani ei ole tunnin mittainen. Tunteet ovat siinä kuitenkin mukana.
Hah! Tunteet eivät kuulu projektimaailmaan! Meillä pitää olla faktoja eikä tunteita! Mittarit kertovat meillä tarvittavat asiat ja muu on turhaa nyyhkytystä! Vai onko?
Suomessa ei ole kovin paljoa puhuttu testauksesta tunteiden pohjalta, mutta Michaelin mukaan nopean ja tehokkaan tutkivan testauksen yksi kulmakivistä on tunteiden liittäminen testaukseen. Tunteet toimivat toiminnan laukasijana. Usein viitataan intuitioon, perstuntumaan, jne. tapauksissa, joissa meillä ei ole suoranaista faktaa tai mittareita kertomaan asioista. Mittarina toimii siis henkilö itse. Esimerkkinä Michael käytti autolla ajamista: "Jos mietit, että ajanko liian lujaa, ajat liian lujaa." Ihminen saa tuntemuksia erilaisten tapahtumien johdosta, esimerkiksi hämmennys testatessa tarkoittaa, että jokin testauksen kohde on hämmentävä. Tämä toimii mittarina sille, että kaikki ei välttämättä ole kohdallaan.
Tämä siis puhtaasti sitä, mitä kurssilla opetettiin... Miten tämä siis kääntyy esimerkiksi meidän yrityksemme testausprosessiin? Kun prosessi on määritelty sellaiseksi, että automaatio näyttelee (tai tulee näyttelemään) suurta osaa, täytyy testauksen hallinnan luovia itselleen väylä tuonne. BDD tyyppisen prosessin johtaminen tunteella ei välttämättä ole se, mitä johtoporras tai asiakas haluaa kuulla. Voidaanko tunteen pohjalta kuitenkin tehdä bisnespäätöksiä? Tarvitseeko kaikki päätökset tehdä mittareiden pohjalta?
Jos testaaja saa tunteen, että "tässä on jokin vialla", eikö se ole maailman paras mittari? Jos jokin toiminnallisuus herättää epäluuloa, eikös se ole vahvempi mittari kuin "3 minor defectiä, joista kaksi korjataan 9. sprintissä"? Jos testaaja tuntee turhautumista siitä, että ei löydä toiminnallisuudesta enempää vikoja, kertooko se enemmän kuin "S-käyrän taittuminen toiminnallisuuden vikakertymää tarkasteltaessa"?
Kuinka siis esittää liiketoiminnalle arvio järjestelmään liittyvistä riskeistä, jos ne pohjataan mittareihin? Voidaanko testausprosessiin liittää tutkivan testauksen tuoma reaktiokyvyn kasvattaminen sekä tunteiden "kuunteleminen", mutta säilyttää iteraatiomallin automatisoitu regressiotestaus? Testausprosessiin tulisi liittää vaihe, joka on rinnan muun testauksen kanssa, joka käsittelee testattavaa tuotetta tutkivan testauksen näkökantilta, mutta joka tapahtuu rinnan kaiken muun testauksen kanssa. Heuristiset menetelmät ja sessiopohjainen testauksen hallinta voivat vapauttaa resursseja kankeista manuaalisista testausprosesseista ilman että manuaalisesta testauksesta luovutaan (ja tätäkin ajatusta maailmalla viedään eteen- ja taaksepäin). Tämä prosessimalli mahdollistaisi automaation tuoman jatkuvan ja nopeatempoisen raportoinnin etujen liittämisen tutkivaan testaukseen ja älykkääseen päätöksentekoon.
Mutta Antin mielipidettä kunnioittaakseni aion pitäytyä nyt lyhyessä pohdiskelussa ja vielä tämän viikon aikana aion avata sanaisaa arkkuani toisen merkinnän puitteissa. Siihen asti... tunteella mukana.
Monday, 23 May 2011
Tuesday, 10 May 2011
Manuaalisen testauksen profiilin nostaminen
Testauksen automatisointi on manuaalisen testauksen suorittamista koneellisesti, jonkin testausohjelman avulla. Automaatio onkin muodostunut suureksi osaksi nykypäivän testausta ja sillä on vankkaa kannatusta läpi testaus-skenen. Lähes kaikki testaajat ovat vakuuttuneita automaation hyödyistä - myös minä. Kuinka moni enää kuitenkaan uskoo manuaalisen testauksen voimaan testauksessa?
Automaatiota arvostetaan suhteessa enemmän kuin manuaalista testausta: kun etsin manuaalisesta testauksesta kertovaa materiaalia, jokaisessa oli vähintään ohjeistus kuinka automatisoida nuo manuaaliset testit. On ilman muuta totta, että automatisoidut testit vievät vähemmän aikaa ajaa, kunhan ne on toteutettu. Onko kuitenkin jokin kuitenkin pudonnut kelkasta matkan varrella, koska manuaalinen testaus testauksena on maailman hienoin asia (puhtaasti oma mielipide eikä minulla ole tieteellistä faktaa tukemaan tätä väitettä)?
Testauksen automaation helppoutta korostetaan monessa paikassa (mm. Bhavian Turakhia esityksessään), vaikka helposti automaation toteuttaminen on huomattavasti vaikeampaa kuin manuaalinen testaaminen. Testausautomaation edut eivät siis suinkaan ole testit toteuttamisen helppoudessa, ainakaan kaikissa tapauksissa. Pentti Pohjolainen kirjoitta gradussaan:
Tämä tarkoittaa käytännössä sitä, että sen lisäksi että pitää olla hyvä määrittely- ja suunnitteludokumentaatio, tulee tapaus pystyä testaamaan ylipäänsä. Lisäksi Pohjolainen viittaa siihen, että järjestelmän toiminta tulee olla ennustettavissa tarkkaan, että tiedetään mikä loppu tulema tulee tarkalleen olemaan. Automaatiota ei kannata tehdä ilman tarkistuksia. Manuaalisessa testauksessa tarkistuksen tulevat automaattisesti, kun tulosta tarkistetaan! (No menipähän saivarteluksi..)
Testausautomaatio on äärimmäisen kannattavaa silloin, kun samaa tapausta ajetaan useita kertoja. Jos puhutaan ketteristä menetelmistä, joissa iteraatioita on paljon, yönylitestit tuovat lisäarvoa ja ennustettavuutta, jne., testausautomaatio on tehokas työkalu. Jos verrataan manuaalisen testauksen kustannuksia iteraatiotilanteissa, ei manuaalisen testauksen kustannustehokkuus yllä lähellekään automaatiossa säästettäviä summia. Mitä tapahtuu, kun määrittely muuttuu? Mitä tapahtuu, kun muutetaan komponenttien nimeämispolitiikkaa? Mitä tapahtuu muutoksen yhteydessä? Jotain muuttuu! Kun testiautomaation kohteena oleva järjestelmä muuttuu, täytyy testi päivittää. Kun testi päivitetään, sen toiminta tulee ensin varmistaa jollakin tapaa että testi itse ei jää vialliseksi -> manuaalinen testaus. Kun tehdään automatisoitua testausta ketterissä menetelmissä, voidaan olla varmoja, että testien päivitystä tapahtuu. Kuinka suuret kustannukset aiheutuvat testien päivittämisestä, koestamisesta, uudelleenajamisesta? Kuinka "hauskaa" (lainatakseni herra Turakhiaa) testien päivittäminen on, kun koko sovelluslogiikka muuttuu?
Manuaalisen testauksen ollessa pääasiallinen lähestymistapa edellä mainitussa tapauksessa, voidaan manuaalisesti saada palaute nopeammin kuin automatisoiduissa testeissä. Automaation kannattava voimahan on sen "palautteen nopeus". Jos tämä voima katoaa, onko automaatiosta mitään hyötyä? Toki joitakin testitapauksia on vaan puhtaasti viisaampi testata automaattisesti, mutta näissäkään tapauksissa ei puhuta puhtaasta automaatiosta vaan manuaalisen testauksen tukena käytettävästä työkalusta, jossa testausta helpotetaan työkalun ominaisuuksilla. Hyvänä esimerkkinä on suorituskykytestaus, joka ei luonnistu ihan helposti manuaalisesti... vaikkakin mm. Sokoksen verkkokaupan case-esittelyssään kerrottiin koko kehittäjätiimin (noin 100 henkeä) tehneen viiden minuutin aikana pikaisen suorituskykytestin, jossa kaikki kirjautuivat verkkokauppaan, jne. Pointti on kuitenkin se, että manuaalinen testaus sitä tukevin työkaluin on usein tehokkaampaa kuin puhtaasti automaattinen testaus.
F-secure on yksi testauksen edelläkävijöitä Suomessa ja heidän automaation toteutustavat herättävät minussakin kateutta. Voiko kuitenkaan samaa mallia soveltaa kaikkialle? Onko järkevää toteuttaa automaatiota sellaisiin projekteihin, joissa kalenteriajassa on viikko testausaikaa ja määrittelyt ovat powerpoint-tasolla (onko kenellekkään tuttu malli?) tai toteutus on niin paljon myöhässä, että vesiputousmallinen projekti karsii taas testauksesta? Ei heilläkään kuitenkaan ole hylätty automaatiota vaan se tukee heidän manuaalista testaustaan ja toimii "takaporttina", jolla mahdollistetaan regression poissulkeminen mahdollisimman pian. Heidän testausprosessinsa on sen mallinen, että automaatio mahdollistaa kypsän softan pääsyn manuaaliseen testaukseen.
No, kaikki tämä puhe automaation ongelmista ei tarkoita sitä, että automaatio pitäisi karsia kokonaan pois. Ei suinkaan! Päämääränä on tuoda älykkyys takaisin testaukseen (oliko se se, mikä taannoin putosi kelkasta?). Älykkyydellä en suinkaan tarkoita teknistä tietämystä tai taitoa, vaan sellaista älykkyyttä, mikä testaajalla pitää olla: kyseenalaistava älykkyys. Voidaanko puhua älykkyydestä, jos työkalujen tarjoajat mainostavat manuaalista testausta vanhentuneeksi? Voidaanko puhua älykkyydestä, kun koko laadun pohjaksi muodostetaan yönylitestien vihreänä pitäminen? Voidaanko puhua älykkyydestä, kun mottona on testauksen automatisointi, jolloin myös testauksen suunnittelu on automaattista? Jos kaikki on automaattista, niin mihin sitä älykkyyttä itse asiassa tarvitaan edes? (Onnistuinko puhumaan itseni pussiin...)
Sivusin aiemmin manuaalisen testauksen palautteen "hitautta" verrattuna automaatioon. Minulle on itselleni tuputettu teesiä "automaatiolla palaute on sekunteja, kun manuaalisella se on päiviä". Mitä tapahtuu, kun automaattista testisettiä pitää päivittää ja kyseinen setti voidaan ajaa vasta seuraavana päivänä? Testataan se manuaalisesti, kun kerran samoilla spekseillä se automatisoidaankin. Palaute on jopa nopeampi. "Automaattiset raportit", joku sanoo. Muun muassa Quality Center, Microsoftin Test Manager ja Test Runner ovat yksi keino palautteen nopeuttamisessa. Eikös se vähän niin kuin syö automaatiolta sen pääteesin? Tokihan pitkissä iteraatioissa automaatio on kustannustehokkaampi ja se huomaa regression nopeammin. Näissä tilanteissa se tulee kuitenkin ajatella työkaluna, jolla annetaan enemmän aikaa manuaaliseen testaukseen. Manuaalinen testaus huomaa erilaisia vikoja kuin automaatio, ja yleensä automatisoidaan ne tapaukset, missä manuaalisesti vikoja huomataan.
Ei manuaalinen testaus tietenkään mikään ihmelääke ole. Se ei ole idioottivarma, mutta ei sen pidäkään olla! Jos olisi olemassa idioottivarma testausmenetelmä, niin ei asiasta kiisteltäisi! Manuaalisen testauksen kompastuskiviä on (ja tulee aina olemaan) sen kustannustehokkuus iteratiivisessa projektimallissa. Älykkäällä manuaalisella testauksella voidaan kuitenkin löytää paljon enemmän kuin automaatiolla. Ei-älykäs testaus on usein se, mitä vasten automaatiota verrataan: testitapauksissa harpotaan, testien tarkistaminen unohtuu, jne. Tilastollinen tosiasia on (en pysty löytämään tämän julkaisijaa, mutta muistaakseni löytyy James Bachin webinaarista, en kuitenkaan mene oikeuteen tästä lainauksesta ;) ), että
Voiko manuaalisesta testauksesta sanoa kuitenkaan samaa? Jos järjestelmä on alhaalla, niin näyttääkö manuaaliset testit vihreää, koska tarkistus puuttuu?
Jos siis saataisiin manuaaliseen testaukseen integroitua joitakin automaation peruspiirteitä (eli nopea vaste ja raportoinnin helppous), voitaisiin manuaalista testausta nostaa voimakkaammin automaation rinnalle. Ehkä tällä tavoin manuaalisen testauksen piiriin saataisiin lisää huippuosaajia, jotka kehittäisivät testaustekniikoita ja -metodeita manuaalisen testauksen piirissä. Totta kai nykyiset testingdojot ja testingweekendit ovat nostaneet profiilia, mutta miten se saadaan nostettua samalle tasolle automaation tekniikan kehityksen kanssa? Miten voidaan tehdä manuaalisesta testauksesta seuraava ISO JUTTU? Miten saadaan ihmiset ymmärtämään, että testauksen tehokkuus ja eritoten kustannustehokkuus riippuu puhtaasti testaajien älykkyydestä eikä automaatiotyökalun käytettävyydestä?
Automaatiota arvostetaan suhteessa enemmän kuin manuaalista testausta: kun etsin manuaalisesta testauksesta kertovaa materiaalia, jokaisessa oli vähintään ohjeistus kuinka automatisoida nuo manuaaliset testit. On ilman muuta totta, että automatisoidut testit vievät vähemmän aikaa ajaa, kunhan ne on toteutettu. Onko kuitenkin jokin kuitenkin pudonnut kelkasta matkan varrella, koska manuaalinen testaus testauksena on maailman hienoin asia (puhtaasti oma mielipide eikä minulla ole tieteellistä faktaa tukemaan tätä väitettä)?
Testauksen automaation helppoutta korostetaan monessa paikassa (mm. Bhavian Turakhia esityksessään), vaikka helposti automaation toteuttaminen on huomattavasti vaikeampaa kuin manuaalinen testaaminen. Testausautomaation edut eivät siis suinkaan ole testit toteuttamisen helppoudessa, ainakaan kaikissa tapauksissa. Pentti Pohjolainen kirjoitta gradussaan:
Ennen kuin voidaan automatisoida, täytyy toimiva manuaalinen testausjärjestelmä olla olemassa. Sen täytyy sisältää vähintään seuraavat piirteet: Ensinnäkin yksityiskohtaiset testitapaukset sekä odotetut tulokset, jotka perustuvat vaatimusmäärittelyihin ja suunnitteludokumentteihin.
Tämä tarkoittaa käytännössä sitä, että sen lisäksi että pitää olla hyvä määrittely- ja suunnitteludokumentaatio, tulee tapaus pystyä testaamaan ylipäänsä. Lisäksi Pohjolainen viittaa siihen, että järjestelmän toiminta tulee olla ennustettavissa tarkkaan, että tiedetään mikä loppu tulema tulee tarkalleen olemaan. Automaatiota ei kannata tehdä ilman tarkistuksia. Manuaalisessa testauksessa tarkistuksen tulevat automaattisesti, kun tulosta tarkistetaan! (No menipähän saivarteluksi..)
Testausautomaatio on äärimmäisen kannattavaa silloin, kun samaa tapausta ajetaan useita kertoja. Jos puhutaan ketteristä menetelmistä, joissa iteraatioita on paljon, yönylitestit tuovat lisäarvoa ja ennustettavuutta, jne., testausautomaatio on tehokas työkalu. Jos verrataan manuaalisen testauksen kustannuksia iteraatiotilanteissa, ei manuaalisen testauksen kustannustehokkuus yllä lähellekään automaatiossa säästettäviä summia. Mitä tapahtuu, kun määrittely muuttuu? Mitä tapahtuu, kun muutetaan komponenttien nimeämispolitiikkaa? Mitä tapahtuu muutoksen yhteydessä? Jotain muuttuu! Kun testiautomaation kohteena oleva järjestelmä muuttuu, täytyy testi päivittää. Kun testi päivitetään, sen toiminta tulee ensin varmistaa jollakin tapaa että testi itse ei jää vialliseksi -> manuaalinen testaus. Kun tehdään automatisoitua testausta ketterissä menetelmissä, voidaan olla varmoja, että testien päivitystä tapahtuu. Kuinka suuret kustannukset aiheutuvat testien päivittämisestä, koestamisesta, uudelleenajamisesta? Kuinka "hauskaa" (lainatakseni herra Turakhiaa) testien päivittäminen on, kun koko sovelluslogiikka muuttuu?
Manuaalisen testauksen ollessa pääasiallinen lähestymistapa edellä mainitussa tapauksessa, voidaan manuaalisesti saada palaute nopeammin kuin automatisoiduissa testeissä. Automaation kannattava voimahan on sen "palautteen nopeus". Jos tämä voima katoaa, onko automaatiosta mitään hyötyä? Toki joitakin testitapauksia on vaan puhtaasti viisaampi testata automaattisesti, mutta näissäkään tapauksissa ei puhuta puhtaasta automaatiosta vaan manuaalisen testauksen tukena käytettävästä työkalusta, jossa testausta helpotetaan työkalun ominaisuuksilla. Hyvänä esimerkkinä on suorituskykytestaus, joka ei luonnistu ihan helposti manuaalisesti... vaikkakin mm. Sokoksen verkkokaupan case-esittelyssään kerrottiin koko kehittäjätiimin (noin 100 henkeä) tehneen viiden minuutin aikana pikaisen suorituskykytestin, jossa kaikki kirjautuivat verkkokauppaan, jne. Pointti on kuitenkin se, että manuaalinen testaus sitä tukevin työkaluin on usein tehokkaampaa kuin puhtaasti automaattinen testaus.
F-secure on yksi testauksen edelläkävijöitä Suomessa ja heidän automaation toteutustavat herättävät minussakin kateutta. Voiko kuitenkaan samaa mallia soveltaa kaikkialle? Onko järkevää toteuttaa automaatiota sellaisiin projekteihin, joissa kalenteriajassa on viikko testausaikaa ja määrittelyt ovat powerpoint-tasolla (onko kenellekkään tuttu malli?) tai toteutus on niin paljon myöhässä, että vesiputousmallinen projekti karsii taas testauksesta? Ei heilläkään kuitenkaan ole hylätty automaatiota vaan se tukee heidän manuaalista testaustaan ja toimii "takaporttina", jolla mahdollistetaan regression poissulkeminen mahdollisimman pian. Heidän testausprosessinsa on sen mallinen, että automaatio mahdollistaa kypsän softan pääsyn manuaaliseen testaukseen.
No, kaikki tämä puhe automaation ongelmista ei tarkoita sitä, että automaatio pitäisi karsia kokonaan pois. Ei suinkaan! Päämääränä on tuoda älykkyys takaisin testaukseen (oliko se se, mikä taannoin putosi kelkasta?). Älykkyydellä en suinkaan tarkoita teknistä tietämystä tai taitoa, vaan sellaista älykkyyttä, mikä testaajalla pitää olla: kyseenalaistava älykkyys. Voidaanko puhua älykkyydestä, jos työkalujen tarjoajat mainostavat manuaalista testausta vanhentuneeksi? Voidaanko puhua älykkyydestä, kun koko laadun pohjaksi muodostetaan yönylitestien vihreänä pitäminen? Voidaanko puhua älykkyydestä, kun mottona on testauksen automatisointi, jolloin myös testauksen suunnittelu on automaattista? Jos kaikki on automaattista, niin mihin sitä älykkyyttä itse asiassa tarvitaan edes? (Onnistuinko puhumaan itseni pussiin...)
Sivusin aiemmin manuaalisen testauksen palautteen "hitautta" verrattuna automaatioon. Minulle on itselleni tuputettu teesiä "automaatiolla palaute on sekunteja, kun manuaalisella se on päiviä". Mitä tapahtuu, kun automaattista testisettiä pitää päivittää ja kyseinen setti voidaan ajaa vasta seuraavana päivänä? Testataan se manuaalisesti, kun kerran samoilla spekseillä se automatisoidaankin. Palaute on jopa nopeampi. "Automaattiset raportit", joku sanoo. Muun muassa Quality Center, Microsoftin Test Manager ja Test Runner ovat yksi keino palautteen nopeuttamisessa. Eikös se vähän niin kuin syö automaatiolta sen pääteesin? Tokihan pitkissä iteraatioissa automaatio on kustannustehokkaampi ja se huomaa regression nopeammin. Näissä tilanteissa se tulee kuitenkin ajatella työkaluna, jolla annetaan enemmän aikaa manuaaliseen testaukseen. Manuaalinen testaus huomaa erilaisia vikoja kuin automaatio, ja yleensä automatisoidaan ne tapaukset, missä manuaalisesti vikoja huomataan.
Ei manuaalinen testaus tietenkään mikään ihmelääke ole. Se ei ole idioottivarma, mutta ei sen pidäkään olla! Jos olisi olemassa idioottivarma testausmenetelmä, niin ei asiasta kiisteltäisi! Manuaalisen testauksen kompastuskiviä on (ja tulee aina olemaan) sen kustannustehokkuus iteratiivisessa projektimallissa. Älykkäällä manuaalisella testauksella voidaan kuitenkin löytää paljon enemmän kuin automaatiolla. Ei-älykäs testaus on usein se, mitä vasten automaatiota verrataan: testitapauksissa harpotaan, testien tarkistaminen unohtuu, jne. Tilastollinen tosiasia on (en pysty löytämään tämän julkaisijaa, mutta muistaakseni löytyy James Bachin webinaarista, en kuitenkaan mene oikeuteen tästä lainauksesta ;) ), että
80% kaikista automaatiotestitapauksista on kuraa eivätkä todellisuudessa testaa mitään.
Voiko manuaalisesta testauksesta sanoa kuitenkaan samaa? Jos järjestelmä on alhaalla, niin näyttääkö manuaaliset testit vihreää, koska tarkistus puuttuu?
Jos siis saataisiin manuaaliseen testaukseen integroitua joitakin automaation peruspiirteitä (eli nopea vaste ja raportoinnin helppous), voitaisiin manuaalista testausta nostaa voimakkaammin automaation rinnalle. Ehkä tällä tavoin manuaalisen testauksen piiriin saataisiin lisää huippuosaajia, jotka kehittäisivät testaustekniikoita ja -metodeita manuaalisen testauksen piirissä. Totta kai nykyiset testingdojot ja testingweekendit ovat nostaneet profiilia, mutta miten se saadaan nostettua samalle tasolle automaation tekniikan kehityksen kanssa? Miten voidaan tehdä manuaalisesta testauksesta seuraava ISO JUTTU? Miten saadaan ihmiset ymmärtämään, että testauksen tehokkuus ja eritoten kustannustehokkuus riippuu puhtaasti testaajien älykkyydestä eikä automaatiotyökalun käytettävyydestä?
Tuesday, 12 April 2011
Murdering your darlings
eli "kullanmurujen murhaaminen"
Olen innokas miniatyyrifiguuri- ja peliharrastaja. Luen mielelläni alan julkaisuja. Tilaan White Dwarf -nimistä miniatyyrilehteä, jossa eräs tuon alan konkari kirjoittaa artikkeleita milloin mistäkin aiheesta. Tuon artikkelisarjan nimi on "Standard bearer" ja sitä kirjoittaa Jervis Johnson, kymmeniä vuosia miniatyyripelien maailmaa luonut ja tutkinut veteraani. Hän kirjoitti huhtikuun artikkelissaan (White Dwarf 376, April 2011) mantroista, joita hän viljelee töissä ja työn ulkopuolella. Eräs mantra oli "Murdering your darlings" eli "kullanmurujen murhaaminen".
"Murdering your darlings" tarkoittaa käytännössä sitä, että jos teet jotakin, josta olet erityisen ylpeä ja pidät sitä nokkelana tai nerokkaana; yliviivaa se ja tee se uudelleen. Suurin osa asioista, joista olemme erityisen ylpeitä eivät todellisuudessa ole muuta kuin oman itsetuntomme kohottamista eikä tuo tekele vie sitä todellista asiaa eteenpäin. Jervis kirjoittaa (vapaasti käänneetynä):
Tämä teksti on tuon murhaamisen tulos. Jotta pystyn kirjoittamaan hyvän testin, minun täytyy päättää mistä kirjoitan ja miksi kirjoitan. Päämääränä on luoda laatua parantava ajatusmalli. Mistä pitää lähteä liikkeelle?
Lähtökohta on se, että itseään ylentävästi kirjoitettu tekninen teksti ei palvele ketään eikä se vie tavoitteeseen. Tämä laadunparantaminen ei kuitenkaan koske pelkästään teknistä kirjoittamista vaan kaikkea julkaistavaa asiaa. Se pätee sekä ohjelmistokoodiin, testitapauksiin, raportteihin, itse sovellukseen, järjestelmiin, patsaisiin, taloihin, yms. Käytännössä "kullanmurujen murhaaminen" pätee kaikkeen mitä voi tehdä. Lähtökohdan ja tavoitteen välillä tulee olla suora viiva ja kaikki tuon viivan ulkopuolella oleva turhaa informaatiota. Jokainen palanen tulee siis arvioida, jotta voidaan tietää palveleeko tuo kyseinen asia lopputulemaa. Jos näin ei ole, se heikentää laatua.
Onko kyseinen asia välttämätön lopputuleman kannalta? Mitkä ovat kaikessa yksinkertaisuudessaan ne asiat, jotka tarvitsee tietää, tehdä, ratkaista, jne, jotta päästään päämäärään? Kuinka voidaan tehdä mahdollisimman tehokasta työtä, jotta voidaan saavuttaa parasta mahdollista laatua.
Kun nämä vähimmäisvaatimukset on löydetty, tulee jokaiseen vaatimukseen luoda sisältö, joka palvelee ainoastaan tuota tarkoitusta. Jos se täyttää tuon määrityksen, se vie kohti päämäärää. Jos tuo sisältö on lisäksi jotain muuta kuin pelkkää eteenpäinvievää informaatiota tms., se tulee muokata sellaiseksi, että se ei sisällä muuta. Eli otetaan punakynä käteen ja vedetään yli ne asiat jotka eivät täysin ja kokonaisuudessaan vie kohti lopputulemaa. Kun päämäärä on kaikkien näiden kullanmurujen murhaamisen jälkeen saavutettu, lopputulema on laadukkain ja tehokkain, mitä voi olla. Kaiken sisällön tulee palvella lopputulemaa ja tehokkaimmalla mahdollisella tavalla. Näin päästään korkeimpaan mahdolliseen laatuun.
Tämä on siis mahdollista kysymällä kaikessa tekemisessä "Mitä haluan saavuttaa?" ja "Viekö tämä tuotos minua lähemmäs valittua päämäärää?". Tämä pätee myös testaamiseen.
Testaus on kustannustehokkuusmielessä äärimmäisen huonoa - testaus ei tuota mitään, mistä voisi saada rahaa. Sen tähden testauksen tehokkuus on äärimmäisen tärkeää, jotta se asia, mitä testauksella pyritään saavuttamaan, saataisiin mahdollisimman kustannustehokkaasti saavutettua ja työn laatu olisi korkeinta mahdollista. Tämä ei tarkoita ylilaatua, koska se jos jokin on rahan hukkaan heittämistä. Työn tarkoituksen tulee palvella tarvetta niin, että voidaan saavuttaa haluttu tulos niin tehokkaasti kuin mahdollista.
Kun otetaan "kullanmurujen murhaaminen" käytäntöön vaikka testitapauksia luodessa, pystytään luomaan tehokkaasti selkeitä ja laadukkaita testitapauksia, jotka palvelevat tarkoitusta. Niiden tarkoitus ei ole kasvattaa testitapauksen kirjoittajan egoa tai statusta tiimissään. Paras testitapaus on sellainen, että päämäärään päästään suorinta reittiä tehokkaasti ja laadukkaasti.
Eli nyt jokainen tulostaa itselleen A4-kokoisen muistilapun "TODO: Murder your darlings!" ja odota, että joku tulee ihmettelemään, että oletko ajatellut käydä työterveydessä kertomassa näistä murha-aikestasi... ;)
Olen innokas miniatyyrifiguuri- ja peliharrastaja. Luen mielelläni alan julkaisuja. Tilaan White Dwarf -nimistä miniatyyrilehteä, jossa eräs tuon alan konkari kirjoittaa artikkeleita milloin mistäkin aiheesta. Tuon artikkelisarjan nimi on "Standard bearer" ja sitä kirjoittaa Jervis Johnson, kymmeniä vuosia miniatyyripelien maailmaa luonut ja tutkinut veteraani. Hän kirjoitti huhtikuun artikkelissaan (White Dwarf 376, April 2011) mantroista, joita hän viljelee töissä ja työn ulkopuolella. Eräs mantra oli "Murdering your darlings" eli "kullanmurujen murhaaminen".
"Murdering your darlings" tarkoittaa käytännössä sitä, että jos teet jotakin, josta olet erityisen ylpeä ja pidät sitä nokkelana tai nerokkaana; yliviivaa se ja tee se uudelleen. Suurin osa asioista, joista olemme erityisen ylpeitä eivät todellisuudessa ole muuta kuin oman itsetuntomme kohottamista eikä tuo tekele vie sitä todellista asiaa eteenpäin. Jervis kirjoittaa (vapaasti käänneetynä):
"jos kirjoitat huikein sanankääntein nokkelan lausahduksen, se todennäköisesti on olemassa vain sen takia että tuntisit itsesi nokkelaksi".Sillä ei pyritä muokkaamaan asioita muokkamisen tähden vaan pyritää luomaan yksinkertaisin mahdollinen tuote, jolla asiaa voidaan viedä eteenpäin. Kun huomaat tehneesi jotakin, josta olet äärimmäisen ylpeä, sinun tulee miettiä kyseinen asia uudelleen ja tarkastella, viekö tuo tekele kohti sitä päämäärää johon olet pyrkimässä. Jos ei, niin "kullanmuru hengiltä".
Tämä teksti on tuon murhaamisen tulos. Jotta pystyn kirjoittamaan hyvän testin, minun täytyy päättää mistä kirjoitan ja miksi kirjoitan. Päämääränä on luoda laatua parantava ajatusmalli. Mistä pitää lähteä liikkeelle?
Lähtökohta on se, että itseään ylentävästi kirjoitettu tekninen teksti ei palvele ketään eikä se vie tavoitteeseen. Tämä laadunparantaminen ei kuitenkaan koske pelkästään teknistä kirjoittamista vaan kaikkea julkaistavaa asiaa. Se pätee sekä ohjelmistokoodiin, testitapauksiin, raportteihin, itse sovellukseen, järjestelmiin, patsaisiin, taloihin, yms. Käytännössä "kullanmurujen murhaaminen" pätee kaikkeen mitä voi tehdä. Lähtökohdan ja tavoitteen välillä tulee olla suora viiva ja kaikki tuon viivan ulkopuolella oleva turhaa informaatiota. Jokainen palanen tulee siis arvioida, jotta voidaan tietää palveleeko tuo kyseinen asia lopputulemaa. Jos näin ei ole, se heikentää laatua.
Onko kyseinen asia välttämätön lopputuleman kannalta? Mitkä ovat kaikessa yksinkertaisuudessaan ne asiat, jotka tarvitsee tietää, tehdä, ratkaista, jne, jotta päästään päämäärään? Kuinka voidaan tehdä mahdollisimman tehokasta työtä, jotta voidaan saavuttaa parasta mahdollista laatua.
Kun nämä vähimmäisvaatimukset on löydetty, tulee jokaiseen vaatimukseen luoda sisältö, joka palvelee ainoastaan tuota tarkoitusta. Jos se täyttää tuon määrityksen, se vie kohti päämäärää. Jos tuo sisältö on lisäksi jotain muuta kuin pelkkää eteenpäinvievää informaatiota tms., se tulee muokata sellaiseksi, että se ei sisällä muuta. Eli otetaan punakynä käteen ja vedetään yli ne asiat jotka eivät täysin ja kokonaisuudessaan vie kohti lopputulemaa. Kun päämäärä on kaikkien näiden kullanmurujen murhaamisen jälkeen saavutettu, lopputulema on laadukkain ja tehokkain, mitä voi olla. Kaiken sisällön tulee palvella lopputulemaa ja tehokkaimmalla mahdollisella tavalla. Näin päästään korkeimpaan mahdolliseen laatuun.
Tämä on siis mahdollista kysymällä kaikessa tekemisessä "Mitä haluan saavuttaa?" ja "Viekö tämä tuotos minua lähemmäs valittua päämäärää?". Tämä pätee myös testaamiseen.
Testaus on kustannustehokkuusmielessä äärimmäisen huonoa - testaus ei tuota mitään, mistä voisi saada rahaa. Sen tähden testauksen tehokkuus on äärimmäisen tärkeää, jotta se asia, mitä testauksella pyritään saavuttamaan, saataisiin mahdollisimman kustannustehokkaasti saavutettua ja työn laatu olisi korkeinta mahdollista. Tämä ei tarkoita ylilaatua, koska se jos jokin on rahan hukkaan heittämistä. Työn tarkoituksen tulee palvella tarvetta niin, että voidaan saavuttaa haluttu tulos niin tehokkaasti kuin mahdollista.
Kun otetaan "kullanmurujen murhaaminen" käytäntöön vaikka testitapauksia luodessa, pystytään luomaan tehokkaasti selkeitä ja laadukkaita testitapauksia, jotka palvelevat tarkoitusta. Niiden tarkoitus ei ole kasvattaa testitapauksen kirjoittajan egoa tai statusta tiimissään. Paras testitapaus on sellainen, että päämäärään päästään suorinta reittiä tehokkaasti ja laadukkaasti.
Eli nyt jokainen tulostaa itselleen A4-kokoisen muistilapun "TODO: Murder your darlings!" ja odota, että joku tulee ihmettelemään, että oletko ajatellut käydä työterveydessä kertomassa näistä murha-aikestasi... ;)
Saturday, 23 October 2010
"Snakes and ladders"
Otsikko on ehkä hieman harhaanjohtava... Vaikka aihe liippaa hieman otsikossa mainuttua peliä, niin kysymys ei ole mistään pelitestauksesta. Tämän postauksen aihe on puhtaasti kyseenalaistamisen ja kyseenalaistamisen kohteena olemisen vaikeudesta.
Minulle on iskostunut tapa kyseenalaistaa kaikki auktoriteettien luomat käsitykset ja yrittään löytää niistä aukkoja tehdäkseni niistä parempia. Usein teenkin esityötä, jolla voin tukea näkemyksiäni keskustelu / väittelytilanteessa, jotta pystyisin saamaan parhaat näkemykset ja mielipiteet esiin, etten jää ilman perusteluita argumenteilleni. Tämä on kuitenkin ajanut minut tietynlaiseen kierteeseen olla pystymättä täydellisesti hyväksymään asioita. Viime viikon torstaina sain vihdoin yrityksemme kehityspäällikön esittelemään minulle hänen suunnittelemaansa hyväksymistestauskoulutusmateriaalia (jota olin vaatinut nähdä jo jonkin aikaa). Todellisuudessa en nähnyt kuin yhden sivun tästä materiaalista, koska hän keskittyi aivan epäolennaisuuksiin esitelmöinnissään (TDD:n perusperiaatteiden ja CI-ympäristön peruajatusten kuvaamiseen) enkä pystyny siis kommentoimaan juurikaan hänen näkemyksiään itse hyväksymistestauksesta, koska oli kiire seuraaviin palavereihin. Sen sijaan sain poimittua keskustelusta muutaman kiintoisan pointin, muun muassa sen että hänen mukaansa tavoite yrityksemme testauksessa on saada 90 prosenttia kaikesta testauksesta automatisoitua. Hieman riitauduimme tästä kyseisestä asiasta ja hän päätti kyseenalaistaa oman tietämykseni ajantasaisuuden. Tuoreimman tiedon mukaan systeemitestaus ja end-to-end on kuulemma vanhentuneita käsitteitä. (No, jos hän lukee tätä, niin mielestäni 2010 päivitetty ISTQB testausalan standardi ei ole vanhentunut.)
Kuintenkin heti keskustelun jälkeen aloin miettimään onko oma tietämykseni tarpeeksi suuri tukemaan omia mielipiteitäni testauksesta. Tuolloin tajusin, että koska kyseenalaistan hyvin pitkälti kaiken, en pääse johtopäätökseen siitä, mitä pidän hyvänä vaihtoehtona ja mitä en. Koska kyseenalaistamisella pitäisi pystyä parantamaan ymmärrystä sekä sen toisen näkemyksestä että myös omasta näkemyksestä, kyseenalaistaminen pitäisi lopulta johtaa äärimmäiseen tietoisuuteen siitä, mikä on paras mahdollinen keino tehdä jokin asia. Olen kuitenkin kyseenalaistanut omat johtopäätökseni enkä ole sitä kautta pystynyt pysymään yhdessä konkreettisessa mielipiteessä pitkään, koska kyseenalaistamisella johdan itseni aina pois tästä aiemmin hyväksi toteamastani asiasta.
Missä vaiheessa siis tulee lopettaa kyseenalaistaminen, jotta asian parannus ei muutu muutosvastarinnaksi ja sitä kautta taannuta asiaa kehittämisen sijaan? Voiko kyseenalaistamisen ignoteeraamisella johtaa kehittymiseen vai johtaako se välttämättä taantumiseen? Jos en hyväksy ns. best practicea ja yritän kehittää jonkin vielä paremman, voinko vahingossa tehdä hallaa enemmän kuin hyötyä?
Vai kyseenalaistanko minä väärin? Pitäisikö minun alkaa peesaamaan auktoriteettiasemassa olevia?
Olin 18.-19.10. Sovelton järjestämässä ISTQB Advanced level tason koulutuksessa, joka oli pohjakoulutus Test Manager sertifikaattikurssille. Siellä käytimme oppimisen tukena eräänlaista versiota Snakes and ladders -pelistä, jossa siis (asiaa paremmin tuntemattomille) tarkoitus oli päästä pelilaudan alakulmasta yläkulmaan käyttäen hyväksi tikkaita ja varoen käärmeitä. Tikkaat veivät eteenpäin pelilaudalla ja käärme vein taaksepäin. Tähän lisättynä oli testausaiheisia kysymyksiä jotka määrittivät etenemisen tai palaamisen pituuden. Yksi "käärmekysymys" oli seuraavanlainen: Mikä seuraavista on paras tapa arvioida testauksen työmäärä? 1) Pers'tuntuma, 2) Uusi testausarviotyökalu ja 3) Edellisen projektin testuatyömääräarvio. Nämä olivat siis sanasta sanaan mitä kysymyksessä oli. Pohdittuamme pelikavereiden kanssa kysymystä, tulimme siihen tuloskeen että se tulisi olla numero 3. Se olikin kaikkeista huonoin vastaus. Tottakai reippaana testausheebona kyseenalaistin tuloksen! Oikea vastaus olisi ollut 1. ISTQB:n testit ovat hyvin pitkälsi samanlaisia kuin tuo kysymys, eli unohda kaikki mitä tosielämässä tiedät ja kerro se vastaus, mikä teoriassa olisi oikea (tai se, minkä kysymyksen tekijä haluaa kuulla).
Onko siis oikein, että meitä opetetaan irti kyseenalaistamisesta näissä ISTQB standardoimissa koulutuksissa? Pystynkö olemaan hyvä testaaja kyseenalaistamatta kaikkea, mitä minulle tarjotaan faktana? Voinko siis käyttää kyseenalaistamista tikapuina viemään minua eteenpäin kohti tietoisuuden huippua, vai voiko se olla käärme, joka nielaisee minut ja vie takaisin alkuruutuun? Ja vaikka kyseenalaistaisinkin jonkin asian perustellusti ja pystyisin sen ymmärrettävästi ulosantamaan kuuntelijalleni, voisiko se menettää merkityksensä sen takia, että kuuntelijani ei ymmärtäisi kyseenalaistamisen periaatetta vaan pitäisi sitä henkilökohtaisena hyökkäyksenä? Jos auktoriteettihahmo ei pysty korjaamaan näkemyksiään kun niitä kritisoidaan perustellisti, niin onko se taannuttamista? Jos ei, niin mitä? Voiko huono kyseenalaistaja tehdä itselleen hallaa olemalla kyseenalaistamatta selvästi huonoa ajatusmallia tms.?
Miksi siis testausalan standardissa ei opeteta ihmisiä kyseenalaistamaan oikein ja ottamaan kyseenalaistamisen oikein vastaan? Tällä saavutettaisiin parempi tulos kuin kyseenalaistamisen poiskitkemisellä. Tästä on tulossa mielenkiintoinen viikko, kun pääsen taas kolmeksi päiväksi koulutukseen kyselemään "tyhmiä"! Palataan siis astialle!
Minulle on iskostunut tapa kyseenalaistaa kaikki auktoriteettien luomat käsitykset ja yrittään löytää niistä aukkoja tehdäkseni niistä parempia. Usein teenkin esityötä, jolla voin tukea näkemyksiäni keskustelu / väittelytilanteessa, jotta pystyisin saamaan parhaat näkemykset ja mielipiteet esiin, etten jää ilman perusteluita argumenteilleni. Tämä on kuitenkin ajanut minut tietynlaiseen kierteeseen olla pystymättä täydellisesti hyväksymään asioita. Viime viikon torstaina sain vihdoin yrityksemme kehityspäällikön esittelemään minulle hänen suunnittelemaansa hyväksymistestauskoulutusmateriaalia (jota olin vaatinut nähdä jo jonkin aikaa). Todellisuudessa en nähnyt kuin yhden sivun tästä materiaalista, koska hän keskittyi aivan epäolennaisuuksiin esitelmöinnissään (TDD:n perusperiaatteiden ja CI-ympäristön peruajatusten kuvaamiseen) enkä pystyny siis kommentoimaan juurikaan hänen näkemyksiään itse hyväksymistestauksesta, koska oli kiire seuraaviin palavereihin. Sen sijaan sain poimittua keskustelusta muutaman kiintoisan pointin, muun muassa sen että hänen mukaansa tavoite yrityksemme testauksessa on saada 90 prosenttia kaikesta testauksesta automatisoitua. Hieman riitauduimme tästä kyseisestä asiasta ja hän päätti kyseenalaistaa oman tietämykseni ajantasaisuuden. Tuoreimman tiedon mukaan systeemitestaus ja end-to-end on kuulemma vanhentuneita käsitteitä. (No, jos hän lukee tätä, niin mielestäni 2010 päivitetty ISTQB testausalan standardi ei ole vanhentunut.)
Kuintenkin heti keskustelun jälkeen aloin miettimään onko oma tietämykseni tarpeeksi suuri tukemaan omia mielipiteitäni testauksesta. Tuolloin tajusin, että koska kyseenalaistan hyvin pitkälti kaiken, en pääse johtopäätökseen siitä, mitä pidän hyvänä vaihtoehtona ja mitä en. Koska kyseenalaistamisella pitäisi pystyä parantamaan ymmärrystä sekä sen toisen näkemyksestä että myös omasta näkemyksestä, kyseenalaistaminen pitäisi lopulta johtaa äärimmäiseen tietoisuuteen siitä, mikä on paras mahdollinen keino tehdä jokin asia. Olen kuitenkin kyseenalaistanut omat johtopäätökseni enkä ole sitä kautta pystynyt pysymään yhdessä konkreettisessa mielipiteessä pitkään, koska kyseenalaistamisella johdan itseni aina pois tästä aiemmin hyväksi toteamastani asiasta.
Missä vaiheessa siis tulee lopettaa kyseenalaistaminen, jotta asian parannus ei muutu muutosvastarinnaksi ja sitä kautta taannuta asiaa kehittämisen sijaan? Voiko kyseenalaistamisen ignoteeraamisella johtaa kehittymiseen vai johtaako se välttämättä taantumiseen? Jos en hyväksy ns. best practicea ja yritän kehittää jonkin vielä paremman, voinko vahingossa tehdä hallaa enemmän kuin hyötyä?
Vai kyseenalaistanko minä väärin? Pitäisikö minun alkaa peesaamaan auktoriteettiasemassa olevia?
Olin 18.-19.10. Sovelton järjestämässä ISTQB Advanced level tason koulutuksessa, joka oli pohjakoulutus Test Manager sertifikaattikurssille. Siellä käytimme oppimisen tukena eräänlaista versiota Snakes and ladders -pelistä, jossa siis (asiaa paremmin tuntemattomille) tarkoitus oli päästä pelilaudan alakulmasta yläkulmaan käyttäen hyväksi tikkaita ja varoen käärmeitä. Tikkaat veivät eteenpäin pelilaudalla ja käärme vein taaksepäin. Tähän lisättynä oli testausaiheisia kysymyksiä jotka määrittivät etenemisen tai palaamisen pituuden. Yksi "käärmekysymys" oli seuraavanlainen: Mikä seuraavista on paras tapa arvioida testauksen työmäärä? 1) Pers'tuntuma, 2) Uusi testausarviotyökalu ja 3) Edellisen projektin testuatyömääräarvio. Nämä olivat siis sanasta sanaan mitä kysymyksessä oli. Pohdittuamme pelikavereiden kanssa kysymystä, tulimme siihen tuloskeen että se tulisi olla numero 3. Se olikin kaikkeista huonoin vastaus. Tottakai reippaana testausheebona kyseenalaistin tuloksen! Oikea vastaus olisi ollut 1. ISTQB:n testit ovat hyvin pitkälsi samanlaisia kuin tuo kysymys, eli unohda kaikki mitä tosielämässä tiedät ja kerro se vastaus, mikä teoriassa olisi oikea (tai se, minkä kysymyksen tekijä haluaa kuulla).
Onko siis oikein, että meitä opetetaan irti kyseenalaistamisesta näissä ISTQB standardoimissa koulutuksissa? Pystynkö olemaan hyvä testaaja kyseenalaistamatta kaikkea, mitä minulle tarjotaan faktana? Voinko siis käyttää kyseenalaistamista tikapuina viemään minua eteenpäin kohti tietoisuuden huippua, vai voiko se olla käärme, joka nielaisee minut ja vie takaisin alkuruutuun? Ja vaikka kyseenalaistaisinkin jonkin asian perustellusti ja pystyisin sen ymmärrettävästi ulosantamaan kuuntelijalleni, voisiko se menettää merkityksensä sen takia, että kuuntelijani ei ymmärtäisi kyseenalaistamisen periaatetta vaan pitäisi sitä henkilökohtaisena hyökkäyksenä? Jos auktoriteettihahmo ei pysty korjaamaan näkemyksiään kun niitä kritisoidaan perustellisti, niin onko se taannuttamista? Jos ei, niin mitä? Voiko huono kyseenalaistaja tehdä itselleen hallaa olemalla kyseenalaistamatta selvästi huonoa ajatusmallia tms.?
Miksi siis testausalan standardissa ei opeteta ihmisiä kyseenalaistamaan oikein ja ottamaan kyseenalaistamisen oikein vastaan? Tällä saavutettaisiin parempi tulos kuin kyseenalaistamisen poiskitkemisellä. Tästä on tulossa mielenkiintoinen viikko, kun pääsen taas kolmeksi päiväksi koulutukseen kyselemään "tyhmiä"! Palataan siis astialle!
Sunday, 10 October 2010
Mulkoilu (leering)
Tässä määritelmä, joka kehitettiin yrityksessämme kun piti keksiä termi kevyelle katselmoinnille. Tämä siis keksittiin 10.9.2009 Tampereella.
Katselmoinnin kevyempi versio, jossa yksi tai kaksi henkilöä läpilukee dokumentin ja antaa siihen liittyen palautetta. Mulkoilun voi suorittaa joko omatoimisesti (materiaali toimitetaan sähköpostilla tai poimitaan verkkolevyltä) tai se voidaan suorittaa keskitetysti tilassa, jossa dokumentti (tai sen osia) heijastetaan valkokankaalle. Mulkoilussa, kuten kaikessa katselmoinnissa, mulkoilijoidentulee olla tutustunut materiaaliin ennen mulkoilutilaisuutta.
Mulkoilutilaisuudessa on mahdollisesti mukana sihteeri, joka ylöskirjaa mahdolliset kommentit ja huomautukset koskien dokumenttia. Tämä ei kuitenkaan ole pakollista (vaikkakin suotavaa).
Dokumentin versioelinkaaressa tulee olla vähintään yksi mulkoilu (tai vastaavasti katselmointi) ennen kuin se voidaan julistaa valmiiksi. Jos dokumenttin mulkoillaan osissa, tulee kaikki osat mulkoilla läpi.
Sanan hivenen pahantahtoisesta soinnista huolimatta mulkoilun tarkoitus ei ole tuottaa dokumentin tekijälle mielipahaa tai asettaa tätä naurunalaiseksi. Mulkoilutilaisuus on vapaamuotoinen tilausuus, jossa annetaan rakentavaa palautetta mulkoiltavana olevasta dokumentista.
Tutkiva katselmointi (Exploratory review)
Käsittelen tässä vähän katselmointia. Tämä teksti on yritystämme varten tehty yhteenveto katselmoinnin tärkeydestä. teksti on johdettu osittain Rex Blackin "Advanced Software Testing vol.2 - Guide to the ISTQB Advanced Certification as an Advanced test Manager" -kirjasta.
Katselmointi tulee suorittaa projektin jokaisen vaiheen jälkeen ja ennen seuraavan vaiheen alkua. Mulkoilua voi suorittaa vaiheen sisällä, mutta virallinen katselmointi tulee suorittaa aina vaiheen päättyessä. Esim. koodikatselmointi tulee suorittaa, ennen kuin tuote luovutetaan testiin, jotta havaitut puutteet voidaan korjata, eikä testattavaan tuotteeseen pääse ylimääräisiä virheitä.
Miksi katselmoiminen on tärkeää? Oletetaan että luodaan sovellus, jossa on 1000 bugia. Ao. taulukon mukaan, jos käytetään epävirallisinta katselmointia (mutta kaikki tarvittava katselmoidaan), ennen testaamisen aloittamista on estetty 834 bugin pääsy testattavaan tuotteeseen. Testauksessa täytyy siis löytää ainoastaa 166 bugia. Jos taas katselmointi olisi suoritettu raskaimmalla mahdollisella tasolla (katselmoinnit on suoritettu tarkasti ja ammattitaitoisella ryhmällä), ennen testaamisen aloittamista on estetty 996 (!!!) bugin pääsy järjestelmään, jolloin testauksessa täytyy löytää ainoastaan 4 bugia!
Jos edes osa dokumenteista katselmoidaat/mulkoillaan voidaan estää suuri määrä bugeja testaukseen tai edes syntymään.
Katselmoinnin tehokkuus Vähintään
(mulkoilu)Keskimäärin Enintään
(virallinen)Vaatimusmäärittelyt 20% 30% 50% Karkeat suunnitelmat 30% 40% 50% Tuotantokelpoiset suunnitelmat 30% 45% 65% Yksityiskohtaiset suunnitelmat 35% 55% 75% Koodikatselmointi 35% 60% 85% Taulukon luvut tarkoittavat prosenttiosuutta dokumentin virheistä, jotka katselmointi havaitsee.
Taulukko on poimittu Rex Blackin "Advanced Software Testing vol.2 - Guide to the ISTQB Advanced Certification as an Advanced test Manager"
Tämän mukaan siis katselmointia tulisi suorittaa kaikissa vaiheissa jollakin tasolla. Jos katselmointi suoritetaan waterfall mallissa, niin vaiheistus voisi jopa toimia nätisti. Ketterissä menetelmissä katselmointi onkin hieman hankalampi suorittaa. Jos joka kerta kun määrittely tai suunnitelma muuttuu, ne tulisi katselmoida. Eikös ketterissä menetelmissä katselmointi veisi siis järkyttävän paljon aikaa? Kuinka siis katselmointi toteutetaan ketterissä projekteissa?
Jos luodaan määrittelydokumentti, se täytyy versioida. Tämä versio katselmoidaan. Siitä löytyneet viat korjataan ja se annetaan eteenpäin. Tämän jälkeen muutokset määrittelyihin johdetaan versioinnin kautta, eli jokainen määrittelyn muutos merkataan muutoksena aiemmin päätettyyn. Tämä siis katselmoidaan ainoastaan muutosten osalta. Sanotaan, että ainoastaan yksi määrittely muuttu, jolloin tämä ainoastaan katselmoidaan.
Kun määrittelyä muutetaan, se vaikuttaa suoraan seuraavan vaiheen dokumentteihin, eli teknisiin määrittelyihin ja arkkitehtuuriin. Muutosten vaikutus tulee analysoida ja arvioida lisätyön määrä. Jos perusajatus muuttuu täysin määrittelyä muutettaessa, onko järkevämpi uudistaa koko arkkitehtuuri ja tekninen määrittely eikä vain tehdä yksittäisiä muutoksia? Voiko alkuperäisiä dokumentteja käyttää jotenkin hyväksi? Nämä täytyy varmistaa katselmoinnin muodossa. Aina täytyy muistaa, että kaikki voi vaikuttaa kaikkeen. Tulee siis sulkea pois ne alueet, jotka pysyvät muutumattomina työmäärän vähentämiseksi.
Tämä jatkuu aina hierarkisesti aina käyttöohjeeseen asti, joten muutokset täytyy siis katselmoida niiltä osin, mitenkä ne vaikuttavat dokumentin muihin osiin sekä hierarkiassa alempana oleviin dokumentteihin.
Miten voidaan varmistaa, että yhden määrittelyn/suunnittelukohdan/koodirivin muutos ei vaikuta muihin määrityksiin? Pitääkö katselmointia siis laajentaa? Entäs bisnesmäärittelyn muutoksen vaikutus NFR:iin? Koodimuutoksen vaikutus testausautomaatioon? GUI muutoksen vaikutus käyttöohjeeseen? Analysoimalla muutoksen vaikutus voidaan arvioida muihin määrityksiin tehtävät muutokset. Voidaanko suorittaa ns. tutkiva katselmointi, jossa arvioidaan määrittelyn muutoksen vaikutus muihin määrityksiin?
Otetaan tilanne, jossa ketterässä kehityksessä on tilanne, jossa ollan päästy jo pilotointi vaiheeseen, jossa kaikki dokumentit on tehty ja katselmoitu "oikeaoppisesti" tai parhaaksi katsotulla tavalla tarpeeseen nähden. Jos tässä vaiheessa määrittely muuttuu, se täytyy ensin analysoida muita määrittelyita vasten. Tämän jälkeen arvoidaan lisätyö muutoksissa muihin määrittelyihin ja hierarkiassa samalla tasolla oleviin dokumentteihin. Tämän jälkeen analysoidaan näiden muutosten vaikutus hierarkiassa alempana oleviin dokumentteihin ja koodiin ja arvioida muutoksen vaatima lisätyö. Näiden lukujen varjossa ketterän kehityksen tuoma "vapaus" muuttaa määrittelyitä saattaakin olla kallis temppu.
Kuitenkin kun katselmoidaan ajoissa voidaan saada ajatuksia esiin, joilla estetään turhat muutokset loppuvaiheessa (eli korjataan lakuperäisien määrittelyn bugi, joka on päässyt tuotantoon asti). Ketterästi katselmoimalla tai tutkivasti katselmoimalla voidaan vähentää katselmointien määrää tekniikkaa muuttamalla. Tämä vaatii tietenkin asiantuntemusta sekä kokemusta ja lisäksi eri näkökulmia. Jos katselmoidaan tutkivasti määrittelymuutosta tilaisuudessa tulisi olla mukana hierarkisesti alemman vaiheen dokumentoijat (arkkitehti, suunnittelija, koodati, jne.), joka pystyy arvioimaan oman työnsä kautta vaikutuksia saman dokumentin muihin määrittelyihin ja seitä kautta hierarkisesta alempana olevien dokumenttien muutostarpeisiin.
Voidaan siis ottaa käyttöön ns. tutkiva katselmointi (Exploratory Review) jossa tutkitaan muutoksen vaikutusta muihin määrittelyihin ketterästi. Tämä voi siis olla esisuunnittelematonta "kyseenalaistamista", jossa mietitään muutoksen vaikutusta kokonaisuuteen. Tämän tarkoitus on siis lisätä katselmoinnin syvyyttä tai keskittyä ainoastaan muutosten katselmointiin. Jos tutkivaa katselmointia on mukana tavallisissa katselmointitilaisuuksissa, voidaan ehkäistä alueita, joita ei välttämättä ole kunnolla määritelty/suunniteltu/koodattu mutta joka tulisi hierarkisesti olla hyvin määritelty/suunniteltu/koodattu. Onko kenelläkään kokemusta "tutkivasta katselmoinnista" tai onko se olemassa jollakin toisella nimellä? Löytyykö tällaisesta dokumentaatiota?
Monday, 4 October 2010
ISTQB Advanced level Certificate
Sain luvan esimieheltäni osallistua ISTQB Advanced level Certificate - Test manager -koulutukseen. Se on FC sovelton järjestämä kurssi, jolla korvataan ”vanhan mallinen” ISEB sertifiointikoulutus. Edellisestä sertifikaattikokeestani (Foundation level) on noin vuosi aikaa. Sen jälkeen olen kovasti miettinyt sertifioinnin hyötyjä ja haittoja. Tämän kurssin tarkoitus on siis valmentaa sertifikaattikokeeseen. Kokeen voi tietenkin ottaa ilman kurssiakin ja moni varmasti tekeekin niin, jos joutuu vaikkapa kustantamaan itse koko sertifikaatin. Kun alempana puhun kurssista tai sertifikaatista, tarkoitan siis sertifikaattiin valmistavaa kurssia sekä siihen liittyvää koetta. Kun puhun puhtaasti sertifikaatin hankkimisesta, niin on aivan sama onko käynyt kurssin vai ei, kunhan saa paperin kouraan.
Mitä tämä sertifikaatti tuo minulle? Mitä minä saan siitä ammatillisella tasolla? Miten yritykseni hyötyy sertifioinnistani? Miten tulevaisuuteni muuttuu paremmaksi, jos hankin sertifioinnin? Miten tämä sertifikaattikokeeseen valmistava kurssi hyödyntää minua? Kysymyksiä on monia ja aina vastaus ei ole tällaisen tutkivan ja ekstrovertin testaajan mieleen.
Mitä siis yrityksemme hyötyy siitä, että joku sertifioi itsensä testauspäälliköksi? Ensin ajattelen, että ei juuri mitään, sehän on vain sertifikaatti. Miten yritys voisi hyötyä siitä, että joku sen työntekijä menee kurssille, joka saattaa olla yrityksen maksama (eikä halpa) ja saattaa johtaa vielä tuon sertifikaatin hankkineen henkilön palkkatason tarkastamiseen? Sehän on kaikki yritykseltä pois! ajattelen. Kannattaako siis vain kannustaa työntekijöitään hankkimaan sertifikaatti omatoimisesti, jolloin yrityksen ei tarvitse kustantaa kalliita kursseja?
Miten sertifiointi näkyy yrityksillä? Näkyykö se mitenkään millään yrityksen osa-alueella, jos työntekijä on sertifioitu? Todellisuudessa työntekijän sertifioinnista on suuri hyöty yritykselle kokonaisuudessa. Pelkkä sertifikaatti on sinänsä yritystasolla jo suuri saavutus. Kilpailuasemassa voimme tuoda esiin, että "meillä on käytössämme ISTQB sertifioitu testaustiimi ja testauspäälliköt", jolla voidaan myydä parempaa laatua. Tämä voi olla yrityksen imagolle myös tärkeä, koska saadaan joku joka todella tietää testausalan standardit ja perusperiaatteet. Joku asiakas voi antaa sertifioidun testaustiimin vaatimukseksi kaupan tekemiseksi. Voidaanhan esim. Microsoftin sertifikaatteja pitää pakollisina tiettyjen asioiden saavuttamiseksi, niin miksi ei sertifioitu testaus voi olla kaupanteon peruste.
Toinen näkökulma yritystasolla on puhdas taito. Miten yksittäisen henkilön taito ja teitämys vaikuttaa yritystasolla? ajattelen. Kun yrityksessa hankitaan lisää tietoa/taitoa se kasvattaa yrityksen "taitopääomaa". Se taito, mikä ei alunperin ollut yrityksessä, piti ehkä hankkia alihankintana tai sitten toteuttaa ko. toiminta niillä taidoilla mitä yrityksessä on, eikä se välttämättä aina tuo haluttua tulosta. Kun saadaan parempi tieto-/taitotaso, voidaan ottaa uudenlaisia asioita huomioon yritystasolla ja pystytään suoriutumaan sellaisista vaatimuksista, joita ei aiemmin kyetty täyttämään. Sertifikaattikoulutus tukee tätä taidon hankkimista ja sertifikaatti itse on todistus näiden taitojen hallitsemisesta. Tuleeko siis taitoa, jos kurssilla ainoastaa pyritään siihen, että kokelas läpäisee kokeen? Onko kurssin anti rahasijoituksen arvoinen, jos henkilö ei läpäpise koetta? Näitä on syytä miettiä sertifointia ja koulutusta harkittaessa.
Kolmas näkökulma on sekä yritys- että henkilökohtaisella tasolla. Testaustapahtumissa luodaan aina kontakteja. Muiden tietoisuus yrityksestä leviää ja sertifiointikoulutukseen osallistuva henkilö tutustuu muiden yritysten testaushenkilöihin. Tämä voi johtaa yhteistyöhön, ajatustenvaihtoon tai alihankintaan ynnä muuhun, mikä tulevaisuudessa auttaa molempia yrityksiä.
Eli yritystasolla sertifiointi voi hyödyttää kolmella tasolla: imago, taito ja kontaktit.
Huonoja puolia sertifioinnista voi myöskin tulla. Yrityksen imago saattaa muuttua sertifioinnin kautta kankeaksi tietyissä ammattipiireissä ja kaupan syntyminen tämänkaltaisiin asiakkuuksiin voi muuttua hankalammaksi. Lisäksi setifiointi saattaa johtaa kankeaan prosessimalliin, johon tukeudutaan sen takia, että "se on yritysstandardien mukainen". Nämä ovat kuitenkin olettamuksia eivätkä aina paikkaansapitäviä. Prosessit voivat olla ketteriä ja kevyitä (en määrittele tässä tarkemmin, mikä on ketterä ja mikä kevyt), vaikka ne pohjautuisivatkin testausalan standardeihin.
-
Henkilökohtaisella tasolla sertifikaatti voi olla hieman vaikeampi istuttaa hyötyihin ja haittoihin. Haittana saattaa olla "siiloutuminen" ja ajatusten suuntautuminen tiettyyn malliin. Sertifiointi saattaa aiheuttaa sen, että henkilö ajattelee asiat niin kuin ne on valmiiksi hänelle pureskeltu testaus standardeissa. Sertifioimattomuus saattaa kuitenkin säilyttää ajattelun tuoreuden ja oivaltavuuden. Tämä saattaa kuitenkin johtaa "pyörän keksimiseen uudelleen". Mielestäni ISTQB sertifikaatti ja sen omistaminen tulee ottaa oppimisena suuntautumisen sijaan. Voidaanko siis säilyttää tuoreus ja samalla saada mahdollisuus noudattaa standardeja? ajattelen. Voinko olla täysin irrallaan sertifikaatin tuomista ajatusmallien rajoitteista (onko niitä edes?) ja pakotteista, mutta samalla tuntea standardit ja termistön sertifikaattitasolla? Onko valtavirta paha asia? Onko ”vastavirta” hyvä asia?
Mitä siis hyötyy jos hankkii sertifikaatin? Mitä haittaa siitä saattaa koitua? Suoranainen hyöty henkilökohtaisella tasolla on tietämysken kasvattaminen. Tämä siis vain siinä tapauksessa, jos hankkii tietoa itse ennen koetta tai osallistuu kurssille. Jos tietää jo "kaiken" ennen koetta, niin tiedon kasvu ei ole relevannti peruste sertifikaatin hankkimiselle. Haittoja saatta olla rahallisia, jos joutuu kustantamaan setrifioinnin itse varsinkin, jos joutuu useasti uusimaan kokeen.
Miten sertifiointi hyödyttää uraa? Kuinka se voi vahvistaa/heikentää asemaani yrityksessä? Sertifiointi tuo tiettyä vakautta yrityksessä. Se kertoo päättäjille että sinä osaat tietyt asiat ja sinulla on dokumentti siitä todisteena. Jos se on vielä testausalan standardien mukainen sertifikaatti, sen painoarvo on suuri. En puutu tässä vaihtoehtoisten sertifikaattien arvoon, sillä en tunne näitä muita kovin hyvin. Kuitenkin sertifikaatti varmasti vahvistaa asemaa yrityksessä. Aseman heikkeneminen saattaa olla ajankohtainen ainoastaan, jos ei pysty jokapäiväisessä työssään nousemaan sertifikaatin vaatimalle tasolle. Tämä tarkoittaa siis riman nousemista. Sertifioidun henkilön tulee näyttää, että todellisuudessa täyttää sertifikaatin asettamat odotukset. Sertifointi hyödyttää uraa pitkällä tähtäimellä myös henkilökohtaisena markkinointikeinona. Se voi olla pääsylippu paikkoihin, joihin ilman sertifikaattia ei pääse. Työnhaussa sertifikaatti on varma keino näyttää taito ja osaaminen. En tässä paneudu enempää rekrytoinnin ja sertifioinnin etuihin ja hasasteisiin, mutta mainittakoon, että sertifikaatti on rekrytoinnissa kaksiteräinen miekka, sillä se saattaa leimata sinut tiettyyn muottiin mahtuvaksi testaajaksi kun taas sertifioimaton saattaa näyttää raikkaammalta ja ajatuksiltaan tuoreemmalta kuin sertifioitu. Ja kuten yritystasollakin, kontaktit ovat yksi testaustapaamisten suola. Tämä hyödyttää sekä tämänhetkistä tilannetta että tulavaisuutta uusien mahdollisten työpaikkojen "tiedustelussa" ym.
Miten saan siis kaiken hyödyn irti sertifikaattikoulutuksesta ja itse sertifikaatin mahdollisesta hankkimisesta (en tietenkään tiedä pääsenkö kokeesta läpi vielä tässä vaiheessa)? Pyrin ainakin luomaan mahdollisimman paljon suhteita testaushenkisiin kollegoihin koulutustilauudessa ja tuomaan yritystämme julki mahdollisimman monessa käänteessä. Lisäksi yritän kyseenalaistaa omia ajatusmallejani tätä ISTQB:n mallia vasten ja toisinpäin, jolloin en menetä tuoreutta ja oivaltavuutta, jonka olen saavuttanut tutkivan testauksen saralla. Mitä enemmän kyseenalaistan kuulemian oppeja, sitä paremmin opin asiat. Saan uusia näkökulmia jo tiedossani oleviin asioihin ja nämä uudet asiat saavat ehkä sijan mielessäni hyväksitodettuina taitoina.
Mita ajatuksia muilla on sertifioinnista sekä testausalalla että IT-alalla yleensä?
Subscribe to:
Posts (Atom)