Blogi: Ketterä testaus

Perinteisesti testaus on ollut viimeinen vaihe järjestelmän kehityksessä ennen valmistumista. Lähtökohtaisesti se ei siis ole voinut tapahtua kovinkaan ketterästi koska kattava testaus tarvitsee toimivan version koko järjestelmästä.

Uudet kehitysmallit kuitenkin kyseenalaistavat tätä ajattelua, ja harvassa projektissa on enää mahdollisuutta varata testaukseen riittävä aika ja resurssit projektin loppuvaiheeseen. Tarvitsemme siis ehdottomasti testausta pitkin matkaa, mutta käytännössä siinä on kuitenkin erilaisia haasteita.

Ketterän testauksen haasteita

Muuttuvat vaatimukset

Kattava ja laadukas järjestelmän testaus edellyttää riittävän tarkkoja määrittelyitä, joiden pohjalta testitapaukset ja mahdollinen testiautomaatio rakennetaan. Ketterässä kehityksessä vaatimukset kuitenkin tarkentuvat tai jopa muuttuvat matkan varrella. Käyttäjätarinat ovat harvoin projektin alkuvaiheessa riittävän tarkkoja kaikkien testitapausten määrittelyä varten. Sprinttien valmistumisen ja katselmoinnin myötä tiimin näkemys ratkaisusta muuttuu tai vähintään tarkentuu ja sitä kautta testejä tulee tarkentaa projektin edetessä.

Testausasiantuntijat onkin syytä ottaa mukaan tärkeisiin kokouksiin, kuten sprintin suunnitteluun ja katselmointiin. Ja on tärkeää että he ymmärtävät sekä asiakkaalle tärkeimmät ominaisuudet että ei-toiminnalliset vaatimukset (kuten tietoturvan) ja osaavat kohdistaa testauksen panokset näihin. Mutta heidän roolinsa ei enää ole suorittaa kaikkea testausta.

Sprinttien testaus

Kehitystiimi toteuttaa tuotteeseen uutta toiminnallisuutta jokaisessa sprintissä viikon-kahden välein. Miten nämä saadaan testattua kattavasti niin, että tiimi voi luottavaisesti demonstroida uusia toimintoja? Tämä onkin keskeinen kysymys, jota kannattaa pohtia jo ennen kuin projekti on käynnissä.

Ketterän testauksen periaatteiden mukaan koko tiimi testaa ja valvoo laatua aina kun tuotoksia syntyy. Kehittäjät tekevät yksikkötestit ennen koodauksen aloittamista ja testaavat tarinat niiden valmistuttua. Ihanteellisesti näiden tulisi olla mahdollisimman pitkälle automatisoitu. Tuoteomistaja (Product Owner) määrittelee käyttäjätarinoille hyväksymiskriteerit, ja myös testaa niiden toteutumisen kun kyseinen tarina on toteutettu. Asiakas tekee hyväksymistestauksen kun sopiva julkaisu on valmiina tuotantoympäristössä.

Testaustiimin laajempi rooli

Kun ketterässä kehittämisessä koko tiimi on vastuussa laadusta, perinteisen testaustiimiin (tai paremminkin testausasiantuntijoiden) rooli on hyvin erilainen. Heidän tehtävänsä on ennen kaikkea tukea muuta tiimiä, niin että testaus voi edetä muun kehittämisen mukana. Käytännössä tähän voi kuulua esimerkiksi:

• Testausnäkökulman (hyväksyntäkriteerit) edistäminen ja varmistaminen käyttäjätarinoiden kirjoittamisessa
• Testiautomaation ja muiden testausvälineiden käyttöönotto ja tuki
• Muun tiimin avustaminen laadunvarmistamiseen liittyvissä tehtävissä

Tehokas testaus ja sen automaatio edellyttää tänä päivänä vahvaa osaamista sekä siihen käytettävistä välineistä että testattavasta järjestelmästä. Jos esimerkiksi järjestelmiin rakennetaan uusia rajapintoja, tulisi nämä testata erikseen eikä vain niitä käyttävien sovellusten kautta.

Riittävää osaamista ei kuitenkaan välttämättä kaikilla kehittäjillä tai tuoteomistajilla ole, ja testaajien apu on tällöin kullan arvoinen. Tämä pitää myös muistaa kun tiimejä resurssoidaan, valitettavan usein käytännössä testausosaaminen on pahasti aliedustettuna.

Automaation merkitys

Miksi automaatio on tärkeää ketterässä testauksessa? Vastaus on lopulta varsin yksinkertainen. Iteratiivinen kehitys tuottaa uusia toiminnallisuuksia tietyn perustan päälle, joka voi kasvaa joka iteraatiossa, mutta on (yleensä) muuttumaton. Olisi tärkeätä, että tähän perustaan kohdistuvat testit saataisiin automatisoitua mahdollisimman pitkälle ja suoritettua kaikkien tulevien iteraatioiden aikana regressiotesteinä.

Mikäli automaatiota ei saada rakennettua, tarvittavan testauksen määrä kasvaa kohtuuttoman suureksi kun uutta toiminnallisuutta on testattava tarkkaan, mutta perustakin on testattava, jotta varmistutaan että muutokset eivät ole vaikuttaneet sen ulkoiseen toimintaan. Kannattaa myös muistaa, että ketterään kehittämiseen usien kuuluva refaktorointi lähtökohtaisesti lisää regressiotestauksen tarvetta.