T Tietojenkäsittelyopin ohjelmatyö

Transkriptio

1 T Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä dokumentti on tietokonegrafiikka-algoritmien visualisointiin tarkoitettujen visualisointien ja niiden tekemiseen tarkoitetun ohjelmointirajapinnan testisuunnitelma. Päivämäärä Projektiryhmä Keimo Kirjoittajat Matti Kannala Muutokset PVM Tekijä Versio Selitys Matti Kannala 0.1 Versio ryhmän kommentoitavaksi Iiro Ojala 0.2 Katselmoinnissa tehtyjä muutoksia Matti Kannala 1.0 Viimeistely palautukseen 1

2 Sisällysluettelo 1 n tunniste Johdanto Suunnitelman tarkoitus ja esittely Sanasto Lähteet Yleiskatsaus dokumenttiin Testauksen kohteet Yksikkötestauksen kohteet Järjestelmätestauksen kohteet Hyväksymistestauksen kohteet Kohteet, joita ei testata Testattavat ominaisuudet Jako testisarjoihin Guimon perustoiminnallisuus Visualisaatio 1: Lokaalit valaistusmallit ja materiaaliparametrit Visualisaatio 2: Perustransformaatiot Visualisaatio 3: 3D-kameran parametrit Visualisaatio 4: Globaalit valaistusmallit Visualisaatio 5: Z- ja A-puskuri Hyväksymistestaus Ominaisuudet, joita ei testata Lähtökohdat Konfiguraation hallinta Testitapausten tärkeysluokat Virheiden vakavuusluokat Testaustyökalut Rajoitukset Testien hyväksymis- ja hylkäämisperusteet Yksikkötestien hyväksymis- ja hylkäämisperusteet Testisarjojen hyväksymis- ja hylkäämisperusteet Hyväksymistestauksen hyväksymis- ja hylkäämisperusteet Testauksen keskeyttämisen ja jatkamisen kriteerit Toimitukset Välttämättömät toimitukset Suositeltavat toimitukset Tehtävät testauksessa Ympäristövaatimukset Turvallisuus Tilat Laitteet Ohjelmistot Vastuut Henkilökunta- ja koulutustarpeet Roolit

3 13.2 Henkilöt Koulutus Aikataulu Projektin päävaiheiden aikataulu Tehtävien aikataulu ja status Riskit Riskien mittaaminen Kurssiorganisaatioon liittyvät riskit Asiakkaaseen liittyvät riskit Projektiryhmään liittyvät riskit Yhteenveto riskeistä Testisarjat Testisarjojen rakenne Testisarjat

4 1 n tunniste Keimo_TS_ _1.0 2 Johdanto 2.1 Suunnitelman tarkoitus ja esittely Tämän suunnitelman tarkoituksena on toimia projektisuunnitelmana Keimotietokonegrafiikka-algoritmien visualisointien ja niiden tekemiseen tarkoitetun ohjelmointirajapinnan testausprojektille. Testattava ohjelmisto sisältää Windowsympäristössä toimivan 3D-grafiikkaa sisältävän ohjelman sekä C++-kielisen ohjelmointirajapinnan. Suunnitelmassa kuvataan testausaktiviteetit laajuuksineen, lähestymistavat, resurssit ja aikataulu. Tarkoituksena on luetella testattavat asiat ja ominaisuudet, testaukseen sisältyvät tehtävät, vastuut ja riskit. Testauksessa pyritään löytämään ohjelmiston virheet mahdollisimman tehokkaasti ja aikaisessa vaiheessa. Testauksella pyritään myös varmistamaan ohjelmiston riittävä laatu ennen lopullisen tuotteen luovuttamista ohjelmistoprojektin viimeisessä vaiheessa, luovutuksessa. Testausprojektissa käytetään testausmenetelminä yksikkötestausta, järjestelmätestausta ja hyväksymistestausta. Yksikkötestaus toteutetaan automaattitestauksena käyttäen Junit- ja CppUnit-testauskirjastoja. Järjestelmä- ja hyväksymistestaus suoritetaan ennaltamäärättyjen testisarjojen avulla. Lisäksi projektin aikana suoritetaan ad-hoctestausta ja käytettävyyden parantamiseen käytetään heuristista arviointia. 2.2 Sanasto Alla on esitetty dokumentissa käytetyt keskeiset termit englanniksi ja suomeksi: englanti test plan test suite test case test log test report bug bug report ad-hoc-testing suomi testisuunnitelma testisarja (testitapaussarja) testitapaus testiloki testiraportti virhe virheraportti ad-hoc-testaus (ennalta määräämätön testaus) 4

5 2.3 Lähteet Keimon projektisuunnitelma Keimon käyttäjävaatimusdokumentti Keimon yksikkötestauksen käyttöönottosuunnitelma Keimon heuristisen arvioinnin käyttöönottosuunnitelma CppUnit Home Page, URL: JUnit Home Page, URL: IEEE Standard for software test documentation Burana-virheraportointiohjelma URL: Yleiskatsaus dokumenttiin Luvussa 1 määritellään dokumentin tunniste, josta selviää dokumentin nimi, versio ja päivämäärä. Luvussa 2 esitellään suunnitelman tarkoitus ja käydään lyhyesti läpi testauksen kohde ja käytettävät menetelmät. Luvussa 3 kerrotaan testauksen kohteet ja miten ne on saatavilla testausta varten. Luvussa 4 määritellään, mitä asioita testataan. Luvussa 5 määritellään, mitä asioita ei testata. Luvussa 6 esitellään testauksen lähtökohdat: konfiguraation hallinta, luokitukset, työkalut ja mittarit. Luvussa 7 kerrotaan, millä perusteella testit voidaan hyväksyä tai hylätä. Luvussa 8 kerrotaan, millä perusteella testaus pitää lopettaa ja milloin testausta saa jatkaa. Luvussa 9 määritellään testausprojektissa toimitettavat dokumentit. Luvussa 10 esitellään testauksen tehtävät ja niiden väliset suhteet. Luvussa 11 keskitytään ympäristövaatimuksiin, joita testauksella on. Luvussa 12 kerrotaan henkilöstön vastuut eri vaiheissa. Luvussa 13 esitellään testaushenkilökunta rooleineen ja mahdolliset koulutustarpeet. Luvussa 14 esitellään testausprojektin aikataulu ja status. 5

6 Luvussa 15 määritellään testausprojektin riskit ja analysoidaan niiden vakavuudet. Luvussa 16 esitellään lyhyesti järjestelmä- ja hyväksymistestauksen testisarjat. 3 Testauksen kohteet 3.1 Yksikkötestauksen kohteet Yksikkötestauksessa CppUnit:lla tai JUnit:lla testattavat kohteet ovat ohjelmakoodin luokat, joihin on kirjoitettu yksikkötestejä. Koska yksikkötestit ovat automaattisia, ne ajetaan joka kerta läpi, kun muutettua koodia aiotaan siirtää versionhallintaan. Yksikkötestausta tehdään siis vain kun ohjelmakoodia muutetaan. Aluksi kehittäjä ottaa versionhallinnasta tuoreimman version kaikesta ohjelmakoodista paikalliselle levylle ja tekee muutokset koodiin. Muutosten jälkeen kehittäjä yhdistää samaan aikaan muiden kehittäjien tekemät muutokset paikalliselle levylleen. Yhdistetty versio on versio, jonka moduuleille yksikkötestaus suoritetaan ennen versionhallintaan siirtämistä. Tarkemmat ohjeet yksikkötestaukseen löytyy Keimon yksikkötestauksen käyttöönottosuunnitelmasta. 3.2 Järjestelmätestauksen kohteet Järjestelmätestauksen kohde on aina täysi versio ohjelmistosta. Täysi versio sisältää kaikki version toteutetut visualisaatiot ja käyttöliittymämoduulin Guimon. Järjestelmätestausta varten testaaja hakee versionhallinnasta uusimman asennuspaketin tai sitä vastaavat binäärit, jos asennuspakettia ei ole projektin kyseisessä vaiheessa vielä toteutettu. Sen jälkeen testaaja asentaa testattavan ohjelman testikoneelle. Järjestelmätestaus suoritetaan testitapauksilla, jotka on koottu testisarjoiksi. Testisarjat on dokumentoitu testisarjoittain dokumentteihin, jotka on nimetty testattavan kokonaisuuden mukaan. 3.3 Hyväksymistestauksen kohteet Hyväksymistestauksen kohde on asiakkaalle luovutettava lopullinen versio. Testaaja hakee testattavan version asennuspaketin versionhallinnasta ja asentaa ohjelmiston testauskoneelle. Hyväksymistestauksessa suoritetaan käyttäjävaatimusdokumentin vaatimuksista kirjoitetut testitapaukset. Testitapaukset löytyvät hyväksymistestauksen testisarjadokumentista. 3.4 Kohteet, joita ei testata Projektin ainoat testaamattomat kohteet ovat ohjelmakoodin luokat, joihin ei kirjoiteta yksikkötestejä ja automaattisesti generoidut dokumentit. Testaamattomia luokkia ovat 6

7 luokat, joissa ei ole mitään testattavissa olevaa monimutkaista toiminnallisuutta. Automaattisesti generoidut dokumentit ovat ohjelmakoodista Doxygen-ohjelmalla generoidut dokumentit. Dokumenttien toiminnallisuus tulee riittävästi testattua kehittäjien toimesta, kun he selaavat luokkien määrittelyjä. 4 Testattavat ominaisuudet 4.1 Jako testisarjoihin Järjestelmän ominaisuudet testataan järjestelmä- ja hyväksymistestauksessa. Ominaisuuksien testaus on jaettu testisarjoihin, jotka sisältävät testitapauksia. Järjestelmätestausta varten tehdään 7 testisarjaa: yksi testaamaan käyttöliittymän, Guimon perustoiminnallisuuksia, yksi jokaista visualisaatiota kohden ja yksi hyväksymistestausta varten. Jokaisesta testisarjasta on lueteltu käyttäjävaatimukset, jotka testisarjan tulisi testata ja minkä perusteella testitapauksia kirjoitetaan. Kaikkia visualisaatioita koskevat vaatimukset on jaettu visualisaatioiden testisarjojen kesken siten, että testitapauksissa ei ole toistoa. Hyväksymistestaus koostuu yhdestä kaikki käyttäjävaatimukset kattavasta testisarjasta. Testitapausten prioriteettien määrityksessä käytetään apuna vaatimuksien prioriteetteja. 4.2 Guimon perustoiminnallisuus Käyttöliittymäkomentojen nauhoittaminen Nauhoitusten toistaminen 4.3 Visualisaatio 1: Lokaalit valaistusmallit ja materiaaliparametrit Ohjelman käynnistäminen Visualisoinnin käynnistäminen Materiaaliparametrien säätäminen Paikallinen valaistusmalli: Phong Valojen liikuttaminen 4.4 Visualisaatio 2: Perustransformaatiot Perustransformaatiot Kameroiden navigointi Kappaleiden renderöintitavan muuttaminen Normaalivektorien näyttäminen 7

8 4.5 Visualisaatio 3: 3D-kameran parametrit Kameroiden lisääminen Debug-kameran lisääminen Kameran polttoväli Etu- ja takaleikkaustasot Ortogonaaliperspektiivi 4.6 Visualisaatio 4: Globaalit valaistusmallit Varjojen näyttäminen 4.7 Visualisaatio 5: Z- ja A-puskuri Z-puskurin visualisointi A-puskurin visualisointi 4.8 Hyväksymistestaus Tuote hyväksytään hyväksymistestauksella. Hyväksymistestauksessa testataan, mitkä vaatimuksista ovat toteutuneet. Kaikkia testitapauksia ei tarvitse kirjoittaa, koska ne voidaan suurimmaksi osaksi kerätä muista testisarjoista. Testaa kaikki käyttäjävaatimusdokumentin vaatimukset, jotka voidaan testata 5 Ominaisuudet, joita ei testata Käytettävyys Käytettävyyttä arvioidaan ja parannetaan projektissa heuristisen arvioinnin avulla. Käytettävyyteen liittyviä virheitä saattaa kuitenkin löytyä myös testauksessa, mutta testaus keskittyy lähinnä toiminnallisuuden varmistamiseen. Heuristisesta arvioinnista löytyy lisää tietoa Keimo heuristisen arvioinnin käyttöönottosuunnitelmasta. Luotettavuus Virheen korjauksen tarkistaa virheen löytäjä. Jos virhe on korjaantunut, virhe voidaan sulkea. Projektissa ei suoriteta erityistä korjattujen virheiden tarkistusta kootusti. Suorituskyky Suorituskykyä ei testata millään erityisellä testillä. Suorituskykyä tarkkaillaan projektissa koko ajan ja se yritetään pitää mahdollisimman korkeana, jotta järjestelmä olisi käytettävissä myös hieman hitaammilla koneilla. Jatkokehitettävyys 8

9 Jatkokehitettävyyttä ei testata, johtuen sen vaikeasta testattavuudesta. Siirrettävyys Siirrettävyys varmistetaan ilman erityistä testiä kääntämällä ohjelmakoodi unixjärjestelmässä. Siirrettävyyden testaaminen laajemmassa skaalassa on projektissa vaikeaa, johtuen riittävän monen erilaisen alustan saatavuudesta. 6 Lähtökohdat 6.1 Konfiguraation hallinta Projektin versionhallinta hoidetaan CVS-versionhallintaohjelmalla. Kaikki testaukseen liittyvät dokumentit tallennetaan versionhallintaan. Ennen testauksen aloittamista testaaja hakee testaukseen tarvittavat dokumentit ja uusimman testattavan version versionhallinnasta. Testattavia versioita luodaan testaustarpeiden mukaan. Testausdokumentit sijaitsevat versionhallinnassa hakemistossa project-docs/test-docs/ ja testattavat ohjelmaversiot sijaitsevat hakemistossa releases/. Järjestelmä- ja hyväksymistestausta varten luodaan versionhallintaan seuraavat testattavat versiot (asennuspaketit): Guimo testiversio1 (järjestelmätestaus) Keimo testiversio1 (järjestelmätestaus) Keimo testiversio2 (järjestelmätestaus) Keimo testiversio3 (järjestelmätestaus) Keimo testiversio4 (järjestelmätestaus)... Keimo testiversion (järjestelmätestaus) Keimo julkaisuversio1 (hyväksymistestaus) Keimo julkaisuversio2 (jos hyväksymistestaus ei mene läpi) Muut paitsi Guimo ovat helposti asennettavia paketteja. Guimo on Keimo-järjestelmän käyttöliittymäkomponentti, joka on pelkkä java-luokat sisältävä jar-paketti. Jar-paketti käynnistetään testausta varten testikoneen java-tulkilla komennolla: java jar guimo.jar. 6.2 Testitapausten tärkeysluokat Käytettävät testitapausten tärkeysluokat on kuvattu alla olevassa taulukossa. Taulukko 1 Testitapausten tärkeysluokat Vakavuus Kriittinen Tärkeä Normaali Kuvaus Välttämätön ohjelman toiminnalle Keskeinen toiminto tai ominaisuus Lisäominaisuus tai ei-kriittinen toiminto 9

10 6.3 Virheiden vakavuusluokat Vakavuusluokituksena käytetään virheraportointiohjelman Buraran vakavuusluokitusta. Käytettävät virheiden vakavuusluokat on kuvattu alla olevassa taulukossa. Taulukko 2 Virheiden vakavuusluokat Vakavuus Burana Kuvaus Vähäinen Minor Kuten normaali, mutta esiintyy harvoin ja on helposti kierrettävissä. Normaali Normal Normaali ongelma, väärä toiminto, häiritsevä käyttäytyminen jne. Vakava Serious Tekee yhden tai useamman järjestelmän toiminnon käyttökelvottomaksi Kriittinen Critical Tekee koko järjestelmän käyttökelvottomaksi 6.4 Testaustyökalut Testauksessa käytetään Bunara-, JUnit-, CppUnit- ja Word-työkaluja. Burana on kurssin tarjoama www-pohjainen virheraportointijärjestelmä, jonne löydetyt virheet kirjataan. Virheraportin huolellinen täyttäminen on erityisen tärkeää. Jos virhe löydetään testitapauksia suorittaessa, on todella tärkeää kirjata testitapauksen tunniste (ID) virheraporttiin. Sille ei ole omaa kenttää lomakkeessa, joten se kirjataan kentän Synopsis alkuun. Kenttä voisi olla esim. T106 Play-komento ei toimi menulta. Ilman tunnistetta ei virhettä voida mitenkään yhdistää testitapaukseen. Buranan www-osoite on: JUnit- ja CppUnit-työkalut on tarkoitettu yksikkötestausta varten. Työkalut ovat testauskirjastoja, joiden avulla voidaan ohjelmakoodiluokille toteuttaa yksikkötestejä. Näiden työkalujen käytöstä löytyy lisätietoja Keimon yksikkötestauksen käyttöönottosuunnitelmasta tai työkalujen kotisivuilta. Word-tekstinkäsittelyohjelmaa käytetään testauksen dokumentoinnissa. Tämä dokumentti ja testisarjat ovat Word-dokumentteja. Testilokit kirjataan testitapausten yhteyteen dokumentissa sitä varten olevaan taulukkoon. 6.5 Rajoitukset Testauksen rajoituksina on tiettyihin päivämääriin sidottu aikataulu ja projektityhmän henkilöstön määrä. 10

11 7 Testien hyväksymis- ja hylkäämisperusteet 7.1 Yksikkötestien hyväksymis- ja hylkäämisperusteet Yksikkötestausta verifioi koodiin tehdyt muutokset. Jotta ohjelmakoodin muutokset olisivat siirrettävissä versionhallintaan, pitää kaikkien yksikkötestien mennä läpi. Jos yksi tai useampi testi ei mene läpi, on testi hylätty. 7.2 Testisarjojen hyväksymis- ja hylkäämisperusteet Testisarjat koostuvat useista testitapauksista, joilla jokaisella on prioriteetit. Jotta testisarja olisi hyväksytty, pitää seuraavat testisarjan ehdot täyttyä: Kaikki testisarjan kriittisen tärkeysluokan testitapaukset on hyväksytty Korkeintaan 1 kpl tärkeän tärkeysluokan testitapauksista on hylätty Yli puolet normaalin tärkeysluokan testitapauksista on hyväksytty Jotta yksittäinen testitapaus olisi hyväksytty, pitää seuraavat testitapauksen ehdot täyttyä: Kriittisiä tai vakavia virheitä ei löydy Normaaleja virheitä löytyy korkeintaan 1 kpl. Vähäisiä virheitä löytyy korkeintaan 2 kpl. 7.3 Hyväksymistestauksen hyväksymis- ja hylkäämisperusteet Jotta tuotteen hyväksymistestaus menisi läpi, pitää kaikkien testisarjojen ja moduulien yksikkötestaus mennä läpi. 8 Testauksen keskeyttämisen ja jatkamisen kriteerit Testaus keskeytetään, jos ulkoiset syyt siihen pakottavat. Testausta jatketaan välittömästi, kun testauksen keskeyttämisen aiheuttaneet ulkoiset tekijät eivät enää vaikuta. Joissakin tapauksissa voidaan joutua odottamaan uuden testiversion julkaisua. Testaus keskeytetään esimerkiksi seuraavissa tilanteissa: Force Majeure syyt sota, luonnonkatastrofi, yleislakko, poikkeustila, jne. Käytetty tietokonelaitteisto hajoaa Testattava ohjelma ei toimi ollenkaan Jos testisarjan aikana löytyy enemmän kuin 2 kriittistä virhettä 11

12 9 Toimitukset 9.1 Välttämättömät toimitukset Tämä dokumentti sekä siitä tehdyt parannetut versiot. Testisarjat Sisältää joukon testitapauksia. Testitapausten määrittelyt Sisältää kuvaukset yksittäisistä testitapauksista ja niiden kulusta. Testitapaus sisältää tiedot: id, prioriteetti, kuvaus, alkutilanne, askeleet ja odotettu lopputilanne. Testilokit Testitapauskohtainen loki testauksesta. Testiloki sisältää tiedot: testaaja, pvm, testattu versio ja tulos (hyväksytty/hylätty). Virheraportit Virheraportti tehdään Burana-ohjelmalla. Virheraportti sisältää tiedot: virheen löytäjä, organisaatio, moduuli, vakavuus, sisäinen prioriteetti, ohjelman versio, luokka, vastuuhenkilö, korjauksen estimaatio, ympäristö, lyhyt kuvaus (sisältäen testitapauksen id:n), kuvaus, toistaminen ja korjausehdotus. Vaikka Burana hyväksyy vain osittain täytetyt raportit, tarkoituksena on täyttää kaikki kentät. Testiraportit Yhteenvetoraportti testauksesta projektin yhdessä vaiheessa. Testiraportti sisältää: yhteenveto, poikkeukset, kokonaisarviointi, tulosten yhteenveto, evaluointi ja aktiviteettien yhteenveto. Koodirivien raportointi Koodirivien määrä raportoidaan Buranaan mahdollisimman usein. 9.2 Suositeltavat toimitukset Testisarjapohja Dokumenttipohja testisarjoja varten Testitapauspohja Dokumenttipohja testitapausta varten 12

13 10 Tehtävät testauksessa Testauksen tehtävät jakautuvat testausta valmisteleviin, testauksen suorittamiseen liittyviin tehtäviin ja raportointiin. Kaikilla testausprojektin jäsenillä on riittävät taidot mihin tahansa tehtävään. Tehtävien vastuut löytyvät luvusta 12 Vastuut ja tehtävien aikataulu sekä status on kerrottu luvussa 14 Aikataulu. Seuraavassa listassa on lueteltu testauksen tehtävät osineen ja suhteineen: n luonti kirjoitetaan T1-vaiheen aikana. Suunnitelmaan tehdään tarpeen mukaan muutoksia muissa vaiheissa. Testisarjojen luonti Testisarjoja on yhteensä 7 kpl. Testisarjat pitää kirjoittaa ajoissa, ennen vaiheen loppua, jotta testaus ja raportointi ehditään myös tehdä. Testisarjojen testaus Testisarjat suoritetaan ennen vaiheen loppua. Jotta testisarjan suorittaminen onnistuu, pitää testisarja olla luonnollisesti luotu. Testauksessa löydetyt virheet pitää raportoida Buranaan ja testilokit kirjoittaa. Testiraporttien luonti Testiraportit kirjoitetaan vaiheiden T1, T2, T3 ja LU lopuksi. Jotta raportin kirjoittaminen onnistuu, pitää vaiheen testaus olla suoritettu ja niiden testilokit kunnossa. Ad-hoc-testaus Ennalta määräämätöntä järjestelmätestausta. Testauksessa löydetyt virheet pitää raportoida Buranaan. 11 Ympäristövaatimukset 11.1 Turvallisuus Turvallisuusvaatimukset eivät tässä projektissa ole tiukat. Turvallisuuden osalta vaatimukset kohdistuvat lähinnä henkilöstöön ja tietojärjestelmiin. Riittävän turvallisuustason takaa se, että henkilöstö koostuu nuhteettomista Suomen kansalaisista, ja että tietojärjestelmänä käytetään TKK:n atk-keskuksen järjestelmiä. 13

14 11.2 Tilat Projektin henkilöstö työskentelee hajautetusti. Jokainen huolehtii itse omalta osaltaan tarvittavan työskentelytilan järjestämisestä. Testaustilassa pitää olla Internet-yhteys, jotta testattava versio ja dokumentit voidaan hakea versionhallinnasta ja löydetyt versiot raportoida WWW-pohjaisella Buranalla Laitteet Testiympäristö muodostuu tavallisesta PC-tietokoneesta Windows-käyttöjärjestelmällä varustettuna. Jokaiselta projektin jäseneltä löytyy omasta takaa testiympäristön vaatimukset täyttävä kone. Windows 2000 on suositeltavin käyttöjärjestelmä testaukseen Ohjelmistot Varsinaiseen järjestelmä- ja hyväksyntätestaukseen ei tarvita muita ohjelmistoja kuin käyttöjärjestelmä (ks. edellinen kohta). Yksikkötestaukseen tarvitaan JUnit- ja CppUnittyökalut. Virheiden raportointiin WWW-pohjaisella Buranalla tarvitaan WWW-selain. Testaukseen projektin jäsenet järjestävät käyttöönsä seuraavat ohjelmistot: Keimo (testattava ohjelmisto) Word (tekstinkäsittely) Excel (taulukkolaskenta) JUnit- ja CppUnit-työkalut (yksikkötestaus) WWW-selain (virheiden raportointi Buranalla) 12 Vastuut Vastuut jaetaan vaihekohtaisesti. Projektin henkilöstöstä jokainen kykenee hoitamaan minkä tahansa rooleista missä tahansa vaiheessa. Työtehtäviä on kierrätetty vaihtelun ja oppimisen maksimoinnin takia. Roolien tarkat vastuukuvaukset löytyvät luvusta 13 Henkilökunta- ja koulutustarpeet. Seuraavassa taulukossa on jaettu testauksen vastuut vaiheittain: Taulukko 3 Testauksen vastuut vaiheittain Rooli Toteutus 1 Toteutus 2 Toteutus 3 Luovutus Testauspäällikkö Tero Tero Tero Tero Testauksen Matti Johan Iiro Matti suunnittelija 1 Testauksen Yrjö Iiro - - suunnittelija 2 Testaaja 1 Iiro Matti Yrjö Samuli Testaaja 2 - Yrjö Samuli Petri Yksikkötestaus- Tero Samuli Petri Johan 14

15 vastaava 13 Henkilökunta- ja koulutustarpeet 13.1 Roolit Jokaisessa testausvaiheessa tarvitaan seuraavia henkilöitä: Testauspäällikkö 1 kpl o On vastuussa siitä, että ohjelmisto tulee testattua suunnitelman mukaan. o Päivittää testisuunnitelmaa tarpeen mukaan. o Pitää huolen, että testaajille on saatavilla testattava versio. o Pitää huolen, että testauksen suunnittelijat kirjoittavat testitapauksia suunnitelman mukaan. o Pitää huolen, että myös asiakkaalle toimitetaan ohjelmiston versio testattavaksi ja ohjeistaa asiakasta virheiden raportoinissa. o Kirjoittaa vaiheen päätyttyä testiraportin. Testauksen suunnittelija 0-2 kpl o Kirjoittaa testitapauksia testisarjoihin. o Kirjoittaa testisuunnitelmaa. Testaaja 1-2 kpl o Suorittaa valitut testisarjat valitulle ohjelmiston versiolle. o Kirjoittaa testilokit ja raportoi virheistä Buranaan. Yksikkötestausvastaava 1kpl o Pitää huolen, että ohjelmoijat kirjoittavat yksikkötestitapauksia riittävästi. o Pitää huolen, että versionhallinnassa ei ole koodia, joka ei läpäise yksikkötestejä. o Kirjoittaa yksikkötestauksesta testiraporttiin Henkilöt Taulukko 4 Testausprojektin henkilökunta Nimi Rooli koko Sähköposti Puhelin projektissa Johan Engström Projektipäällikkö johan.engstrom@hut.fi Matti Kannala Tuotepäällikkö matti.kannala@hut.fi Iiro Ojala Laatupäällikkö iaojala@cc.hut.fi Yrjö Peussa Konfiguraatiopäällikkö peussa@iki.fi Samuli Laine Järjestelmäarkkitehti, smlaine2@cc.hut.fi ohjelmoija Tero Karras Testauspäällikkö, käyttöliittymäsuunn., ohjelmoija tkarras@cc.hut.fi

16 Petri Kero 13.3 Koulutus Riskienhallintapäällikkö, ohjelmoija Testauksessa käytettävät työkalut eivät vaadi erityistä koulutusta projektiryhmän jäsenille. Virheraportointiohjelma Burana on hyvin yksinkertainen ja helposti käytettävä. Burana sisältää lisäksi hyvät käyttöohjeet. Yksikkötestauksen työkalut JUnit ja CppUnit vaativat enemmän tutustumista. Keimon yksikkötestauksen käyttöönottosuunnitelmasta löytyy korkean tason ohjeet. Esimerkkejä käytännön käytöstä löytyy jo toteutetuista yksikkötesteistä ja työkalujen kotisivuilta ja 14 Aikataulu 14.1 Projektin päävaiheiden aikataulu Projekti jakautuu viiteen vaiheeseen. Testausta tehdään neljässä viimeisessä vaiheessa. Seuraavassa taulukossa on kuvattu korkealla tasolla testauksen sijoittuminen projektin vaiheisiin: Taulukko 5 Testauksen sijoittuminen projektiin Vaihe Viikot Viikot Viikot 49-6 Viikot 7-12 Viikot PS T1 23% T2 23% T3 31% LU 23% 14.2 Tehtävien aikataulu ja status Testausprojekti on aikataulutettu kappaleessa 10 Tehtävät testauksessa määriteltyjen tehtävien mukaan. Yksikkötestausta ei aikatauluteta, koska se tehdään ohjelmoinnin yhteydessä ja testaus on automaattista. Myöskään asiakkaan tekemää testausta ei ole aikataulutettu. Aikaa testausprojektille on kokonaisuudessaan käytettävissä noin 100 tuntia. Kokonaisaika on arvioitu antamalla testaukselle noin puolet yhden henkilön koko työpanoksesta. Aikataulun arvioita ja statusta päivitetään projektin edetessä. Aikataulutusta ei voitu tehdä suhteelliseksi riippuvuuksien avulla, koska projektissa suurin osa on ennaltamäärättyjä ajankohtia. 16

17 Taulukko 6 Testauksen aikataulu ja status T1 Viikot Tehtävä Status Suunniteltu Toteutunut n luonti Valmis 15h 20h Guimo-testisarjan luonti Valmis 3h 6,5h Guimo-testisarjan testaus Valmis 2h 3h Testiraportin luonti Valmis 2h 7h Yhteensä: 22h 35,5h T Tehtävä Status Suunniteltu Toteutunut Ad-hoc-testausta Ei aloitettu 10h Visu1-testisarjan luonti Ei aloitettu 3h Visu1-testisarjan testaus Ei aloitettu 2h Visu2-testisarjan luonti Ei aloitettu 3h Visu2-testisarjan testaus Ei aloitettu 2h Testiraportin luonti Ei aloitettu 2h Yhteensä: 22h T Tehtävä Status Suunniteltu Toteutunut Ad-hoc-testausta Ei aloitettu 15h Visu3-testisarjan luonti Ei aloitettu 3h Visu3-testisarjan testaus Ei aloitettu 2h Visu4-testisarjan luonti Ei aloitettu 3h Visu4-testisarjan testaus Ei aloitettu 2h Visu5-testisarjan luonti Ei aloitettu 3h Visu5-testisarjan testaus Ei aloitettu 2h Testiraportin luonti Ei aloitettu 2h Yhteensä: 32h LU Tehtävä Status Suunniteltu Toteutunut Ad-hoc-testausta Ei aloitettu 5h Hyväksymistestisarjan luonti Ei aloitettu 5h Hyväksymistestisarjan testaus Ei aloitettu 5h Testiraportin luonti Valmis 5h Yhteensä: 20h 15 Riskit 15.1 Riskien mittaaminen Riskien todennäköisyydet on luokiteltu kolmeen eri luokkaan: 3 Suuri 2 Keskinkertainen 17

18 1 Pieni Seuraukset on myös jaettu kolmeen luokkaan: 3 Kriittinen 2 Vakava 1 Lievä Riskin vakavuus lasketaan näiden kahden parametrin tulona. Vakavin riski on Suuri * Kriittinen = 3 * 3 = 9. Lievin riski on Pieni * Lievä = 1 * 1 = Kurssiorganisaatioon liittyvät riskit Ongelma kurssin ohjelmistoissa Todennäköisyys Keskinkertainen, tuntikirjauksessakin oli ongelmia projektin suunnitteluvaiheessa. Seuraus Vakava, ei voida käyttää kurssin pakollista virheraportointiohjelmaa Buranaa. Vakavuus 4 Ennaltaehkäisy Mahdotonta Varasuunnitelma Virheraportointi voidaan tehdä myös esim. Excel:llä. Riski 1 Ongelma kurssin ohjelmistoissa Kurssin testausvaatimukset muuttuvat Todennäköisyys Pieni, muutokset aiheuttaisivat kurssilla suuren hälyn. Seuraus Vakava, testisuunnitelmaan joudutaan tekemään suuria muutoksia ja testauksen aikataulut menevät pieleen. Vakavuus 2 Ennaltaehkäisy Mahdotonta Varasuunnitelma Aikataulut on suunniteltava heti uudestaan, jos vaatimukset muuttuvat. Riski 2 Kurssin testausvaatimukset muuttuvat 15.3 Asiakkaaseen liittyvät riskit Asiakkaan testausvaatimukset muuttuvat Todennäköisyys Keskinkertainen Seuraus Vakava, testisuunnitelmaan joudutaan tekemään suuria muutoksia ja testauksen aikataulut menevät pieleen. Jo suoritetut testit saattavat olla ylimääräistä työtä. Vakavuus 4 Ennaltaehkäisy Asiakkaan kanssa pitää olla sopimukset testausvaatimuksista ja niistä pitää ajoissa keskustella mahdollisimman paljon. Varasuunnitelma Aikataulut on suunniteltava heti uudestaan, jos vaatimukset muuttuvat. 18

19 Riski 3 Asiakkaan testausvaatimukset muuttuvat 15.4 Projektiryhmään liittyvät riskit Henkilöstö vähenee Todennäköisyys Pieni, ryhmän jäsenet ovat terveitä nuoria miehiä ja kaikki ovat hyvin sitoutuneita projektiin. Seuraus Vakava, seitsemän hengen projektissa yhden hengen työpanoksen menettäminen on noin 15% menetys projektin testausresursseihin. Vakavuus 2 Ennaltaehkäisy Mahdotonta, sairastumisia on vaikea ennustaa. Varasuunnitelma Asiakkaan kanssa pitää heti keskustella testausvaatimusten vähentämisestä ja aikataulut on myös heti laadittava uudestaan. Toinen vaihtoehto on siirtää resursseja testaukseen muista aktiviteeteista. Riski 4 Henkilöstö Aikatauluarviot pettävät Todennäköisyys Suuri, projektiryhmällä ei ole kovinkaan paljoa kokemusta testauksen aikataulutuksesta Seuraus Vakava Vakavuus 6 Ennaltaehkäisy Aikatauluihin pitää varata hieman ylimääräistä aikaa, jotta testaukseen varataan tarpeeksi aikaa. Varasuunnitelma Testausta fokusoidaan ohjelman tärkeimpiin alueisiin ensisijaisesti ja aikataulut tarkistetaan, jotta ne eivät pettäisi jatkossa. Jos aikataulu on mitoitettu yläkanttiin, ei siitä ole haittaa (ylimääräinen testaus ei ole pahaksi). Riski 5 Aikatauluarviot pettävät Resurssien puute Todennäköisyys Keskinkertainen, projektiryhmällä ei ole kovinkaan paljoa kokemusta testauksen resurssien allokoinnista, mutta toisaalta resursseja voidaan ottaa muista tehtävistä tilapäisapuun. Seuraus Vakava, kaikkea suunniteltua testausta ei saada suoritettua ja ohjelmaan saattaa jäädä pahoja virheitä. Vakavuus 4 Ennaltaehkäisy Suunnitelmat pitää tehdä tarkasti ja tehtävät pitää pilkkoa mahdollisimman pieniin osiin, joita on helpompi arvioida. Varasuunnitelma Resursseja voidaan ottaa muista tehtävistä, jos tilanne näyttää pahalta. Riski 6 Resurssien puute 19

20 Testattavaa ohjelmistoa ei saada testaukseen Todennäköisyys Pieni, ohjelmistoa kehitetään siten, että versionhallinnassa on aina toimiva versio testaukseen. Seuraus Kriittinen, testaus ei onnistu Vakavuus 3 Ennaltaehkäisy Ennen testauksen alkamista varmistetaan ajoissa, että testattava versio ohjelmasta on saatavilla ja että se on testattavissa. Varasuunnitelma Siirretään testausta hieman eteenpäin, jos se on mahdollista. Riski 7 Testattava ohjelmisto 15.5 Yhteenveto riskeistä Yhdenkään riskin vakavuus ei ole suurinta luokkaa (9) ja vakavuudeltaan seuraavaksi suurinta luokkaa (6) esiintyy vain kerran. Tämä vakavin riski on aikataulujen pettäminen. Käytettävissä olevaa aikaa ja projektin etenemistä on siis seurattava huolella ja kaikkien ryhmän jäsenten pitäisi yrittää parhaansa mukaan varata riittävästi aikaa projektia varten jo ennakkoon. Tärkeintä on, että ohjelmisto tulee testattua riittävällä tasolla, vaikka jokin riski toteutuisikin. Tähän tavoitteeseen voidaan päästä riskien ennaltaehkäisyllä ja varasuunnitelmilla. 16 Testisarjat 16.1 Testisarjojen rakenne Järjestelmä- ja hyväksymistestaus suoritetaan testisarjoilla. Testisarjoja kirjoitetaan yhteensä 7 kpl. Testisarjat koostuvat testitapauksista. Testisarjat on tarkoitettu testaamaan rajattua toiminnallista aluetta. Testisarjadokumentti sisältää seuraavat asiat: Johdanto o Testisarjan tarkoitus o Testiympäristö o Testiympäristön pystytys Testitapaukset o Testitapaus1 Id T101 Prioriteetti Kriittinen Tärkeä Normaali Kuvaus Alkutilanne Askeleet ja odotetut tulokset Odotettu lopputilanne 20

21 16.2 Testisarjat Testiloki (taulukko) PVM Testattava versio Testaaja Löytyneiden virheiden Id:t Hyväksytty / hylättty o Testitapaus2 Id T102 jne. Jokainen testisarja on oma dokumentti. Kaikkia testisarjoja ei ole tarkoitus kirjoittaa heti projektin alussa, vaan ne kirjoitetaan vähitellen projektin edetessä luvun 14 Aikataulu mukaan. Seuraavat testisarjadokumentit kirjoitetaan projektin aikana: Testisarja_guimo.doc Testisarja_lokaalit_valaistusmallit.doc Testisarja_perustransformaatiot.doc Testisarja_kameran_parametrit.doc Testisarja_globaalit_valaistusmallit.doc Testisarja_z-_ja_a-puskurit.doc Testisarja_hyväksymistestaus.doc 21