Miksi kukaan haluaisi testaajaksi?

Vahingossa, lienee vastaus kun kysytään, miten joku on päätynyt testaajaksi. Olen tehnyt testaus- ja 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ä.

 

Teksti: Tuomas Peurakoski, Managing Consultant, Sogeti