Laadunvarmistuksen loppuraportti

Laadunvarmistuksen loppuraportti Dokumentin historia Versio Päiväys Muokkaaja Kuvaus Hyväksytty 1.2 26.02.06 Rönkkö Kirsi Päivitetty viimeiset data dokumenttiin 1.1 24.02.06 Rönkkö Kirsi Liitetty muilta saatua tekstiä ja korjattu virheitä 1.0 23.02.06 Rönkkö Kirsi Alustava sisältö

Sisällysluettelo 1. Laadunvarmistuksen haasteet...2 2. Saavutetut tulokset...3 2.1. Heuristinen arviointi...3 2.2. Virheiden määrät...4 2.3. Katselmoinnit...6 2.4. Yksikkötestauksen kattavuus...7 3. Arvio vertaistestauksesta...7 4. Tavoitteiden täyttyminen...8 5. Yhteenveto...9 1

Johdanto Tässä dokumentissa kuvataan Valpas-projektissa käytetyn laadunvarmistusprosessin toimivuutta sekä sen hyviä ja heikkoja puolia. Lisäksi dokumentin lopusta löytyy yhteenveto laadunvarmistuksen tuloksista. 1. Laadunvarmistuksen haasteet Hyvistä aikeista ja suunnitelmista huolimatta projektissa ei niinkään keskitytty laadun varmistamiseen vaan laadun määrittelemiseen. Osittain tähän oli syynä laadunvarmistuskokemuksen puute projektiryhmästä. Parhaimmillaankin ryhmän jäsenet olivat vasta käymässä T-76.5613 Ohjelmistojen testaus ja laadunvarmistus kurssia. Tästä johtuen tiedot ja taidot kyseiseltä aihe-alueelta eivät olleet toivotulla tasolla. Vaativa aihe olisi vaatinut enemmän sulattelua ennen ensimmäistä tulikoetta. Suurin ongelma laadunvarmistuksen mielestä oli siinä, että järjestelmän osat valmistuivat hyvin myöhään, eikä kunnollista systeemitason testausta ehditty tekemään lainkaan ensimmäisen vaiheen aikana. Suunnitelmissa oli ollut myös järjestelmän pidempiaikainen testaus joululoman ylitse, mutta jonkin aikaa testin aloittamisen jälkeen järjestelmä todettiin liian kypsymättömäksi ja testaus lopetettiin. Suhteellisen myöhäisessä vaiheessa ymmärrettiin, ettei Valppaan perustoiminnan testaamiseen välttämättä tarvita Ilmo-simulaattoria, jonka kypsymättömyys pääosin oli ollut testauksen lopettamisen syynä. Pidempään testiajoon ilman laitteen testaussimulointia olisi riittänyt pelkkä päällä oleva puhelin. Osittain tämä havaittiin, kun eräs systeemitestaus kaatui siihen, että kehittäjä ei malttanut pitää kehittämäänsä Ilmo-simulaattoria pyörimässä havaittuaan siinä virheitä. (Sopivien testikoneiden vähyys oli ajanut testauksen siihen tilanteeseen, että systeemitestissä yhtä simulaattoria pyöritettiin kehittäjän kotona.) Ensimmäinen pitempiaikainen Valppaan testiajo päästiin tekemään vasta hyvin myöhäisessä vaiheessa projektia, jolloin löytyi iso määrä ongelmia. Pahimpina ongelmina olivat speksien vastainen toiminta ja viestien lähettämättä jättäminen pidemmän päälläolon jälkeen. Nämä ongelmat saatiin korjattua osittain juuri ennen vertaistestausta ja loput vasta vertaistestauksen aikana. Korjausten jälkeen olikin jo kiire, että hyväksyntätestit ehdittäisiin suorittamaan ennen demotilaisuutta. Hyväksyntätestinä oli kaksi neljän päivän testiajoa kahdella Ilmo-simulaattorilla. Laadunvarmistusmielessä olisi testilähtöinen kehittäminen ollut hyvä kehitysmenetelmä, mutta laadunvarmistusta suunniteltaessa tiedettiin projektiryhmässä olevan tätä menetelmää suuresti vastustava taho. Näin ollen laadunvarmistus päätyi vain suosittelemaan testilähtöistä kehitystä ja jättämään yksikkötestauksen kehittäjien itsensä vastuulle. Tästä huolimatta yksikään kehittäjä ei tainnut käyttää testilähtöistä kehitystä koko projektin aikana. Osittain ongelmana oli myös se, että yksikkötestien kehitys tuntui välillä unohtuvan kehittäjiltä kokonaan. Lisäksi testejä ei muistettu ylläpitää, vaan ne saattoivat CVS:stä suoraan otettuna epäonnistua. Tämä osittain vaikeutti myös kattavuuslaskujen tekemistä ja ajoi laadunvarmistusta siihen tilaan, jossa aika kulutettiin yksikkötestien läpäisyn varmistamiseen, eikä niinkään niiden laadukkuuden tutkimiselle. 2

Ongelmaan puututtiin moneen otteeseen ja sitä yritettiin korjata useilla erilaisilla keinoilla. Muutama viikko ennen joulutaukoa kehittäjiä muistutettiin siitä, että jokaiseen tehtävään sisältyi myös tehtävän toiminnallisuuden varmentaminen yksikkötesteillä. Tämä auttoi tilannetta ja testejä alkoi syntyä paremmalla tahdilla. Joululoman jälkeen huomasimme taas, että yksikkötestien tekeminen oli unohtunut ja muistutimme niiden tärkeydestä. Lisäksi kerroimme myös, että jokaisen osan tavoitteena on saavuttaa vähintään 60 % lausekattavuus yksikkötesteissä. Myöhemmin kattavuuslukujen keräämisvastuuta siirrettiin kehittäjille, siinä toivossa, että epäonnistuvat testit korjautuisivat sen avulla. Käytännössä jokainen kehittäjät ajoi kattavuusajon yhden ainoan kerran tietyn viikon aikana, mutta testien läpimeno ei silti parantunut. Laadunvarmistussuunnitelmissa oli vähennetty virheiden vakavuuteen käytettäviä tasoja helpottamaan niiden määrittelyä. Tasoja ei kuitenkaan osattu vähentää Bugzillasta, jota käytettiin virheiden hallintatyökaluna, joten suunnitelmat eivät toimineet. Useasti vikailmoitusta kirjatessa unohdettiin kokonaan määritellä kuinka vakavia virheet olivat tai kuinka nopeasti ne pitäisi korjata. Ongelmaksi muodostui se, että Bugzillassa oletuksena oli vakavuus "normaali", jota projektin laadunvarmistus ei tuntenut. Laadunvarmistussuunnitelmien muuttaminen olisi varmasti ollut helpompi tie, mutta laadunvarmistus halusi kaikin keinoin välttää mielikuvat virheestä, joka on aivan normaali. Laadunvarmistussuunnitelmassa oli myös mietitty erilaisten metriikoiden hankkimista. Kaikkia metriikoita ei myöskään välttämättä laskettu suoraan valmiiksi samalla tavalla kuin oli suunniteltu. Kerätyn datan soveltaminen projektin hallintaan ja ohjaukseen tapahtui kuitenkin hyvin hitaalla tahdilla. Toisaalta kerätty tieto ei missään vaiheessa ollut kovin hälyttävää. Pieniä haasteita aiheutti myös koodikatselmointien "ulkoistaminen" laadunvarmistuksesta. Tämä johtui siitä, että kehittäjät olivat valinneet SEPA-aiheekseen koodikatselmoinnit, joten katselmointien järjestäminen kuului siten heidän vastuulleen. Laadunvarmistuksen patisteluista huolimatta katselmointeihin ryhdyttiin vasta viimeisellä viikolla ensimmäisessä vaiheessa ja liian isolla kerta taakalla. Laadunvarmistuksen puolesta kehittäjiä yritettiin neuvoa, että asia sujuisi paremmin seuraavassa vaiheessa. Tämän toteutumisesta laadunvarmistuksella ei ole tietoa, koska laadunvarmistuksen tunnit olivat niin vähäiset, että johtoryhmässä katsottiin parhaaksi jättää kehittäjien harteille, että nämä saisivat riittävästi aineistoa tehtäväänsä varten. 2. Saavutetut tulokset 2.1. Heuristinen arviointi Heuristisia arviointeja tehtiin projektin aikana kahdelle suunnitteluvaiheessa olleelle käyttöliittymälle. Molemmista käyttöliittymästä löytyi käytettävyysongelmia, jotka ainakin osittain korjattiin kehitettyyn käyttöliittymään. Suunnitteluvaiheessa osa tärkeistä toiminnallisuuksista oli täysin unohtunut. Nämä asiat löytyivät heuristisen arvioinnin yhteydessä, jolloin suunnitelmat paranivat ennen toteutukseen siirtymistä. Taulukko 1: Heuristisella arvioinnilla löydetyt ongelmat vakavuuksittain Käyttöliittymä Päivämäärä Kriittiset Vakavat Vähäiset Kosmeettiset Yhteensä Analysaattori 21.11.05 3 12 11 9 35 WWW-käyttöliittymä 24.1.06 1 9 18 6 34 3

2.2. Virheiden määrät Projektin aikana rakennetusta järjestelmästä löydettiin 104 virhettä (105, joista kaksi oli päällekkäistä jonkin toisen kanssa). Kuva 1 kertoo projektin tiedossa olleiden ongelmien määrän eri aikoina. Kuva 2 puolestaan kuvaa saman ajan tiedot ongelmien statuksena. Kuvien asteikko ei ole tasaisesti jatkuva. Ongelmat yhteensä 102 107 100 80 80 63 60 53 44 40 24 24 25 28 30 15 3 4 7 8 0 27.11.05 28.11.05 1.12.05 2.12.05 3.12.05 4.12.05 5.12.05 6.12.05 6.1.06 13.1.06 17.1.06 24.1.06 31.1.06 7.2.06 14.2.06 21.2.06 26.2.06 Triviaali Vähäinen Vakava Kriittinen Yhteensä Kuva 1: Tiedettyjen virheiden määrä eri aikoina Ongelmien status 102 107 100 80 60 40 0 3 4 27.11.05 28.11.05 7 8 1.12.05 2.12.05 3.12.05 4.12.05 15 24 24 25 28 30 Kuva 2: Ongelmien tilan kehittyminen ajan suhteessa. 5.12.05 6.12.05 6.1.06 13.1.06 17.1.06 24.1.06 31.1.06 7.2.06 14.2.06 44 53 63 80 21.2.06 26.2.06 Suljettuja Vahvistettuja Korjattu Avattu Uusia Yhteensä 4

Kuva 3 ja Kuva 4 kuvaavat puolestaan miten ongelmien vakavuusasteet ovat jakautuneet avoimissa ja suljetuissa ongelmissa. Näissä kuvaajissa akseli on tasaisesti jatkuva, jolloin kuvaajista on helposti nähtävissä myös projektissa ollut joulutauko. Hoidetut ongelmat 45 40 35 30 25 15 10 5 0 27.11.05 4.12.05 11.12.05 18.12.05 25.12.05 1.1.06 8.1.06 15.1.06 22.1.06 29.1.06 5.2.06 12.2.06 19.2.06 26.2.06 Kuva 3: Eri vakavuudella olevat suljetut ongelmat projektin aikana Avoimet ongelmat Kriittinen Vakava Vähäinen Triviaali 45 40 35 30 25 15 10 5 0 27.11.05 4.12.05 11.12.05 18.12.05 25.12.05 1.1.06 8.1.06 15.1.06 22.1.06 29.1.06 5.2.06 12.2.06 19.2.06 26.2.06 Kuva 4: Eri vakavuudella olevat avoimet ongelmat projektin aikana Kriittinen Vakava Vähäinen Triviaali Kuvista voidaan huomioida, että avoimien ongelmien määrä on pysynyt melko hyvin samoissa lukemissa koko projektin ajan. Tästä voidaan vetää johtopäätöksenä, että ongelmia on korjattu kutakuinkin samalla tahdilla, kun niitä on löydetty. 5

Ongelmien status 80 70 60 50 40 30 Suljettuja Vahvistettuja Korjattu Avattu Uusia 10 0 27.11.05 4.12.05 11.12.05 18.12.05 25.12.05 1.1.06 8.1.06 15.1.06 22.1.06 29.1.06 5.2.06 12.2.06 19.2.06 26.2.06 Kuva 5: Ongelmien tilan kehittyminen projektin aikana Kuva 5 esittelee ongelmien tilanteen kehittymisen aika-akselilla. Tästä kuvaajasta voidaan huomata, että ongelmien korjauksien testaus on aluksi ollut hieman puutteellista kaikkien laadunvarmistusresurssien keskittyessä enemmän ongelmien paikantamiseen. 2.3. Katselmoinnit Projektissa katselmoitiin sekä koodia, että projektissa tuotettua kirjallista materiaalia. Osa dokumenteista käytiin läpi hyvin paljon vapaamuotoisemmin, joten näistä tapauksista varsinaista tilastollista tietoa ei ole. Taulukko 2 kuvaa löydettyjen ongelmien määrää suhteessa käytettyyn aikaan. Osa dokumenteista oli niin lyhyitä, että niitä tarkistettiin samojen katselmointien aikana, jolloin on mahdotonta erottaa yksittäiseen dokumenttiin käytettyä aikaa. Käytettyyn aikaan on laskettu myös valmistautuminen katselmointiin ennen varsinaista katselmointitilaisuutta. Suurin osa ongelmista liittyi enemmänkin dokumentin ulko- ja kieliasuun, eikä niinkään itse sisältöön. Korjauksia tehtiin myös jonkin verran dokumentin asiasisältöön. Kaikkein eniten asiasisällöstä johtuvia ongelmia kirjattiin käyttöohjeista. Taulukko 2: Dokumenttien katselmoinnilla löytyneet ongelmat Dokumentti Ongelmat Käytetty aika Projektisuunnitelma 84 15 Vaatimusmäärittely 25 3,75 Analysaattorin asennus- ja käynnistysohje 4 18,5 Analysaattorin käytönaikainen ohje 23 Simulaattorin asennus- ja käyttöohje 82 Valppaan asennus- ja käynnistysohje 43 WWW-käyttöliittymän sisäinen ohje 43 Yhteensä: 304 37,25 6

Taulukko 3 kuvaa järjestelmän eri osille eri aikoina tehtyjen katselmointien tuloksia. Koodikatselmoinneilla löydettiin myös varsinaisia virheitä, vaikkakin useimmat kommentit liittyivät koodin ulkoasuun. Eniten katselmointiaikaa sai projektin tärkeimpänä osana itse Valpas. Taulukko 3: Koodikatselmoinneilla löydetyt ongelmat osa-alueittain Järjestelmän osa Ongelmat Rivit Aika Ongelmia / 100 riviä Analysaattori 31 960 8,25 3,23 Simulaattori 75 1463 13,75 5,17 Valpas 105 2951 26 3,56 Yhteensä: 211 5374 48 3,93 2.4. Yksikkötestauksen kattavuus Kuva 6 kertoo kuinka yksikkötestien lause- ja haarakattavuudet ovat kehittyneet projektin aikana. Mukana on myös käyttöliittymään liittyvät luokat, vaikka käyttöliittymään liittyviä luokkia ei oletettu yksikkötestattaviksi. Käyttöliittymäluokkien erottaminen olisi ollut turhan työlästä pelkkien kattavuusarvojen keräämiseksi, joten sitä ei tehty. 80,00 % 70,00 % 60,00 % 50,00 % 40,00 % 30,00 %,00 % 10,00 % Valpas Lausekattavuus Valpas Haarakattavuus Ilmo-simulaattori Lausekattavuus Ilmo-simulaattori Haarakattavuus Analysaattori Lausekattavuus Analysaattori Haarakattavuus 0,00 % 1.1.1900 2.1.1900 3.1.1900 4.1.1900 5.1.1900 6.1.1900 7.1.1900 8.1.1900 9.1.1900 10.1.1900 11.1.1900 Kuva 6: Lause- ja haarakattavuuksien kehittyminen ajan suhteen 3. Arvio vertaistestauksesta Vertaistestaukseen toimitimme järjestelmän käyttö- ja asennusohjeet sekä tarvittavat järjestelmän osat tutkivaa systeemitestausta ja analysaattorin tutkivaa testausta varten. Vertaistestauksen suoritti vertaisryhmästä kaksi henkilöä, joista toinen (testaaja 1) testasi 4 tuntia, toinen (testaaja 2) 5,5 tuntia. Testaaja 1 löysi 5 virhettä. Virheistä kaksi oli Valppaan käyttö- ja asennusohjeissa, yksi analysaattorin käyttöohjeessa ja kaksi Valppaan WWW-käyttöliittymästä. Testaaja 2 löysi 10 7

virhettä. Näistä viisi oli simulaattorin asennus- ja käyttöohjeessa, neljä Valppaan asennus- ja käyttöohjeessa ja yksi analysaattorin käyttöohjeessa. Suurempi löytyneiden virheiden määrä johtuu osittain siitä, että testaaja 1 merkitsi pienemmät seikat huomautuksiksi virheiden sijaan. Testaajien testien suorittamisessa oli pieniä ongelmia johtuen pääosin siitä, että testipaketti koottiin Windowsissa mutta testialustana oli Linux, josta aiheutui merkistöongelmia. IRC-neuvottelulla ongelma löydettiin ja korjattiin kohtuullisessa ajassa. Ohjelmat saatiin asennettua ja käyntiin lukuunottamatta Valppaan WWW-käyttöliittymää, jonka käynnistäminen ei onnistunut. Syynä oli testaajille toimitettuun testikoneeseen tehty epäonnistunut Tomcatin asennus. Tomcatia ja muita järjestelmän toimintaan vaadittavien ohjelmien asentamista ei haluttu testauttaa vertaisryhmällä, sillä niiden oli todettu kyllä asentuvan, eikä niiden asennusta nähty riittävän merkittäväksi tuotteen laadun parantamisen kannalta. Testaajat kokivat käyttöohjeet riittäviksi ohjelmien käyttämiseen, joskin korjausehdotuksia saatiin. Osa ehdotuksista oli hyviä, osa pieniä seikkoja joita ei vielä ole nähty tarpeellisiksi korjata. Kriittisiä ongelmia testauksella ei löydetty. Ryhmä sai hieman lisätyötä siitä, ettei toinen testaajista ohjeista huolimatta lisännyt löytämiään virheitä suoraan Bugzillaan. Testauksesta saatiin korjausehdotuksia, mutta niiden määrä ei yltänyt siihen, mitä ryhmä olisi toivonut testauksesta saatavan. Toisaalta myös vertaistestauksen valmistelusta saatiin hyötyä esimerkiksi analysaattorista ei oltu huomattu lainkaan tehdä ajettavaa pakettia ennen kuin testien valmistelu aloitettiin. Kokonaiskuvaksi jäi, että testauksesta oli hyötyä lähinnä siinä mielessä, että ohjeiden toimivuus saatiin testattua ryhmän ulkopuolisilla henkilöillä, ja ne todettiinkin riittäviksi järjestelmän asennukseen ja käyttöön. Uskomme kuitenkin, että vastaavalla työmäärällä ryhmän sisällä olisi saatu selvästi enemmän tuloksia, varsinkin kun myös testauksen koordinointiin kului kohtuullisen paljon ryhmän omaa aikaa. 4. Tavoitteiden täyttyminen Projektissa on ollut seuraavanlaisia tavoitteita: Testitapaukset Suunnitella kattavat testitapaukset käyttötapauksille. Laadunvarmistus Projektin eri tuotoksien laatua varmistetaan staattisin menetelmin. Dokumenttien katselmointi aikaisessa vaiheessa asiakkaan kanssa. Projektin lopussa järjestelmässä ei ole yhtään kriittistä virhettä. Yksikkötestit Jokainen toteutettu luokka läpäisee yksikkötestauksen. Kaikille metodeille, lukuun ottamatta yksinkertaisia getter- ja setter-metodeja, on olemassa automatisoidut yksikkötestit. JUnit-testien kattavuus vähintään 60 80 % muissa kuin käyttöliittymiin liittyvissä luokissa. Paritestaus Löydetään paritestauksessa ainakin 10 virhettä tai muuta ongelmaa. 8

Testitapauksen kattavuuden arvioimiseen ei käytetty projektin aikana aikaa. Ensimmäisessä vaiheessa valmiiden testitapausten joukossa oli hyvin vähän negatiivisia testitapauksia, mikä ei ollut hyvä asia. Toisaalta siinä vaiheessa toteutetut käyttötapaukset olivat myös luonteeltaan sellaisia, että niiden pohjalta olisi ollut haastava kehittää enempää negatiivisia testitapauksia kuin mitä sillä hetkellä oli. Lisäksi ensimmäisessä vaiheessa ei testaajan tuntemus järjestelmästä ollut välttämättä riittävän suuri, mutta kasvoi tarvittaviin määrin projektin aikana. Järjestelmää on kuitenkin testattu kattavasti, joten voidaan katsoa, että tavoite, johon testitapauksiin viittaavalla tavoitteella pyrittiin, on saavutettu. Katselmointiin käytettiin paljon aikaa ensimmäisessä vaiheessa. Valitettavasti asiakas ei useinkaan päässyt dokumenttien katselmointi tilaisuuksiin tai saapui myöhässä. Tämä oli valitettavaa, mutta tavoitteet saavutettiin siinä määrin kuin sen saavuttaminen oli mahdollista. Koodin staattiseen varmistamiseen käytettiin myös katselmointia. Katselmoinnin avulla löydettiin virheitä, joten tavoite täyttyi ja oli hyödyllinen. Yksikkötestaus oli kaikkein vaikein tavoite, vaikkakin sen tavoitteet olivat helpommasta päästä mitata. Aikaa luokka- tai metodikohtaiselle tarkistamiselle ei kuitenkaan projektin puitteissa ollut. Pakettitasolla 60 % kattavuus saavutettiin poikkeuksetta, jos tarkastelualueen ulkopuolelle rajataan käyttöliittymiin liittyvät paketit. Projektin lopuksi myös kaikki yksikkötestitapaukset menivät läpi, vaikka projektin aikana niissä on ollut ongelmia. Vertaistestauksessa toinen testaajamme löysi 24 virhettä ja 11 muuta huomautettavaa kohtaa ja toinen testaaja 14 virhettä ja 8 muuta huomautettavaa asiaa. Vaikka tulokset varmasti ovat jonkin verran päällekkäisiä, niin testauksemme täytti sille asetetut tavoitteet, eli uskomme siitä olleen toiselle ryhmälle hyötyä. 5. Yhteenveto Vaikka Valpas-projektin laadunvarmistusprosessi ei välttämättä ole ollut aivan oppikirjan mukainen, on laadunvarmistus osaltaan tyytyväinen projektin lopputulokseen. Ongelmia löydettiin, ne korjattiin ja tärkeimmät osa järjestelmää ovat toimintavarmoja. Hieman ennen hyväksyntätestejä oli ilmassa vielä pelko siitä, että toimisiko järjestelmä varmasti myöhään löydettyjen ongelmien tähden. Ongelmat saatiin kuitenkin korjattua ja jopa testattua ennen hyväksyntätesteihin siirtymistä. Hyväksyntätesteissä asiakkaan kanssa ei ilmennyt ongelmia itse järjestelmässä, järjestelmän ulkopuolisten osien toiminnassa kylläkin. Hyväksyntätestien aikana Valppaan yhteyspalvelin TETRA-verkkoon oli suorituskykytestauksen alaisena, joten viestit eivät aina päätyneet Ilmosimulaatoreille asti. Valpas kuitenkin selvisi hyvin näistä tilanteista. 9