Miksi kukaan haluaisi testaajaksi?

 

Vahingossa, lienee vastaus kun kysytään, miten joku on päätynyt testaajaksi. Olen tehnyt testausja
laadunvarmistusalan töitä reilun yhdentoista vuoden ajan ja arvaisin, että merkittävä osa
alallamme lienee saapunut jostain toisaalta ohjelmistotestauksen pariin.

Mutta mitä ohjelmistotestaaja sitten tekee? Testaa. Mitä sitten on testaus? Oxford Dictionary
määrittää sanan ”test” suomeksi käännettynä osapuilleen näin: ”Asioita, joita tehdään jonkin asian
laadun, suorituskyvyn tai luotettavuuden selvittämiseksi, etenkin ennen kuin se päätyy
laajamittaiseen käyttöön.” Testaaja on siis henkilö, joka tekee asioita selvittääkseen asioiden
laadun, suorituskyvyn tai luotettavuuden.

Vuosia testaaja nähtiin helposti vain suorittavana henkilönä, jonka tehtävä oli nakuttaa
samanlaisia testitapauksia aamusta iltaan uudestaan ja uudestaan. Sen jälkeen
automaatiotestausvälineet ovat kehittyneet, eikä testaajan työ ole enää käytännössä lainkaan sitä,
millaiseksi se on aiemmin mielletty. Kun kone voi tehdä testitapausten näppäilyn aamusta iltaan,
pääsee testaaja tekemään toisenlaisia asioita.

Testaaja – kehittäjän kustannustoimittaja

Nykyisin testaajan työ on hyvin erilaista. Periaatteessa lähin vertailukohta testaajalle voisi olla
kehittäjän kustannustoimittaja: pyrkimyksenä on tarkistaa kehittäjän tekemä koodi ja toimivuus,
saada ohjelma valmiiksi ja tuotantoon sekä lopulta koko tiimi näyttämään hyvältä. Tämä saattaa
joskus vaatia hieman ”kovaa rakkautta” ja sen vuoksi testaajan on oltava sosiaalinen, hyvin asiansa
perusteleva, periksiantamaton ja mittaamattoman kärsivällinen.

Itse olen nähnyt testaajan työn enimmäkseen kaikki kerrokset läpäisevänä, holistisena toimena.
Jos prosessissa tai ohjelmistokehityksessä jokin menee pieleen, se tipahtaa testaajan syliin ennen
tuotantoonmenoa. Helpottaakseen elämäänsä, testaaja pyrkiikin näkemään potentiaalisia
kehityskohteita kaikkialla.

Kuinka vaatimuksia määritellään? Onko ohjelmoijalla tänään kaikki hyvin? Toimiiko ohjelmoitu asia
niin kuin on sovittu, vaikka tosiasiassa se onkin asia, jota kukaan ei tarvitse? Ja ennen kaikkea, jos
kaikki tuntuu menevän harvinaisen hyvin putkeen, mikä on se asia, jonka olen missannut ja milloin
se osuu omaan nilkkaan?

Sanon usein, että ”minulle maksetaan siitä, että olen hieman paranoidi”. Se tarkoittaa sitä, että
testaajan on osattava pohtia asioita kantilta, jolta niitä ei osata pohtia. Jos ohjelmisto hajoaa
väärin käytettäessä, ei pidä vastata ”no, ei sitten käytetä sitä väärin” vaan hyväksyä se tosiasia,
että tuotantoon siirtäessä ohjelmistoa tullaan varmasti käyttämään kaikilla mahdollisilla tavoilla.

Siksi pitää nähdä ennalta se, mitä ennalta ei voi nähdä.

Entäs se teknologia?

Testaajan elämää helpottaa, jos hän tuntee erilaisia teknologioita ja osaa lukea koodia, miksei
kirjoittaakin. Varsinaista koulua ohjelmistotestaukseen ei ole (vielä), mutta etenkin
selaintestiautomaatiopuolella on hyvä tietää vaikkapa mitä Seleniumilla tehdään, millaisia ovat
Robot Framework, Mocha.js, Jenkins tai JMeter tai esimerkiksi TestCafe. Automaatio voi toisaalta
myös liittyä vaikkapa sulautettuihin järjestelmiin ja silloin on tärkeää, että testiframework kykenee
ajamaan millaisia skriptejä tahansa. Tällöin päästään taas hieman lähemmäs koodaamista.

Koska alalle ei juurikaan voi kouluttautua, tarkoittaa se toisaalta myös sitä, että mukaan pääsee
myös vastavalmistunut ja työn voi oppia tehdessä. Täytyy vain olla valmis oppimaan asioita laajaalaisesti
ja sietää sitä, että asiat muuttuvat joskus nopeallakin syklillä.

Vaikka teknologisesta osaamisesta on paljon hyötyä, on kuitenkin tärkeää, ettei testaaja ole liian
lähellä koodia, vaan näkee ohjelmiston kokonaisuutena. Tärkeimpiä ominaisuuksia testaajalle ovat
loputon uteliaisuus, tarkkanäköisyys sekä rohkeus kysyä kysymyksiä. Sosiaaliset taidot ovat myös
paikallaan, toimimmehan kuitenkin alalla, jossa kerromme ihmisille työksemme huonoja uutisia.

Olennainen osa testiautomatisoijan työtä on myös se, että hän osaa ”kiertää” kehittäjän tekemät
jännät ratkaisut ja automatisoida silloinkin, kun sitä ei ole tehty helpoksi. Tärkeintä on osata kysyä
”mitä jos”. Mitä jos teen näin? Mitä jos tapahtuu noin? Kokeillaan! Näin saadaan aikaan
ohjelmistoja, joita on ilo käyttää ja joista on kaikille hyötyä.

Tuomas Peurakoski
Managing Consultant, Sogeti