Priorisointia, tavoitteita ja tehtävänhallintaa

Joulukuu kului joulukiireissä, joten jäi blogin kirjoittaminen taas vähemmälle. Testaukseen liittyviä ajatuksia loppuvuosi herätteli työn lisäksi parinkin testaukseen liittyvän tilaisuuden tiimoilta.

Toinen näistä oli testausyhdistyksen järjestämä teemailta, jonka aiheena oli ajanhallinta. Teemu Vesalan ansiokkaan alustuksen pohjalta keskusteltiin erilaisista haasteista, joita oman työn aikatauluttamiseen liittyy.

Aihetta käsiteltiin monesta kulmasta, erityisesti haasteena nostettiin esiin mahdollisuudet uppoutua keskeytyksettä työhön ja toisaalta myös irtautua siitä. Keskustelu oli kiinnostavaa ja tarjosi hyviä uusia ajatuksia, vaikka monet näkökulmat muistuttivatkin minua lähinnä siitä, miksi olen nauttinut niin paljon mahdollisuudesta siirtyä isosta firmasta pieneen.

Minun ajankäytölliset haasteeni eivät tällä hetkellä liity siihen, että kalenterini täyttyisi turhista palavereista, joihin on vaellettava valtavan rakennuksen toisesta päästä toteamaan, että tapaamisen avainhenkilöt eivät ole edes tulossa paikalle. Työsähköpostini ei täyty kummoistakaan vauhtia, eivätkä työtäni rajoita byrokraattiset käytännöt, joista ei itse työn kannalta ole mitään hyötyä. Organisaation sisäisten siilojen väliset haasteet ovat muisto vain.

Sen sijaan haasteita syntyy ajankäytön priorisoinnista, tekemisen fokuksoimisesta ja tehtävänhallinnasta.


Kun on kiire saada valmista, tekemistä täytyy priorisoida. Se tarkoittaa sitä, että oleellisimmat asiat tehdään mahdollisimman hyvin, ja vähemmän tärkeät unohdetaan väliaikaisesti.

Tällaista toimintatapaa voi perustella useammallakin tavalla.

Ensiksikin, joskus deadlinet ovat ihan aitoja deadlineja. Jos ominaisuus X ei ole vielä ollenkaan käytettävissä kun sitä pitäisi esitellä messuvieraille, tai asiakkaan aikataulukriittinen asia Y pitäisi saada vietyä sillä läpi, aikataulua venyttävä pilkunviilailu tulee kalliiksi.

Toisekseen, joskus asiakkaasta on mahdotonta saada irti riittäviä tietoja jonkin toiminnallisuuden valmiiksisaattamiseksi ennen kuin hänet päästetään koekäyttämään sitä. Silloin ei välttämättä ole tarkoituksenmukaista tehdä sitä kovin pikkutarkasti heti ensimmäisellä kierroksella.

Kolmanneksi, työtä voi sisäisessäkin kehityksessä tehdä ja jaksottaa eri tavoin. Yhden päivän aikana ei voi tehdä kaikkea, eikä testausta ole mielekästä lähestyä joka kerta täsmälleen samalla tavalla. Vain pieni osa tehtävistä on sellaisia, joissa pikaisesta vilkaisusta ennen seuraavaa kontekstin vaihtamista olisi minkäänlaista hyötyä, ja siksi työtä pitäisi saada tehdä riittävän pitkinä sessioina. Toisaalta usein tauon ottaminen on välttämätöntä uusien lähestymistapojen löytämiseksi, ja siksi myös mahdollisuus vaihdella tehtävien välillä on hyvä asia. 

Nämä kaikki asiat vaikuttavat siihen, että kaikkea ei tehdä kerralla täydellisesti, vaan tietyt polut ja tietyt piirteet jäävät perusarjessa vähäisemmälle huomiolle kuin toiset.

Priorisoinnissa on kuitenkin riskinsä.

Yksi riski on vääränlainen priorisointi, eli se että keskitytään kuitenkin vääriin asioihin, tai ainakin jotain tärkeää jää huomaamatta.

Toinen asia on jälkien siivoaminen deadlinen jälkeen. Jääkö tekemisen puutteista riittävät tiedot, että tekemätön työ on mahdollista muistaa dl:n jälkeen? Tuleeko se tehtyä? Onko olemassa jonkinlaista suunnitelmaa, miten epämääräiseksi jääneet asiat saadaan tarkentumaan? Onko analysoitu asiakkaan tarvetta käyttöönottoon liittyvään lähitukeen? Ymmärtävätkö kaikki, että vielä ei ole valmista, vaikka lyhyen tähtäimen tavoite saavutettiin?

Ajanhallinnan kannalta haasteellista on löytää tapa huolehtia aikataulukriittisten asioiden riittävän nopeasta etenemisestä pitäen samalla vähemmän kiireiset asiat aidosti työlistalla, niin että nekin tulevat hoidetuksi. Jatkuvalla kiireellä on tapana pitkällä aikavälillä kostautua. Teknisen velan lisäksi ongelmaksi saattaa muodostua se, että tuotteen kasvaessa pienen prioriteetin asioiden imagovaikutus voi käyttäjän silmissä kasvaa yllättävän merkitykselliseksi.

Samalla omaa tekemistä pitää osata arvioida kriittisesti. Tuliko työ tehtyä riittävän hyvin? Tuliko mieleen asioita, jotka olisi syytä lisätä backlogiin? Oliko tekeminen hyödyllistä? Mikä on oleellista siinä mitä teen, ja miten pian tätä on tarpeen arvioida uudelleen? Mikä minua juuri nyt häiritsee käsillä olevien tehtävien asettamien tavoitteiden ulkopuolella? Mitä minun juuri nyt olisi hyödyllistä opetella? Onko jotain mihin liittyen pitäisi pyytää apua?

Rutiinien keskellä on löydettävä tavat katsoa tilannetta konkreettisten tehtävien ulkopuolelta ja saada palautetta tekemästään työstä. Asettaa pidemmän tähtäimen tavoitteita ja etsiä uutta. Kyseenalaistaa.

Jotta tämä olisi mahdollista, on löydettävä säännöllisesti tilaisuuksia irtautua projektia suoraan edistävistä tehtävistä. Vähän päivittäin, ja silloin tällöin ihan kunnolla.

Näin ruuhkavuosirumban keskellä tuntuu välttämättömältä, että tähän voi varata myös ihan oikeaa työaikaa. Silti sen ajan ottaminen vaatii hieman itsekuria.


Minulle luontevin tapa jäsentää ajatuksiani on kirjoittaminen. Alkavan vuoden tavoitteisiin voisinkin asettaa aktiivisemman blogin kirjoittamisen. Aika näyttää, kuinka moni sepustukseni lopulta tulee julkaistua. Toivottavasti lopputuloksesta on iloa myös muille.

Olenko hyvä testaaja

Minulle esitettiin hiljattain suora kysymys: oletko hyvä testaaja?

Kysymys on hyvä, mutta siihen on vaikea vastata. Mistä tunnistaa hyvän testaajan? Miten voi arvioida omaa hyvyyttään testaajana, jos ei pääse juurikaan tekemään töitä hyvien testaajien kanssa, joiden tekemisiin voisi omaa puuhasteluaan verrata? Ja toisaalta, hyvätkin testaajat ovat erilaisia. Jos saisin työskennellä gurun kanssa, joka saisi minut tuntemaan itseni jollain testauksen osa-alueella kädettömäksi, silti saattaisi olla jokin toinen osa-alue, jolla hänellä olisi opittavaa minulta.

Kehittäjiltä saatu palaute on tietenkin yksi mittari. Esim. "keksii luovia tapoja rikkoa asioita" on luonnehdinta, jonka otan kehuna. Myös kysymykset kuten "miten tämän sinun mielestäsi pitäisi toimia" ja "tiedätkö, onko tämä android-puhelinten yleinen virhe" luovat vaikutelmaa, että ammattitaitooni luotetaan. Samoin tuoteomistajilta, projektipäälliköiltä ja asiakkailta tuleva palaute kertoo paljon siitä, miten hyvin työssään onnistuu.

Pohjimmiltaan he ovat kuitenkin kaikki ihmisiä, joiden oma osaaminen kohdistuu johonkin muuhun kuin testaamiseen - ehkä he eivät vain tiedä paremmasta?

Ehkä hyvän testaajan on hyväkin olla hieman epävarma omasta ammattitaidostaan. Olemme kaikki vain ihmisiä. Kuka tahansa saattaa tehdä virhearvioita, olla keksimättä jotain oleellista tapaa väärinkäyttää järjestelmää tai jopa olla tunnistamatta jotakin testauksen osa-aluetta, joka olisi juuri käsillä olevan projektin kannalta äärimmäisen tärkeä. Tästä syystä testaaja ei voi eristäytyä yksin omaan kammioonsa, vaan hänen tulee jatkuvasti löytää uusia näkökulmia työhönsä. Tähän tärkeä väline on keskusteleminen muiden projektin osapuolten kanssa. Joskus yksinkertainen kysymys voi olla vaikuttavampi kuin päivän testausrupeama.

Niin kauan kuin on pienikin epäilys oman osaamisen riittämisestä, mieli etsii aukkoja omasta päättelystä. Ilman tätä uusia oivalluksia ei tule. Olisi vaarallista kuvitella osaavansa ja ymmärtävänsä jo kaiken.

Testausta on monenlaista. Kurinalaisuuden ja järjestelmällisyyden yhdistäminen luovuuteen ja jatkuvaan oppimisprosessiin on haasteellinen kokonaisuus, jossa minkä tahansa kulman laiminlyöminen voi johtaa kalliisiin epäonnistumisiin.

Siksi ei ole yhdentekevää, kuka tuotettasi testaa.

Ninjakin tarvitsee mestaria

Testaus on käsityöläisammatti, jonka oppimiseen on vain yksi tie: harjoitus. Työn tekeminen ja tulosten kriittinen analysointi ovat edellytys sille, että voi osata testausta.

Käsityöläisammatit eivät kuitenkaan ole kehittyneet vain yksittäisten ihmisten kekseliäisyyden varassa. Ammattilaiseksi kehitytään mestarin ohjauksessa, ja mestareista parhaat ovat hakeneet oppia useammaltakin mestarilta, tyypillisesti myös ulkomailta.

Tavallaan testausta voidaan verrata myös kamppailulajien harjoittelemiseen. Opetellaan uusia tekniikoita, hiotaan niitä, opetellaan tunnistamaan tilanteita joissa niitä käytetään, ja opetellaan käyttämään niitä tehokkaasti. Hyvät harjoitukset rakennetaan vastaamaan mahdollisimman realistisia todellisia tilanteita.

Myös jokaisella dojolla on oma mestarinsa, jonka oppeja seurataan, vaikka opetuksesta tyypillisesti huolehtiikin joku muu.

Nykypäivänä emme ole täysin suullisen tiedon varassa. Kirjastoista ja netistä löytää tietoa niin käsitöistä, kamppailulajeista kuin testauksestakin. Pyörää ei tarvitse keksiä kokonaan itse, vaikka ei mestarin ohjauksesta saisikaan nauttia.

Silti, ilman ohjausta voi olla vaikea löytää tietään parhaan tiedon luo. Tarvitaan myös mahdollisuuksia kysymiseen ja keskustelemiseen. Näihinkin netti tarjoaa onneksi mahdollisuuksia.

Netin kautta mestari ei kuitenkaan voi korjata virheellistä ranteen asentoa tai jalan väärää liikerataa. Tekniikan hioutumiseen on mahdollisuuksia vain siellä, missä oppija itse näkee tarpeen kehittymiselle.

Voiko myöskään testauksessa koskaan toteuttaa täyttä potentiaaliaan, jos ei saa tilaisuuksia harjoitella yhdessä mestarin kanssa?

Älä turhaan suunnittele testausta

Testauksen voi suunnitella monella tavalla. Testitapauksia voi kirjoittaa hyvin yksityiskohtaisesti, tai ne voi rakentaa vain otsikkotasolla, muistilistanomaisesti. Itse testauksen organisointia voi suunnitella enemmän tai vähemmän perusteellisesti. Testaussuunnitelma voi kertoa mm. kuinka paljon työaikaa ja kalenteriaikaa käytetään mihinkin testikierrokseen, miten paljon aikaa varataan niihin liittyviin korjauksiin verifiointeineen, kuinka usein testikierroksia toistetaan, ja mitkä ovat kriteerit testauksen lopettamiseen.

Joskus on hyvä pysähtyä hetkeksi miettimään, millä tarkkuustasolla nämä asiat kannattaa tehdä projektin suunnnitteluvaiheen aikana.

Perusteellinen testaussuunnittelu liittyy usein siihen, että asiakkaalle on luvattu tiettyjä dokumentteja tietyssä vaiheessa projektia. Jos asiakkaan kanssa sovitaan, että he saavat toimittajan testitapaukset sisältöineen kaikkineen käytettäväksi omassa hyväksymistestauksessaan, ne on rakennettava paljon huolellisemmin ja paljon enemmän aikaa käyttäen kuin jos luodaan vain alustava testitapausluettelo, jota muokataan ja täydennetään tarpeen mukaan testausvaiheessa. Jos asiakas haluaa lukea testaussuunnitelman, siinä ei oikein voi lukea että testataan sitä mukaa kun jotain on likipitäen testattavissa, testaajana se joka sattuu silloin parhaiten ehtimään. Joskus tämä kuitenkin olisi tarkoituksenmukaisempi suunnitteludokumentti kuin sellainen, joka ottaa kantaa kaikkeen mahdolliseen testaamisen aloitus- ja keskeytyskriteereistä testikierrosten organisointiin. Kenties keskeisin hyvän testaussuunnitteludokumentin piirre voisi olla se, että se on riittävän lyhyt jotta projektin kulkua ohjaavat henkilöt lukevat ja sisäistävät sen.

Jos oikeastaan mikään ei todellisuudessa tapahdu suunnitteludokumentaation mukaisesti, eikä sitä tosiasiallisesti edes yritetä noudattaa (olipa syy tähän sitten piittaamattomuus tai projektielämän realiteetit), kuinka paljon aikaa tällaisen dokumentin kirjoittamiseen kannattaa käyttää?

Jos projektia edistetään vähän miten nyt kukakin sattuu ehtimään, on testauksessakaan turha pyrkiä tämän suurempaan kurinalaisuuteen. Klassinen testaus perusteellisine testitapausluetteloineen ja huolella ennalta suunniteltuine testikierroksineen on mielekästä vain, jos myös projektin edeltävät vaiheet viedään läpi vastaavaa kurinalaisuutta noudattaen. Eli määritysvaiheessa todella määritetään ja kiinnitetään määritykset, suunnitteluvaiheessa ihan oikeasti suunnitellaan määrityksen pohjalta, ja toteutusvaiheessa nämä suunnitelmat viedään läpi aikataulussa.

Kaikissa projekteissa tämä ei kuitenkaan ole mahdollista. Eikä kyse ole vain toteuttavan projektihenkilöstön osaamisesta ja viitseliäisyydestä. Tilanteeseen vaikuttaa myös esimerkiksi asiakkaan määritysosaaminen, eli pystyvätkö he kertomaan, mitä haluavat, ja kuinka paljon projektin aikatauluun sisällytettäviä muutoksia he keksivät suunnittelu- ja toteutusvaiheiden aikana, Ja tähän taas vaikuttaa paitsi asiakkaan projektiryhmän IT- ja substanssiosaamisen riittävyys, myös asiakkaan tarpeiden selkeys.

Lisäksi, ihmiset ovat erehtyväisiä. Paraskin projektipäällikkö voi unohtaa jotakin, ja paraskin tekninen vastuuhenkilö ymmärtää jotain väärin. On vain hyvä asia, jos nämä unohdukset ja väärinymmärrykset jäävät kiinni ennen stabilointivaihetta, koska silloin niiden vaikutukset aikatauluihin ja työmääriin ovat vähäisemmät. 

Jokainen projektiin tuleva muutos kuitenkin syö etukäteen tehdyn perusteellisen testaussuunnittelun arvoa. Mitä enemmän asioita on kirjoitettu auki testitapauksiin, sitä enemmän niitä on pakko muokata muutosten mukaisesti, ja sitä suurempi riski on sille että testaus raportoi vääriä asioita bugeina. Mitä enemmän projektin käytännöt ja järjestelyt poikkeavat testaussuunnitelmasta ehdotetuista, sitä vähemmän arvoa on sen kirjoittamiseksi tehdyllä työllä. Kun tämän päälle tulee vielä testaussuunnittelun itsensä epätäydellisyys, on selvää että määritysvaiheen perusteella tehdyt testitapaukset on vähintään katsottava läpi kriittisellä silmällä testauksen alkaessa.

Testaussuunnittelu on mahdollista tehdä myös toisin. Määritys- ja suunnitteluvaiheessa testauksen rooli voi keskittyä enemmänkin katselmointiin ja konsultointiin. Testaussuunnitteludokumentaation keskeisin rooli voi olla tiedon kerääminen siitä, mihin dokumentteihin nojaten testaus on tehtävä, sekä millaisia riskejä projektiin liittyy testaamisen näkökulmasta ja miten niihin varaudutaan. Riskitarkastelussa käsitellään niin testaukseen ulkopuolelta vaikuttavat riskit kuin riskit joihin testaaja voi itse vaikuttaa, muistaen erityisesti asiakkaan toiminnan kannalta keskeisimmät toimitettavaan järjestelmään liittyvät riskit, joiden tulisi vaikuttaa testauksen sisällölliseen painotukseen. Varsinaiset testitapaukset voidaan luoda tutkivan testauksen ohessa, tosin tällöin on muistettava että testaukseen tarvittavaan aikaan on lisättävä myös dokumentaation vaatima aika.

Mikä siis on päivän opetus? 

Klassisella, kurinalaisella testauksella on oma arvonsa ja paikkansa, mutta kaikkialle se ei sovi. Jos tiedät, ettet aikuisten oikeasti pysty viemään projektia läpi tiukasti vesiputousmallin mukaisesti, älä tee myöskään testaussuunnittelua niin kuin mentäisiin vesiputousmallilla. Älä silloin myöskään lupaa asiakkaalle testitapauksia (paitsi korkeintaan otsikkotasolla) suunnitteluvaiheessa. Tosiasiat voi tunnustaa jo etukäteen, ja ammattimainen testaaja pystyy kyllä luovimaan tiensä myös vähän epämääräisemmässä projektiympäristössä. Säästytään puolin jos toisin paljolta pahalta mieleltä ja turhalta työltä, jos projektin toimintatavoista sovitaan avoimesti etsien ne tavat, joilla tieto parhaiten löytää tarvitsijansa, ja testaus voidaan suunnitella tavalla jolla se todennäköisesti voidaan myös toteuttaa.

Elämäni mutteriapinana ja muita motivaatiokokemuksia

Kenties turhauttavinta testaustyössä on säätäminen.

Siis se, miten pahimmillaan parikin kertaa päivässä joutuu kyselemään projektien vastuuhenkilöiltä, joko olisi testattavaa, miten aikataulu elää, missä testataan, milloin ympäristö päivitetään, mitä ja miten on testattavissa. Mitkä ovat juuri nyt testauksen prioriteetit ja tavoitteet.

Miten viime hetken kiireellisen tilauksen vuoksi joutuu keskeyttämään juuri vauhtiin päässeen työskentelyn tehdäkseen taas uuden syöksyn tuntemattomaan. Tai kyselemään, voisiko jonossa seuraavan projektin aloittaa sovittua aikaisemmin, kun se ensimmäinen ei olekaan vielä testattavissa. Järjestelemään testauksen jakamista tai siirtämistä toiselle testaajalle, kun projektien toteutuvat aikataulut vaativat suurempaa työpanosta kuin mihin on kohtuullista yksin venyä.

Kysymään useampaan otteeseen, ennen kuin saa riittävät tiedot jonkin asian testaamiseen, vain löytääkseen itsensä tilanteesta, jossa joku tuhoaa varoittamatta vaivalla rakennetun testiaineiston, tai selviää että sovittua päivitystä ei sitten ollutkaan tehty. Tai päivitettiin epästabiiliksi tiedettyyn versioon, ja nyt päästään testaamaan samoja bugeja useammassa ympäristössä yhtäaikaa.

Tähän kaikkeen liittyy piinallinen tuntuma siitä, ettei saa mahdollisuutta tehdä työtään niin hyvin kuin haluaisi, olla niin hyödyllinen kuin omasta mielestään osaisi olla.

Jonkin verran epävarmuutta, inhimillisiä erehdyksiä ja niihin liittyvää säätämistä on pakko hyväksyä. Testaajan työn aikataulu ja työmäärä riippuvat siitä, miten kehittäjät tekevät työnsä, eikä sitä ole täysin mahdollista ennakoida. Kun vielä testaajan työn idea on enemmän tai vähemmän keskeneräisen kanssa työskentely - sen tarkistaminen, miten tukeva rakennelmasta tulikaan - virheisiin törmääminen vähän niin kuin kuuluu toimenkuvaan.

Siksi välillä on pakko joustaa ja järjestellä. Joskus on myös pakko hyväksyä se, että juuri nyt ei ole tarjolla mielekästä testaustyötä. Tai että aika ei riitä tekemään asioita oikeasti perusteellisesti. Työ on lopulta vain työtä, ei sen takia kannata yöuniaan menettää, eikä sen tarvitse olla tärkein elämään sisältöä tuova asia.

Joskus kuitenkin on vaikea välttää ajatusta, olisiko asiat kuitenkin mahdollista tehdä edes vähän paremmin.

Yksi vaihtoehto olisi tehdä projekteja ketterämmin, jolloin testattavaa syntyisi tasaisempaa tahtia ja pienempiä määriä kerrallaan. Tämäkään vaihtoehto ei kuitenkaan yksin tuo pelastusta, sillä monia vesiputousmallia rampauttavia toimintatapoja (tai tapoja olla toimimatta) on mahdollista käyttää myös projekteissa, joita periaatteessa edistetään ketterästi - häröilyhän ei sellaisenaan kuulu mihinkään prosessimalliin. Eikä järjesteltävien palikoiden pienentäminen itsessään poista järjestelyn tarvetta, vaan lopputulos voi olla jopa päinvastainen.

Yllättävän paljolta turhalta työltä ja mielipahalta säästyttäisiin ihan vain skarppaamalla projektien sisäisen tiedonkulun kanssa. Siis esimerkiksi sillä, että aina kun tapahtuu jotain aikatauluun tai sisältöön vaikuttavaa, myös testaaja saisi kuulla asiasta. Tai jos kehitetään ja testataan yhtäaikaisesti, saman projektin parissa painivilla olisi tieto siitä, mitä muut ovat tekemässä, ja keihin kaikkiin omat tekemiset voivat vaikuttaa. Että saisi senkin tiedon, jota ei ole helppoa keksiä itse kysyä. Monet näistä asioista varmaankin helpottaisivat myös kehittäjien työtä.

Pitäisikö testaajan istua kehittäjien luona jo toteutusvaiheessa? Pitäisikö hänen osallistua projektipalavereihin alusta alkaen? Ainakin osaan niistä? Pitäisikö projektien tiedotus hoitaa spämmäämällä aina sähköpostilistaa, jolle myös testaaja kuuluu?

Ratkaisuvaihtoehtoja voi olla useampia. Ehkä lopulta tärkeintä on, että projektin sisäinen viestintä ylipäätään nähdään panostamisen arvoisena, tapana ehkäistä ongelmia. Esimerkiksi, että palaverit suunnitellaan jollain tasolla, niistä jaetaan etukäteen jonkinlainen agenda, ja niihin pääsevät tavalla tai toisella osallistumaan kaikki, joita käsiteltävä asia jotenkin koskee, tietäen mitä heidän osallistumiseltaan odotetaan. Että niiden ensisijainen tarkoitus ei ole raportointi, vaan tiedon jakaminen kaikille niille jotka siitä hyötyvät.

Miten saada paras hyöty irti testaajasta?

Työpanoksen mittaaminen on vaikeaa. Jollain tavalla työntekijöiden suoriutumista pitäisi seurata, mutta mittareilla on paha tapa vaikuttaa ihmisten suoriutumiseen paitsi hyvässä myös pahassa.

Testaajan työn arviointia hankaloittaa se, että se on niin riippuvaista muiden työskentelystä. Samoin helpoiten muodostettavat testaajan työssä onnistumisen mittarit ovat kaikki omalla tavallaan ongelmallisia.

Löytyvät bugit riippuvat paitsi testaajasta myös kehittäjästä, joten tietyssä aikavälissä löytyvien bugien määrä tai laatu ei välttämättä kerro kovin paljoa siitä, miten hyvin testaaja on aikansa käyttänyt. Jos testaajan työtä arvioidaan mittaamalla löytyvien bugien määrää, se kannustaa testaajaa tehokkaaksi löytämään virheitä, mutta ei suuntaamaan tekemistään oleellisimpiin asioihin - näin bugikanta saadaan helposti täyttymään pienen prioriteetin virheistä. Bugien merkittävyyden arvioiminen statistiikkaa varten taas on työlästä, ellei luoteta testaajan tai hänen kanssaan työkentelevän kehittäjän omaan arvioon bugien prioriteeteistä. Toisaalta tarkkakaan tieto bugien vakavuudesta ei anna tietoa testauksen tehokkuudesta, jos testaaja käyttää paljon aikaa sellaisten asioiden manuaaliseen läpikäymiseen, joiden testaaminen kannattaisi automatisoida.

Testauksen tehokkuutta voidaan mitata myös esimerkiksi sillä, miten suuri osa raportoiduista bugeista saadaan ratkaistua kerralla, kysymättä lisätietoja bugin toistamiseksi. Tämä vaatii kuitenkin suhteellisen huolellista bugiraportointijärjestelmän käyttöä, jotta statistiikkaa saadaan helposti kerättyä, ja siten mahdollistaa myös huijaamisen. Asiakkaan löytämien bugien määrä ja laatu kertoo paljon sisäisesti tehdyn testauksen onnistumisesta, mutta tämän mittarin käyttäminen on monella tavalla hankalaa: miten tieto asiakkaan löydöistä raportoidaan ja luokitellaan, ja miten hallitaan tieto järjestelmään tehtävien päivitysten vaikutuksesta sekä niihin liittyvien testikierrosten vastuista.

Testaajan mahdollisuudet käyttää aikansa hyödyllisesti riippuvat myös siitä, mihin tahtiin testattavaa valmistuu. Hänellä ei ole valtaa vaikuttaa siihen, tuleeko asiakasprojekteista hommia tasaiseen tahtiin, vai joudutaanko vuoroin käyttämään aikaa toissijaisiin tehtäviin ja vuoroin priorisoimaan projekteja. Jos siis mitataan sitä, miten suuri osa ajasta kuluu laskutettavien projektien parissa, kannustaa se toki priorisoimaan ajankäytössä asiakasprojekteja, mutta myös käyttämään näihin projekteihin tarpeettoman paljon aikaa silloin kun asiakasprojekteja ei ole tarjolla täysipäiväisesti. Jos taas mitataan sitä, miten hyvä tuntihinta saadaan tehtävästä työstä, kipeimmin testausta kaipaavat katastrofiprojektit päätyvät testaajan ajankäytön priorisoinnissa viimeiseksi. Entä miten pitäisi huomioida tuotekehityksen tukeminen, tämä työ kun hyödyttää useita asiakasprojekteja?

Asiakastyytyväisyyttäkään ei saavuteta pelkällä testauksella, vaan siihen vaikuttavat mm. projektipäällikön kommunikointitaidot ja määrityksen tekemiseen osallistuvien kyky ymmärtää asiakkaan tarpeet ja muotoilla ne ymmärrettävästi. Jos järjestelmää ei ole onnistuttu määrittämään ja suunnittelemaan täyttämään asiakkaan tarvetta, timanttinenkaan testaus ei tilannetta pelasta. Asiakkaan löytämillä bugeilla kun on merkitystä vain, jos ne ovat syy joka estää järjestelmää täyttämästä sitä tarvetta, jota varten se hankittiin. Jos tärkeimmät valituksen aiheet ovat luonteeltaan muutospyyntöjä, liikutaan alueella jolla testaajien rooli on usein tarkoituksenmukaisinta pitää melko pienenä - ellei häntä sitten tuoda jo määritysvaiheesta alkaen asiakasrajapintaan niin, että hänellä on aidosti mahdollisuus arvioida toteutuksen soveltumista asiakkaan liiketoimintatarpeisiin.

Voidaan myös yksinkertaisesti kysyä projektihenkilöstöltä rivikoodarista projektipäällikköön, onko yhteistyö testaajan kanssa koettu hyödylliseksi, ja millaisia puutteita siinä nähdään. Tällaisten kartoitusten kompastuskiveksi vain koituu helposti se, että kenelläkään ei ole aikaa paneutua ylimääräisiksi koettuihin asioihin, kun seuraavat projektit painavat jo päälle. Lisäksi subjektiivisiin arviointeihin liittyy myös persoonallisuuksiin liittyviä piirteitä, jotka tekevät arvioinnista ylipäätään epämääräistä.


Toisaalta, onko testaajan työn mittaamisella edes merkitystä, jos organisaatio ei osaa täysin hyödyntää testaajan työpanosta?

Pystytäänkö tekeminen projekteissa aikatauluttamaan niin, että testaajan työaika saataisiin mahdollisimman tehokkaasti hyödynnettyä, eli testattavaa saataisiin eri projekteista valmistumaan mahdollisimman tasaiseen tahtiin? Mahdollistavatko projektien aikataulut sellaisen testaamisen, että ammattitestaajista on oikeasti hyötyä?

Onko organisaation sisäiset laskutuskäytännöt muodostettu niin, että projektien kannattaa hyödyntää ammattitestaajia?

Miten testaajan työaikaa hyödynnetään parhaiten silloin, kun testattavaa ei ole? Onko sisäisiä kehitysprojekteja, jotka tuovat hyötyä asiakasprojekteille, tai muita aikataulultaan väljiä tehtäviä, joihin voi käydä käsiksi, jos ei testaamalla pysty olemaan oikeasti avuksi? Tuetaanko testaajien mahdollisuuksia kouluttautua suoriutumaan paremmin työssään? Onko kehittäjien mahdollista itsenäisesti pyytää tukea testaajalta, jos he kokevat sen hyödylliseksi jotakin toiminnallisuutta rakentaessaan?

Entä mitä testaukselta ylipäätään halutaan? Onko tarkoituksena vain etsiä bugeja niin pitkään kuin projektin aikataulu ja budjetti antavat myöten, vai onko tavoitteena esimerkiksi antaa projektipäällikölle mahdollisuus keskittyä työssään olennaiseen, helpottaa kehittäjien työtä, tai saada tieto ohjelmiston laadusta tietyllä ajanhetkellä?

Kun näihin kysymyksiin löytyy vastauksia, on myös relevanttien mittareiden rakentaminen varmasti helpompaa.