lauantai 6. syyskuuta 2014

Testaaja - koodarin vihollinen vai puolustaja?

Testaajien ja kehittäjien yhteistyö ei ole aina ihan kitkatonta.

Kun testaajan eteen tuodaan jotain valmiiksi väitettyä, jonka testaaminen on hidasta koska koko ajan löytyy raportoitavaa, on haasteellista tuoda löydöksiä esiin tavalla, jota hiukankin herkkähipiäinen kehittäjä ei kokisi osin henkilökohtaisuuksiin menevänä nipottamisena. Aikataulu- ja budjettipaineet kiristävät molempien pinnaa, samoin kaikenlaiset "tyhmät" virheet.

Erityisesti kun kyse on valmisohjelmistoon tehtävistä muutoksista, vastaan voi myös tulla vanhaan koodiin liittyviä ongelmia, joiden kiertämisen haasteellisuus siirtää helposti keskustelun korjaustavan etsinnästä bugin merkityksen vähäisyyden perusteluun. Näissä tilanteissa osapuolten voi olla vaikea nähdä tekevänsä yhteistyötä, ennemminkin tuntemukset molemmin puolin risteilevät ärtymyksessä, miksi muutenkin niukkaa aikaa on käytettävä johonkin näin turhauttavaan.

Testaajan tehtävä ei kuitenkaan ole mollata kehittäjää väärin tehdystä työstä, vaan auttaa tätä tekemään työnsä hyvin.

Erityisesti silloin kun testauksesta puhutaan laadunvarmistuksena, testaajan tehtävä on merkittäviä virheitä löytäessään viedä projektin johtoon viestiä, että kehittäjien mahdollisuudet tehdä työnsä hyvin on taattava.

Laatua kun on vaikea saada aikaan, jos sen tekijöillä ei ole tarpeeksi aikaa, tarpeeksi mahdollisuuksia keskittyä, tai tarpeeksi ohjausta.

Harva koodari tekee ihan vaan piittaamattomuuttaan virheitä, ja kokonaisuuden kannalta edullisinta olisi, jos mahdollisimman moni toimintalogiikkaan liittyvä tai muuten merkittävä virhe jäisi kiinni jo silloin kun niitä ollaan kirjoittamassa.

Tässä mielessä olisi myös hienoa, jos testausta ei nähtäisi vain valmiin tuotteen toiminnan verifiointina.

Testaaja voi auttaa ehkäisemään virheitä mm. katselmoimalla määritys- ja suunnitteludokumentteja, esittämällä kysymyksiä sprinttipalavereissa, keskustelemalla rakenteilla olevasta toiminnallisuudesta kehittäjien kanssa, käymällä kehittäjän kanssa demoluonteisesti läpi toteutettua toiminnallisuutta, ja testaamalla hyvinkin keskeneräistä (kunhan hänellä on tieto siitä, mitä voi testata ja minkä ei ole tarkoituskaan vielä toimia). Tärkeää on löytää yhteinen tavoite tekemiselle.

Laatu ei parane testaamalla, vaan tekemällä paremmin.

Ei kommentteja :

Lähetä kommentti