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

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?

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.

Testauksen Jin ja Jang!

Lueskelin taas kerran gurujen blogeja ja päädyin (ensin James Bachin blogista johdettuna) Michael Boltonin blogilla olleeseen käsikirjoitukseen näiden kähden keskustelusta koskien IEEE:n määritelmää testitapauksesta tai ainakin Lanette Cramerin tulkinta aiheesta:

Clinically defined a test case is an input and an expected result...

Mutta tämä on aivan toinen asia käsiteltäväksi. Kuitenkin seurasin Jamesin ja Michaelin keskustelua ja totesin, että herrat ovat hyvällä asialla, joten ei siitä sen enempää. Sen sijaan erä kommentti Michael Boltonin blogimerkinnässä sai minut ajattelemaan:

“Over-specialize and you breed in weakness"

eli ylierikoistuminen johtaa heikkouteen. Tämä metafora oli alunperin animaatio elokuvasta “Ghost in the Shell", mutta kuten Petteri Lyytikäinen sanoo kommentissa, tämä pätee sekä taistelulajeihin että testaamiseen.

Ajatukseni alkoivat rullata kuin hullu tuolloin, vaikkakin hän puheessaan viittasi ainoastaan ajatusmallien ennakoitavuuteen se pätee mielestäni myös testaustaitoihin. Jos testaaja erikoistuu liikaa yhteen aihealueeseen (sanotaan suorituskykytestaukseen) hänen diversiteettinsä testausmaailmassa katoaa. Testaajan kyky toimia tehokkaana testaajana perustuu juuri sille, että hän osaa ajatella sitä, mitä muut eivät osaa - hän löytää asioita mitä muut eivät löydä.

En sano kuitenkaan, että älkää erikoistuko - päinvastoin! Hankkikaan tietämystä erikoisaloilta ja tulkaa parhaaksi siinä, mitä teette! Muistakaa kuitenkin pitää mielessä se, että ei kaikki testaus ole puristettavissa siihen yhteen alueeseen, johon erikoistut. Tietoja ja taitoja tulee omata muualtakin testauksen piiristä. Manuaalisen testaajan on hyvä osata automatisointia, tutkivan testaajan testitapaustestausta, jne.

Kun pystyy hallitsemaan (ei erikoistumaan) mahdollisimman suureen ja mieluusti toistensa vastapainona toimiviin testaustekniikoihin ja -näkemyksiin, löytyy tie Nirvanaan! Se, joka pystyy tasapainottamaan itsessään ne vastavoimat (Rex Black vs. James Bach) on kuningas testaajien joukossa.

Tämä johtaa myös väistämättä puolueettomuuden tukemiseen. Kun päästään eroon vastakkaisista leireistä, voidaan yhteisellä päämäärällä päästä suurempiin tavoitteisiin!

Oppiminen on kaksisuuntainen tie

Yritykseemme on saatu taistelun jälkeen toinen testaaja (jee!) ja sain kunnian olla hänen kouluttajansa testauksen ihmeelliseen maailmaan. Hän mielestäni (yhden päivän kokemuksella) lahjakas kaveri, joka ei haasteita pelkää. Oikea asenne testaajalle!

Koulutuksen lomassa tuli puheeksi testaustermit, jotka olivat hänelle hieman epäselvät. Ja ovathan ne kaikille. Miten voit järkevästi kääntää suomeksi testaustermejä, jotka ovat epäselkeitä ja organisaatiokohtaisia (parhaimmillaan) englanniksikin. Ja vaikka sana olisikin hallussa, niin tarkoittaako se yrityksessä sitä mitä kirjassa tai kurssilla?

James Bach sanoo blogissaan, että testaus ei ole sitä, että opetellaan täyttämään valmiiksi luotuja kaavakkeita ja suunnitelmapohjia ja hoetaan valmiiksi opeteltuja testaussana litanioita. Hän kehottaa kehittämään itseään aina paremmaksi testausalalla ja viettämään aikaa niiden kanssa, jotka tuntevat samoin. Jos useammat ajattelisivat näin, niin näiden oppivien testaajien määrä ylittäisi näiden "kaavaketestaajien" määrän, ja näin "oppimishaluiset tulevat perimään maailman".

Testausmaailmaan pääsy on jokseenkin helppoa ja jokainen voi sanoa testanneensta jotakin elämänsä aikana - joko systemaattisesti tai AdHoc - mutta jokainen on testannut jotakin joskus. Se mikä erottaa testaajan tavallisesta ihmisestä, on se että testaaja pyrkii systemaattisesti etsimään virheitä ja kehittämään testauskykyään jokaisen testin yhteydessä.

Se mikä Bachin mukaan erotta hyvän testaajan testaajasta on se, että hyvä testaaja jakaa mielipiteitään ja haastaa toisia testaajia.

Kuinka siis saan parhaan mahdollisen tuloksen tästä testausharjoittelijasta ilman, että hänestä muodostuu geneerinen kaavaketestaaja? Menin jo (mielestäni) tekemään yhden virheen: annoin hänelle esimerkkidokumentin. Todellisuudessa tämä kaveri ei täyttänytkään testaussuunnitelmaa suoraan olemassaolevaan dokumenttiin vaan oikeasti käytti mielikuvotustaan ja taitojaan, jotta saisi testitapauksista ja suunnitelmasta järkevän. Jatkossa minun täytyy antaa hänelle vapaat kädet ja hän saa tarvittaessa pyytää apua, mutta kokeilla myös omia siipiään. Näin syntyy mehukkaita ideoita ja oivalluksia, joita kokenut testaaja ei välttämättä osaa löytää.

Kaikesta huolimatta, tulen kuitenkin kokeneempana testaajana haastamaan ja kyseenalaistamaan hänen tekemisiään, jotta hän oppii tekemästään ja minä opin samalla. Oppiminen on siis kaksisuuntainen tie, jossa sekä opettaja että oppilas oppivat. Kun vain nyt muistaisi pysyä tuolla tiellä, niin tämänkin yrityksen testaus alkaisi näyttää valoisammalta! =)

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

Suorituskykytestaus integraatioprojektissa

Projektipäällikkö pyysi minua tekemään suorituskykytestaussuunnitelman integraatioprojektiin. Ongelma on vain se, että meiltä puuttuu kokonaan NFR:t. En ole koskaan aiemmin tehnyt suorituskykytestaussuunnitelmaa, joten nyt pitäisi sellaisen tekemiseen paneutua.

Ensiksi täytyy löytää vastaus kysymykseen "Miksi testaamme suorituskykyä?". Tässä tapauksessa varmaankin pyritään ensikädessä luomaan ne raamit, missä järjestelmä tällä hetkellä on. Tämän takia täytyisi siis siis rajata se alue, jossa suorituskykytestit tehdään ja selvittää arvio sielttä liikkuvista massoista. Jos suorituskyvyssä ilmenee ongelmia, niin ne on helpompi paikata ennen kun niistä muodostuu tuontannollisia ongelmia. Lisäksi tulevaisuuden kannalta tulee selvittää millaisia pullonkauloja saattaa olla tiedossa ja missä vaiheessa tuotteen elinkaarta.

Pullonkaula saattaa vääristää end-to-end prosessin kaikkien komponenttien suorituskykyä. Jos yhdessä kohdassa on pullonkaula, se tulee eristää ja poistaa. Tämä voi lisäksi vapauttaa yhden pullonkaulan aiheuttamia lisäpullonkauloja edempänä prosessissa.

Toinen kysymys mihin tarvitaan vastaus on "Miten testaamme suorituskykyä?". Integraatioprojektissa testaus kannattaa suorittaa työkalulla, joka pytyy muodostamaan halutun määrän sanomia halutussa ajassa ja lähettämään niitä haluttuun end-pointiin.

Lisäksi täytyy tietää, millaisilla testeillä testaamme suorituskykyä.

Käyttäjämäärätestaus (Performance): Integraatiotestauksessa on harvoin kysymys käyttäjän/käyttäjien suorittamasta toiminnasta vaan kahden järjestlemän keskenäisestä kommunikoinnista. Integraatiotestauksessa ei tarvitse siis ottaa huomioon käyttäjämäärätestausta sellaisenaan, vaan käyttäjien sijaan lisätäänkin kommunikoivia järjestelmiä (lähteitä/threadeja). Pyritään siis etsimään se kohta, jolloin lähteiden määrä alkaa aiheuttaa hitautta tai sovelluksen toiminta muuttuu.

Massatestaus (Volume): Intergaatio testauksessa on tärkeä tietää, kuinka paljon sanomia järjestelmä pytyy käsittelemään kerrallaan. Lisäksi on tärekää, että pyritänkö luomaan suorituskykytesti niin, että syötetään yhdestä lähteestä sanomia samanaikaisesti vai useasta yhtäaikaa. Tässä pyritään siis selvittämään,e ttä suoriutuuko järjetelmä vaadituista arvoista. Tässä tapauksessa emme tiedä, mitä vaatimuksia on, joten tämä jää tällä kertaa pimentoon.

Kuormitustestaus (Stress): Integraatiotestauksessa on tärkeää löytää ne tilanteet, jolloin sanomien/tapahtumien määrä on siis suuri, että se vaikuttaa järjestelmän käyttäytyimiseen. Tässä testauksessa voidaankin ottaa arvioitu sanomamäärä ja lisätä sitä 20% joka kierroksella (mahdolliseseti lisätä säikeiden määrää aina välillä). Pyritään lisäämään niin kauan, että järjestelmä ei enää toimi.

Yhtäaikaisuus (Concurrency): Integraatiotestauksessa yhtäaikaiset käyttäjät ei ole oleellisia, mutta yhtäaikaiset (toisensa kumoavat) tapahtuman ovat. Pyritään siis luomaan testi, jolla luodaan yhtaisiaisia, toisensa kumoavia toimintoja. Tällä voidaan selvittää esim. jonoihin kasaantuvia ristiriitaisia tapahtumia.

Suorituskykyä testatessa voidaan yhdistää sekä sanomien määrällä että lähteiden määrällä testausta, jolloin voidaan saada erilaisia testituloksia. Integraatiotestauksessa täytyy myös pyrkiä siihen, että testidata on tuotantoa vastaavaa.

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