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".

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:

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ä?

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ä?

Saarnamies Marjamäki

Lueskelin omia blogimerkintöjäni tässä heräsin miettimään omaa kirjoittamistani. Kirjoituksissani on selvästi ajatusta ja oivalluksia - osa niistä muiden oivalluksista johdettuja, mutta silti. Kuitenkin osa tekstistäni on huttua - siitä puuttuu punainen lanka. Olen aloitteleva blogaaja, joten se ei varmasti ole mikään suuri epäkohta tässä, mutta lukiessani enemmän ja enemmän muiden testausblogeja huomaan toisten kirjoittavan pitkiä ja selkeitä kokonaisuuksi, siinä missä omani ovat lyhyitä ja katkonaisia.

Olen löytänyt siis kehittymisen mahdollisuuden omista virheistäni, joita en edes tiennyt niiden tekohetkellä tekeväni. Joku voi olla eri mieltä siitä, onko kirjoitustyylini sinänsä virheellinen, mutta ehkä "puutteellinen" on se sana, joka kuvaa sitä parhaiten. Ehkä tämän kirjoituksen syntymiseen johti James Bachin teksti kyseenalaistamisesta (johon olen aiemmin viitannutkin). Olen siis löytänyt kyseenalaisen toimintamallin ja se kaipaa parantamista.

Miten siis parannan asiaa, joka ei oikeastaan ole virheellinen - tai ainakaan haitallinen? Miten motivoitua asian korjaamiseen, minkä korjaus ei sinänsä ole tarpeellinen.

-

Kun testaaja tutkii sovellusta (eli siis tutkiva testaaja), hän löytää siitä vikoja. Hän löytää myös poikkeamia. Vika tässä blogin tapauksessa olisi ehkä aiheen vierestä kirjoittaminen ja/tai kirjoitusvirheet. Mahdollisesti asiavirheet.

Kirjoitusvirheet tässä tapauksessa ovat pienimmän vakavuuden virheitä, joiden korjaus ainoastaan parantaa kosmeettista ulkoasua. Ne vaikeuttavat blogin "käytettävyyttä", kun käyttäjä (l. lukija) joutuu jatkuvasti miettimään onko jokin kirotusvirhe vai tarkoituksella väärin (tai jopa eri sana). Korjaus on helppoa tässä tapauksessa, joten matalasta vakavuudesta huolimatta korjaus on syytä tehdä jos vian huomaa.

Asiavirhe on korkeamman vakavuuden virhe. Se saattaa johtaa lukijaa harhaan, joka ei ole tämän blogin tarkoitus. Lisäksi se vähentää kirjoittajan nauttimaa luottamusta, joten hänen totena julkaisemiaan tekstejä ei pidetä totena vaan virheellisenä. Asiayhteyksien tarkistus on siis erittäin tärkeää! Korkea vakavuus! Korjaus näissä tapauksissa on siis uusi versio tekstistä tai tekstin hyllytys. Jos sovelluksesta löytyy sellainen vika, joka estää sovelluksen käytön siihen tarkoituseen mihin se on suunniteltu, se poistetaan käytöstä ja siihen tehdään tarvittavat korjaukset, jotta se toimisi halutulla (oletetulla) tavalla.

Poikkeama on tässä tapauksessa poikkeama todellisesta tai oletetusta totuudesta. Jos jokin asia ei vastaa lukijan ennakko-odotuksia, hän pitää sitä poikkeamana. Poikkeama ei sinänsä ole virhe, se on tavalla toteutettu eri tavalla kuin käyttäjä olettaa. Jos joku julkaisee tekstiä, joka on valtavirrasta poikkeavaa hänen täytyy pystyä perustelemaan valintansa käyttäjää tyydyttävällä tavalla (jolloin siitä tulee ominaisuus tekstille) tai poikkeama muuttuu virheelliseksi (eli viaksi tekstissä). Sama pätee sovelluksiin, joissa jokin ominaisuus tehdään määrittelyiden (ennakkoasenteiden, -oletusten, -odotusten) vastaisesti.

Tästä johdettuna: Onko aiemmat blogimerkintäni siis viallisia? Tekeekö (turhaan viljelty) saarnaamista muistuttava blogaaminen tekstistä viallista, virheellistä vai poikkeavaa? Ennakkoasenne omalla kohdallani on se, että se on sekä viallista että poikkeavaa. Katsotaan pitääkö se paikkansa...

Tarkoitukseni alunperin tekstissä "Kuinka haastattelen uutta testaajaa?" oli laittaa ajatuksia ylös ja luoda suuntaviivoja itselleni ja muille asiasta kiinnostuneille, jotka painivat saman asian kanssa. Teksti on puutteellinen moneltakin osaa, johtuen näkökulman puutteesta. Viittaukset olemassaoleviin teksteihin ja niiden vertaaminen omaan todellisuuteeni olisivat lisänneet tekstin syvyyttä. Esimerkiksi Software Testing Clubin hassu kirja "The Ridiculously Simple Guide Building A Test Team" olisi ollut hyvä vertailumateriaali... Hävettää tunnustaa, että tein varmasti suurimman osan kirjassa mainituista "hyviksi todetuista" asioista ja kysyin aivan vääriä asioita. (Tästä viisastuneena saatan kirjoittaa ko. blogimerkinnän uudelleen ennen seuraavan testaajan haastattelua.)

"Suorituskykytestaus integraatioprojektissa" tarkoitus oli luoda selkeä runko suorituskykytestaukselle alueella, jossa en ennen ole ollut. Blogaus tutkikin tätä asiaa teknisestä näkökulmasta ja voi jopa toimia referenssimateriaalina asiasta kiinnostuneille. Tästä johtuen blogaus oli mielestäni varsin onnistunut yksilö. Se pohjautui olemassaolevaan suorituskykytestausmalliin. Tämän olisi kuitenkin voinut mainita tekstissä eikä pitää koko roskaa omana ideana.

Jottä tämä blogaus ei muutu puolustelevaksi, tahdon pitää sen kriittisellä linjalla. Kuten tuossa ilmaisin, nämä olivat siis oletuksia ja toteutumia. Toteutumat olivat jokseenkin poikkeavia oletuksistani, mutta joissakin tapauksissa (kuten "Suorituskykytestaus integraatioprojektissa") poikkeamat olivat pieniä. Vaikkakaan ne eivät olleet hyvin perusteltuja, ne olivat sellaisia ettei niiden korjaamiselle ole suurta tarvetta. Sen sijaan "Testauksen Jin ja Jang!" epäonnistuu täyttämään odotukseni. Kuten tekstissä sanon "Ajatukseni alkoivat rullata kuin hullu tuolloin -", joka on oli sillä hetkellä totta, tuo päässäni kehittynyt punainen lanka ei välittynyt tekstiin. Jälkikäteen arvioiden tekstistä voisi suodattaa sen saarnaosuuden ja keskittyä olennaisiin ja faktoihin. Olisinko pystynyt esittämään omia kokemuksiani tai viitata muiden kokemuksiin aiheesta? Olisiko tästä materiaalista saatu kasattua hyvä ja ytimekäs, muiden ajatuksia "hullun lailla" kiihottava blogaus? Tekstistä puuttuu kosketus todellisuuteen, joka estää tekstin ottamisen todesta. Tämä vaatii siis uudelleenkirjoittamista sekä blogauksen vikojen että poikkeamien takia.

-

Miten siis motivoitua asian korjaamiseen, minkä korjaus ei sinänsä ole tarpeellinen. Itsensä kehittäminen! Jos on mahdollisuus kehittää itseään, niin se tulee ilman muuta tehdä. Koskaan ei tiedä, mihin omien puutteellisuuksiensa tarkastelu voi johtaa.

Sen sijaan että tämäkin blogaus muuttuu saarnaamiseksi itsensä kehittämisen puolesta, haluan painottaa sitä, että kaikki viat, virheet ja poikkeamat tulee tunnistaa ja tutkia. Niiden korjaus saattaa tapahtua itsestään tutkimalla ja etsimällä niitä. Tämä saattaa olla kuin aavikon tutkimista: tutkiminen johtaa hiekassa olevan poikkeaman (pyramidin kärjen) löytämiseen, joka tutkimisen (kaivamisen) jälkeen paljastuu maailman mahtavimmaksi hautamonumentiksi jumalaisine aarteineen.

Testaustyön riittävyys

Meillä on projektit sellaisia pienehköjä kehitysprojekteja, joissa on yleensä 2-3 kehittäjää ja ne kestävät noin 1-4 viikkoa per projekti. Sitten meillä on sellaisia mammuttiprojekteja, jotka vievät koko tulosyksikön henkilöresurssit ja kestävät 6-9 kuukautta. Eli kehittäjät puskevat kovalla syötöllä koko ajan tavaraa ulos ja asiakkaalle.

Tähän soppaan kaadetaan testaaja. Testattavaa on vaikka kuinka paljon, mutta sitä ei aina ole mahdollista laskuttaa, jos sitä ei ole asiakkaalle myyty. Asiakkaalle on myyty ainoastaan kehitystestaus ja hän hoitaa itse testuaksen. Tämä malli on hyvin järkevää pienissä projekteissa ja asiakaskohtaisissa mutoksissa. Testaajat siis sijoitetaan suuriin projekteihin, joissa on paljon testtattavaa ja joka on laskutettavaa.

Ah, tullos tilanne, jossa viikon aikana ei tulekaan mitään testattavaa ominaisuutta tai käyttöliitymänäyttöä tms. jolloin testaaja kyselee pitkin toimistoa, olisiko kenelläkään testattavaa. JA KAIKILLA ON!!!! Testattavaa on simppeleistä käyttöliittymätestauksista aina monimutkaisiin integraatio hässäköihin ja suorituskykytesteihin, joita kukaan kehittäjä ei osaa/ehdi tehdä projektin puitteissa. Ja tämän ajan testaajan täytyisi tehdä 100% laskutettavaa työtä ja samalla pysyä kärryillä uusimmissa työkaluissa ja tekniikoissa (sekä testaus- että kehitysrintamalla).

Miten tästä siis selvitään?

Testaukselle pitäisi asettaa jonkinmoinen "puskuri", joka on laskuttamatonta työtä (esim. 5 tuntia viikossa) Tämän määrä vaihtelee 5-25% välillä riippuen viikosta. Tähän voidaan siis ympätä hankalat "testauksettomat" projektit, joita on todellisuudessa pakko testata, mutta niitä ei voi asiakkaalta laskuttaa. Lisäksi tähän voidaan lukea esim. työkalututoriaalit, webinaarit, blogien lukeminen (nykypäivänä helkkarin tärkeä *wink*) ym. ei suoranainen testaus, mutta testaukseen liittyvä.

Tällätavoin laatu paranee sekä yleisellä tasolla (ihmsiet ymmärtävät testauksen tärkeyden ja osaavat myydä sitä asiakkaalle) ja testausresurssitasolla (henkilökohtainen tieto-/taitotaso nousee ja tietämys alan suunnasta lisääntyy). Tämä maksaa kuitenkin yritykselle, joten sen kannattavuus kannattaa laskea tarkkaan.

Vaihtoehtona on tietenkin peukaloiden pyörittäminen ja se, että testaaja ei voi merkata tunteja joita ei voi laskuttaa...

Pureskelkaapa sitä...

Kuinka haastattelen uutta testaajaa?

Olen huomenna joutumassa tulikokeeseen saralla, josta minulla ei ole minkäänlaista kokemusta: joudun haastattelemaan kahta mahdollista testaajaa ja valitsemaan heistä pätevämmän (tai ehdottamaan molempia mukaan, jos molemmat ovat järkevä ottaa mukaan).

Nyt minun pitäisi yrittää löytää ne kysymykset, millä saan kaivettua tarvittavan testausosaamisesta kertovan tiedon. Koska en muualta löytänyt informaatiota (suomeksi) kuinka testaajia kannattaa haastatella, kirjoitan siitä pienen muistion tänne.

Ensimmäiseksi haastateltavan tulisi omin sanoin kertoa omasta testauskokemuksestaan. Tässä tulisi tulla ilmi seuraavaa:
- projektimallit (SCRUM, Waterfall, jne)
- testaustasot (yksikkötestaaja, systeemitestaaja)
- tekniikat (manuaalinen, automaatio, suorituskyky)
- metodit (tutkiva, kokemuspohjainen, testitapauspohjainen)

Jos hakija ei itse huomaa kertoa näitä asioita, häneltä voi kysyä näitä asioita.

Lisäksi on hyödyllistä tiedustella seuraavia asioita (riippuen mahdollisesta tulevasta roolista):
- testaustyökalut (mitä ja miten on käyttänyt, minkälaisissa ympäristöissä)
- testauksen suunnittelukokemus (testitapaukset, -suunnitelmat, automaatioarkkitehtuurit)
- koodauskokemus (skriptaus, valkolaatikkotestaus)
- testauksen hallinta (raportointi, jne)

Jos hakijalla on olemassa testausta tukevaa koulutusta, sitä voi tiedustella, jos se ei ole tullut ilmi. Lisäksi mahdolliset sertifikaatit ja todistukset testausalalta (ja IT-alalta yleensä) tulee tiedustella. Lisäksi kaikki mahdolliset esimerkit luoduista testitapauksista ja/tai testiskripteistä ovat hyviä kertomaan taidoista.

Jos hankitaan testausryhmän jäsentä ryhmään, jossa painotetaan erilaisuutta testaustaidoissa, -kokemusessa ja -näkökulmissa, täytyy haastattelija pystyä arvioimaan testaajan sopeutuminen testauryhmään ns. kovien kykyjen lisäksi. Testaus on ennen kaikkea sosiaalinen prosessi, jossa testaajan tulee voida antaa kritiikkiä kehittäjille. Tästä jöhtuen hyvät kirjalliset ja suulliset taidot (käytettävillä kielillä) ovat tärkeät.

Näiden lisäksi voidaan tutkia erikoisosaamiseen liittyviä asioita lyhyillä kokeilla esim. testitapaussuunnitelijalle: "Muodosta kaksikymmentä testitapausta MS-Wordin fontti näytöltä."