Blogi: Scrum, Test Managerin painajainen?

Ketteryys on päivän sana. Pitää joustaa ja olla valmiina jatkuviin muutoksiin. Tässä artikkelissani en edes pyri tarjoamaan ratkaisuja niihin kaikkiin ongelmiin, joita ketteryydestä saattaa aiheutua, vaan pikemminkin tuomaan esiin mahdollisia toiminnallisen testauksen ongelmakohtia, jotta niihin osattaisiin oikeasti myös testauksen näkövinkkelistä varautua.
Mitä vasten testaus tapahtuu?
Perinteisessä testauksessa puhutaan käyttötapauksista, jotka puretaan auki testitapauksiksi. Näin testauksesta jää myös jälki, mitä on täsmälleen ottaen testattu, mitä arvojoukkoja on käytetty, mitkä ovat olleet testauksen tulokset, jne. Ketterässä testauksessa testauksen käytettävissä on pyrähdysten (sprint) tehtävälistalta (backlog) poimitut, kyseisen pyrähdyksen toteuttamat käyttäjätarinat.

Nuo vastaavat melko 1:1 perinteisiä käyttötapauksia, mutta niitä ei puretakaan enää määrämuotoisiksi testitapauksiksi, vaan annetaan testaajalle vapaammat kädet tutkivaan, ketterään testaamiseen. Testaaja siis omaan intuitioonsa ja kokemukseensa pohjautuen keskittyy ohjelmiston jonkin tietyn osa-alueen läpikäyntiin ilman varsinaista toimintojensa ohjausta. Koska ohjausta ei ole ennalta määritelty, pitää testaajan pitää päiväkirjaa (test log), mitä hän on täsmälleen ottaen tehnyt. Tämä on ainoa keino jälkeenpäin selvittää mitä on tehty. Ongelma korostuu erityisesti, jos projekteja toteutetaan tavoite- tai jopa kiinteähintaisina, kenties jopa toimittajan takuuvelvoittein. Tällöin testauksen täsmällinen kirjaus on erityisen kriittistä – onko jokin virhe päässyt testauksen huomaamatta läpi, kenties jo käyttäjätarinassa olevasta virheestä tai ehkä vieläkin kauempaa vai onko kyseessä kokonaan uusi toiminto. Kaikelle tekemiselle kun on hintalappunsa.
Yksikkötestaus ketterässä projektissa
Scrumin määrittelyn mukaan testaajalla ei varsinaisesti ole omaa rooliaan tiimissä, vaan jokainen tiimin jäsen osallistuu omalta osaltaan testaamiseen, mutta tiimissä voi kuitenkin olla myös testauksen erikoisosaaja. Tavoite joka tapauksessa on, että jokaisen pyrähdyksen jälkeen tiimi tuottaisi toimivaa, julkaisukelpoista materiaalia, joka on myös tiimin itsensä jo toimivaksi toteamaa. Julkaisu on tarkoitus esitellä myös asiakkaalle, jotta hekin näkevät mihin suuntaan ollaan menossa ja tarpeen vaatiessa asiakas voi sekä korjata että tarkentaa kehityksen suuntaa tulevissa pyrähdyksissä. Vaan jos moduli toimii, ja vaikka se saadaankin integroiduksi osaksi suurempaa kokonaisuutta, mikä takaa että myös uusi kokonaisuus toimii? Tarvitaan siis myös laajempaa, kehitystiimin ulkopuolista testausta.
Regressiotestaus
Kehittäjille ketteryys voi olla erityisenkin miellyttävä tapa toimia. He saavat koko projektin ajan tehtäväantonsa lyhkäisinä, valmiiksi pieninä palasina ja voivat keskittyä juuri sen toteuttamiseen. Ei; en todellakaan rohkene väittää, että tehtävät silti olisi helppoja, mutta usein on huomattavasti helpompaa hallita pientä osakokonaisuutta kuin suurta järjestelmää. Toisinaan asiakkaan visio projektin lopputuloksesta saattaa olla hieman epämääräinen ja sen auki purkaminen voi olla haastavaa. Yksikkötestauskin on vielä yksinkertaista ja kenties jopa integraatio aikaisemmin tuotettuun on varsin suoraviivainen tehtävä. Vaan entäs regressiotestaus, jo olemassa olleen toiminnallisuuden varmistaminen? Kun pyrähdyksen lopputuloksen pitää olla toimivaa, pitää jollain keinoin varmistaa, että uusi tuotos ei ole rikkonut mitään vanhemmista, jo toteutetuista toiminnoista. Tarvitaan siis regressiotestausta. Mitä pidemmälle projekti etenee, sen enemmän on jo aikaansaadussa tuotoksessa toimintoja ja tarvittava regressiotestauksen määrä kasvaa samassa suhteessa. Jatkuvasti kasvavan testausmäärän hallinta on haastavaa, varsinkin jos projektissa ei Scrumin määritysten mukaan ole pyrähdysten ulkopuolista testausta. Toki asiakkaan voi olettaa testaavan jokaisen pyrähdyksen jälkeen, saavathan he tuotokset heti käyttöönsä, mutta onko se riittävää? Voiko toimittaja ylipäätään velvoittaa asiakasta testaamaan? Toimittajan omankin edun mukaista on siis itse varmistaa tuotteensa toimivuus ennen kuin laittaa leimansa projektin lopputulokseen.
Korjauksen aikataulutus
Kuten aikaisemmin jo todettiin, on melko selvää, että Scrum tarvitsee myös pyrähdyksen ulkopuolisen testauksen, vaikkakaan nyt ei vielä puhuta kuin toiminnallisesta testauksesta. Testauksen työmäärä on kasvaa sitä mukaa kun projekti etenee, tästä syystä testausautomaatio on käytännössä välttämätöntä. Testauksen havaitsemien virheiden korjaamisellekin pitää löytyä aikaa. Houkutus on suuri lisätä korjaukset projektin tehtävälistalle, mutta se ei taida olla niille oikea paikka. Kunkin pyrähdyksen tulisi olla rauhoitettu eli pyrähdyksen alussa tiimi itse on päättänyt, mitä tehtäviä se projektin tehtävälistalta toteuttaa. Toisaalta muutosten tulisi olla tervetulleita, mutta korjaus ja muutos eivät ole sama asia. Ehkä tässä kohtaa tullaan Scrumin projektikohtaisen soveltamisen alueelle. Toiselle projektille sopii hyvinkin, että pyrähdyksen N aikaansaamat korjaustarpeet tulevat mukaan kesken kaiken pyrähdyksen N+1 toteutusta, toisilla kukin pyrähdys on ikään kuin minivesiputous, johon ei kesken kaiken muutoksia tuoda ja näin pyrähdyksen N korjaukset viivästyvät pyrähdykseen N+2 saakka. Tällöin projekti ikään kuin kantaa korjausvelkaa jatkuvasti mukanaan. Tunnetustihan mitä pidempään velka pääsee kasvamaan korkoa korolle, sen kalliimmaksi sen takaisinmaksu tulee. Lopputuotos voi myös olla kahden tai useamman rinnakkaisen tiimin aikaansaannos. Miten voidaan osoittaa korjaustarpeen johtuvan nimenomaan jonkin tietyn tiimin tuottamasta modulista?
Testauksen raportointi
Testauksen hallinnan tulisi kyetä toimittamaan projektin managementille riittävän tarkkoja raportteja testauksen etenemästä, löydettyjen virheiden määristä ja vakavuuksista sekä niiden korjaukseen käytetystä ajasta. Ketterässä testauksessa kun ei ole ennakkoon suunniteltu testausta selkein testitapauksin, on testauksen hallintakin uuden haasteen edessä. Projektin etenemään nojautuen voidaan testauksenkin etenemää rinnastaa, mutta itse testauksestahan tuo ei kerro vielä yhtään mitään. Toisaalta voidaan esittää myös kysymys tarvitaanko sitä? Jos kerran tiimi on itsenäinen, omaa toimintaansa ohjaava älykäs solu, jonka tuotoksilla on vain merkitys, onko sillä lopulta suurtakaan merkitystä miten se on lopputulokseensa päässyt? Lopputulokset voidaan kuitenkin testata yhdessä suuremman kokonaisuuden kanssa ja tarkistaa, että ne toimivat odotusten mukaisesti. Tämä testaus onkin jo testauksen hallinnalle huomattavasti läpinäkyvämpää, raportointikelpoista materiaalia. Vastauksena lyhyesti aiemmin esittämääni kysymykseen: Kyllä on! Emmehän saa unohtaa testauksen jäljitettävyyttä, joten sillä todellakin on merkitystä miten kukin tiimi on testauksensa hoitanut.
Yhteenveto
Ketterät projektit tarvitsevat ketteryyttä myös testaukseen, mutta myös perinteisemmällä testauksella on näissäkin projekteissa yhä oma asemansa. Kehityksessä käytetty Scrum ei millään tavoin poissulje mm. järjestelmä-, tietoturva- tai suorituskykytestauksen tarvetta. Kullekin näistä on yhä oma, tärkeä paikkansa ja perusteltu olemassaolonsa jokaisessa ohjelmistoprojektissa. Ainoa testauksen alalaji, josta Scrumia noudattava ketterä kehitysprojekti voi kenties oikaista, on asiakkaan itsensä suorittama hyväksymistestaus (UAT), sillä onhan asiakas ollut kiinteästi mukana koko kehitysprosessin ajan, jokaisen pyrähdyksen lopputuloksia tarkastelemassa. Sen sijaan ketterä testaus perinteisempien testauksen lähestymistapojen ja -menetelmien rinnalla kykenee löytämään mahdolliset virheet jo varsin tehokkaasti ja on siksi erittäin tervetullut lisä testauksen työkaluihin.
Jari Kaskikallio
Senior Consultant
etunimi.sukunimi@consultor.fi