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

Ketterä testaus on asia josta tuntuu olevan yhtä monta määritelmää kuin määrittelijääkin. Kuten tietysti ketteryydestä yleensäkin. Aktiivisena Agile Finland ry:n aktiivina olen löytänyt samanmielisiä ketteryyden laajuuden tulkitsijoita. Ohjelmistokehitys tietotyönä, lyhyiden syklien tärkeys palautteena oppimiselle, kaikkien tekijöiden onnellisuus ja toimiva yhteistyö keskinäisessä kunnioituksessa, hyväntahtoisuus, siilojen purkaminen, win-win -ajattelu ja onnistunut liiketoiminta menestyksekkaine yrityksineen kuuluvat kaikki ketteryyteen. Ketteryys ei ole vain ohjelmistokehityksen erityisoikeus, vaan ihania tarinoita ketterien ajatusmallien hyödyksi olemisesta löytyy yhtä lailla vaikka päiväkodeista. Puretaan vanhan tyyppisiä rakenteita ja luodaan tilalle uusia.

Lähiaikojen lempioivallukseni ketterästä testauksesta tiivistyy vapaamuotoisesti lainaten Scott Barberia (tai Michael Boltonia, joka asiaa on popularisoinut):

Testing is Testing, Agile is Context.

Testaus on siis testausta ja ketterää testausta ei ole. Mutta silti, onhan testauksen maailma aivan eri näköinen ketteryyden aikakaudella kuin ennen sitä. Ketteryys on paras asia mikä testaukselle on koskaan tapahtunut. Ketteryys tuo testauksen – palautteen – keskiöön. Ja muistuttaa että palautteen viivästyminen kuukausilla tai vuosilla ei ole enää hyväksyttävää kun haluamme onnistua ohjelmistokehityksessä.

Ketteryys antaa testaukselle mahdollisuuden tapahtua

Ketteryys tuo mukanaan lyhyet syklit, joiden aikana ja tuloksena syntyy toimivaa ohjelmistoa. Aikana ennen ketteryyttä testausta suunniteltiin spekuloiden vuosikaudet, varautuen lyhyeen aikaväliin jolloin varsinainen testaus – ja oppiminen testauksen kautta – tapahtuisi. Toimittiin aina tilanteessa jossa oli kaksi vaihtoehtoa: laadusta tinkiminen tai aikataululupauksesta luopuminen, yleensä varsin isossa mittakaavassa.

Olen elänyt projektiketteryyttä monenlaisissa muodoissa. Olen opetellut erottelemaan mielessäni asioita muoto (form) ja sisältö (substance) -ketteryyteen.

Muoto-ketteryys on  usein jokin prosessi ja resepti, johon kuuluu vaikka päivittäiset tapaamiset, käyttäjätarinat ja laajamittainen testauksen automatisointi, mutta jossa ihmiset eivät ole onnellisia ja tuottavuudessa parhaimmillaan. Usein katsaukset tehtyyn, retrospektiivit, muodostavat rituaalin, jolla tilanne ei oikeasti parane kun haastekohtiin ei etsitä tai löydetä ratkaisuja. Tehdään Scrumia, koska se on hyvä. Inhotaan Scrumia, koska ollaan kuultu että Kanban on parempi ja tehdään sitä. Tai tehdään SAfe:a (Scaled Agile Framework) koska sekä Scrum että Kanban ovat pikkutiimeille. Toiminnan muodossa on ketteriin menetelmiin liittyviä reseptejä – testauksen osalta usein automatisoinnin painottuminen – mutta jotain keskeistä puuttuu.

Sisältö-ketteryys lähtee enemmän ihmisistä, ihmisten vahvuuksista ja yhdessä toimimisesta, sen huomioimisesta että erilaisuus on vahvuus. Sisältöasiat ilmenevät usein puhutuilla muodoilla, mutta niiden syntymekanismi on enemmän sisäinen kuin ulkoinen. Tarvetta toimia tietyllä tapaa nousee yhteisellä ymmärryksellä liiketoiminnan tarpeista mutta myös siitä millaisia yksilöitä tiimeihimme kuuluu.

Projektiketteryydessä oppii, että ketteryys ei ole päämäärä, vaan se on matka. Se on jatkuvaa toisen huomioimista ja yritystä erinomaisuuteen muuttuvassa tilanteessa. Mitä pidemmälle pääsee, sitä pidemmälle on kuljettavaa. Ja työ on päivä päivältä motivoivampaa.

Testaajana toimiminen tälläisessä ihmiskeskeisessä kontekstissa on ihanaa. Tasa-arvoista. Palkitsevaa. Kiiteltyä. Mahtavaa suorastaan. Mutta testaus, miten se oikeasti tapahtuu? Puitteiden vuoksi eri lailla, fiksummin, mutta muuten varsin samalla tapaa. Otetaan sovellus ja testatataan sitä monipuolisesti ajatellen.

Ketterät testaajat

Ketteryys tuo mukanaan jatkuvan oppimisen. Kun hyväksyn että jokainen päivä on oppimista, voin keskittyä miettimään mikä osaaminen tiimiäni auttaisi parhaiten eteenpäin. Mitä minä osaan nyt, juuri tänään? Mitä voin oppia helposti, mikä vaatii enemmän aikaa ja energiaa? Kaikki eivät osaa testata: nähdä virheitä, käyttää ohjelmistoa pikakelauksella monipuolisesti virheitä paljastaakseen. Automatisoidessa on tärkeää testata oikeita asioita, emme halua virheiden menevän ohi toteuttamistamme tarkistuksista. Jos ongelmaa on, se pitäisi huomata. Jatkuva oppiminen ei poista sitä tosiasiaa että ihmisen kyky oppia on rajallinen, vanhat osaamiset käyttämättöminä happanevat eivätkä palaa kivuttomasti käyttöön vuosien ruostumisen jälkeen. Jos yrittää liian montaa asiaa kerralla, ei saa valmiiksi mitään. On priorisoitava, tehtävä valintoja.

Ajan myötä avoimella mielellä pääsee tilanteeseen, jossa ”testaaja” yksilössä yhdistyy kyky tuottaa testikoodia ja testata löytäen virheitä, kenties jopa tuottaa tuotantokoodia. Ja vähitellen testaaja/kehittäjä -eroa ei ole. Mutta niin kauan kuin olemme ihmisinä rajallisia, voi olla haastavaa osata kaikki tarvittava kerralla. En ainakaan löydä muita selityksiä sille miksi käytännön kokemus on että monelta kehittäjältä toimivana tulevasta ohjelmistosta löytyy suuria määriä ongelmia, jos vain osaa katsoa. Toinen kehittäjä katsoo ja kaikki toimii. Tuodaan erilainen silmäpari, testaaja, ja paljastuu asioita jotka ennen ovat näkyneet vasta tuotannossa.

Kuten aikaan ennen ketteryyttä puhuttiin, testaajat ja kehittäjät ajattelevat eri tavalla. Keskeisin opittava asia ensin on oppia ajattelemaan tavalla joka tuottaa ko. alueen tuloksia. Ajatusmallit eivät kuitenkaan ole ahtaita ja sitovia, vaan niiden tiedostaminen ehkä auttaa meitä myös ulos lokeroistamme.

testaaja-kehittaja

Testaajana tarvitaan erilaista asiantuntemusta, keskitytään mallintamaan järjestelmää eri tavalla, keskitytään ajattelemaan eri tavalla ja kesketään yksitoikkoisuutta ja ristiriitoja – välillä liiankin kanssa. Ihmisten erilaisuus on vahvuus kokonaisuuden onnistumiselle.

Katselen hieman murheissani rekrytointi-ilmoituksia, joissa haetaan ketterää testaajaa, ja keskeinen kuvaus haetulle henkilölle listaa automatisointia – muoto-ketteryyttä. Automatisointi on tärkeää, mutta se ei ole tärkeää yksilölle vaan tiimille. Voi olla että tiimi on ketteryyden matkallaan jo kohdassa, jossa jokainen tiimiläinen osaa tasapäisesti tuottaa tuotantokoodia, testikoodia ja testata tuloksellisesti ilman automaatiota ja tiimiin haetaan yhtä superosaajaa lisää. Tai voi olla että tiimi on kohdassa, jossa ei vielä ole ymmärretty lainkaan ilman automaatiota tuloksellisen testaamisen merkitystä tai sitä että yhden idea voi olla toisen toteutus myös testauksessa – tiimi vastaa testauksesta ja käytännön tehtävät tiimi voi osaamistensa puitteissa jakaa monella tapaa.

Ketteryyden uudet vaatimukset testaukselle

Testaus on siis testausta, ja ketteryys on konteksti. Se on konteksti, jossa osaaminen korostuu. Lyhyemmät aikavälit, jatkuva palaute vieden ohjelmistoa tuotantoon vaatii että osaamme ja ennen kaikkea, osaamme oppia. Opimme virheistämme. Opimme sokeista kohdistamme. Ja opimme tekemään luovasti ja rohkeasti uusia virheitä tuottaaksemme innovatiivisia sisältöjä.

Testauskursseista edelleen varsin harvalla testataan. Opetan itsekin kursseja, joissa opetan mitä kaikkea testaajan elämään tarinoina mahtuu. Myös tarinoista oppii. Mutta testaamista pitää harjoitella. Testaamista pitää tehdä. Pitää ottaa erilaisia ohjelmistoja, erilaisia materiaaleja ja lähteä selvittämään mikä toimii ja mikä ei, onko ongelmia.

Ketteryys kontekstina vähentää entisestään perinteisten testauskurssien – prosessikurssien – merkitystä. Ei enää suuria suunnitelmia, vuosien valmisteluja ja lyhyttä testausaikaa suojattavana. Mutta ketteryys kontekstina myös nostaa testaussisältöä opettavien testauskurssien merkitystä. Tiimeihin ei enää helposti oteta ”testaajaa” joka opettelee itsekseen ajattelemaan siten että tuottaa hyötyjä. Junioreilta pyydetään nykyään ensimmäisenä automaatiota ja uusien hyvien testaajien syntymekanismi katoaa kehittäjän ajatusmalliin opiskellessa.

Ensimmäinen asia johon pitäisi oppia on selittää esimerkein mitä testaus oikeasti on. Mitä se on aina ollut. Ja miksi onnistuneet ohjelmistoprojektit eivät päästä sitä osaamista katoamaan vaan tekevät siitä koko tiimin omaisuutta. Testaus ei ole taikaa ja salatiedettä. Prosessilaatikkokuvien mukanaan tuoma etäisyys ja mystifiointi eivät auta. Keskitytään kuvaamaan mitä testatessa oikeasti tapahtuu, ketterän ohjelmistokehityksen eduksi.