Laaturaportti [iteraatio 2] Ryhmä 14

Laaturaportti [iteraatio 2] Ryhmä 14

Versio Pvm Tekijä Kuvaus 1.0 2.3.2008 Luukkonen Ensimmäinen versio

Sisältö 1. Käytetyt laatumenetelmät... 1 1.1 Automaattiset yksikkötestit, tutkiva testaus ja jatkuva integraatio... 1 1.2 Muut laatumenetelmät... 2 2. Laatustatus... 3 2.1 Laatukojelauta... 3 2.2 Poikkeukset ja laatumittarit... 4 2.3 Laatutavoitteet... 5 3. Laadunvarmistuksen kehitystoimet... 6

1. Käytetyt laatumenetelmät Seuraavassa (Taulu 1.) on esitetty toiselle iteraatiolle suunnitellut laatumenetelmät, näiden vaikutus laatutavoitteiden saavuttamisessa ja käytön määrä. Riskit löytyvät projektisuunnitelmasta. Taulu 1. ( x = käyttö suunniteltu, 0 3 = menetelmän vaikutus laatutavoitteen saavuttamisessa (3 suurin), punainen keltainen vihreä = menetelmän käytön määrä (vihreä paljon). Laatutavoitteet Menetelmät Toiminnallisuus Suorituskyky Skaalautuvuus Käytettävyys Riskien hallinta Testitapauspohjainen testaaminen NUnit -työkalulla x3 x3 x3 x3 Tutkiva testaus x3 x3 x3 x2 Jatkuva integraatio CruiseControl.NET -työkalulla omalla palvelimellaan x3 x3 Systeemi- ja validointitestaus x3 x2 x3 x2 Poikkeusten hallinta Bugzilla - työkalulla x3 x2 x3 Pariohjelmointi x3 x2 x3 Koodikatselmointi x3 x3 Vertaisryhmätestaus x3 x2 x3 Ohjelmointi-standardi x2 x3 x2 Asiakaspalaute x3 x2 x3 x3 x3 1.1 Automaattiset yksikkötestit, tutkiva testaus ja jatkuva integraatio Testitapauspohjaisella testaamisella, käyttäen NUnit työkalua, on ollut suuri merkitys ohjelmiston toiminnallisuuden laadun takaamisessa ja suorituskyvyn testaamisessa. Testitapausten suunnittelun pääpaino on ollut kriittisissä ja virhealttiissa toiminnallisuuksissa mikä testaaminen onkin onnistunut hyvin. Koska kyseinen työkalu vaatii kehittäjiä kirjoittamaan testin alku- ja loppuarvot sekä vaiheet lähdekoodiin, se on niin sanotusti itsedokumentoiva. Tästä syystä erillisiä testilokeja ei ole täytetty vaan testitapaukset löytyvät suoraan projektin lähdekoodista testikokoelmiin ryhmiteltynä. Testitapauksia on suunniteltu yhteensä 26 kappaletta ja ne testaavat ohjelmiston eri moduulien luokkia ja näiden välisiä toimintoja. Muutama näistä 1

testeistä on omistettu ohjelmiston suorituskyvyn testaamiseen ja näitä on ajettu oikeaa testidataa sisältävää tietokantaa vasten. Toisen iteraation aikana päästiin myös käsiksi asiakkaan tiloissa sijaitsevalle varsinaiselle webbipalvelimelle mikä mahdollisti paremmin suorituskyky- ja skaalautuvuustestit. Automaattinen yksikkötestaus on myös auttanut merkittävästi riskien hallinnassa sekä ohjelmiston skaalautuvuuden varmistamisessa. Erityisen ansiokas NUnit työkalu on ollut regressiotestauksessa: kehittäjät ovat lähdekoodin refaktoroinnin jälkeen pystyneet ajamaan automaattisesti kaikki testit läpi. Tämä on taannut kehittäjille varmuuden siitä, että muutokset eivät ole häirinneet ohjelmiston aikaisempaa toiminnallisuutta. Toiminnallisuuden laadun takaamisessa ja riskien hallinnassa jatkuvan integraation menetelmä on ollut kovin tehokas. Menetelmä käyttää CruiseControl.NET työkalua, jota pyöritetään omalla integraatiopalvelimellaan. Työkalu havaitsee muutokset lähdekoodin versionhallinnassa ja kääntää sekä testaa ohjelmiston muutoksen havaitessaan. Projektiryhmää on ohjeistettu työkalun käytöstä Ohjelmointiprosessi dokumentissa ja jatkuvan integraation menetelmän käytöstä löytyy oma kattava raporttinsa SEPA päiväkirjasta. Kaikki projektin dokumentit löytyvät projektiryhmän perustamalta sivulta Google Docs palvelusta osoitteessa: docs.google.com Tutkivaa testausta on harjoitettu pitkin toista iteraatiota, mutta enemmän kohti iteraation loppua. Sitä on käytetty erityisesti nopeiden ja triviaalien asioiden testaamisessa mihin se soveltuu jäykkää testitapausten suunnittelua paremmin. Vertaisryhmätestauksen jälkeen projektiryhmä sai uudenlaisen Test Charterin (Freemind työkalu) käyttöönsä, jota on käytetty myös omaan sisäiseen tutkivaan testaukseen projektin loppumetreillä viikolla yhdeksän. Tutkiva testaus on tuonut esille toiminnallisuuden laadun ohella paljon ohjelmiston käytettävyyteen ja suorituskykyyn liittyviä ongelmia ja kehitysehdotuksia. 1.2 Muut laatumenetelmät Poikkeusten hallinta on toteutettu kurssin tarjoaman Bugzilla työkalun avulla. Havaitut virheet on kirjattu kyseiseen järjestelmään ja tästä on automaattisesti lähtenyt sähköpostit asiaa koskeville projektiryhmän jäsenille. Bugzilla työkalu on ollut hyödyllinen virheiden raportoimisessa yhteen keskitettyyn paikkaan mihin kaikilla projektiryhmäläisillä on vapaa pääsy ja muokkausoikeus kaikkina aikoina. Tämä on edesauttanut erityisesti ohjelmiston toiminnallisuuden laadun takaamisessa ja riskien hallinnassa. Kaikki havaitut virheet eivät epäilemättä ole päätyneet Bugzillaan, mutta tämän vaikutus ohjelmiston toiminnallisuuteen on ollut vähäinen, koska kehittäjät ovat ahkerasti korjanneet havaitsemansa virheet vaikka siitä ei ole tehty virallista merkintää. Automaattiset yksikkötestit sekä integraatiopalvelin ovat auttaneet regressiotestauksessa ja muutenkin virheiden nopeassa havaitsemisessa. Pariohjelmointi harjoitettiin suhteellisen vähän toisen iteraation aikana. Ohjelmiston tuntemus projektiryhmällä oli jo siinä vaiheessa, että kehitystä pystyttiin tekemään hajautetusti. Kuitenkin ne kerrat, kun kyseistä menetelmää on harjoitettu, on sillä ollut suuri merkitys toiminnallisuuden kehityksen kannalta. Pariohjelmointi on toiminut myös riskien hallinnan menetelmänä, koska tieto ohjelmiston moduulien toiminnallisuudesta on jaettu useamman kehittäjän kesken. Koodikatselmointi suoritettiin vain yhden kerran, mutta se keskittyi ohjelmiston tärkeimpään moduuliin eli ohjelmakoodiin, joka käsittelee kielitermien lataamista käyttöliittymäsivulle. Projektiryhmä sai dokumentit muodollisen katselmuksen ohjeista ja tarkasteltavasta materiaalista. Katselmoinnin seurauksena löydettiin suuri joukko virheitä ja puutteita tarkasteltavasta lähdekoodista. Nämä on raportoitu omaan Koodikatselmointi dokumenttiin. Vertaisryhmätestaus oli merkityksellinen kaikkien laatutavoitteiden saavuttamisen kannalta. Testauksen tuloksena löytyi erityisesti ohjelmiston toiminnallisuuteen ja käytettävyyteen liittyviä virheitä ja kehitysehdotuksia. Nämä kirjattiin vertaisryhmän toimesta Bugzillaan ja 2

raportoitiin käyttäen aiemmin mainittua Freemind työkalua. Asiakkaan jakama ohjelmointistandardi listasi ohjelmointityylin, säännöt ja kommentointiohjeet. Näillä on merkitystä etenkin ohjelmiston jatkokehitettävyyden ja dokumentoinnin kannalta. Osaltaan standardi auttoi myös toiminnallisuuden kehittämisessä, koska kehittäjät pystyvät paremmin ymmärtämään muiden projektiryhmäläisten luomaa lähdekoodia. Kaikki nämä vähentävät projektin riskejä ja parantavat ohjelmiston skaalautuvuutta. Asiakaspalautteen kerääminen on koostunut asiakkaalle viikoittain toimitetusta raportista koskien projektin tilaa. Projektiryhmän kolme jäsentä (Matti, Lauri ja Aleksi), jotka työskentelevät Innofactorilla, ovat lähellä asiakasta ja pystyneet näin olleen pitämään tiiviisti yhteyttä asiakkaaseen. Asiakkaalle on myös järjestetty pieni iteraatiodemo tai tarkemmin sanottuna ohjelmiston vapaamuotoinen esittely viikolla seitsemän. Sähköpostiviestintä asiakkaan kanssa on ollut aktiivista ja tällä on ollut mahdollisuus tutustua projektiryhmän tuottamiin dokumentteihin Internetissä. Systeemi- ja validointitestaus on periaatteessa koostunut muista aikaisemmin mainituista menetelmistä kuten jatkuvan integraation työkalun käytöstä yhdistettynä tutkivaan testaukseen sisältäen vertaisryhmätestauksen, suoritettuna luonnollisesti oikealle testidatalle. Ensimmäisen iteraation demo toimi varsinaisena ensimmäisenä validointitestauksena ja toisen iteraation demo edustaa luonnollisesti asiakkaan suorittamaa lopullista ohjelmiston validointitestausta. Projektin riskit on kuvattu tarkemmin projektisuunnitelman kappaleessa seitsemän. Tässä viittaan niihin numerolla ja otsikolla. Asiakkaan tarpeiden väärinymmärryksen, riskit 2, 4 ja 5, välttämiseksi on asiakaspalautteen kerääminen ehdottoman tärkeää samoin kuin systeemi- ja validointitestaus sekä poikkeustenhallinta. Riskit "Kehittäjä lopettaa kesken projektin", "Tuotettu arkkitehtuurin ei ole riittävän selkeä" ja "Editorin toteutuksessa törmätään johonkin esteeseen tai tuntiarviot ovat vääriä", riskit 2, 3 ja 6, vaativat koodikatselmointeja ja pariohjelmointia sekä tietenkin hyvää dokumentointia. Laatumenetelmistä asiakaspalaute on ratkaisevimmassa roolissa. 2. Laatustatus 2.1 Laatukojelauta Evaluoidaan systeemin laatustatusta. Kojelaudassa (kuva 1.) systeemi on jaettu eri moduuleihin sekä dokumentaatioon. Koska dokumentaatio ei vaikuta yhtä suorasti lopputulokseen ovat kaikki dokumentit niputettu tässä vaiheessa vielä yhteen nippuun. Moduulit puolestaan on kuvattu erikseen koska asiakasta kiinnostava toiminnallisuus toteutetaan niiden avulla. Siten moduulit ovat suuremman huomion arvoisia. Laatukojelauta on jaettu kolmeen pääosaan; tarkastelun alla olevan osan tilaan, arvion luotettavuuteen sekä kommentit. Tila kuvaa kuinka valmis osa on, eli kuinka suuri osa sen suunnitellusta toiminnallisuudesta on toteutettu ja testattu. Tilaan on yhdistetty myös laatustatus, mikä kuvaa kuinka laadukkaasti osan arvioidaan toteuttavan sille suunnitellun toiminnallisuuden, kuinka laadukkaasti osa on testattu ja kuinka hyvin se vastaa alkuperäisiä vaatimusmäärittelyitä. Luotettavuus kuvaa kuinka luotettavana projektiryhmä pitää omia arvioitaan valmiusasteesta ja laatustatuksesta. Kommenteissa kuvataan mihin arviot perustuvat. 3

Kuva 1: Laatuliikennevalot 2.2 Poikkeukset ja laatumittarit Poikkeusten hallinta on toteutettu kurssin tarjoamalla Bugzilla työkalulla. Seuraavassa (Taulu 3.) esitetään avoimet virheet. Tarkempi listaus avoimista virheistä löytyy Avoimet bugit dokumentista. Taulu 3. Avoimet virheet Bugzilla työkalussa. ID Sev Pri OS Summary 12 nor P2 Win Tyhjään tietokantaan ei voi editorissa lisätä tunnisteita 17 cri P5 Win Ohjelmisto ei salli konfiguraatiota, jossa käytetään vain jaettua kantaa 21 maj P4 Win Editorissa sisältöä muutettaessa ei luoda uutta sisältöä 23 nor P3 Win Epäselvä käyttöliittymä 26 nor P1 Win Liikaa hakutuloksia Tutkivan testauksen tuloksia löytyy myös Test Charter Editor ja Test Charter Search dokumenteista. Kyseisten dokumenttien raportoimia bugeja ei ole lisätty Bugzillaan, mihin vaikutti merkittävästi testitulosten valmistuminen iteraation viimeisen viikon lopulla ja testauksen puuttuminen alkuperäisestä laadunvarmistussuunnitelmasta. Tällöin olemassa olevat tärkeimmät bugit oli jo käsitelty ja projektiryhmän keskittyminen siirtyi dokumentointiin ja ohjelmiston luovuttamisen asiakkaalle. Testien koodinkattavuutta on seurattu NCover työkalun avulla. Viimeisin raportti löytyy CoverageReport dokumentista. Koodikattavuuden taso on liikkunut noin 60 prosentin tasolla viimeisten viikkojen aikana ja viimeisin raportti kertoo arvon olevan 61.1 prosenttia. 4

Ohjelmiston moduuleista Core.CacheHandler pudottaa kokonaiskattavuutta, koska sen uusimpia luokkia varten ei ole kehitetty testejä, koodikattavuuden arvona 50 prosenttia. Tietokantatason moduuli Core.Data:n käsitteitä ja konteksteja käsittelevät luokat ConceptManager ja ContextData sisältävät vierailemattomia funktioita mikä pudottaa reilusti moduulin kattavuutta, tarkalleen 64,9 prosenttiin. Core.Model -moduulin ContentKeyGroup luokka sekä tuotelinja- ja versiohierarkiaa käsittelevät luokat ProductLineHierachy ja ProductLineVersion pudottavat osaltaan moduulin koodikattavuutta 78,5 prosenttiin. Lopuksi Core.Util moduuli on lähes testaamaton mikä tiputtaa edelleen jonkin verran kokonaiskattavuutta. CVS Stat työkalun raportti versionhallinnan muutoksista löytyy CVS Stat report pakkauksesta. Raportti listaa muun muassa kehittäjien versionhallintaan kommitoimat koodirivit ajan suhteen eri näkymillä, varsinaiset kommitoidut tiedostot ajan suhteen sekä statistiikkaa ohjelmiston tiedostoista. Yksi tärkeistä raportin osuuksista on koodirivien määrä ajan suhteen. Alkuun kehitys on ollut suhteellisen tasaista viikolta 42 viikolle 47 saakka. Kuvaajasta käy ilmi kuinka koodirivit ovat lisääntyneet voimakkaasti ennen ensimmäisen iteraation demoa, toisin sanoen viikoilla 48 49. Tämän jälkeen kehitys näyttää talviloman seurauksena pysähtynyt kokonaan pitkäksi aikaa, mutta taustalla on kuitenkin tehty jonkin verran lähdekoodin refaktorointia. Kehitys on näkyvästi jatkunut vasta viikosta 5 eteenpäin ja kiihtynyt voimakkaasti jälleen juuri ennen iteraatiodemoa, viikolla 9. 2.3 Laatutavoitteet Seuraavassa (Taulu 4.) on esitetty projektin laatutavoitteiden statuksen tila ja perustelut arvioinnille. Taulu 4. Projektin laatutavoitteiden tila. Tavoite Tila Perustelut Toiminnallisuus OK Toteuttaa asiakkaan priorisoimat toiminnallisuudet Suorituskyky Skaalautuvuus? Käytettävys OK OK Riskien hallinta OK Testattu yksikkötason testeillä oikealla datalla. Testattu myös tutkivalla testauksella mukaan lukien vertaisryhmätestaus. ei ole ollut mahdollista testata tätä kattavasti koska ryhmällä ei ole saatavilla riittävää testauslaitteistoa Saatu palautetta asiakkaalta. Testattu myös tutkivalla testauksella mukaan lukien vertaisryhmätestaus. Yllätyksiä on tullut mutta tilanteista on selvitty osaamisen hajautuksen ja muun valmistautumisen avulla Yhteenvetona voidaan sanoa että laatutavoitteet on saavutettu niiltä osin kun ne on ollut mahdollista saavuttaa. 5

3. Laadunvarmistuksen kehitystoimet Seuraava vaihe projektissa on jo asiakkaalle luovutus mikä ei tietenkään tarkoita, että laadunvarmistusta tulee unohtaa. Asiakkaan kannattaa tutustua käytettyihin laatumenetelmiin, etenkin automaattisen yksikkötestaukseen ja jatkuvan integraation menetelmään. Tässä dokumentissa ja loppuraportissa esitettyjen kommenttien perusteella pitäisi lukijalle käydä selväksi miksi nämä menetelmät ovat paikallaan ohjelmiston kuin ohjelmiston kehityksessä. Tutustumalla avoimiin virheisiin, laadunvarmistussuunnitelmaan ja muihin teknisen toteutuksen dokumentteihin asiakas voi jatkaa suhteellisen vaivattomasti ohjelmiston kehitystä. 6