Laadunvarmistusdokumentti

Laadunvarmistusdokumentti Dokumentin historia Versio Päiväys Muokkaaja Kuvaus Hyväksytty 1.10 07.11.2005 Rönkkö Kirsi Erotettu omaksi dokumentikseen

Sisällysluettelo 1. Koko projektissa...2 1.1. Tavoitteet...2 1.2. Laadunvarmistusmenetelmät...2 1.2.1. Yksikkötestaus...2 1.2.2. Integraatiotestaus...2 1.2.3. Systeemitestaus...2 1.2.4. Hyväksyntätestaus...3 1.2.5. Tutkiva paritestaus...3 1.2.6. Katselmointi...3 1.3. Testitapaukset...3 1.4. Tuotokset...4 1.5. Vikahallinta...4 1.6. Laatumetriikat...5 1.7. Vastuunjako...5 2. Implementaatio I...6 2.1. Tavoitteet...6 2.2. Testauksen kohteet...6 2.3. Testattavat ominaisuudet...6 2.4. Testien ulkopuolelle jätettävät ominaisuudet...6 2.5. Testien läpäisyvaatimukset...7 2.6. Testausympäristö...7 3. Implementaatio 2...7 1

Johdanto Tässä dokumentissa kuvataan Valpas-projektin laadunvarmistussuunnitelmat ja menetelmät. 1. Koko projektissa Tässä luvussa esitellään koko projektin kannalta tärkeimmät laadunvarmistus asiat. Eri iteraatioiden laatutavoitteet on kuvattu erillisissä kappaleissaan. 1.1. Tavoitteet Projektin lopussa järjestelmässä ei ole yhtään kriittistä virhettä. Projektin eri tuotoksien laatua varmistetaan staattisin menetelmin. Jokainen toteutettu luokka läpäisee yksikkötestauksen. Kaikille metodeille, lukuun ottamatta yksinkertaisia getter- ja setter-metodeja, on olemassa automatisoidut yksikkötestit. 1.2. Laadunvarmistusmenetelmät 1.2.1. Yksikkötestaus Jokainen kehittäjä on vastuullinen kehittämään kirjoittamalleen koodille yksikkötestit. Koska projektissa yksikkötestit tehdään automaattisiksi, voidaan yksikkötestejä tarvittaessa käyttää myös regressiotesteinä. Mikäli koodin ulkoinen käytös syystä tai toisesta muuttuu, tulee muokkaajan tarkistaa, että muutokset päivitetään myös yksikkötesteihin. 1.2.2. Integraatiotestaus Kun järjestelmän eri osat ovat läpäisseet yksikkötestauksen, on projektin testaajan tehtävä suorittaa integraatiotestausta järjestelmän eri kokonaisuuksille. Integraatiotestit pyritään myös tekemään automatisoiduiksi, jolloin myös näitä voidaan käyttää regressiotestauksessa. Testaajan tulee myös huolehtia siitä, että integraatiotestit pysyvät ajantasaisina vaatimusten muuttuessa. Integraatiotestauksessa pyritään suorittamaan myös mahdollisuuksien mukaan järjestelmän eri osien rasitus- ja suorituskykytestausta, sillä projektin tapauksessa testien järjestäminen järjestelmän osille voi olla helpompaa kuin koko järjestelmälle. 1.2.3. Systeemitestaus Kun järjestelmä on perusosiltaan kasassa ja jotain toiminnallisuutta on saatu toteutettua, aloitetaan järjestelmän systeemitestaus niiltä osin kuin se on mahdollista. Systeemitestauksen suorittavat testaaja ja laadunvarmistuspäällikkö asiakasta tarpeen mukaan konsultoiden. Systeemitestauksessa huomioidaan toiminnallinen testaus ja mahdollisuuksien mukaan myös suorituskykytestaus. Suorituskykytestauksen laajuutta voi rajoittaa tarpeellisten testauslaitteiden puute. Tästä syystä paljon suorituskyky- ja rasitustestausta pyritään tekemään ohjelman eri osille erikseen. Tarvittaessa muitakin testaustyyppejä käytetään. 2

1.2.4. Hyväksyntätestaus Hyväksyntätestaus sovitaan yhdessä asiakkaan kanssa. Testitapaukset pohjautuvat suurimmaksi osaksi toteutettuihin käyttötapauksiin, joten niitä kehitetään järjestelmän kanssa rinnakkain. Itse hyväksymistesti järjestetään, kun järjestelmä on stabiili ja projektissa on vielä aikaa mahdollisesti löydettyjen puutteiden korjaamiseen. 1.2.5. Tutkiva paritestaus Loppuvaiheessa järjestelmä annetaan testattavaksi toiselle ryhmälle, joka testaa tuotetta tutkivalla menetelmällä. Implementaatio 1:n alkaessa tulee mahdollisimman aikaisessa vaiheessa miettiä alueita, jotka pystytään testaamaan tällä menetelmällä ja jotka hyötyvät mahdollisimman paljon ulkopuolisesta testausryhmästä. Mikäli järjestelmästä löytyy paljon asioita, jotka hyötyvät paritestauksesta, voidaan tätä testausmuotoa käyttää jo aikaisemmassa vaiheessa projektia. 1.2.6. Katselmointi Laadunvarmistukseen käytetään myös mahdollisimman paljon katselmointia. Koodin katselmointia käsitellään tarkemmin Halttusen ja Närjäsen SEPA:ssa Staattisista menetelmistä. Muiden projektissa syntyvien tuotosten kohdalla katselmointi lienee paras keino varmistua niiden laadusta. Katselmointiin osallistuu aina tuotoksen tekijä, testaaja ja laatupäällikkö. Tärkeimpien tuotosten katselmointiin pyydetään tarvittaessa mukaan myös muita johtoryhmän jäseniä. Asiakas pyydetään mukaan katselmointiin, mikäli tuotos on tarkoitettu asiakkalle annettavaksi. Projektin sisäisen dokumentaation katselmointiin asiakasta ei pyydetä mukaan, koska useimmat näistä dokumenteista saattavat olla asiakkaan teknisen tietämyksen ulkopuolella (esimerkiksi yksityiskohtaisemmat arkkitehtuurisuunnitelmat). Joissakin tapauksissa saattaa käydä niin, ettei kaikille osapuolille sopivaa katselmointi aikaa voida enää järjestää lähestyvän aikarajan sisällä. Tällöin katselmointi pyritään järjestämään mahdollisimman suurella osajoukolla ja/tai pyytää tarvittavilta osapuolilta tuotoksen kommentointia esimerkiksi sähköpostin välityksellä. 1.3. Testitapaukset Testitapausten hallinnointiin ei ole erityistä työkalua. Testitapaukset kirjataan Excel-taulukkoon. Samalla taulukolla voidaan raportoida testisession jälkeen, mitkä testitapaukset käytiin läpi ja läpäisikö järjestelmä testin. Testitapauksia kehitetään käyttötapausten ja vaatimusten pohjalta. Lisäksi aina soveltuvissa kohdissa käytetään muunkinlaisia testausmenetelmiä: ekvivalenssiluokkia, reunaehtoja ja pairwisemenetelmää. Testitapausten priorisointiin käytetään seuraavassa taulukossa esiteltyä luokittelua. 3

Taulukko 1: Testitapauksien priorisointiperusteet Prioriteetti Kuvaus Pakollinen Nämä testitapaukset tulee ehdottomasti suorittaa. Ilman näiden suorittamista, järjestelmää ei voida hyväksyä julkaistavaksi. Korkea Nämä testitapaukset tulisi suorittaa, jotta voidaan varmistua järjestelmän julkaisukelpoisuudesta. Normaali Nämä testitapaukset olisi hyvä suorittaa. Matala Suorita nämä testitapaukset vain, jos aikataulu antaa periksi. 1.4. Tuotokset Laadunvarmistusprosessin yhteydessä syntyy seuraavanlaisia dokumentteja: Testilokeja Testiraportti Testitapaukset Ohjeistus vertaistestaukseen Vertaistestausraportti Vikaraportit 1.5. Vikahallinta Löydetyt viat kirjataan Bugzillaan. Bugzilla tarjoaa vioille vakaavuudeksi seuraavat vaihtoehdot: tukkeuttava (blocker), kriittinen (critical), vakava (major), normaali (normal), vähäinen (minor), triviaali (trivial) ja parannusehdotus (enchantment). Projektimme ei tarvitse aivan näin kattavaa erottelua, joten käytämme annetuista vakavuuksista vain muutamia. Näiden merkitys on kuvattu seuraavassa taulukossa. Taulukko 2: Löydettyjen vikojen lajitteluperusteet Vakavuus Kuvaus Kriittinen Kaataa ohjelman, hävittää tietoa Vakava Suurempi puute toiminnallisuudessa, aiheuttaa järjestelmän epästabiiliutta Vähäinen Vähäisempi puute toiminnallisuudessa, käyttöä hankaloittava ominaisuus Triviaali Tuskin huomattava virhe, aiheuttaa käyttäjälle hankaluuksia tuskin ollenkaan Lisäksi Bugzillassa on erilaisia vikojen statuksia, jotka on selvennetty seuraavassa taulukossa. Taulukko 3: Statuksen määrittelyperusteet Status Kuvaus Vahvistamaton (unconfirmed) Kun vikaraportti saadaan projektiryhmän ulkopuolelta, tulee sen statukseksi asettaa vahvistamaton, kunnes voidaan päätellä, että se todellakin esiintyy järjestelmässä. Uusi (new) Uusi vika, jonka kohtalosta ei ole vielä päätetty. Toteutuksessa (assigned) Vika on määrätty korjattavaksi. Tällä statuksella varustetulla vialla täytyy olla myös määritelty vastuullinen korjaaja. Avattu (reopened) Vika, joka on ollut suljettu, mutta havaittu uudestaan tai saatu lisätietoa. Korjattu (resolved) Henkilö, jonka korjattavaksi vika oli määritelty, on mielestään korjannut vian. Tällainen vika odottaa vielä vahvistusta siitä, että korjaus on tehty oikein. Vahvistettu (verified) Laadunvarmistusyksikkö on tarkistanut vian korjauksen ja hyväksynyt sen. Suljettu (closed) Vika, joka on sekä korjattu että vahvistettu tai vika, jota ei ole saatu vahvistettua tapahtuvaksi. 4

Kun vika on joko uusi tai vahvistamaton, tulee laatupäällikön yhdessä pääarkkitehdin kanssa määritellä mitä vialle tehdään ja määritellä tarvittavat resurssit, vian korjaamiseksi. Kun vika on korjattu, tulee korjaus vielä hyväksyä. Vahvistuksen suorittaa laatupäällikkö testiraporttien ja regressiotestin perusteella. Bugzillaan on määritelty helpomman hallinnan mahdollistamiseksi omat osiot järjestelmän kolmelle osiolle. Osiot ovat Analysoija, Ilmo-Simulaattori ja Valpas. 1.6. Laatumetriikat Järjestelmän ja testauksen laatua arvioidaan monella tavalla. Kehittäjien itse kirjoittamien yksikkötestien laatua varmistetaan satunnaisilla pistotarkistuksilla, jotka laatupäällikkö ja testaaja suorittavat. Aluksi pistotarkistukset määräytyvät satunnaisuuden ja osan tärkeyden (mahdollisesti myös saatavuuden) perusteella, mutta myöhemmässä vaiheessa tarkistuksia tehdään enemmän kertyvään kokemukseen pohjautuen. Tarkistuksista kerätään tietoa tarkistetuista testeistä ja siitä läpäiseekö testi tarkistuksen. Läpäisyä arvioidaan miettimällä tehtyjen testien järkevyyttä, tarkoituksen mukaisuutta ja todennäköisyyttä virheiden löytämiseen. Yksikkötestien kattavuutta arvioidaan puolestaan Cobertura-nimisen ohjelman avulla. Ohjelma tarkistaa kuinka suuri osuus koodiriveistä ja -haaroista yksikkötestien avulla on katettu ja koostaa tuloksista visuaalisen WWW-sivun. Cobertura kertoo suoraan prosenttiosuudet koodista, joita voidaan käyttää järjestelmän laadullisen kehityksen arvioimiseen. Lisäksi kerätään seuraavanlaisia tietoja aina kun uutta tietoa on tai vähintään viikoittain: Suoritettujen testitapauksien määrä suhteessa suorittamattomiin. Läpäisseet ja hylätyt testit suhteessa suoritettuihin. Testeissä löytyneiden vikojen määrä vakavuuksittain sekä niiden osuus kaikista vioista. Eri järjestelmän osista löytyneiden vikojen määrä vakavuuksittain. Katselmoinneissa löydettyjen ongelmakohtien määrä. Heuristisessa arvioinnissa löytyneiden vikojen määrä vakavuuksittain. Kerätty materiaali raportoidaan projektin Wikissä ja iteraation lopuksi kasataan kattava raportti projektin tilasta. 1.7. Vastuunjako Testaustiimiin kuuluvat Kirsi Rönkkö (laatupäällikkö) ja Antti Poikela (testaaja). Kirsin tehtävä on enemmän hallinnointipuolella: vikahallinnassa, raportoinnissa, ohjauksessa ja päätösten teossa. Kirsin vastuulle kuuluu myös tarvittaessa laatuun liittyvän koulutuksen järjestäminen kehittäjille ja muulle projektin väelle. Antin vastuulle kuuluvat testitapauksien kirjoittaminen ja testien suorittaminen. Lisäksi automatisoitujen integraatiotestien ja tarvittavien testistubien kehittäminen on Antin vastuulla. 5

2. Implementaatio I 2.1. Tavoitteet Ensimmäisen iteraation tavoitteena on saada laadunvarmistusprosessit kunnolla käyntiin. Erityisesti kaikkien dokumenttien katselmointiin kiinnitetään enemmän huomiota. Tavoitteisiin kuuluu myös varmistaa kehittäjien yksikkötestaustaidot. Lisäksi vikahallinnan aloittaminen ja kehittäminen projektin tarpeet ajatellen kuuluu suunnitelmiin. Testitapauksien osalta pyritään saamaan aikaan kattavat testit iteraatioon valituille käyttötapauksille, sekä saada suoritettua ainakin pakollisen ja korkean prioriteetin testit kyseisistä testitapauksista. 2.2. Testauksen kohteet Testauksen kohteisiin kuuluu kolme osajärjestelmää: Valpas Ilmo-simulaattori Analysoija 2.3. Testattavat ominaisuudet Seuraavassa taulukossa on esitelty ominaisuudet, jotka tässä iteraatiossa pyritään testaamaan. Taulukko 4: Testattavat ominaisuudet Käyttötapaus Järjestelmän osa Ominaisuus Vaatimus Prioriteetti K04 Simulaattori Viestien haku E01 Pakollinen K04 Simulaattori Viestien tallentaminen T05, T06, T07, R03 Korkea K04 Simulaattori Viestien lähetys E01 Pakollinen K04 Simulaattori Viestien tulkinta T31 Korkea K05 Simulaattori Viestin lähetys E01 Pakollinen K06 Analysaattori Tietojen lukeminen Pakollinen K06 Analysaattori Tietojen vertailu T05, T06, T07 Korkea K06 Analysaattori Tietojen esitys Korkea K09 Valpas Tukiaseman hakeminen T32 Normaali K09 Valpas Viestien hakeminen T02, T04, T09, T10, E04 Pakollinen K09 Valpas Perillemenotietojen hakeminen T02, T04, T10, E10 Pakollinen K09 Valpas Viestien lähetys T02, T04, T33, T34, E05 Korkea K09 Valpas Tietojen tallentaminen tietokantaan E08, E10 Korkea K09 Valpas Viestien tallentaminen T05, T06, T07, R03 Korkea K14 Valpas Viestien hakeminen T31 Korkea K14 Valpas Viestien lähetys T31, T34 Korkea K14 Valpas Tietojen tallentaminen tietokantaan T35, E10 Normaali K14 Valpas Viestien tallentaminen T05, T06, T07, R03 Korkea 2.4. Testien ulkopuolelle jätettävät ominaisuudet Seuraava taulukko kertoo ominaisuudet, jotka jätetään testauksen ulkopuolelle, ainakin tässä iteraatiossa. 6

Taulukko 5: Testien ulkopuolelle jätettävät ominaisuudet T-76.4110 Ohjelmistonkehitysprojekti I Käyttötapaus Osa Ominaisuus Vaatimus Prioriteetti K09 Valpas Määräajoin toiminen T01, T03 Matala K14 Valpas Perillemenotietojen hakeminen T31, E10 Matala 2.5. Testien läpäisyvaatimukset Jotta järjestelmän osa läpäisee testin, se ei saa sisältää yhtään kriittisen tai korkean tason virhettä. Jos järjestelmän osa ei läpäise testiä, on tavoitteena, että se korjataan viikon sisällä ja toimitetaan uudestaan testaukseen. Matalamman tason virheet voidaan korjata löysemmällä aikataululla. 2.6. Testausympäristö Ensisijaisesti testausympäristönä käytetään Linux-koneita, mutta myös kehittäjien omat koneet ja muut käytössä olevat koneet kelpaavat. Ilmo-simulaattorin testaamista varten tarvitaan muutama TETRA-puhelin. Testausympäristönä käytetään ensisijaisesti Linux-konetta, mutta tarvittaessa muutkin koneet käyvät. Osa testeistä vaatii Tetra-puhelimen, jolloin 3. Implementaatio 2 Toisen iteraation suunnitelmat käsitellään myöhemmin vaiheen I2 alussa. 7