HICCUPPS
Tämä viittaa tuotteen testauksessa oraakkeleihin. Eli mihin voit perustaa havaintojen oikeellisuuden. Oraakkeli on kuten heuristiikan yleensä "ehkä päteviä omassa kontekstissaan". Oraakkeli siis kertoo /mielipiteen/, joka ohjaa toimintaa tavalla tai toisella. Oraakkelit koostuvat seuraavista: H = History, I = Image, C = Comparable products, C = Claims, U = User expectations, P = Purpose, P = Product itsef, S = Standards. Nämä ovat ylseensä jo testauksen aikana tapahtuvia heuristisia ajatusmalleja. Näillä voidaan mitata tuotteen yhteneväisyyttä jonkin oraakkein kanssa. Onko se yhteneväinen asiakkaan esittämien lupausten kanssa? Onko se yhteneväinen itsensä kanssa?
Historia antaa aina ideoita testaukseen. Miten tuote käyttäytyi edellisissä versioissa, eilen, jne. Tämä osittain sisältää myös bugilistat.
Yrityksen antama kuva toimii heuristiikkana silloin, kun testauksen kohde on räikeästi tai hienovaraisesti pois yrityksen antamasta linjasta. Esimerkiksi Officetuotteissa on samantyyppinen ulkoasu, joten linjasta poikkavien asioiden huomaaminen on helppoa. Toisaalta esimerkiksi vakavarainen vakuutustoimija saattaa haluta ilmaista järjestelmillään luotettavuutta, jota kirjoitusvirheet sivuilla eivät edusta.
Verrokkituotteet ovat äärimmäisen hyvä oraakkeli. Jos on olemassa esimerkiksi tuotantoversio, johon tehdään päivitys, voidaan alkuperäisestä varmistaa toimintojen käyttäytymistä. Jos kilpailijalla on saman tyyppinen tuote, sitä voidaan käyttää vertailuun.
Lupaukset ja julkaisut ovat omiaan tuottamaan testausideoita. Manuaalit, helppi-tiedostot, mainokset, jne. voivat tarjota ideoita, jotka käyttäjän näkökulmasta sotisivat lupauksia vastaan. Lisäksi käyttöohjeiden testaaminen sovellusta vasten voi olla hyödyllistä myös käyttöohjeen itsensä kannalta.
Käyttäjän odotuksien kanssa yhteneväisyydessä saatta olla ongelmia. Jos olettaa esimerkiksi, että ohjelma käynnistyy automaattisesti ja se vaatiikin pääkäyttäjäoikeudet, saattaa virheilmoitus aiheuttaa närää käyttäjällä. Odotukset ylipäänsä ovat vahva oraakkeli, koska ne viittaavat siihen miten oikeasti tuotetta käytetään.
Tarkoituksen vastaan sotivien asioiden testaus saattaa herättää mielenkiintoisia kysymyksiä. Onko tarkoitus, että sääennustussovellus täyttää veroilmoituksesi? Onko tarkoituksenmukaista kaksoisklikata linkkiä, jos yksi painallus selvästi riittää?
Tuote itsessään voi olla ristiriidassa itsensä kanssa. Esimerkiksi saman tiedon näyttäminen samassa järjestelmässä eri tavalla. Tämä saattaa horjuttaa luottamusta tietojen oikeellisuuteen ("Älä pidä kahta kelloa laivassa. Jos toinen on väärässä, niin mistä tietää kumpi on oikeassa."). Ongelmia voi tulla eri näkymien erilaisuudesta tai vaikkapa virheilmoitusten yhteneväisyydestä.
Lait, asetukset, standardit tuovat oman mausteensa testaukseen ja yhtenevyys lakeihin esimerkiksi vakuutus- tai ilmailuhallintajärjestelmissä voi aiheuttaa jopa vaaratilanteita. (Se että turvallisuuskriittisten järjestelmien testaus ei aina ole viisasta pelkästää heuristiikkoja hyväksikäyttäen, on aivan toinen lukunsa.)
Sunday, 19 June 2011
Testausheuristiikat 2/7
CIDTESTD
Tämä heuristiikka viittaa projektiin ja ympäristön tuomiin testausajatuksiin. C = Customer, I = Information, D = Developers, T = Test team, E = Equipment, S = Schedule, T = Test item, D = Deliverables. Näillä heuristiikoilla on tarkoitus suunnitella ja priorisoida tulevaa testausta. Näillä heuristiikoilla helpotetaan kontekstin havaitsemista, ja tuotteen ja testaajien sijoittumista ympäristöönsä.
Asiakkaan tapauksessa testi-ideointi tapahtuu lähinnä sellaisella tasolla, että "mitä tietoa asiakas voi meille tarjota ko. asiasta, jota emme jo tiedä tai ole huomanneet kysyä". Tämä ei siis tarkoita, että asiakas on testausidea itsessään, mutta asiakkaan huomioiminen testausta ideoitaessa voidaan löytää asioita, joita projekti tai projektiryhmä itsessään ei pystyisi tarjoamaan. Asiakasta kannattaa ja pitääkin kyseenalaistaa, koska usein on niin, että asiakas ei itsekään aivan tarkkaan tiedä mitä haluaa. Kyseenalaistamalla voidaan parantaa asiakkaan tietämystä omista haluistaan ja vaatimuksistaan. Testaajalla on suuri rooli parantaa kaikkien sidosryhmien tietämystä ja ymmärrystä tuotteesta.
Informaation toimii heuristiikkaana käytännössä asettamalla fokuksen dokumentteihin. Tässä kohtaa painota, että dokumentteihin luottaminen ei saa olla testauksen pääasia. Dokumentit ovat vanhentuneita, viallisia, saavuttamattomissa, jne. Ne saattavat kuitenkin sisältää sellaista tietoa, mitä testauksessa tarvitaan. Ne ovat yksi heuristiikka eli ne "voivat olla päteviä ko. kontekstissa". Dokumentit ovat kuitenkin hyödyllisiä ja niiden olemassaoloon on usein syy. Ne tapaavat tuoda lisää tietoa asioihin, mutta niihin ei kannata sokeasti luottaa. Dokumentteihin pätee samat kyseenalaistamisen säännöt kuin ihmisiinkin!
Kehittäkät ja testaustiimi tuovat oman panoksensa testien ideoinnissa. Testausryhmän sisäinen dynamiikka yleensa johtaa tiettyihin painotuksiin ja jokaisen panos on tärkeä testi-ideoita mietittäessä. Jokainen nimittäin testaa eri lailla ja jokaiselle eri asiat ovat tärkeämpiä kuin toiselle. Kehittäjien mielipiteet, taidot, mieltymykset antavat myös omat ideansa testaukseen. Jonkin kehittäjän tuotteista saattaa löytyä tietynlaisia vikoja, joten kehittäjän passiivinen mukanaolo saattaa tuoda ideoita testaukseen. Tämän takia kannattaa aina käyttää ideoinnissa mukana eritasoisia ja jopa eri ryhmien asiantuntijoita. Taas kerran: käytetään hyväksi kyseenalaistamista ja kysymistä, jotta saadaan esille ne asiat, jotka pitää saada esille.
Työkalut, välineet, ympristöt vaikuttavat omalta osaltaan testaukseen. Voidaan miettiä asioita työkalujen kannalta ottamalla huomioon käytössä olevat työkalut ja niiden hyväksikäyttäminen testauksessa sekä tarpeet työkaluille, joita mahdollisesti tarvitaan. Esimerkiksi testausryhmässä on kokemusta suorituskykytestaustyökaluista, mutta integraatiotyökalut ovat vähemmän käytettyjä. Voisiko heuristiikkana olla tehdä tutkivaa testausta integraatiotyökalulla? Olisiko yrityksessä joku integraatioasiantuntija? Aikataulu saattaa myös herättää testausaiheisia kysymyksiä priorisoinnista ja testausryhmän kokoonpanosta. Aikataulu tuo yleensä oman leimansa testauksen suorittamiseen. Esimerkiksi aikataulun yhdistäminen vaikkapa asiakkaan vaatimiin suorituskykytesteihin määrittää tiettyjen alueiden testaamisen ennen toisia. Tai jos toteutus on pilkottu releaseihin, joissa testaus pitää kohdistaa tiettyihin osa-alueisiin, koska toisia ei ehkä vielä ole toteutettu.
Testauksen kohde on aina hyvä herättämään kysymyksiä: "Mikä tämä on? Mitä se tekee?" Se herättää todennäköisesti jatkokysymyksiä ja nostaa muita heuristiikkoja esiin. Jamesbachmainen heuristiikka "Huh? Really? So?" (HRS) pätee hyvin usein, kun kysytään ihmisiltä juuri noita kysymyksiä. Kyseenalaistamalla saamasi vastauksen testauksen kohteesta voi nousta uusi kysymyksiä ja ehkä juuri ne kysymykset ovat niitä, mitkä pitää kysyä.
Testaustuotteet voivat myös nostaa ideoita, esimerkiksi bugilistoista voi löytyä ideoita. Kaikki testauksen tuottama materiaali, opitut asiat, raportit, jne. voivat nostaa asioita esiin, joita täytyy miettiä tässä kyseisessä testausprojektissa. Testaustuotteena on tietenkin myös taitopääoma, joten käytännössä kaikki testausmateriaali ja taito, mitä yrityksessä on saatavilla kannatta jollakin tasolla hyödyntää.
Heuristiikan käyttäminen toimii myös muussa kuin dynaamisessa testauksessa. Kyseenalaistaminen ja katselmointi hyödyntävät myös näitä heuristiikkoja. Jokainen kehittäjä pystyy parantamaan omaa työtään kyseenalaistamalla määrittelyitä tai suunnitelmia hyväksykäyttäen testaukseen käytettäviä heuristiikkoja. Eikä pelkästään projektin alkuvaiheessa vaan pitkin toteutusta ja lopulta koodin valmistuttua koodikatselmoinneissa ja korjaus/muutospyynnöissä.
Tämä heuristiikka viittaa projektiin ja ympäristön tuomiin testausajatuksiin. C = Customer, I = Information, D = Developers, T = Test team, E = Equipment, S = Schedule, T = Test item, D = Deliverables. Näillä heuristiikoilla on tarkoitus suunnitella ja priorisoida tulevaa testausta. Näillä heuristiikoilla helpotetaan kontekstin havaitsemista, ja tuotteen ja testaajien sijoittumista ympäristöönsä.
Asiakkaan tapauksessa testi-ideointi tapahtuu lähinnä sellaisella tasolla, että "mitä tietoa asiakas voi meille tarjota ko. asiasta, jota emme jo tiedä tai ole huomanneet kysyä". Tämä ei siis tarkoita, että asiakas on testausidea itsessään, mutta asiakkaan huomioiminen testausta ideoitaessa voidaan löytää asioita, joita projekti tai projektiryhmä itsessään ei pystyisi tarjoamaan. Asiakasta kannattaa ja pitääkin kyseenalaistaa, koska usein on niin, että asiakas ei itsekään aivan tarkkaan tiedä mitä haluaa. Kyseenalaistamalla voidaan parantaa asiakkaan tietämystä omista haluistaan ja vaatimuksistaan. Testaajalla on suuri rooli parantaa kaikkien sidosryhmien tietämystä ja ymmärrystä tuotteesta.
Informaation toimii heuristiikkaana käytännössä asettamalla fokuksen dokumentteihin. Tässä kohtaa painota, että dokumentteihin luottaminen ei saa olla testauksen pääasia. Dokumentit ovat vanhentuneita, viallisia, saavuttamattomissa, jne. Ne saattavat kuitenkin sisältää sellaista tietoa, mitä testauksessa tarvitaan. Ne ovat yksi heuristiikka eli ne "voivat olla päteviä ko. kontekstissa". Dokumentit ovat kuitenkin hyödyllisiä ja niiden olemassaoloon on usein syy. Ne tapaavat tuoda lisää tietoa asioihin, mutta niihin ei kannata sokeasti luottaa. Dokumentteihin pätee samat kyseenalaistamisen säännöt kuin ihmisiinkin!
Kehittäkät ja testaustiimi tuovat oman panoksensa testien ideoinnissa. Testausryhmän sisäinen dynamiikka yleensa johtaa tiettyihin painotuksiin ja jokaisen panos on tärkeä testi-ideoita mietittäessä. Jokainen nimittäin testaa eri lailla ja jokaiselle eri asiat ovat tärkeämpiä kuin toiselle. Kehittäjien mielipiteet, taidot, mieltymykset antavat myös omat ideansa testaukseen. Jonkin kehittäjän tuotteista saattaa löytyä tietynlaisia vikoja, joten kehittäjän passiivinen mukanaolo saattaa tuoda ideoita testaukseen. Tämän takia kannattaa aina käyttää ideoinnissa mukana eritasoisia ja jopa eri ryhmien asiantuntijoita. Taas kerran: käytetään hyväksi kyseenalaistamista ja kysymistä, jotta saadaan esille ne asiat, jotka pitää saada esille.
Työkalut, välineet, ympristöt vaikuttavat omalta osaltaan testaukseen. Voidaan miettiä asioita työkalujen kannalta ottamalla huomioon käytössä olevat työkalut ja niiden hyväksikäyttäminen testauksessa sekä tarpeet työkaluille, joita mahdollisesti tarvitaan. Esimerkiksi testausryhmässä on kokemusta suorituskykytestaustyökaluista, mutta integraatiotyökalut ovat vähemmän käytettyjä. Voisiko heuristiikkana olla tehdä tutkivaa testausta integraatiotyökalulla? Olisiko yrityksessä joku integraatioasiantuntija? Aikataulu saattaa myös herättää testausaiheisia kysymyksiä priorisoinnista ja testausryhmän kokoonpanosta. Aikataulu tuo yleensä oman leimansa testauksen suorittamiseen. Esimerkiksi aikataulun yhdistäminen vaikkapa asiakkaan vaatimiin suorituskykytesteihin määrittää tiettyjen alueiden testaamisen ennen toisia. Tai jos toteutus on pilkottu releaseihin, joissa testaus pitää kohdistaa tiettyihin osa-alueisiin, koska toisia ei ehkä vielä ole toteutettu.
Testauksen kohde on aina hyvä herättämään kysymyksiä: "Mikä tämä on? Mitä se tekee?" Se herättää todennäköisesti jatkokysymyksiä ja nostaa muita heuristiikkoja esiin. Jamesbachmainen heuristiikka "Huh? Really? So?" (HRS) pätee hyvin usein, kun kysytään ihmisiltä juuri noita kysymyksiä. Kyseenalaistamalla saamasi vastauksen testauksen kohteesta voi nousta uusi kysymyksiä ja ehkä juuri ne kysymykset ovat niitä, mitkä pitää kysyä.
Testaustuotteet voivat myös nostaa ideoita, esimerkiksi bugilistoista voi löytyä ideoita. Kaikki testauksen tuottama materiaali, opitut asiat, raportit, jne. voivat nostaa asioita esiin, joita täytyy miettiä tässä kyseisessä testausprojektissa. Testaustuotteena on tietenkin myös taitopääoma, joten käytännössä kaikki testausmateriaali ja taito, mitä yrityksessä on saatavilla kannatta jollakin tasolla hyödyntää.
Heuristiikan käyttäminen toimii myös muussa kuin dynaamisessa testauksessa. Kyseenalaistaminen ja katselmointi hyödyntävät myös näitä heuristiikkoja. Jokainen kehittäjä pystyy parantamaan omaa työtään kyseenalaistamalla määrittelyitä tai suunnitelmia hyväksykäyttäen testaukseen käytettäviä heuristiikkoja. Eikä pelkästään projektin alkuvaiheessa vaan pitkin toteutusta ja lopulta koodin valmistuttua koodikatselmoinneissa ja korjaus/muutospyynnöissä.
Testausheuristiikat 1/7
Kuten jo taannoin mainitsin, olin Rapid (vai oliko re rabid) Software Testing -kurssilla Suomen kauniissa pääkaupungissa. Kurssi veti testausalan kirkkaimpiin tähtiin kuuluva Michael Bolton. Kurssilla käytiin läpi asia jos toinenkin, mutta yhtenä osa-alueena siellä oli heuristiikkojen käyttö tutkivassa testauksessa.
Heuristiikkojen käyttö ei tarkoita sitä, että sinulla on checklist, jonka sitä tarkistat läpi softassa ja sen jälkeen softa on testattu. Heuristiikan voivat olla päteviä ko. kontekstissa tai olla olematta. Niiden tehtävä on tarjota ajattelulle lähteitä jotta itse testi-ideoiden luominen olisi helpompaa. RST-kurssilla heuristiikat oli niputettu listoiksi, joista tuli anagrammeja tai muistisääntöjä muistamisen helpottamiseksi. Näiden heuristiikkojen muistaminen voisi varmistaa sen, että kuljen koko ajan päässäsi satoja testi-ideoita mistä tahansa testattavasta aiheesta.
Muistisäännöt ovat lontoonkielellä seuraavaa: CIDTESTD (kid tested) , HICCUPPSS (hickups) SFDPOT (San Fransisnco Depot), CRUSSPIC STMPL (Crosspick Stample), FDSFSCURA (Fed-Jeff's Curae).
Jaan nämä heuristiikkamöhkäleet lukemisen helpottamiseksi omiksi blogimerkinnöiksi, joten näitä tulee tippumaan tänne sitä mukaa, kun saan näitä hiottua.
Heuristiikkojen käyttö ei tarkoita sitä, että sinulla on checklist, jonka sitä tarkistat läpi softassa ja sen jälkeen softa on testattu. Heuristiikan voivat olla päteviä ko. kontekstissa tai olla olematta. Niiden tehtävä on tarjota ajattelulle lähteitä jotta itse testi-ideoiden luominen olisi helpompaa. RST-kurssilla heuristiikat oli niputettu listoiksi, joista tuli anagrammeja tai muistisääntöjä muistamisen helpottamiseksi. Näiden heuristiikkojen muistaminen voisi varmistaa sen, että kuljen koko ajan päässäsi satoja testi-ideoita mistä tahansa testattavasta aiheesta.
Muistisäännöt ovat lontoonkielellä seuraavaa: CIDTESTD (kid tested) , HICCUPPSS (hickups) SFDPOT (San Fransisnco Depot), CRUSSPIC STMPL (Crosspick Stample), FDSFSCURA (Fed-Jeff's Curae).
Jaan nämä heuristiikkamöhkäleet lukemisen helpottamiseksi omiksi blogimerkinnöiksi, joten näitä tulee tippumaan tänne sitä mukaa, kun saan näitä hiottua.
Wednesday, 8 June 2011
Täh?! Oikeesti?! Mitä sitten?!
Michael Bolton mainitsi kollegansa James Bachin käyttävän äärimmäisen tehokasta kyseenalaistamisen heuristiikkaa: Huh? Really? So? (aiemmin viittamani HRS-heuristiikka) Päätin ottaa itsekin tuon heuristiikan käyttöön ja olen nyt kokeillut sitä erinäisissä tilanteissa, jopa testannut omia puheitani ja kirjoituksiani tuon heuristiikan kautta.
Huh? Täh? Siis mitä?
Oletko koskaan istunut neukkarissa, kun joku "sankari" esittää kuninkaan elkein hienoja prosessimalleja tai pitää yhteenvetoa asiasta, josta et ole kuullutkaan? Sinut on kutsuttu paikalle, koska se ehkä liippaa sinun asiantuntemusaluetta jollakin tasolla (normaali kriteeri palaverikutsulle). Mies tai nainen edessä selittää, osoittelee graafeja ja vuokaavioita, ja jokatoinen neukkarissa oleva henkilö piirtelee tikku-ukkoja paperin reunaan tai näpyttelee puhelintaan. Osa saattaa jopa tuijottaa taululle, koska luulee ymmärtävänsä jotakin, mutta silmissä on tyhjä katse.
Tässä vaiheessa taitava testaaja kysyy: "Täh?" Kaikki tuijottavat testaajaa kuin tämä olisi sanonut jotakin tyhmää - varsinkin "sankari". "Niin mitä tämä tarkoitti? Voitko selittää tämän niin, että testaajakin ymmärtää? En ehkä ole käynyt kaikkia kouluja enkä ole tehnyt kehitystä vuosia, mutta tiedän kuitenkin että en ymmärrä kaikkea, mitä sanot. Onko minun tarpeellista siis edes ymmärtää tätä (ja päätellen paikallaolostani ON)? Mielestäni on. Voitko siis kertoa, mitä tuo tarkoittaa?" Tässä vaiheessa kynät lopettavat tuhertelun ja kännykät menevät taskuun.
Muut ajattelevat ehkä: "Olipas fiksu testaaja. Vitsi, kun olis itse ymmärtänyt kysyä asiaa hetki sitten, niin en olisi niin pihalla." Kukaan tuskin ajattelee, että "onpa tyhmä kaveri kun ei ymmärrä, mistä puhutaan". Todennäköisesti tässä vaiheessa "sankari" selittää hieman matalammalla tai korkeammalla tasolla (riippuen kumpi on selkeämpi tai hänen mielestään selkeämpi). Tämän jälkeen suurin osa kallistuu tuolissaan taaksepäin ja alkaa taas tuhertelemaan. "Anteeksi, en kyllä vielä ymmärtänyt. Meneekö se oikeesti niin?"
Really? Oikeesti? Ootko ihan varma?
"Sankari" tuijottaa ja toteaa, että näinhän se menee. Esimerkkiä pyydettäessä taas kaikkien mielenkiinto palautuu. Nyt "sankari" esittää prosessimallia hieman käytännön tasolta tai raporttia henkilönäkökulmasta. Tässä vaiheessa testaajalla nousee useita kysymyksiä käytännön asioita. "Entäs tapaus 1? Entäs tapaus 1a?"
Tässä vaiheessa muut ajattelevat, että "olisiko minun pitänyt tietää kysyä näitä asioita? Olenko niin fiksu, kun luulen olevani?" Sankari kysyy tätä varmasti itseltään. Kun sankari on joko "oikeesti" pystynyt selittämään asian tai todennut, että ei ole miettinyt asiaa tuolta kantilta vaikka olisi ehkä pitänyt. Taas porukka rentoutuu... "Mitä tällä siis haetaan? Miksi näitä asoita esitellään?"
So? Mihin se johtaa? Mitä sitten?
... ja taas porukan mielenkiinto nousee taas. "Tämä saattaa koskea minua. Tämä seuraava lause voi vaikuttaa minun tulevaisuuteeni tai työntekooni."
Testaajan tehtävä on nostaa esille asoita, mitä muut eivät ole vielä osanneet miettiä. Testaajan tehtävä on tarjota tietoa asiayhteydestä siitä kiinnostuneille sidosryhmille. Testaaja itse on osa yhtä sidosryhmää, joten hänen tehtävänsä on vaatia se tieto, mikä hänelle kuuluu. Ei ole olemassa tyhmiä kysymyksiä - on olemassa kysymyksiä, joita pidetään tyhminä kunnes ne kysytään. Usein on tyhmää olla kysymättä. Näiden "tyhmien" kysymysten tarkoitus on herättää uusia kysymyksiä - kysymyksiä, joita kukaan ei ole vielä kysynyt. Käyttäkää tätä heuristiikkaa tulevissa palavereissa ja olkaa kriittisiä. Kyseenalaistakaa oma toimintanne siinä missä muidenkin.
Todennäköisesti palaverin jälkeen muu porukka kyselee asioita testaajalta eikä "sankarilta".
Huh? Täh? Siis mitä?
Oletko koskaan istunut neukkarissa, kun joku "sankari" esittää kuninkaan elkein hienoja prosessimalleja tai pitää yhteenvetoa asiasta, josta et ole kuullutkaan? Sinut on kutsuttu paikalle, koska se ehkä liippaa sinun asiantuntemusaluetta jollakin tasolla (normaali kriteeri palaverikutsulle). Mies tai nainen edessä selittää, osoittelee graafeja ja vuokaavioita, ja jokatoinen neukkarissa oleva henkilö piirtelee tikku-ukkoja paperin reunaan tai näpyttelee puhelintaan. Osa saattaa jopa tuijottaa taululle, koska luulee ymmärtävänsä jotakin, mutta silmissä on tyhjä katse.
Tässä vaiheessa taitava testaaja kysyy: "Täh?" Kaikki tuijottavat testaajaa kuin tämä olisi sanonut jotakin tyhmää - varsinkin "sankari". "Niin mitä tämä tarkoitti? Voitko selittää tämän niin, että testaajakin ymmärtää? En ehkä ole käynyt kaikkia kouluja enkä ole tehnyt kehitystä vuosia, mutta tiedän kuitenkin että en ymmärrä kaikkea, mitä sanot. Onko minun tarpeellista siis edes ymmärtää tätä (ja päätellen paikallaolostani ON)? Mielestäni on. Voitko siis kertoa, mitä tuo tarkoittaa?" Tässä vaiheessa kynät lopettavat tuhertelun ja kännykät menevät taskuun.
Muut ajattelevat ehkä: "Olipas fiksu testaaja. Vitsi, kun olis itse ymmärtänyt kysyä asiaa hetki sitten, niin en olisi niin pihalla." Kukaan tuskin ajattelee, että "onpa tyhmä kaveri kun ei ymmärrä, mistä puhutaan". Todennäköisesti tässä vaiheessa "sankari" selittää hieman matalammalla tai korkeammalla tasolla (riippuen kumpi on selkeämpi tai hänen mielestään selkeämpi). Tämän jälkeen suurin osa kallistuu tuolissaan taaksepäin ja alkaa taas tuhertelemaan. "Anteeksi, en kyllä vielä ymmärtänyt. Meneekö se oikeesti niin?"
Really? Oikeesti? Ootko ihan varma?
"Sankari" tuijottaa ja toteaa, että näinhän se menee. Esimerkkiä pyydettäessä taas kaikkien mielenkiinto palautuu. Nyt "sankari" esittää prosessimallia hieman käytännön tasolta tai raporttia henkilönäkökulmasta. Tässä vaiheessa testaajalla nousee useita kysymyksiä käytännön asioita. "Entäs tapaus 1? Entäs tapaus 1a?"
Tässä vaiheessa muut ajattelevat, että "olisiko minun pitänyt tietää kysyä näitä asioita? Olenko niin fiksu, kun luulen olevani?" Sankari kysyy tätä varmasti itseltään. Kun sankari on joko "oikeesti" pystynyt selittämään asian tai todennut, että ei ole miettinyt asiaa tuolta kantilta vaikka olisi ehkä pitänyt. Taas porukka rentoutuu... "Mitä tällä siis haetaan? Miksi näitä asoita esitellään?"
So? Mihin se johtaa? Mitä sitten?
... ja taas porukan mielenkiinto nousee taas. "Tämä saattaa koskea minua. Tämä seuraava lause voi vaikuttaa minun tulevaisuuteeni tai työntekooni."
Testaajan tehtävä on nostaa esille asoita, mitä muut eivät ole vielä osanneet miettiä. Testaajan tehtävä on tarjota tietoa asiayhteydestä siitä kiinnostuneille sidosryhmille. Testaaja itse on osa yhtä sidosryhmää, joten hänen tehtävänsä on vaatia se tieto, mikä hänelle kuuluu. Ei ole olemassa tyhmiä kysymyksiä - on olemassa kysymyksiä, joita pidetään tyhminä kunnes ne kysytään. Usein on tyhmää olla kysymättä. Näiden "tyhmien" kysymysten tarkoitus on herättää uusia kysymyksiä - kysymyksiä, joita kukaan ei ole vielä kysynyt. Käyttäkää tätä heuristiikkaa tulevissa palavereissa ja olkaa kriittisiä. Kyseenalaistakaa oma toimintanne siinä missä muidenkin.
Todennäköisesti palaverin jälkeen muu porukka kyselee asioita testaajalta eikä "sankarilta".
Monday, 23 May 2011
Tunteet pinnassa
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.
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.
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... ;)
Subscribe to:
Posts (Atom)