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.

Kehittäjät Marsista, testaajat Venuksesta

Pari vuotta sitten osallistuin testaajana poikkeuksellisen haasteelliseen projektiin, jossa bugipingiksen pahimpina aikoina projektia tekevät koodarit eivät voineet irvistelemättä tulla kanssani samaan hissiin. Kun projektin tilanne rauhoittui, minut kutsuttiin kakulle, varoittaen toki että tarjolla olevat herkut saattavat olla myrkytettyjä.

Tapaus tuli taas mieleen, kun osallistuin keskusteluun, jossa kehittäjät kertoivat käsityksensä luomustensa sisäisestä kauneudesta ja testaajien pinnallisesta tavasta löytää aina jotain valittamista.

Optimistina uskon että nämä jutut esitettiin kaikki vähän pilke silmäkulmassa (ja niitä voi joskus jopa ottaa jonkinlaisena kehuna) mutta jotain ne kuitenkin kertovat testaajan ja kehittäjän välisen suhteen kompleksisuudesta.

Kehittäjä on se joka luo, ja sitten tulee testaaja ja lyttää lopputuloksen maanrakoon (ehkä jopa nauraa sille hieman, anteeksi vaan). Ymmärrettävästi kehittäjän voi joskus olla vaikeaa suhtautua asiaan niin, että me teemme tässä yhteistyötä, kun oma osa on se tekeminen ja toisen osa on pelkkä virheistä nipottaminen. Sitä kuvittelee saaneensa jotain valmiiksi, kunnes seuraavana päivänä edessä on kymmenien kohtien lista ongelmista, joiden syyt pitäisi etsiä ja korjata.

Ehkä jollain tavalla tilanne tuo mieleen 80-luvun stereotyyppiset parisuhdesketsit, joissa mies on se eteenpäinvievä järjen ääni, kun taas nainen esittää kohtuuttomia vaatimuksia eikä ole ikinä tyytyväinen.

Vertauksen tekee entistäkin herkullisemmaksi se, että siinä missä kehittäjistä valitettavan harvat ovat naisia, testaajien joukossa taas miehet ovat yllättävän harvinaisia.

Testaajan ammattitaidon keskeisimpiä puolia onkin palautteen antaminen kehittäjille tavalla, joka kannustaa yhteistyön ilmapiiriä. Täysin asiallinenkin palaute saatetaan ottaa henkilökohtaisesti (vaikka kuinka ollaan rationaalisia miehiä!) jos se esitetään väärin. Riippuu myös henkilöstä, voiko tunnelmaa esimerkiksi keventää vai kiristää huumorilla tai kehumalla onnistumisia ("hei, kolme bugia oli sentään ihan oikeasti korjaantunut!"), tai vaikuttaako puhtaan asiallinen palaute tylyltä. Toiset arvostavat mahdollisimman rautalangasta väännettyjä bugikuvauksia ja korjausehdotuksia, toiset haluavat pitää asioiden selvittelyt ja suunnittelut enemmän omana reviirinään.

Siksi testaajalle on tärkeää saada tavata kasvokkain niitä ihmisiä, joiden kanssa tekee töitä. Se ei yleensä ole välttämätöntä projekteihin liittyvän informaation välittämisen kannalta (vaikka usein auttaakin myös siinä), mutta se auttaa ymmärtämään niin kehittäjien kuin projektipäälliköidenkin persoonallisuuksia, sekä antamaan myös näille kuvaa testaajasta ihmisenä eikä pelkkänä bugiraportoijana. Tämä helpottaa yhteistyön sujumista suuresti.

Isossa yrityksessä näiden tapaamismahdollisuuksien järjestäminen voi olla haasteellista. Eri toimipisteissä työskentelevät ihmiset eivät kenties koskaan pääse työnsä puitteissa tapaamaan toisiaan, ja jos toimipiste on kovin iso, sen sisälläkin tapaaminen voi olla yllättävän harvinaista. Silloin on tärkeää, että edes joskus järjestetään koulutus-, kehitys- ja virkistyspäiviä, joiden lomaan voi ujuttaa aikaa siihen, että käy tutustumassa ihmisiin, joiden kanssa tekee töitä. Erilaiset projektien aloitus- ja lopetustapahtumat voivat nekin tarjota tärkeitä tutustumismahdollisuuksia.

Lisäksi sähköinenkin kommunikaatio muuttuu yllättävän paljon inhimillisemmäksi, kun siihen käytetyt sovellukset osaavat näyttää toisen osapuolen valokuvan.

Mistä laatu tulee?

Testaajan työ on laadunvarmistusta. Joskus vastaan tulee käsitystä, että testaajan mukaan ottaminen takaisi lopputuloksen laadun.

Näin ei kuitenkaan ole. Testaajan tehtävä on laadun mittaaminen ja arviointi, sen parantaminen taas on pohjimmiltaan ihan muiden heiniä.

Laatu ei muutenkaan ole erillinen palikka, jonka voisi lisätä projektiin ihan vain jonkin dokumentin tai yksittäisen henkilön muodossa. Laatu on kaikkien yhteinen asia.

Laadun syntyminen vaatii tarkoituksenmukaista määritystä ja suunnittelua. Nykymaailmassa käytettävyys ja visuaalinen miellyttävyys ovat keskeisessä asemassa laadun kokemisessa, mutta tärkeää on tietenkin myös se että tuote vastaa toiminnallisuuksiltaan käyttäjien tarpeilta.

Laadun tuottamista helpottaa mahdollisuus seurata tarkoituksenmukaista prosessimallia, hyödyntäen sen tarjoamia työvälineitä.

Testausosaamisesta on apua laadun tuottamisessa niin järjestelmän määrittelijöille, suunnittelijoille kuin toteuttajille. Oma etunsa on kuitenkin myös siitä, että testaajalla ei ole vastuuta minkään näiden osa-alueiden tekemisestä. Näin siksi, että ihminen on sokea omille virheilleen, eikä testausosaaminen itsessään suojele ihmistä erehdyksiltä. Sen sijaan testausosaaminen antaa välineitä sen arviointiin, antaako määritys riittävät tiedot ohjelmiston toteuttamiseen tai vastaako toteutus määritystä.

Keskeisimpään kysymykseen, eli vastaako järjestelmä asiakkaan tarpeita, testaus voi vastata vain silloin kun asiakas itse testaa. Toimittajan testaajalla harvoin on mahdollisuutta verrata määritystä asiakkaan tarpeisiin, koska hän ei osallistu määrityksen tekemiseen eikä siksi pääse käsiksi tietoon joka voisi osoittaa määrityksen puutteet tarpeisiin nähden.

Erityisesti isojen asiakasorganisaatioiden kanssa työskennellessä ongelma on myös se, ettei asiakkaankaan projektiryhmällä välttämättä ole riittävää tietoa kaikkien tulevien käyttäjien tarpeista.

Lisäksi järjestelmän määrittäminen on helposti liian abstraktia henkilölle, joka ei ole määritysammattilainen. Todelliset tarpeet saattavat tulla tästä syystä esiin vasta testausvaiheessa.

Tämä nostaa haasteeksi sellaisten työvälineiden ja työskentelytapojen löytämisen, jotka konkretisoivat, mistä projektissa on kysymys.

Erilaiset demoympäristöt tai vaikka paperille hahmoteltu käyttöliittymä jota saa ihan itse "klikata" voivat auttaa konkretian luomisessa. Ketterät menetelmät taas antavat mahdollisuuden tarkentaa määrittelyä sitä mukaa kuin asiat konkretisoituvat.

Joskus voi olla myös tarpeen opettaa asiakasta testaamaan, tai esimerkiksi kysyä, pääsevätkö kaikkien tulevien käyttäjäryhmien edustajat arvioimaan määrityksen onnistumista.