Artikkelin on kirjoittanut Maaret Pyhäjärvi. Tämä teos on lisensoitu Creative Commons Nimeä-Epäkaupallinen 4.0 Kansainvälinen -käyttöluvalla.
Creative Commons -käyttölupa

 

Ohjelmisto- ja järjestelmäkehitystyö on tietotyötä, jota tekevät ihmiset. Ja meitä ihmisiä on moneksi. Osaamme eri asioita, osaamme yhdistellä asioita eri tavoilla, ajattelemme eri tavoilla ja olemme kiinnostuneita eri asioista. Moninaisuus on vahvuus työssä, jossa muutetaan ajatuksia ohjelmistoiksi. Osaamisemme ovat kertyneet oppimalla: esimerkeistä, yrityksestä ja erehdyksestä, teorian käytäntöön soveltamisesta. Jokainen päivä tuo mukanaan mahdollisuuden oppia lisää. Kiinnostusten, jopa taipumusten, pohjalta ihmiset aloittavat opiskelunsa eri puolilta moninaista palettia. Aika ja oppimiskyvykkyys harvoin riittää kaikkeen mahdolliseen, vaan teemme valintoja.

Nämä valinnat, tahallaan tai puolihuolimattomasti tehdyt, saattavat olla hyvinkin määrittäviä. Ne määrittävät että joistakin meistä tulee testaajia. Joistakin meistä tulee kehittäjiä. Joistakin meistä tulee liiketoiminta-asiantuntijoita. Meitä kaikkia yhdistää se että tuotamme yhdessä, yhteistyössä, ajatuksistamme ohjelmistoja. Ja että juuri kukaan meistä ei ehdi, eikä usein osaakaan, tehdä kokonaisuutta yksin.

Testaus ohjelmistoprojekteissa – palaute – on liian tärkeää jätettäväksi vain asiaan erikoistuneen testausammattilaisen hoidettavaksi. Nopea palaute, saatavilla heti toteutuksen tai muutoksen jälkeen kehittäjän omasta testaamisesta, auttaa reagoimaan asiaan pienemmässä mittakaavassa kuluttaen vähemmän eri osapuolien aikaa. Toinen silmäpari, joka ajattelee samaa asiaa hieman erilaisesta kulmasta, voi huomata ongelmia, joiden löytäminen on kehittäjälle vaikeaa tai työlästä. Kehittäjät ja testaajat parhaimmillaan toimivat työpareina. Testaus tuottaa tietoa laadusta, joka ei muutu reagoimatta palautteeseen.

Tarkastelemme seuraavaksi kahta kehittäjä-testaaja -työparia. Tarinat ovat kuvitteellisia, mutta tarinan yksityiskohdat perustuvat todelliseen projektikokemukseen. Tarinoiden testaaja on sama henkilö, jonka työn sisältö muuttuu merkittävässä määrin työparista riippuen. Molempien tarinoiden henkilöt ovat ohjelmistokehitykseen osallistumisvuosissa kokeneita konkareita.

Tarina 1

Viikkopalaverissa puhuttiin uudesta ominaisuudesta, joka on valmistumassa. Toisen silmäparin tuominen ominaisuutta tarkastelemaan tuntuu järkevältä tällä viikolla – kunhan vielä saadaan nämä pari asiaa viimeisteltyä. Tekemisestä ja ajankäytöstä sopimista ohjaa se että tiimissä on selkeästi useampia kehittäjiä kuin testaajia. Niinpä ominaisuudesta on keskusteltu ja sen rajoitteita työparina yhdessä ideoitu ennenkin, mutta testauksen hoitaminen tähän saakka on hoitunut kehittäjän toimesta. Kehittäjän testauksen tuloksena on syntynyt jonkin verran – aika reilustikin – testiautomaatiota. Osa testeistä on yksikkötestejä, osa taas testaa toimintoa enemmän rajapintojen kautta.

Keskiviikko-iltapäivänä kehittäjä huikkaa testaajalle, että sai laitettua versionhallintaan sisään version, jota kannattaisi lähteä testaamaan. Työpari pyöräyttää uuden version testiympäristöön, ja testaaja kaivaa omat aiheeseen liittyvät muistiinpanonsa esiin. Muistiinpanot ovat syntyneet keskusteluista ominaisuuden osalta, ja yhdistyvät yleiseen malliin, jota testaaja on sovelluksen toiminnallisuudesta hahmotellut.

Ensitestit hoituvat yhdessä. Kehittäjä esittelee mitä on toteuttanut ja testaaja ohjaa osaltaan esittelyä mielenkiinnon kohteisiin. Ensikokeilussa yhdessä huomataan joitakin puutteita, jotka kehittäjä ottaa saman tien korjaustyön alle. Mikään ei kuitenkaan estä ominaisuuden jatkokäyttöä, vaikka jokunen havainnoista onkin sen luonteinen että hidastaa tekemistä.

Testaaja jatkaa korjaustyön rinnalla testaamista. Kokemuksiin pohjautuen hän lähtee tarkastelemaan ensin lisäys-muokkaus-poisto -tilanteita sekä uuden ominaisuuden suhdetta muihin jo olemassaoleviin ominaisuuksiin. Ominaisuudesta löytyy monenlaista korjattavaa: vastaavanlaisia toiminnallisuuksia tehdään toisaalla sovelluksessa eri tavalla, valikoidut syötearvot tuottavat vääränlaisia tuloksia, käyttöliittymässä on kirjoitusvirheitä ja yksi osatoiminto, josta valmistelutyössä keskusteltiin näyttäisi puuttuvan toistaiseksi kokonaan.

Testaus-korjaus -kierroksia tehdään ja työ etenee kunnes yhdessä todetaan että jäljellä olevat huomiot eivät ole reagoimisen arvoisia – hyvä että niistä kuitenkin keskusteltiin. Jotkin korjaukset, automaatiotestien olemassaolosta huolimatta, poikivat sivuvaikutuksia testaajan nähtäväksi. Mutta kahvipöydän äärellä jutellessa käy ilmi että oli myös jokunen korjaus, joka tehtiin automaatiotestien tukemana ilman että olisivat ehtineet testaajan silmiin saakka lainkaan.

Yhteistyön kruunaa tuotehallinnasta tullut viesti: toimii hyvin hyväksymistestauksessa mutta jos sitä voisi vielä tälläkin tapaa laajentaa niin toimisi vielä paremmin käyttötarkoitukseensa. Tuotantoa seuraten lokeille ilmestyy yksi uusi virhe, joka korjataan lokitietojen perusteella. Eipä tullut kummankaan mieleen että tuollakin muuttujalla olisi merkitystä ominaisuuden toimintaan. Samalla mietitään että mitä tästä voisi yleisemmin opiksi ottaa.

Sopivan tilaisuuden tullen käydään vielä yhdessä läpi testiautomaatiota suhteessa testauksen aikana löytyneisiin ongelmiin. Testaajan maailmankuvaan keskeisin oppi läpikäynnistä on tietää mitä automaatio tarkemmin kattaa, ja tekemisen aikana löytyy vielä muutamia lisäideoita, jotka testauksesta ennen toimittamista jäivät ulos. Ja ongelmia, joista kukaan ei ole ehtinyt vielä mainita, mutta jotka korjataan yhteisesti tärkeinä pidettyinä asioina. Automaatiotestit laajenevat joukolla uusia testejä, joiden ylläpito jää kehittäjälle.

Tarina 2

Viikkopalaverissa nousee esiin uusi ominaisuus, jota pääsee testaamaan keskiviikkona. Projektipäällikkö tiedustelee kehittäjän oman testauksen tilannetta, ja tiimiläiset kuulevat että alkuviikko vielä tässä hommassa vierähtää, muuten ominaisuus onkin jo valmis. Tiistai-iltapäivänä kehittäjä huikkaa, että on nyt tökkinyt ominaisuutta aikansa ja hänen mielestään se toimii, voisi olla aika antaa ominaisuutta toiselle silmäparille tarkasteluun.

Kehittäjä ja testaaja hoitavat ensitestit yhdessä. Yllättävästi ensihavainto on että peruskäyttötilanteessa on estävä ongelma. Selviää, että ongelma toistuu vain testiympäristössä, josta puuttuu osa tarvittavista palasista. Kun ensimmäinen peruskäyttötilanne saadaan toimimaan, työpäivä onkin päätöksessä ja testaaja jatkaa testausta itsenäisesti seuraavana päivänä.

Testaaja lähtee käymään ominaisuutta läpi ja viettää seuraavan työpäivän lähinnä kirjaten ongelmia. Kehittäjä käy ongelmia läpi ja kertoo korjausten olevan helppoja – testaus sen sijaan on varsin työlästä. Korjauksia tuleekin vauhdilla ja silloin tällöin toimineita asioita menee rikki ja korjataan. Korjaustarpeita nousee testaajalta, joka käyttää ominaisuuteen merkittävässä määrin aikaa, kuten kehittäjäkin korjaamiseen.

Välillä on päiviä, jolloin testaaja testaa muita alueita – osin estävien ongelmien vuoksi, osin sen vuoksi että muut ominaisuudet vaativat huomiota. Tekemisestä ja ajankäytöstä sopimista ohjaa se että tiimissä on selkeästi useampia kehittäjiä kuin testaajia.

Testaus-korjaus -kierroksia tehdään, kunnes yhdessä todetaan että jäljellä olevat huomiot eivät ole reagoimisen arvoisia.

Tämänkin yhteistyön kruunaa tuotehallinnasta tullut viesti: toimii hyvin hyväksymistestauksessa.

Jatkokehittäminen testiautomaation puutteen ja kehittäjän oman testauksen tuloksellisuuden rajoitteiden vuoksi muutoksia tehdään sopivalla tahdilla ehtien sovittaa yhteistyö kokonaisaikatauluun. Taustalla testaaja käy keskusteluja siitä että tällä työmallilla testaajia ei ole riittävästi – vain osa tiimin tuottamista ominaisuuksista voidaan käydä läpi eikä palaute hyväksymistestauksesta ja käytöstä ole pääsääntöisen positiivista. Kaikkiaan on käynyt niin, että testaustaitoja ja -tahtoa omaavammat kehittäjät tiimissä eivät juurikaan saa tukea testaajalta, jonka huomio kuluu keskeisten ominaisuuksien oikea-aikaisen korjailun mahdollistamisessa. Tiimihenki on hyvä, ja töitä tehdään sen puitteissa mikä on mahdollista, jatkuvasti kehittäen. Tunnistettavissa oleva aukko on kuitenkin kehittäjien testausosaamisessa ja -tahdossa.

Tarinoiden opetus?

Ylläolevista tarinoista voi lukea monenkinlaista opetusta.

  1. Testaajan työkentän laajuus on suoraan suhteessa kehittäjän kykyyn kattaa osansa testauksen työkentästä. Tekemätön ja tarpeellinen testaus heijastuu havaintoina, joita esiin nostaessa ei kateta uusia asioita yhtä nopeasti ja tehokkaasti kuin sovelluksella joka pääpiirteissään toimii testatessa.
  2. Testiautomaatio on osa ohjelmistokehitystä, ei testaajan työkalu oman työnsä hoitamiseen. Testiautomaatiolla on merkitystä kun ylläpidetään, muutetaan ja korjataan sovellusta.
  3. Virheiden löytäminen suuressa määrin ei ole hauskaa testaajallekaan. Vaikka tarinassa 2 testaajan rooli onkin merkittävämpi lopputulokseen pääsemisessä, työ on huomattavassa määrin kuluttavampaa. Myös testaajat ymmärtävät kokonaistehokkuuden päälle.
  4. Testausvaiheet eivät ole testausvaiheita, vaan korjausvaiheita. Jos hyvin käy, hyväksymistestaus on testausvaihe, jossa voidaan todeta toiminnallisuuden olevan kunnossa.
  5. Hyvää yhteistyötä on monenlaista. Molemmissa tarinoissa lopputulos on hyvä käyttäjän kannalta. Mutta tarinan 2 osalta – joka on yleisempi kokemani tilanne vielä tänäkin päivänä – on jotakin kehitettävää ennen testaajan testausta tapahtuvan testauksen laadussa.
  6. Testausta pitää tarkastella sekä lyhyellä tähtäimellä (”saadaan tuotantoon nyt”) että pitkällä tähtäimellä (”saadaan korjattuna tuotantoon myöhemminkin”) kustannusnäkökulmasta. Myös vaihtoehtoiskustannus – mitä muuta samalla ajalla olisi voitu saavuttaa – on keskeisiä käsitteitä.
  7. Testausta oppivat kehittäjät vievät omia taitojaan eteenpäin, mutta kaikkien kapasiteetti ja kiinnostukset eivät riitä tähänkin oppimisen ulottuvuuteen.

Yhteistoiminta ja sen säröt

Ylläolevien tarkoiden osalta kehittäjä-testaaja -yhteistyö toimii molemmissa tapauksissa. Kumpikin kehittäjistä ottaa testaajan mielellään työparikseen. Kummankaan osalta ei ole tarvetta todistella että ”se toimii minun koneellani” kun halutaan järjestelmä toimimaan käyttäjille. Kummankaan osalta ei kursoorisesti hylätä tai hyväksytä palautetta keskustelematta sen sisällöistä ja merkityksistä perustuen ”vaatimuksiin” – tai ajoissa keskustelemattomiin yksityiskohtiin. Kummankaan osalta testaajan perusagendalla ei ole virheiden henkilöiminen, eikä tuotantovirheitä henkilöidä yhtään sen enempää testauksen puutteisiin – ne ovat yhteisen oppimisen paikka.

Molemminpuolinen huomiointi ja kunnioitus ei aina ole odotettavissa oleva tilanne. Yhteistoiminnan ongelmat heijastuvat testauksen tekemiseen. Kilpailuasetelma, mahdollisesti ulkoisten mittarien tuomana, ei helpota tilannetta.

Testaajat tuottavat palvelua laatutiedon empiirisen keräämisen palvelua. Teoria (”näin sen pitäisi toimia” ja käytäntö (”kokeilin, näin se toimii”) ovat molemmat tärkeitä.  Testaus ei ole kehittämistä helpompi taito, vaan se on erilainen.

Yhteistoimintaa parhaimmillaan voi olla, jos molemmat osaamiset, testaus ja kehittäminen, löytyvät samasta henkilöstä. Tunnen monta erinomaisesti testaavaa kehittäjää, mutta ainakin minun kokemukseni on, että testaajana pystyn heidän rinnallaan auttamaan tuottavuudessa – saamme yhdessä asioita tehtyä tehokkaammin.