SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant

Transkriptio

1 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 8

2 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä Ensimmäinen versio Petri Kalsi Pieniä lisäyksiä käyttöönottoon ja kuvaukseen Heikki Salminen I1-vaiheen muutokset ja kokemukset kirjattu Petri Kalsi Dokumentin rakennetta muutettu Esa Mommo I2-vaiheen kokemukset kirjattu Heikki Salminen FD-vaiheen kokemukset Petri Kalsi Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Petri Kalsi Heikki Salminen Tehtävä Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Seppo Sahi Tehtävä Mentor Aihe: PK&HS Sivu 2 / 8

3 Sisällysluettelo 1. Esittely Tarkoitus Viittaukset Menetelmän kuvaus Käyttöönotto Kokemukset ja muutokset PP-vaihe I1-vaihe I2-vaihe FD-vaihe Yhteenveto...8 Aihe: PK&HS Sivu 3 / 8

4 1. Esittely 1.1 Tarkoitus Tämän dokumentin tarkoitus on kuvata ElectricSeven-ryhmän kahden jäsenen käyttämää SEPAmenetelmää automaattisia yksikkötestejä. Menetelmä esitellään ja perustellaan luvussa 1. Luku 2 sisältää suunnitelmat menetelmän käyttöönotolle. Lukuun 3 kirjataan kokemuksia ja havaintoja menetelmän hyödyistä ja sopivuudesta projektin tarpeisiin. 1.2 Viittaukset Muut käytetyt testaus- ja laadunvarmistusmenetelmät on kuvattu testaussuunnitelmassa. 1.3 Menetelmän kuvaus Valitsemamme SEPA-aihe on automaattiset yksikkötestit. Aiheen valinta oli helppo, sillä yksi asiakkaan järjestelmälle asettamista vaatimuksista oli automaattisten yksikkötestien käyttö. Yksikkötestaus soveltuu myös aiheena hyvin meille, testausvastaavan (Petri Kalsi) ja laatuvastaavan (Heikki Salminen) rooleissa toimiville ryhmän jäsenille. Kurssin T Ohjelmistojen testaus ja laadunvarmistus suoritus samanaikaisesti projektin ohella antaa hyvät pohjat yksikkötestauksen suunnittelulle ja toteutukselle. Yksikkötestit integroidaan build-skripteihin, ja ne suoritetaan aina uuden version kääntämisen yhteydessä. Yksikkötestaus ei aiota suorittaa koko järjestelmälle, vaan ainoastaan tärkeimmille, matalan tason toiminnallisuudesta vastaaville luokille, ja yleisesti sille osalle johon yksikkötestaus parhaiten soveltuu. Yksikkötestaukseen osallistuvat kaikki ohjelmoijat, jotka implementoivat yksikkötestauksen piiriin kuuluvia luokkia. Testiluokkien ohjelmointi tehdään pääosin I1 ja I2-vaiheissa. Testeistä pyritään tekemään mahdollisimman mukautuvia, jotta samoja testejä voidaan ajaa vähin muutoksin koko projektin ajan. Aihe: PK&HS Sivu 4 / 8

5 2. Käyttöönotto Yksikkötestaus aloitetaan heti I1-vaiheessa samanaikaisesti ohjelmoinnin aloituksen kanssa. Yksikkötestaukseen kuuluvien luokkien toteutuksesta vastaavien ohjelmoijien vastuulla on myös toiminnallisuutta testaavien testiluokkien ohjelmointi. Yksikkötestausta jatketaan niin kauan kuin testattavien luokkien kehitys jatkuu. Yksikkötestit on ajettava aina, kun testattavaan luokkaan tehdään jotain muutoksia. Käytännössä tämä tapahtuu integroimalla yksikkötestit ajettavaksi automaattisesti tehtävän buildin yhteydessä. Testiluokkien toteutukseen käytetään JUnit-frameworkia. Testaukseen käytetty aika on rajallista, joten nyrkkisääntönä pidetään, että yksikkötestien kirjoittamiseen kulutetaan % siitä ajasta, mitä vastaavan toiminnallisuuden implementointiin on arvioitu kulutettavaksi. Tämän takia testaus pyritään keskittämään kussakin luokassa tärkeimpiin ominaisuuksiin. Mikäli luokassa on yksi tärkeä ulkoa päin kutsuttava metodi, joka itse käyttää suurta osaa luokan muista metodeista, on testaus järkevää keskittää kyseiseen metodiin. Jos luokkaa joudutaan myöhemmin muuttamaan esimerkiksi löydetyn vian vuoksi, testitapausten lisäämiseen ja parantamiseen käytetään taas 20 % toiminnallisuuden korjaamiseen käytetystä ajasta. Testiluokat nimetään periaatteella <testattava_luokka>test.java, jotta testiluokat olisivat helposti erotettavissa ja integroitavissa build-skripteihin. Testimetodit nimetään mahdollisimman kuvaavasti, tyyliin test<testattava_asia>(), esim. testaddissuetoincrementbacklog(). Kaikki ryhmän jäsenet ovat suorittaneet kurssin T , tai suorittavat sitä parhaillaan projektin ohella, joten erillistä koulutusta menetelmän käyttöönotolle ei tarvita. Yksikkötestaus painottuu luotuihin Enterprise Java Bean -luokkiin, jotka muodostavat järjestelmän matalan tason rajapinnan Hibernate-tietokantakerroksen päälle. Jokaisen EJB-luokan tärkeimpiä metodeja pyritään testaamaan vähintään kerran jossain testitapauksessa. Täydelliseen kattavuuteen ei pyritä vielä I1-vaiheessa rajallisen tuntimäärän takia. I2-vaiheessa jatketaan yksikkötestien kehittämistä kattavuuden parantamiseksi, ja automaattista ajamista buildien yhteydessä. Aihe: PK&HS Sivu 5 / 8

6 3. Kokemukset ja muutokset 3.1 PP-vaihe Yksikkötestausta ei oteta käyttöön PP-vaiheessa. 3.2 I1-vaihe EJB-luokkien implementointi lykkääntyi myöhäiseen vaiheeseen I1-iteraatiota, joten yksikkötestausta ei ehditty toteuttaa suunnitellussa laajuudessa. Testejä toteutettiin esimerkin omaisesti muutamille luokille (CycleManager, ProductManager, BacklogItemManager), jotta muiden ryhmän jäsenten olisi helpompaa ryhtyä kirjoittamaan testejä. Lopuille EJB-luokille kirjoitetaan yksikkötestejä joulukuun aikana ennen I2- vaiheen alkua. Testit ehdittiin integroida ant-työkalun avulla automaattiseen build-järjestelmään nimeltä CruiseControl. Testit ja uusi build ajetaan aina, kun järjestelmä havaitsee muutoksia cvs:n hakemistopuussa. Testien tulokset ovat luettavissa erillisellä www-sivulla < josta löytyvät myös aiempien buildien tulokset. Niiltä osin kuin testejä ehdittiin kirjoittaa, yksikkötestaus havaittiin käteväksi tavaksi testata matalan tason rajapintaa. Testit paljastivat useita virheitä, jotka ehdittiin korjata I1-vaiheen lopussa. Automaattisen testausympäristön pystyttäminen osoittautui yllättävillä tavoilla hankalaksi. Tietokantaan ladattavan testidatan hallinta ja kantaan lataaminen aiheutti vaikeuksia, koska osa testeistä muokkasi samaa dataa tai sotki kantaa niin, että myös tietokannan tyhjentäminen testauskierrosten välillä täytyi automatisoida. Suuri osa yksikkötesteistä on sivuvaikutuksellisia, joten aikaisemmat testitapaukset vaikuttavat järjestelmän tilaan ja testien suoritusjärjestyksellä on suuri merkitys. Päätimme tehdä yksittäisistä testitapauksista hieman tavanomaista laajempia. Yksi testitapaus testaa yhden luokan useampaa metodia tai toimintoa, jotta sivuvaikutusten määrä saadaan minimoitua. Yksi testitapaus suorittaa muutaman peräkkäisen toiminnon sarjan samalle datalle. Näin datan ja suoritusjärjestyksen hallinta helpottui ja testitapausten ylläpitäminen on selkeämpää. Järjestelmän arkkitehtuuri asetti rajoitteita yksikkötestien muotoilemiselle. Käytännössä yhtä EJB-luokkaa testaavan testijoukon täytyi käyttää myös muutamaa (1-4) muuta EJB:tä testeille sopivan alkutilan aikaansaamiseen ja parametrien muodostamiseen. Tästä ei ole toistaiseksi aiheutunut ongelmia. Tämän takia testijoukot (JUnitin TestSuitet) kannattaa suorittaa tietyssä järjestyksessä, jotta vian löytäisi oikeaa luokkaa testaava testi. Näin saadaan siistein virheilmoituslista. Nopeasti hyvän testikattavuuden saavuttamiseksi implementoitiin jo alkuvaiheessa testit luokkaa BacklogItemManager varten. Se käyttää suoraan tai epäsuoraan noin puolta järjestelmän kaikista EJBluokista. Muut ryhmämme jäsenet eivät ole vielä päässeet kunnolla mukaan yksikkötestien kirjoittamiseen, mutta toisaalta implementaatiokoodiakin on hieman suunniteltua vähemmän. Mielestämme testien nykyinen kattavuus on kohtalaisen hyvä. 3.3 I2-vaihe Tässä vaiheessa näyttää selvältä, että alkuperäinen suunnitelma yksikkötestien kirjoittamisesta ei olisi voinut toimia näin hajanaisessa ja löyhästi aikataulutetussa projektissa. Jos yksikkötestejä halutaan kirjoittaa kattava määrä, se olisi pitänyt aikatauluttaa I2- ja FD-vaiheien alkuun. Vaiheen lopussa aikataulu on väistämättä niin sekava, että yksikkötestit jäävät tekemättä. Aihe: PK&HS Sivu 6 / 8

7 Tämän lisäksi joulukuuksi suunniteltu siistimis-, dokumentointi- ja yksikkötestausvaihe epäonnistui tai ainakin jäi suunniteltua suppeammaksi. Sen aikana saatiin ainoastaan yksi uusi luokka (UserManager) yksikkötestien piiriin. Lisäksi vaiheen aikana saatiin toteutettua pohjaluokka yksikkötestien kirjoittamiseen (DefaultBeanTestCase), mikä on sinänsä merkittävä parannus, mutta ei lisää testien kattavuutta. I1-vaiheessa toteutettuja EJB-luokkia on muutettu I2-vaiheessa jonkin verran muuttuneiden vaatimusten takia. Lisäksi niihin on tehty merkittävä määrä uusia toimintoja. Olemassaolevia yksikkötestitapauksia ajetaan edelleen säännöllisesti CruiseControllin avulla, mutta ne eivät ole löytäneet uusia virheitä. Yksikkötestien kattavuus on I2-vaiheen aikana hieman huonontunut. Kaikenkaikkiaan ohjelmoimiseen on käytetty tähän mennessä noin 300 tuntia. Jos alkuperäisestä tavoitteesta (10-20 % ohjelmointiajasta yksikkötestien kirjoittamiseen) pidettäisiin kiinni, yksikkötestejä pitäisi kirjoittaa tuntia. Yksikkötesteihin käytettyä aikaa ei ole erikseen seurattu, mutta alkuperäisestä tavoitteesta ollaan kuitenkin tällä hetkellä niin kaukana, että sen saavuttaminen tuntuu hyvin epätodennäköiseltä. Jos samaa sovelletaan ainoastaan yksikkötestauksen piiriin otettuihin komponentteihin (EJB-luokat), tavoite on jotakuinkin savutettu. EJB-luokkiin on kulunut suuruusluokkaa kolmannes ohjelmointiajasta, joten yksikkötesteihin pitäisi käyttää suuruusluokkaa 15 tuntia, mikä todennäköisesti vastaa aika hyvin tämänhetkistä todellisuutta. Lisäksi kattavien automaattisten yksikkötestien kirjoittaminen osoittautui vielä oletettuakin työläämmäksi. Suunniteltu % ei selvästikään ole jatkokehitettäväksi tarkoitetulle ohjelmistolle riittävä määrä. Tähän ei kuitenkaan tässä projektissa ehditä enää reagoida. Emme myöskään uskalla esittää arvausta siitä, mikä olisi riittävä määrä. Koska nykyinen yksikkötestikattavuus on huonompi kuin mitä asiakas haluaa, yksikkötestejä on tarkoitus kirjoittaa huomattava määrä lisää FD-vaiheen alussa. Jo alkuperäisessä suunnitelmassa oli varattu FDvaiheen alusta runsaasti aikaa testaamiseen. Osa tästä tullaan käyttämään yksikkötesteihin. Lisäksi FDvaiheen aikana on tarvoitus arvioida automaattisten yksikkötestien kattavuus ainakin summittaisesti. 3.4 FD-vaihe Viimeisessä vaiheessa ehdittiin lisätä muutama yksikkötesti, mutta muuten FD-vaiheessa keskityttiin aiemmissa iteraatioissa ja FD-vaiheen aikana löytyneiden vikojen korjaamiseen. Löydettyjen vikojen korjaaminen katsottiin tärkeämmäksi kuin uusien löytäminen, ja muutama vika jäi vielä korjaamatta. Tämän vaiheen aikana tuotteen testaukseen osallistuivat sekä asiakas (hyväksymistesti) että vertaisryhmä (kurssin järjestämä vertaistesti). Lisäksi ryhmä itse käytti tuotetta oman työnsä ohjaukseen, tuntikirjauksiin ja edistymisen seurantaan. Siksi varsinaiseen testaukseen käytettävää työmäärää pienennettiin yleisesti. Tämä vaikutti myös yksikkötesteihin. Projektin päättyessä automaattisten yksikkötestien kattavuutta voidaan kuvata arvosanalla tyydyttävä. Sama pätee myös yksikkötestaukseen liittyvään prosessiin. Kaikki ei tapahtunut suunnitellulla tavalla, suunnitellussa aikataulussa tai suunnitellussa laajuudessa, mutta tulos ei silti ollut missään tapauksessa huono. Yksikkötestien tarkkaa kattavuutta ei saatu arvioitua. Kaupallisilla välineillä se olisi ilmeisesti onnistunut melko helposti. Myöskään yksikkötestien kirjoittamiseen käytettyä työmäärää ei pystytty mittaamaan aivan tarkasti. Lopullisen arvion mukaan yksikkötesteihin käytettiin keskimäärin 15 % toteutukseen ja bugikorjauksiin kuluneesta työmäärästä. Arvio perustuu suurimmaksi osaksi tuntikirjauksiin, mutta osittain arvioon, koska kirjaukset eivät olleet täydellisiä. Tulos vastaa hyvin suunniteltua. Arvion mahdollinen virhe on joka tapauksessa niin pieni, että todellinen arvo on varmasti suunnitellulla välillä. Olemme kuitenkin edelleen sitä mieltä, että yksikkötesteille suunniteltu % työpanos ei selvästikään ole jatkokehitettäväksi tarkoitetulle ohjelmistolle riittävä määrä. Aihe: PK&HS Sivu 7 / 8

8 3.5 Yhteenveto Yksikkötestit olivat mielenkiintoinen kokeilu. Yksikkötestien kattavuus jäi kuitenkin siihen budjetoidulla ajankäytöllä valitettavan alhaiseksi. Yksikkötestit olivat asiakkaan vaatimus projektille, ja ne löysivät muutamia oikeita vikoja, joten testit eivät olleet turhia. Testien tulosten seurantaan tulisi myös panostaa enemmän, jotta menetelmästä olisi enemmän hyötyä. CruiseControl-järjestelmän kanssa oli ongelmia testien ajon kanssa, Ant-skriptissä oli pitkän aikaa se ongelma, että juuri ennen testien ajoa ohjelma-paketti siirrettiin JBossin ajettavaksi, ja välillä osa testeistä ehdittiin ajaa samalla kun JBoss lataili uutta pakettia. Tämä aiheutti välillä vääriä hälytyksiä yksikkötestien tuloksissa. Kokonaisuudessaan automaattisista yksikkötesteistä ei ollut tässä projektissa riittävää hyötyä suhteessa käytettyyn työmäärää. Emme usko, että tilanne olisi muuttunut, vaikka yksikkötestit olisi suunniteltu toisin. Projekti oli liian lyhyt, kompakti ja suoraviivainen, jotta testien hyödyt olisivat tulleet kunnolla esiin. Regressiotestaukseen liittyvä hyöty jäi vähäiseksi, koska projektissa voitiin keskittyä uusien toimintojen lisäämiseen, ei entisten muuttamiseen. Tavallaan tämä liittyy siihen, että projekti onnistui hyvin ja asiakas ei muuttanut vaatimuksia. Uskomme, että yksikkötesteistä olisi hyötyä, jos projektia olisi jatkettu huomattavasti pidempään. Nyt tuote jäi niin pieneksi, että jo muutaman tunnin exploratory-testauksella voidaan saavuttaa riittävä (tuotteen kriittisyys huomioiden) varmuus siitä, että uudet muutokset eivät ole rikkoneet mitään toimintoja. Toisaalta emme voi täysin arvioida pitkän tähtäimen hyötyä, koska emme koskaan joutuneet merkittävästi ylläpitämään yksikkötestejä (ts. muuttamaan niitä vaatimusten ja toiminnallisuuden muuttuessa) ja emme siis voi perustellusti arvioida siihen liittyvää työmäärää. Yksikkötestien tärkein hyöty liittyy jatkokehitettävyyteen. Tämä hyöty on niin merkittävä, että se yksinään riittää yksikkötestien perusteeksi. Jos tuote siirtyy tämän projektin päätyttyä jonkin toisen projektiryhmän kehitettäväksi, yksikkötesteistä on todennäköisesti merkittävää hyötyä. Hyöty on suurimmillaan, jos tuotetta jatkokehittävä ryhmä ei tunne sen toimintaa lainkaan entuudestaan (kukaan alkuperäisistä kehittäjistä ei ole mukana) tai jos tuotetta jatkokehitetään avoimessa ja hajanaisessa yhteisössä (esim. Open Source). Aihe: PK&HS Sivu 8 / 8