Kävin eilen kuuntelemassa James Bachin esitelmää testattavuudesta, ja siinä yksi hänen teeseistään oli käsitteiden "testaaminen" ja "tarkistaminen" erottaminen toisistaan. Ideana oli, että tarkistaminen on toimintaa, joka voidaan ja usein myös kannattaa automatisoida. Testaaminen on kuitenkin enemmän. Tekoälyn kehittämisessä on otettava vielä monta pitkää harppausta, ennen kuin ihminen voidaan testaustehtävissä täysin korvata tietokoneella.
Järjestelmällisyyttä ja standardoitavuutta rakastaville voi olla hieman hankalaa hyväksyä se, että se missä ihminen voittaa koneen, on henkilöriippuvaista. Riippuu testaajan kokemuksesta, tuotetuntemuksesta, teknisestä ajattelutavasta ja monesta muusta henkilökohtaisesta ominaisuudesta, millaisia asioita hän huomaa.
Esimerkiksi, mitä laajempi kokemus sinulla on julkaisujärjestelmistä, ja mitä enemmän olet testannut juuri nyt testattavana olevaa julkaisujärjestelmää, sitä parempi intuitio sinulla on siitä, miten järjestelmän pitäisi toimia, ja mistä bugeja todennäköisimmin löytyy. Toisaalta joskus etua on siitä, ettet ole eläissäsi nähnyt yhtä ainutta julkaisujärjestelmää. Tällöin pystyt parhaiten löytämään niitä bugeja ja epäloogisuuksia, joita harjaantumattomat, pari kertaa vuodessa järjestelmän kanssa työskentelevät ei-niin-kovin-tekniset päivittäjät löytävät työssään.
Vastaavasti testaajalle on tietyissä tilanteissa apua koodaritaustasta, toisissa tilanteissa se vaikeuttaa käyttäjän kannalta ongelmallisten asioiden huomaamista. Tätä kautta löytyy arvo sille, että testaustiimi koostuu erilaisista ihmisistä, joiden taustat ja tavat työskennellä poikkeavat jollain tapaa toisistaan.
Itse huomaan hakevani testaukseeni lisätehoja valitsemalla itselleni jonkin roolin, näkökulman tai tavoitteen testauksen alkaessa, ja vaihtamalla sitä kun koen saaneeni siitä kaiken oleellisen irti. Testauksen kattavuutta voi parantaa vielä enemmän vaihtelemalla saman tuotteen kimpussa painivaa testaajaa. Mielenkiintoista kyllä, testaukseen saa entisestään tehoja tekemällä sitä parityöskentelynä, jolloin testaajien välinen vuorovaikutus tavallaan kuroo umpeen heidän väliltään löytyviä sokeita pisteitä.
Testaaminen ei ole vain ennalta määrättyjen tehtävien suorittamista. Se on myös uteliaisuutta ja ennakkoluulottomuutta vaativa oppimisprosessi. Lisäksi se on vuorovaikutusta: yhdessä oppimista, sekä pyrkimystä ymmärtää niin käyttäjää kuin kehittäjää.
Esimerkiksi, mitä laajempi kokemus sinulla on julkaisujärjestelmistä, ja mitä enemmän olet testannut juuri nyt testattavana olevaa julkaisujärjestelmää, sitä parempi intuitio sinulla on siitä, miten järjestelmän pitäisi toimia, ja mistä bugeja todennäköisimmin löytyy. Toisaalta joskus etua on siitä, ettet ole eläissäsi nähnyt yhtä ainutta julkaisujärjestelmää. Tällöin pystyt parhaiten löytämään niitä bugeja ja epäloogisuuksia, joita harjaantumattomat, pari kertaa vuodessa järjestelmän kanssa työskentelevät ei-niin-kovin-tekniset päivittäjät löytävät työssään.
Vastaavasti testaajalle on tietyissä tilanteissa apua koodaritaustasta, toisissa tilanteissa se vaikeuttaa käyttäjän kannalta ongelmallisten asioiden huomaamista. Tätä kautta löytyy arvo sille, että testaustiimi koostuu erilaisista ihmisistä, joiden taustat ja tavat työskennellä poikkeavat jollain tapaa toisistaan.
Itse huomaan hakevani testaukseeni lisätehoja valitsemalla itselleni jonkin roolin, näkökulman tai tavoitteen testauksen alkaessa, ja vaihtamalla sitä kun koen saaneeni siitä kaiken oleellisen irti. Testauksen kattavuutta voi parantaa vielä enemmän vaihtelemalla saman tuotteen kimpussa painivaa testaajaa. Mielenkiintoista kyllä, testaukseen saa entisestään tehoja tekemällä sitä parityöskentelynä, jolloin testaajien välinen vuorovaikutus tavallaan kuroo umpeen heidän väliltään löytyviä sokeita pisteitä.
Testaaminen ei ole vain ennalta määrättyjen tehtävien suorittamista. Se on myös uteliaisuutta ja ennakkoluulottomuutta vaativa oppimisprosessi. Lisäksi se on vuorovaikutusta: yhdessä oppimista, sekä pyrkimystä ymmärtää niin käyttäjää kuin kehittäjää.
Ei kommentteja :
Lähetä kommentti