T Ohjelmistotuotannon seminaari. Agile Processes. XP:n hyväksymistestit

T-76.650 Ohjelmistotuotannon seminaari Agile Processes XP:n hyväksymistestit 15.4.2002 Mikko Pasanen 49159H Tik N mspasane@cc.hut.fi

Tiivistelmä 2 Extreme Programming on kevyt ohjelmistokehityksen metodologia, jonka testauskäytäntö koostuu kahdesta tasosta: yksikkö- ja hyväksymistesteistä. Ohjelmoijien ylläpitämillä ja ajamilla automatisoiduilla yksikkötesteillä pyritään helpottamaan integraatiota ja varmistumaan toteutuksen virheettömyydestä. Hyväksymistestit puolestaan määrittelee asiakas testaajan avustuksella. Hyväksymistesteillä asiakas varmistuu siitä, että haluttu toiminnallisuus löytyy tuotteesta. Hyväksymistestit toimivat myös projektin seurannan ja dokumentoinnin välineenä. V-mallin mukaiseen testaukseen verrattuna XP-testaus tuntuisi tarjoavan tavan parantaa projektiryhmän ja asiakkaan välistä kommunikaatiota. Se pyrkii lisäksi käytäntöjensä avulla välttämään perinteisen testauksen ongelmakohtia kuten riittämätöntä kehityksen aikaista tai matalan tason testausta. Toisaalta V-malliin verrattuna koko XP-testauksen lähestymistapa on erilainen se painottaa toiminnallisuuden löytämistä testauksen kattavuuden sijaan. XP:n hyväksymistesteillä voidaan katsoa olevan joitakin rajoitteita, jotka johtuvat niiden lähestymistavasta. Niiden ei katsota soveltuvan hyvin kriittisten järjestelmien tai laajaa rinnakkaisuutta sisältävien ohjelmistojen testaamiseen. Toisaalta tämäkin riippuu paljon asiakkaan painotuksista ja asiantuntemuksesta. Lisäongelmia hyväksymistestaukseen tuovat sekä projektiryhmän että asiakkaan sitoutuminen noudatettavaan prosessiin. Tietyt XP-käytännöt, kuten yksikkötestaus ja jatkuva integrointi, ovat edellytyksiä hyväksymistestien onnistumiselle. Haasteita aiheuttavat myös asiakkaan kiireisyys ja osaamistaso testauksen suhteen.

Sisällysluettelo 3 1 Johdanto... 4 1.1 Tutkimuksen tausta... 4 1.2 Tutkimusongelma... 4 1.3 Tutkimuksen tavoitteet... 5 1.4 Tutkimuksen laajuus... 5 1.5 Tutkimusmenetelmät... 6 1.6 Raportin rakenne... 6 2 Mitä on extreme Programming?... 6 2.1 Ketterät prosessit... 6 2.2 Historiaa... 7 2.3 XP lyhyesti... 7 2.4 XP:n testauskäytännöt... 9 2.4.1 Yksikkötestit...9 2.4.2 Hyväksymistestit...10 2.5 XP:n roolit hyväksymistestien kannalta... 12 2.5.1 Asiakas...12 2.5.2 Testaaja...12 2.5.3 Ohjelmoija...13 2.6 Nykytilanne... 13 3 Ohjelmistojen testauksen perusteita... 13 3.1 Peruskäsitteitä... 14 3.2 Testauksen V-malli... 14 4 XP-testauksen vertailu V-malliin... 16 4.1 Yhteistyö asiakkaan kanssa... 16 4.2 Lähestymistapa... 17 4.3 Riskialttius... 17 5 XP:n hyväksymistestikäytännön ongelmia... 18 5.1 Tuotteen laatu... 19 5.2 Projektiryhmän XP - prosessi... 20 5.3 Asiakas... 20 6 Yhteenveto...21 7 Lähdeluettelo...23

4 1 Johdanto Extreme Programming eli XP on ketterä ohjelmistojen kehitysmetodologia. Se pyrkii vastaamaan nopeasti muuttuvan ympäristön asettamiin haasteisiin (Beck 2000). Tämä tutkimus keskittyy XP:n hyväksymistestikäytäntöön. 1.1 Tutkimuksen tausta Testaus XP:ssä on jaettu kahteen tasoon. Laajalla automatisoidulla yksikkötestauksella pyritään varmistamaan yksittäisten moduulien toimivuus. Toisen tason muodostavat asiakkaan määrittelemät hyväksymistestit, joiden tarkoitus on auttaa asiakasta arvioimaan tuotteen valmiusastetta. XP:stä on käyty paljon keskustelua viime vuosina, mutta sen hyväksymistesteistä ei ole kirjoitettu kovin paljon. Ne ovat kuitenkin tärkeä osa XP:tä, sillä niitä käytetään osana vaatimusmäärittelyä ja dokumentointia. Etenkin XP-projektin päätösvaiheessa hyväksymistestit ovat tärkeitä, koska niitä pidetään ohjelmiston valmiusasteen mittareina. (Jeffries 2001) Lisäksi XP:tä käsittelevä kirjallisuus on keskittynyt kuvaamaan prosessia vahvasti kehittäjien kannalta ja jättänyt asiakkaan prosessin vähemmälle huomiolle. Usenetin XPkeskusteluissa XP:tä on myös arvosteltu siitä, ettei sitä kehittämässä ole ollut testauksen ammattilaisia. 1.2 Tutkimusongelma XP-projektissa asiakkaan rooli on huomattavasti erilainen kuin perinteisessä

ohjelmistoprojektissa; häneltä odotetaan täysipäiväistä läsnäoloa ja osallistumista 5 projektiin. Tämä tulee ilmi XP:n hyväksymistestikäytännössä, jossa asiakkaan odotetaan aktiivisesti osallistuvan testien määrittelyyn. Tätä voidaan odottaa myös perinteisessä projektissa, mutta se on harvinaista. Tutkimuksen tarkoitus on selvittää, mitä XP:n hyväksymistesteihin kuuluu kirjallisuuden perusteella. 1.3 Tutkimuksen tavoitteet Tutkimuksen tavoitteena on ensiksi selvittää, miten hyväksymistestit on määritelty XPkirjallisuudessa. Toiseksi tarkastellaan sitä, millä tavoin XP-testauskäytännöt eroavat V- mallin mukaisesta testauksesta. Kolmas tavoite on tutkia miten hyväksymistesteihin liittyvät roolit on määritelty kirjallisuudessa ja tarkastella asiakkaan ja projektiryhmän välisen yhteistyön mekanismeja. 1.4 Tutkimuksen laajuus Ensisijaisesti tutkimus keskittyy XP:n hyväksymistestien ymmärtämiseen. Vaikka hyväksymistestit liittyvät läheisesti XP:n suunnittelupeliin, ei siihen puututa yksityiskohtaisella tasolla. Tutkimus ei puutu testien automatisointiin. Testien automatisointi on jo sinänsä niin laaja tutkimusalue, että sen huomioon ottaminen jättäisi XP:n hyväksymistestikäytännön varjoonsa. Niinikään perinteistä testauksen V-mallia noudattelevan testauksen yksityiskohtiin tai eri lähestymistapoihin ei puututa.

1.5 Tutkimusmenetelmät 6 Tutkimus on toteutettu kirjallisuustutkimuksen keinoin. Käytetty materiaali koostuu pitkälti XP-sarjan kirjoista, joiden lisäksi lähteinä on käytetty Cockburnin kirjaa ketteristä metodologioista sekä Polin ym. teosta, joka käsittelee testauksen perusteita. Kirjojen lisäksi materiaalina on haettu akateemisista lehdistä. Materiaali on käyty läpi keskittyen hyväksymistestaukseen ja asiakkaan prosessiin liittyviin seikkoihin. 1.6 Raportin rakenne Paperin loppuosa rakentuu seuraavasti: toisessa luvussa esitellään ketterien prosessien yhteisiä piirteitä, XP:n toimintaa ja sen testauskäytännöt sekä niihin liittyvät roolit. Kolmannessa luvussa käydään läpi ohjelmistojen testauksen peruskäsitteitä sekä testauksen V-mallia. Neljäs luku keskittyy vertaamaan XP:n testauskäytäntöjä V-mallin mukaiseen testaukseen ja viidennessä luvussa pyritään tunnistamaan joitakin ongelmakohtia XP-testauksessa. Paperin lopussa on yhteenveto ja lähdeluettelo. 2 Mitä on extreme Programming? Extreme Programming on nk. ketterä prosessi, joka korostaa asiakkaan tyytyväisyyttä ja tiimityötä. Se on tarkoitettu pienikokoisille kehitystiimeille ja soveltuu hyvin tilanteeseen, jossa asiakkaan vaatimukset ovat epäselviä tai ne muuttuvat nopeasti. 2.1 Ketterät prosessit Termi "ketterä prosessi" tulee englannin kielen sanoista "agile process". Ilmaisu ei ole vielä vakiintunut suomen kielessä, mutta tässä paperissa käytetään sitä. Ketteriksi

prosesseiksi kutsutaan ohjelmistotuotannon metodologioita, jotka: 7 painottavat yksilöitä ja näiden välistä kommunikaatiota prosessin ja dokumentaation sijaan, pitävät toimivaa ohjelmistoa merkkinä edistymisestä, korostavat yhteistyötä projektin asiakkaan kanssa ja pitävät olennaisena kykyä vastata muutokseen (Cockburn 2001). Edellä mainitut periaatteet määriteltiin vuonna 2001 nk. "Agile Manifestossa" (mm. Cockburn 2001), joka oli eri ketterien metodologioiden asiantuntijoiden tapaamisen lopputulos. Ketteriksi metodologioiksi lasketaan mm. XP, SCRUM, DSDM, Crystal Methodologies ja FDD. 2.2 Historiaa XP on pitkälti Kent Beckin aikaansaannos. Se on ohjelmistotuotannon metodologia, joka sai alkunsa vuonna 1996 Beckin kokeillessa ideoitaan paremmasta tavasta tuottaa ohjelmistoja eräässä Daimler Chryslerin projektissa. Nykyään Beckin ajatuksia kuvaamaan käytettäisiin ketterän prosessin käsitettä. Hän keräsi vuosien varrella hyväksi kokemansa työtavat yhteen ja muodosti niistä kevyen metodologian. (Beck 2000) 2.3 XP lyhyesti Beck on määritellyt XP:n koostuvan tietyistä käytännöistä. Käytäntöjä on kaikkiaan 12, ja niiden kaikkien soveltamista suositellaan (Beck 2000).

XP-ohjelmistokehitys koostuu ketterille prosesseille tyypillisistä lyhyistä kehitysjaksoista, 8 joiden pituus voi vaihdella yhdestä viikosta pariin kuukauteen. Kunkin jakson alussa projektin asiakas ja projektiryhmä sopivat jakson tavoitteista. Asiakas määrittelee "tarinoita", joiden toteuttamiseen kuluvan ajan projektiryhmä arvioi. Sitten asiakas päättää, mitkä tarinat jaksossa toteutetaan. Lyhyiden kehitysjaksojen ideana on antaa asiakkaalle jatkuvaa palautetta projektin tilasta. Tavoitteena on, että kunkin kehitysjakson lopussa asiakkaalle voidaan esittää jollakin tasolla toimiva tuote. Toteutuksen suunnittelussa ovat yksikkötestit keskeisessä asemassa. XP:n testauskäytännön mukaan ne tulisi kirjoittaa ennen varsinaista koodia, jolloin ne ohjaavat toteutusta. Yksikkötestien tulee myös olla riittävän kattavia, jolloin niistä muodostuu osa projektin dokumentaatiota. XP:n perusajatuksia on toteutuksen pitäminen yksinkertaisena. Toteutuksessa lähdetään toteuttamaan tarinoita yksinkertaisimmalla mahdollisella tavalla, joka voi toimia. Yksinkertaisuuden vaatimusta tuetaan refaktorointi-käytännöllä, joka tarkoittaa jo kirjoitetun koodin muokkausta yksinkertaisempaan suuntaan. Varsinaiseen ohjelmointiin liittyviä käytäntöjä XP:ssä on useita. Näkyvin näistä on pariohjelmointi, jossa yhden koneen ääressä istuu kaksi ohjelmoijaa. Toinen kirjoittaa koodia, toinen tarkkailee kirjoitettua koodia ja ajattelee "strategisesti" (Wake 2002). Kirjoitettu koodi on kollektiivista omaisuutta, jolloin kuka tahansa projektiryhmästä voi muuttaa mitä tahansa koodista. Koodin kääntäminen ja osajärjestelmien integrointi tapahtuu XP:ssä usein, jopa useita kertoja päivässä. Tämä takaa sen, etteivät integroinnille tyypilliset ongelmat kasaudu iteraation loppuun.

Asiakkaan ja projektiryhmän välisen kommunikaation parantamiseksi vaaditaan XP:ssä 9 asiakkaan kokopäiväistä läsnäoloa. Tällöin asiakas on aina paikalla, kun projektiryhmällä on häntä koskeva ongelma, mikä nopeuttaa projektin etenemistä. 2.4 XP:n testauskäytännöt XP:n testauskäytäntö on jaettu kahteen osaan: yksikkö- ja hyväksymistesteihin. Yksikkötestit ovat projektiryhmän ja hyväksymistestit asiakkaan vastuulla. XP:n pariohjelmointikäytännön voisi ajatella kolmanneksi testausmuodoksi, sillä sen voi nähdä eräänä staattisen testauksen muotona. Se on kuin reaaliaikainen koodikatselmus, koska koodin kirjoittajan lisäksi paikalla on jatkuvasti toinen henkilö tarkkailemassa kirjoitettua koodia. XP:n testauskäytäntöjä leimaava seikka on testien kirjoittaminen ennen koodia. Tämä pätee sekä yksikkö- että hyväksymistesteihin. Koska molempia testejä ajetaan usein, niiden automatisoimista suositellaan. Tosin Chryslerin C3 projektissa, jossa XP-käytäntöjä kokeiltiin ensimmäistä kertaa suuressa mittakaavassa, testit pyrittiin julkaisemaan samaan aikaan koodin kanssa (Anderson 1998). Tästä on sittemmin siirrytty testauslähtöisempään ajattelutapaan toteutuksen suunnittelussa. 2.4.1 Yksikkötestit Yksikkötesteillä pyritään varmistamaan moduulitason toteutuksen virheettömyys. Testit kohdistetaan niihin ohjelman osiin, jotka eivät mahdollisesti toimi oikein (Wake 2002, s.129). Kaikkea ei siis testata yksikkötesteillä. Joka tapauksessa yksikkötestit ovat hyvin kattavia ja niitä ajetaan aina, kun ohjelmaa on muokattu. Näin yksikkötestit puolestaan tukevat integraatiotestausta, joka sellaisenaan puuttuu XP:stä.

XP:n yksikkötestejä on vaikea jaotella white box- tai black box -testeihin, sillä niiden 10 toteuttaminen edellyttää kyllä tietoa koodissa käytettävistä rajapinnoista, mutta ei sinänsä tietoa muusta koodista. Koska niitä käytetään ohjaamaan toteutusta, eroavat ne perustavanlaatuisesti perinteisistä yksikkötason testeistä. Koska yksikkötestien määrä suuressa projektissa voi muodostua hyvin suureksi, on niiden automatisointi välttämätöntä. Chryslerin C3-projekti raportoi 3000 yksikkötestistä (Anderson 1998). XP-käytäntöihin kuuluva jatkuva integrointi edellyttää sitä, että testien ajaminen on mahdollisimman helppoa ja että se voi parhaassa tapauksessa tapahtua vain yhtä nappia painamalla. Kirjoitetun (julkaistun) koodin tulee läpäistä aina kaikki yksikkötestit (Beck 2000, s.118). Tämä on olennaista, koska yksikkötestit varmistavat, että koodi toimii oikein. Edellisten iteraatioiden testien tulee myös toimia. 2.4.2 Hyväksymistestit Hyväksymistestit ovat projektin onnistumisen kannalta yksikkötestejä tärkeämpiä (Auer, Miller 2002, s. 233). Tämä johtuu siitä, että toisin kuin yksikkötestit, hyväksymistestit ottavat asiakkaan vaatimukset huomioon: niiden avulla asiakas varmistuu tuotteen oikeellisuudesta ja toimivuudesta. Hyväksymistestit ovat luonteeltaan funktionaalisia black box -testejä. XP:ssä hyväksymistestit määrittelee asiakas mahdollisesti projektiryhmän avulla. Perinteisen testaajan näkökulmasta arvioituna niiden tarkoitukseksi muodostuukin tuotteen kattava testaus käyttäjän näkökulmasta, ei niinkään kaikkien suorituspolkujen

läpikäyminen. (Crispin 2001) 11 Kaikkia projektin hyväksymistestejä ajetaan usein. (Wake 2002, s. 126) ehdottaa testejä ajettavaksi päivittäin, (Jeffries 2001) puolestaan viikoittain. Näin varmistutaan siitä, että edellisten iteraatioiden toteutukset toimivat yhä. Ne ajamalla nähdään myös, miten projekti on edistynyt. Tämä vaatimus edellyttää testien automatisoimista niin pitkälle kuin mahdollista. Edellä mainitussa C3-projektissa asiakkaalla oli projektin lopussa noin 6000 funktionaalista testiä (Anderson 1998). Niiden ajaminen päivittäin manuaalisesti lienee kallista. Hyväksymistestit toimivat XP:ssä tärkeänä projektin seurannan välineenä (Auer, Miller 2002, s. 55, 235). Hyväksymistestien läpäisyarvot ovat suoraan verrannolliset toteutettujen tarinoiden määrään, joten niiden perusteella voidaan arvioida koko tuotteen valmiusastetta. Projektin edetessä nousevat läpäisyarvot lisäävät asiakkaan luottamusta projektiin. XP:ssä varsinainen dokumentointi jää paljolti koodin ja sen kommentoinnin varaan. Tämän lisäksi tärkeän osan XP-dokumentaatiota muodostavat hyväksymistestit. Ne määrittelevät yksityiskohtaisesti, mitä asiakas haluaa tuotteen tekevän. Kun tuote läpäisee testit, kertovat testit, mitä tuote tekee. Näin hyväksymistesteistä tulee osa projektin dokumentaatiota. Hyväksymistestit ovatkin yksi XP:n tavoista kommunikoida asiakkaan vaatimukset ohjelmoijille. Toisin kuin yksikkötestien, hyväksymistestien tulosten ei odoteta olevan jatkuvasti 100% läpäisyn tasolla (Beck 2000, s.118). Tämä on luonnollista, koska tarinoiden toteuttamisessa on kyse moduuleja suuremmista kokonaisuuksista. Toiminnallisuuden

toteuttamiselle on varattu aikaa yhden iteraation verran, joten iteraation lopussa tuote 12 optimitapauksessa läpäisee kaikki hyväksymistestit. 2.5 XP:n roolit hyväksymistestien kannalta XP määrittelee roolit projektiin osallistuville henkilöille. Hyväksymistestien kannalta kaksi roolia ovat olennaisia: asiakas ja testaaja. Asiakas on roolin nimen mukaisesti projektin asiakkaan edustaja. Testaajan rooli puolestaan kuuluu jollekin projektiryhmän jäsenistä, mutta tälle henkilölle voi kuulua myös jokin muu rooli (esim. ohjelmoija). 2.5.1 Asiakas Asiakkaan tehtävä on hyväksymistestien määrittely. Hän määrittelee jokaiselle tarinalle vastaavat hyväksymistestit. Asiakas voi työskennellä projektiryhmän kanssa oppiakseen, minkälaiset testitapaukset ovat hyviä. Asiakas voi saada apua testien määrittelyyn projektiryhmältä. (Beck 2000) (Wake 2002) tarjoaa joitakin lisäyksiä asiakkaan rooliin. Testien määrittelyn lisäksi asiakkaan tehtävänä olisi niiden ajaminen. Lisäksi kaikkien iteraatiossa toteutettavien tarinoiden hyväksymistestit ajettaisiin päivittäin ja niiden tulokset raportoitaisiin projektiryhmälle. 2.5.2 Testaaja Testaajan rooli XP:ssä keskittyy paljolti asiakkaaseen. Testaajan tehtävänä on auttaa asiakasta kirjoittamaan ja valitsemaan hyväksymistestitapauksia. Testaajaa tarvitaan, koska asiakkaalla ei välttämättä ole testaamiseen tarvittavia taitoja. Testaaja muuntaa

asiakkaan testi-ideat oikeiksi, automatisoiduiksi testeiksi ja auttaa myös testien 13 ajamisessa. (Beck 2000) Lisäksi testaaja raportoi testien tuloksista, refaktoroi testejä ja pyrkii ohjaamaan koko projektia oikeaan suuntaan. (Crispin 2001) 2.5.3 Ohjelmoija Ohjelmoijilla ei ole suurta roolia hyväksymistestien suhteen XP-sarjan kirjallisuuden mukaan. Sen sijaan (Crispin 2001) ehdottaa, että testaaja kävisi asiakkaan kanssa määrittämänsä yksikkötestit läpi jonkin projektiryhmän ohjelmoijan kanssa. Tämä sen vuoksi, että jotkin hyväksymistesteistä on mielekkäämpää toteuttaa yksikkötesteinä. Lisäksi Crispin esittää, että myös ohjelmoijat osallistuvat hyväksymistestien automatisointiin. 2.6 Nykytilanne Tällä hetkellä XP-metodologian soveltamisesta käytäntöön ei ole saatavilla kovinkaan paljon kokemusraportteja. XP:stä on kuitenkin keskusteltu paljon viime vuosina ja se on herättänyt mielenkiintoa sekä akateemisissa että kaupallisissa piireissä. Nykyisen käsityksen mukaan XP soveltuu hyvin pienikokoisiin projekteihin. 3 Ohjelmistojen testauksen perusteita Ohjelmistotuotteet eroavat perinteisistä teollisuustuotteista perustavanlaatuisesti. Ne ovat hyvin abstrakteja tuotteita ja niissä olevia vikoja voi olla vaikea havaita. Lisäksi ohjelmistojen täydellinen testaaminen on usein taloudellisesti kannattamatonta, sillä

tyypillisessä ohjelmassa on hyvin suuri määrä erilaisia suorituspolkuja. Koska 14 ohjelmistojen virheettömyyden todistaminen on työlästä, on ohjelmistotestauksen pääpaino virheiden löytämisessä. 3.1 Peruskäsitteitä Ohjelmistojen testaukseen on kaksi lähestymistapaa: black box ja white box -testaus. Black box -testauksella tarkoitetaan testausta tietämättä sitä, miten ohjelma on toteutettu. White box -testauksessa puolestaan tutkitaan ohjelman lähdekoodia ja laaditaan sen perusteella testitapaukset. Näiden lisäksi ohjelmistotestaus voidaan jakaa staattiseen ja dynaamiseen testaukseen. Staattinen testaus ei suorita testattavaa koodia, vaan testaus tapahtuu koodia tutkimalla. Staattista testausta ovat esim. koodikatselmukset ja kääntäjän virheilmoitukset. Dynaamisessa testauksessa koodia suoritetaan. Ohjelmiston kehitysvaiheen aikana joudutaan usein suorittamaan samoja testitapauksia uudestaan. Tätä kutsutaan regressiotestaukseksi ja sitä tehdään sen vuoksi, että koodin muuttaminen yhdessä paikassa voi johtaa odottamattomiin seurauksiin toisessa. Siksi on järkevää suorittaa kaikki olennaiset testitapaukset uudelleen. Tietyntyyppiset testitapaukset voidaan helposti automatisoida. Automatisointi nopeuttaa testien ajamista, ja on hyödyllistä esim. regressiotestausta tehtäessä. 3.2 Testauksen V-malli Perinteisessä ohjelmistotestauksessa testausprosessia kuvaamaan käytetään nk. V- mallia. Malli on esitetty kuvassa 1. Se kytkee testauksen eri tasot ohjelmistokehityksen elinkaareen (Pol, ym. 2002). Malli jakaa testauksen kolmeen tasoon:

hyväksymistesteihin, joiden tarkoitus on varmistaa asiakkaan vaatimusten 15 toteutuminen tuotteessa, systeemitesteihin, jotka kohdistuvat koko järjestelmään, ja yksikkö- ja integraatiotesteihin, joilla pyritään varmistumaan yksittäisten moduulien ja niiden integroinnin virheettömyydestä. Tässä mallissa funktionaalisen määrittelyn validoivat hyväksymis- ja systeemitason testit, teknisen määrittelyn puolestaan yksikkö- ja integraatiotason testit. Malli kuvaa testauksen etenemistä etenkin vesiputousmallin mukaisessa projektissa. Kuva 1. Testauksen V-malli.

4 XP-testauksen vertailu V-malliin 16 XP-tyyppisen testauksen vertaaminen perinteiseen testaustapaan on mielenkiintoista, koska lähestymistavat ovat perustavanlaatuisesti erilaiset. 4.1 Yhteistyö asiakkaan kanssa Asiakkaan ja projektiryhmän välisen yhteistyön mekanismit ovat hyvin erilaiset. Ketterien prosessien testaukselle on tyypillistä, että kommunikaatio asiakkaan kanssa on sujuvaa ja viiveetöntä (Marick 2001). Koska kehitys XP:ssä on muutenkin asiakaslähtöistä, osallistuu tämä myös testaukseen määrittelemällä hyväksymistestit. Perinteisesti testaus on perustunut paljolti määrittelydokumentteihin, joiden pohjalta laaditaan testitapaukset. Yksikkötesteistä huolehtivat organisaation ja projektin koosta riippuen yleensä kehittäjät, muusta testaamisesta erillinen henkilö, tiimi tai muu ulkopuolinen taho. Pienemmissä organisaatiossa eri testauksen vaiheet voivat olla samojen ihmisten suoritettavana, esim. kehittäjät tekevät kaiken testaamisen. Tieto toteuttajien, testaajien ja asiakkaan välillä liikkuu pahimmillaan ainoastaan dokumenttien välityksellä. XP:ssä ei tällaisia dokumentteja ole, vaan ohjelmistoa suunnitellaan pienissä osissa kerrallaan. Lisäksi ei ole olemassa erillisiä testaajia, vaan kaikki osallistuvat testaamiseen joko yksikkö- tai hyväksymistestien parissa. Kehittäjien ja asiakkaan välinen kommunikaatio perustuu siihen, että kaikki työskentelevät samassa huoneessa. XP:ssä vaatimuksien jäljitettävyyttä lähestytään melko kevyesti. Vaatimuksia ei pyritä jäljittämään koodiin asti, vaan riittää että jokaiseen vaatimukseen voidaan yhdistää hyväksymistesti. (Beck, Fowler 2001, s. 49)

4.2 Lähestymistapa 17 Lähestymistapa testauksen kattavuuteen on hieman erilainen perinteisen ja XP-tyyppisen testauksen välillä. Perinteisesti on ajateltu kaiken mahdollisen testaamisen olevan mahdotonta mitä se tietysti onkin ja valittu testauksen painopisteet riskin odotusarvon mukaan. Sen laskemiseen on käytetty esimerkiksi ohjelman osan käyttötiheyttä ja toimimattomuudesta aiheutuvaa haittaa. XP:ssä pyritään kaikkea testaamaan mahdollisimman kattavasti, mutta ei kovin systemaattisesti. Testaus perustuu hyvin pitkälle toiminnallisuuden löytämiseen koodista (Crispin 2001). Koska yksikkötestit toimivat myös määrittelynä kirjoitettavalle koodille, varmistavat ne vain sen, että koodi toteuttaa halutun toiminnallisuuden. Ne eivät siis käy läpi kaikkia mahdollisia suorituspolkuja tms., joilla toiminnan viat voitaisiin havaita. Sama pätee hyväksymistesteihin, joilla asiakas pyrkii varmistumaan siitä, että ohjelmisto vastaa hänen vaatimuksiaan. Tässä suhteessa XP asettaa asiakkaalle paljon vastuuta. Asiakkaan odotetaan priorisoivan testattavat asiat omien tarpeittensa mukaan. Vikojen korjaamisessa lähestymistavat ovat samantyyppiset. Perinteisesti havaitut viat priorisoidaan ja niistä korjataan tärkeimmät. XP:ssä vikojen korjaaminen luetaan "tarinoiden" joukkoon, jonka asiakas voi valita toteutettavaksi. 4.3 Riskialttius Perinteisessä testauksessa riskialttiutta lisääviä tekijöitä ovat muun muassa: kokemattomat kehittäjät, käyttäjien riittämätön osallistuminen, riittämätön laadunvarmistus kehityksen aikana, riittämätön matalan tason testien laatu, uudet kehitystyökalut tai - ympäristöt, suuret kehitystiimit, huono kommunikaatio kehittäjien välillä sekä ristiriitaiset asiakasvaatimukset (Pol ym. 2002, s. 137). Useat XP-käytännöt tuntuvat puuttuvan

18 suoraan näihin ongelmiin: XP:n testausmalli ja XP sinänsä korostavat jatkuvaa testausta yksikkötestauskäytännön ja päivittäin ajettavien hyväksymistestien muodossa; yksikkötestien kirjoittaminen ennen koodia oletettavasti parantaa näiden testien laatua; XP:ssä kehitystiimi on pieni ja työskentelee samassa huoneessa, näin ollen sen sisäinen kommunikaatiokyky on hyvä. Välillisesti pariohjelmoinnin käyttäminen alentaa kokemattomien kehittäjien aiheuttamaa riskiä, jos heidän annetaan työskennellä kokeneiden kehittäjien kanssa. Lisäksi ristiriitaisiin asiakasvaatimuksiin pyritään vaikuttamaan vaatimalla yhdeltä asiakasorganisaation edustajalta kokopäiväistä läsnäoloa, jolloin tämän on otettava esille nouseviin ongelmiin kantaa. Toisaalta XP-tyylisestä testauksesta aiheutuu joukko uusia riskejä, jotka saattavat olla aivan yhtä haitallisia projektin kannalta. Tällaisia riskejä ovat muun muassa se, että yksikkötestikäytäntöä ei omaksuta, projektin asiakas on liian kiireinen osallistuakseen testaukseen jne. Se että yksikkötestauskäytäntöä ei omaksuta, on riski myös perinteisessä testauksessa, mutta XP:ssä tämä riski on suurempi sillä koko testausmalli rakentuu yksikkötestien noudattamisen pohjalle. 5 XP:n hyväksymistestikäytännön ongelmia Vaikka kokemusraportteja XP:n käytöstä on julkaistu melko vähän, on XP-testauksen hyväksymistestikäytännössä tunnistettavissa joitakin ongelmakohtia. Näiden ongelmien käsittely on tässä jaettu tuotteen laatuun, XP-prosessiin ja projektin asiakkaaseen liittyviin kappaleisiin.

5.1 Tuotteen laatu 19 XP-testauksessa asiakkaiden kanssa luodut testit keskittyvät toiminnallisuuden, eivät bugien löytämiseen tuotteesta (Crispin 2001). Tämän lähestymistavan vuoksi on tärkeää, ettei asiakkaalla ole ylimitoitettuja vaatimuksia saavutetun laadun suhteen, etenkin kun yksikkötestit nojaavat samaan periaatteeseen. XP-tyyppisen testauksen soveltuvuudesta erilaisiin käyttötarkoituksiin on keskusteltu jonkin verran. Yksimielisyys tuntuu vallitsevan siitä, että se sopii huonosti sellaisten järjestelmien testaamiseen, joista riippuu ihmisten henki. Tällaisten järjestelmien tulee olla täysin virheettömiä, mikä edellyttää systemaattisempaa lähestymistapaa niiden testaamiseen. Toinen sovelluskohde, johon tämä testausmuoto soveltuu huonosti ovat paljon rinnakkaisuutta sisältävät ohjelmistot. Näissä voi tyypillisesti tulla esiin lukuisia odottamattomia tilanteita, joiden havaitseminen saattaa edellyttää formaalia analyysiä. Tosin mikään ei estä asiakasta vaatimasta tällaisiin tilanteisiin sopivaa testausmuotoa, mutta se edellyttää valveutunutta asiakasta tai aktiivista testaajaa. V-mallin mukaisessa testauksessa tärkeäksi koettu asia on ulkopuolinen näkökulma testaukseen. Siihen on pyritty antamalla tuote erillisen testaajan tai testaajaryhmän arvioitavaksi. Näin tehdään sen vuoksi, että koodin kirjoittanut henkilö ajattelee koodin toimintaa eri tavalla ja ehkä toivoo sen olevan virheetön. Tällainen ulkopuolinen näkökulma puuttuu XP:n hyväksymistestikäytännöstä yksikkötesteistä puhumattakaan. Hyväksymistesteihin ulkopuolista näkökulmaa tuo asiakas, mutta varsinainen testaukseen liittyvä osaaminen tulee kehittäjäryhmän sisältä (testaaja-rooli). Koska projektin asiakas ei välttämättä ole tuotteen loppukäyttäjä, ei hänellä välttämättä ole tarpeeksi ulkopuolista näkemystä tuotteeseen. On epäselvää, millä tavoin ulkopuolisen näkökulman puuttuminen vaikuttaa XP-testaukseen.

5.2 Projektiryhmän XP - prosessi 20 Jos ohjelmoijat eivät noudata XP:n yksikkötesti- ja integraatiokäytäntöjä, testaajan työ vaikeutuu olennaisesti (Crispin 2001). Tämä johtuu siitä, että hyväksymistestit on tarkoitus ajaa usein, mikä puolestaan edellyttää testattavan ohjelmiston jatkuvaa integrointia ja suhteellista toimivuutta. Näiden XP-käytäntöjen soveltamista voidaan pitää projektiryhmän sisäisenä asiana, mutta se vaikuttaa vahvasti hyväksymistestauksen mielekkyyteen ja aikaisen palautteen saamiseen asiakkaalle. Koska hyväksymistestit tukevat asiakkaan projektiryhmälle toteutettavaksi annettuja tarinoita, olisi ne saatava ohjelmoijille mahdollisimman aikaisessa vaiheessa. Jos iteraation hyväksymistestit annetaan ohjelmoijille kehityskierroksen alkupuolella, nopeuttaa se projektin etenemistä (Jeffries ym. 2001, s. 32). Kuitenkin niiden saaminen valmiiksi iteraation alussa vaikuttaa mahdottomalta (Beck, Fowler 2001, s. 88). Tästä huolimatta (Crispin 2001) mainitsee testaajan tavoitteeksi saada suuri osa iteraation hyväksymistesteistä kirjoitettua iteraation toisen päivän loppuun mennessä. Lienee selvää, että jos testit saadaan valmiiksi vasta iteraation lopussa, ei niistä ole paljon apua projektin edistymisen seurannassa kuluvan iteraation aikana. 5.3 Asiakas XP-kirjallisuus ei selvästi ota kantaa siihen, kuka asiakas lopulta on. Oletus prosessissa on, että asiakas puhuu yhdellä äänellä vaikka edustaisikin suurempaa joukkoa ihmisiä. Tämä ei välttämättä pidä paikkaansa, ellei asiaan ole erikseen puututtu. Etenkin on tärkeää huomata, että asiakas ei välttämättä ole projektissa tuotettavan ohjelmiston käyttäjä. Kuitenkin hyväksymistestit pyrkivät verifioimaan järjestelmää käyttäjän näkökulmasta. Ongelmana on se, että käyttäjien tapa käyttää tuotetta saattaa erota

asiakkaan vastaavasta. 21 Lisäongelmia hyväksymistestikäytännössä voi aiheuttaa asiakkaan kokemattomuus testauksen ja XP-prosessin suhteen (Auer, Miller 2002). Vaikka XP-lähestymistapa ei suoranaisesti vaadikaan asiakkaalta tietoja testaustekniikoista, lisää niiden puuttuminen testaajan työtaakkaa. Kokemattomuus voi näkyä myös siinä, että asiakkaan ja projektiryhmän välisen hyvän kommunikaation ylläpitämisen tärkeyttä ei nähdä. Eräs asiakkaan kokemattomuuteen liittyvä haitta on myös se, että etenkin vähemmän teknisesti suuntautuneet asiakkaat kokevat vikojen läsnäolon tuotteessa esteenä seuraavaan iteraatioon siirtymiselle (Crispin 2001). Käytännössä asiakkaat ovat kiireisiä eivätkä ehdi kirjoittamaan hyväksymistestejä (Crispin 2001). Tästä seuraa se, että suuri osa työstä jää testaajan harteille. Tämä on vakava ongelma, koska hyväksymistestit on annettu asiakkaan määriteltäväksi juuri siitä syystä, että tämä tietää, mitä tuotteen tulisi tehdä. Testaaja ei välttämättä tiedä, mitkä tuotteen todelliset käyttäjävaatimukset ovat. Ongelma on oletettavasti melko yleinen ja herättää kysymyksen siitä, pitäisikö erillisen testaustiimin hoitaa XP:n systeemitason testaus. Tässä valossa on ymmärrettävää, että selkeän strategian luominen hyväksymistestaukselle alentaa XP-projektin riskialttiutta (Auer, Miller 2002). 6 Yhteenveto V-mallin mukaiseen testaukseen verrattuna XP-testaus tuntuisi tarjoavan tavan parantaa projektiryhmän ja asiakkaan välistä kommunikaatiota. Se pyrkii lisäksi käytäntöjensä avulla välttämään perinteisen testauksen ongelmakohtia kuten riittämätöntä kehityksen aikaista

tai matalan tason testausta. Toisaalta V-malliin verrattuna koko XP-testauksen 22 lähestymistapa on erilainen se painottaa toiminnallisuuden löytämistä testauksen kattavuuden sijaan. Asiakkaan ja projektiryhmän välisen yhteistyön kannalta on tärkeää, että asiakas ymmärtää XP-testauksen rajoitteet. Sen avulla ei esimerkiksi ole järkevää tuottaa ihmishengelle kriittisiä järjestelmiä yms. Lisäksi molemmat XP:n testityypit painottavat toiminnallisuuden löytämistä, eivät toteutuksen virheettömyyttä. Projektin lähtökohtien analysoinnilla voidaan välttää joitakin ongelmia. Projektin koon pitäisi vaikuttaa prosessivalintaan. XP:tä suositellaan käytettäväksi pienissä, noin kymmenen hengen tiimeissä. Suurempi ihmismäärä vaatii jo raskaampaa metodologiaa. Lisäksi tulisi pohtia, voiko XP:tä soveltaa sellaiseen projektiin, jossa se ei ole ollut käytössä alusta asti. Olemassa olevalla projektilla voi olla esimerkiksi miljoonia rivejä koodia, jolle ei ole kirjoitettu ainuttakaan automatisoitua yksikkö- saati sitten hyväksymistestiä. Tällaisista lähtökohdista voi olla vaikeata lähteä tekemään XP-tyyppistä testausta, ellei siihen nimenomaisesti varauduta kohdistamalla testit vain muutettuihin järjestelmän osiin. Asiakkaan sitoutuminen XP-prosessiin ja -käytäntöihin näyttäisi olevan ensisijaisen tärkeää, jotta asiakas osaa suhtautua oman roolinsa vaatimuksiin oikein. Olennaista on myös se, että asiakas aidosti ymmärtää hyväksymistestien olevan olemassa hänen omien etujensa suojelemiseksi. Hyväksymistestejä kannattaakin ajatella eräänlaisina sopimuksina, joissa määritellään toteutettavan ohjelmiston ominaisuudet. Tällöin niiden hyvä määrittely asiakkaan etu.

23 Vastaavasti myös projektiryhmän sitouttaminen XP-käytäntöihin on testauksen kannalta tärkeää. XP:ssä tosin kaikkia käytäntöjä ei ole edes tarkoitus soveltaa sellaisenaan, mutta ainakin yksikkötesti- ja integrointikäytäntöjen jättäminen projektin ulkopuolelle voi aiheuttaa ongelmia hyväksymistestauksessa. XP-sarjan kirjallisuus tosin suosittelee kaikkien käytäntöjen mukaan ottamista. Aiheeseen liittyy useita mielenkiintoisia jatkotutkimusaiheita, jotka ovat olennaisia koko XP:n soveltamisen kannalta. Päällimmäinen kysymys on se, millainen on XP:n testausmallilla saavutettava laatu. Aiheesta on keskusteltu Usenetin keskusteluryhmissä jonkin verran, mutta kattavaa tutkimusta ei ilmeisesti ole tehty. Tästä seuraa luonnollisesti jatkokysymys siitä, minkälaisissa projekteissa XP-tyyppistä testausta voi käyttää. Lisäksi tutkittavaa voisi löytyä XP-asiakkaan testausvastuun antamisesta erilliselle testaustiimille. 7 Lähdeluettelo XP-sarja: Auer, K., Miller, R.: Extreme Programming Applied, Pearson Education 2002 Beck, K.: Extreme Programming Explained, Addison-Wesley 2000 Beck, K., Fowler, M.: Planning extreme Programming, Addison-Wesley 2001 Jeffries, R., Anderson, A. ja Hendrickson C.: Extreme Programming Installed, Addison-Wesley 2001 Wake, W.C.: Extreme Programming Explored, Addison-Wesley 2002 Muu kirjallisuus: Cockburn, A: Agile Software Development, 2001 Pol, Martin., Teunissen, Ruud., van Veenendaal, Erik.: Software Testing, A Guide to the TMap Approach, Addison Wesley 2002

Artikkelit: 24 Anderson, A. ym.: Case Study: Chrysler Goes To Extremes, Distributed Computing 10/1998 Crispin, L: Extreme Rules of the Road, STQE 6-7/2001, s. 24-29 Crispin, L: The Need for Speed: Automating Acceptance Testing in an Extreme Programming Environment Marick, B: Agile Methods and Agile Testing, STQE Magazine, Vol 3, Number 5