TESTAUSSUUNNITELMA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)

TESTAUSSUUNNITELMA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)

2 1. JOHDANTO 5 1.1. Tarkoitus ja kattavuus 5 1.2. Tuote 5 1.3. Määritelmät, termit ja lyhenteet 5 1.4. Viitteet 5 2. YMPÄRISTÖVAATIMUKSET 6 2.1. Laitteisto 6 2.2. Ohjelmisto 6 2.3. Turvallisuus 6 2.4. Apuvälineet 6 3. HENKILÖSTÖ- JA KOULUTUSVAATIMUKSET 7 3.1. Henkilöstö 7 3.2. Koulutus 7 4. VASTUUALUEET 8 4.1. Moduulitestausryhmä 8 4.2. Integrointitestausryhmä 8 4.3. Järjestelmätestausryhmä 8 4.4. Luovutustestausryhmä? 8 5. VAADITTAVA TULOSAINEISTO 9 6. TESTATTAVAT TOIMINNOT 10 6.1. Moduulit 10 6.2. Käyttäjän toiminnot 10 7. ERIKOISOMINAISUUKSIA 11 7.1. Ominaisuudet joita ei testata 11

3 7.2. Ominaisuudet jotka testataan 11 8. TESTAUKSEN TEHTÄVÄJÄRJESTYS 12 9. TESTAUSMENETTELY JA TESTAUSTAPAUKSET 13 9.1. Testitapaus- ja virheluokat 13 9.2. Menetelmät ja tekniikat 13 9.2.1. Yleiset menetelmät 13 9.2.2. Testaustekniikka 14 9.2.3. Koodikatselmukset 14 9.3. Kattavuus 14 9.4. Rajoitukset 14 9.5. Regressiotestaus 15 10. TESTIN HYVÄKSYMIS- JA HYLKÄÄMISKRITEERIT 16 10.1. Hyväksymiskriteerit 16 10.2. Hylkäämiskriteerit 16 10.3. Vaatimukset testauksen keskeyttämiselle 16 10.4. Vaatimukset testauksen jatkamiselle 16 10.5. Vaatimukset testauksen lopettamiselle 16 11. RISKIEN HALLINTA 17 12. AIKATAULU 18 13. HYVÄKSYJÄT 19 13.1. Testit ja testitapaukset 19 13.2. Koko testaus 19

4 Dokumentin versiot Vers Muuttaja Pvm Muutos Tarkastanut Hyväksynyt 1.0 Niko Stenberg 22.11.2000 Ensimmäinen luonnos Luonnos 1 1.0 Niko Stenberg 24.11.2000 Toinen luonnos, lisäyksiä, korjauksia Luonnos 2 1.0 Harri Kauhanen 11.12.2000 Pieniä korjauksia (ei varsinaisia sisältömuutoksia). Jakelu Vym Comptel Harri Kauhanen, Tuomo Marttila, Juha Parhankangas, Niko Stenberg, Antti Tuomaala Tuija Rinne, Erkki Viitala

5 1. Johdanto 1.1. Tarkoitus ja kattavuus Tämä dokumentti on Vym-projektissa muodostuvan tuotteen yleinen testaussuunnitelma. Sen tarkoitus on toimia runkona ja viitteenä testiprosessin eri vaiheita toteutettessa. Dokumentissa esitellään testauksen yleiset käytännöt ja menetelmät. Järjestelmän testaaminen on osa projektin laatusuunnitelmaa ja tarkoituksena on varmistaa, että tuote täyttää vaatimusmäärittelyssä esitetyt vaatimukset. Tarkoituksena on luonnollisesti myös saavuttaa asiakkaan tyytyväisyys lopputuotteeseen. 1.2. Tuote Tuote on kuvattu dokumentissa Vaatimusmäärittely, kohdassa 1.5. 1.3. Määritelmät, termit ja lyhenteet Dokumentissa mahdollisesti esille tulevia tuotteeseen liittyviä määritelmiä, termejä ja lyhenteitä on kuvattu dokumentissa Tekninen määrittely, kohdassa 1.3. 1.4. Viitteet Nro Dokumentti Selitys 1 Projektisuunnitelma 2 Vaatimusmäärittely 3 Laatusuunnitelma 4 Toiminnallinen määrittely 5 Tekninen määrittely Testiraportit: 6 Testiraportti VYM 7 Testiraportti AMOK 8 Testiraportti XMLReader luokka

6 2. Ympäristövaatimukset 2.1. Laitteisto Testauksen kaikissa vaiheissa käytetään kehityslaitteistoa, eli PC-konetta, johon on asennettu Linux. Järjestelmätestauksessa tullaan vielä tarvitsemaan muitakin koneita, joilla on verkkoyhteys ja selainvalmiudet. 2.2. Ohjelmisto Testaus toteutetaan JDK1.2.2-ympäristössä, PostreSQL-kannalla ja Tomcat-wwwpalvelimella. 2.3. Turvallisuus Testaus suoritetaan koneella, joka ei ole osana firman verkkoa. Itse testaus tulee olemaan sekä verkolle, että testikoneelle melko pienivolyyminen datamäärältään. VYM-koneen opetusalgoritmeja testataan hetkellä, jolloin konetta ei tarvita muuhun käyttöön, koska ne saattavat kuormittaa prosessoria hieman enemmän. 2.4. Apuvälineet Testattaessa tarvitaan käyttäjille, yhteisöille ja palveluille testidataa, jota oli tarkoitus syöttää järjestelmälle XML-muodossa. XML:n tuottoon ei käytetä mitään tiettyä ohjelmaa, mutta sitä pitäisi saada helposti aika paljon. Testivaiheita varten tehdään testiraporttirungot, joita käytetään kaiken testauksen raportointiin. Testiraporttirunkojen tulee olla valmiit ennen ensimmäistä testaustapahtumaa. Käyttöliittymä ei oleellisesti liity Vym-projektin tuotteeseen, vaan se tehdään itse tuotteen demonstrointiin. Tämän vuoksi käyttöliittymän testauksessa tulee vain osoittaa, että kaikki tieto ja syötekentätä löytyvät, tieto on oikeaa ja että interaktio tapahtuu suunnitellulla tavalla.

7 3. Henkilöstö- ja koulutusvaatimukset 3.1. Henkilöstö Kaikki testaus voidaan suorittaa projektin henkilöiden toimesta. Kun projekti on siinä vaiheessa, että portaali on valmis, voidaan testaukseen www-käyttöliittymällä ottaa mukaan muitakin henkilöitä (ainakin asiakas jossain vaiheessa), mutta se ei ole välttämätöntä. Koska testimateriaaliksi vaaditaan lukumäärältään mahdollisimman iso käyttäjäprofiilijoukko, joudutaan testidataa generoimaan päästä. Olisi epärealistista pyytää esim. sataa käyttäjää testaamaan sovellusta ja antamaan tietojaan. 3.2. Koulutus Moduuli- ja integrointitestausta tehdessä testauksessa tulee olla mukana henkilöiden, jotka ovat kyseessä olevia komponentteja toteuttaneet. Näin ollen koulutusta systeemistä ei erikseen tarvita. Myöskään järjestelmätestauksessa ei tarvita erikseen koulutusta, koska ryhmän jäsenent tuntevat projektin ja tuotteen.

8 4. Vastuualueet 4.1. Moduulitestausryhmä Moduulitestauksen suorittavat kokonaisuudessaan henkilöt, jotka ovat moduulin toteuttaneet. Näiden henkilöiden tulee valmistella ja suorittaa jokainen testitapaus ja tuottaa siitä rungon mukainen testiraportti. Valmistelussa testausvastaava voi olla mukana. 4.2. Integrointitestausryhmä Integrointitestauksen suorittavat testausvastaavan kanssa ne projektiryhmän jäsenet, joilla on kattavat tiedot testauksessa toimivista järjestelmän osista. 4.3. Järjestelmätestausryhmä Järjestelmätestaus suoritetaan koko ryhmän tai projektipäällikön nakittaman osajoukon voimin, mukana tulisi olla ainakin testausvastaavan ja laatupäällikön. 4.4. Luovutustestausryhmä?

9 5. Vaadittava tulosaineisto Jokaisesta testistä laaditaan testiraportti, joka talletetaan /vym/src/doc/testaus/raportit hakemistoon. Jokainen testin suorittaja kirjoittaa oman osansa raportista. Testiraportin tulee sisältää ainakin seuraavat tiedot jokaisesta testitapahtumasta: Testin tyyppi (Moduuli-, integrointi- vai järjestelmätestaus, mahd. uusintatestaus) Testattu moduuli/moduulit (moduuli- tai integrointitestauksessa) Testin ajankohta Testauskohteen ohjelmaversio Testin suorittaja(t) ja vastuuhenkilö(t) Testin tulos: Hyväksytty/hylätty, selitys Testiraportista löytyy malli: /vym/src/doc/testaus/raportit/testiraportti_pohja.doc.

10 6. Testattavat toiminnot 6.1. Moduulit Testattavat moduulit määritellään tarkemmin, kun tekninen määrittely on valmis. 6.2. Käyttäjän toiminnot Kaikki toiminnallisessa määrittelyssä esitetyt toteutettavat käyttäjän ja ylläpidon toiminnot testataan. Testaus tehdään vähintään kahden testikäyttäjän ollessa yhteydessä palvelimeen yhtä aikaa.

11 7. Erikoisominaisuuksia 7.1. Ominaisuudet joita ei testata Vaikkakin sovellus pyritään tekemään tehokkaaksi ja tietoturvaakin on ajateltu, ei sen suorituskykyä tai tietoturvaominaisuuksia tulla testaamaan. Myöskään varsinaista tuotetta käyttävälle www-ympäristölle ei aseteta normaaleja vaatimuksia. Sen tulee kuitenkin osoittaa, että itse tuote toimii ja on käytettävissä www-ympäristössä. Sovelluksen toipumista esim. verkkokatkoksesta ei testata, eikä sovellukselle myöskään tehdä rikseen rasitustestiä. Tietokannan ominaisuuksia, kuten relaatioiden poiston toimivuutta ei testata. 7.2. Ominaisuudet jotka testataan Moduulitestausvaiheessa testataan, että syötteet ja palutteet eivät aiheita virhetilanteita. Ensimmäisissä testeissä kokeillaan syötteinä normaaleja arvoja ja todetaan, että systeemi ylipäätään toimii odotettavissa olevilla arvoilla. Tietokannan tapahtumat testataan toteamalla oikean datan tallentuvan kantaan ja saatavan sieltä haettua.

12 8. Testauksen tehtäväjärjestys Moduulien pitää selvitä moduulitestauksesta hyväksytysti, ennenkuin niitä voidaan käyttää integrointitestauksessa. Kaikkien moduulien ei tarvitse olla valmiita ennen ensiimmäistä integraatiotestausta, vaan integraatitestaus voidaan aloittaa kun moduuleista saadaan ryhmiä, joiden sisällä tapahtumat on testattavissa. Järjestelmätestaukseen voidaan ryhtyä vasta kun integraatiotestaukset on hyväksytysti suoritettu. Moduuli- ja integrointitestausvaiheiden keskinäiset järjestykset määrätään, kun tekninen määrittely on valmis.

13 9. Testausmenettely ja testaustapaukset 9.1. Testitapaus- ja virheluokat Testitapaukset on jaettu luokkiin tärkeytensä mukaan. Testitapauksista on aina tuloksena hyväksyminen tai hylkäys, mutta hylkäämistapauksessa voidaan ottaa vielä kantaa virheen laatuun. Tällä on merkitystä koko testin hyväksymiskriteereissä. Virheet on luokiteltu vakavuutensa mukaan seuraavasti: A-luokan virhe: pahin virhe. A-luokan virhe on tyypillisesti virhe, joka aiheuttaa sovelluksen kaatumisen tai muuttumisen käyttökelvottomaksi. Tällaiset virheet pitää ehdottomasti saada korjattua ja testattua uudelleen. B-luokan virhe: virhe aiheuttaa sovelluksen virheellisen toiminnan sisällöllisellä tasolla, mutta ei ohjelmatasolla (ts. ei kaatumisriskiä). Virhe on tyypillisesti informaation virheellistä käsittelyä, joka suoraan vaikuttaa muuhun sovellukseen. Tällaista voisi olla esim. karkeasti väärä laskukaava. Virhe on korjattava ja testattava. C-luokan virhe: virhe ei vaikuta sovelluksen toimintaan ja on lähinnä kosmeettinen. Tyypillinen tällainen virhe voisi olla esimerkiksi numeraalisen tiedon virheellinen formatointi. Riittää että virhe korjataan. Testitapauksille on käytössä on seuraava luokittelu: A-luokan testitapaus: tärkein testitapausluokka. A-luokan testitapauksessa ei saa esiintyä A- tai B-luokan virhettä, tai koko testikierrosta voidaan pitää epäluotettavana. Testikierrosta ei tällöin voida onnistuneesti viedä loppuun. Virhe tulee korjata korkealla prioriteetilla ja suorittaa testikierros uudestaan. B-luokan testitapaus: testitapaus on melko tärkeä. B-luokan testitapaus pitää suorittaa ilman A- tai B-luokan virheitä, jotta seuraavalle testikierrokselle voidaan edetä. Testissä esiin tullut B- tai C-luokan virhe ei kuitenkaan estä testikierroksen suorittamista loppuun. C-luokan testitapaus: vähiten tärkeä testitapausluokka. C-luokan testitapauksessa testattavana on lähinnä kosmeettinen seikka, jolla ei ole toiminnallista vaikutusta muuhun sovellukseen. Testissä ilmi tulleelle B- tai C- luokan virheelle riittää korjaus, jolloin testiä ei tarvitse suorittaa uudelleen. 9.2. Menetelmät ja tekniikat 9.2.1. Yleiset menetelmät Testausta varten luodaan oma hakemisto, jolloin kaikille on selvää missä toimitaan. Testauksessa käytetään versionhallinnasta viimeisiä leimattuja versiota ohjelmakomponenteista (laatusuunnitelman mukaisesti). Tällöin voidaan varmistua siitä, että käytössä on valmis ja ainakin edes yksin toimiva versio. Moduulitestauksessa tästä leimatusta versiosta olisi ehkä vielä syytä tehdä erikseen testiversio, joka sisältäisi debug-informaation tulostusta ja muiden moduulien kutsujen korvaavia toimintoja. Integraatiotestauksessa moduuleja ryhmitellään tarvittaessa kokonaisuuksiin, jotta

14 voidaan varmistua oikeanlaisesta käyttäytymisestä moduulien välillä. Kahden moduulin keskinäinen toiminta tätä välttämättä kerro. Sovelluksen toiminta on sellausta, että testaus voidaan suorittaa erissä. Toisin sanoen esim. aikatauluongelmien vuoksi keskeytettyä testausta ei tarvitse aloittaa alusta, jotta lopputulos voitaisiin selvittää. Joissain tapauksissa ongelman laatu voi olla sitä luokkaa, että pitää turvautua projektisuunnitelmassa (kohta 5.4.) esitettyyn muutosmenettelyyn. 9.2.2. Testaustekniikka Moduulitestauksessa lähdekoodia käytetään apuna testitapausten muodostamisessa. Testiä muodostamassa tulisi olla henkilöiden, jotka ovat kyseistä moduulia toteuttaneet. Jos testauksen (missä vaiheessa tahansa) tuloksena on virheellinen toiminta, täytyy testitapaus toistaa joitakin kertoja, jotta voidaan päätellä onko virhe konsistentti vai sattumanvarainen. Virheluokitusta ei välttämättä voida päättää yhden kerran perusteella. 9.2.3. Koodikatselmukset Koodikatselmuksia on tarkoitus järjestää heti T2-vaiheessa ennen kuin ensimmäisiä ohjelmanpätkiä viedään testattavaksi, eli ensimmäisen kerran jo ennen moduulitestausta ja ennen T4-vaihetta. Koodikatselmus voidaan suorittaa paritarkistuksena. Näin päästään karkeimmista virheistä eroon ennen kuin ohjelmaa viedään testipenkkiin. Koodikatselmuksissa tullaan kiinnittämään suuri huomio myös koodin ulkoasu- ja itsedokumentointiin. 9.3. Kattavuus Testatessa jokainen toiminto toistetaan vähintään kerran. Nyrkkisääntönä voidaan pitää, että A-luokan testit toistetaan 10 kertaa, B-luokan testit 5 kertaa ja C-luokan testit 3 kertaa. Eri kerroilla pitäisi pyrkiä käyttämään eri syötteitä. Todella tiukassa aikataulussa voidaan C-luokan testit hyväksyä yhdellä kerralla. Moduuli- ja integrointitestauksessa tulisi ensimmäisien testien jälkeen toimintoja testata hyvin erilaisilla syötteillä tilanteissa, joissa ei tiedetä syötteen suodattuvan jo jossain aikaisemmassa vaiheessa. Nimenomaan lukuarvoihin (rajoihin) on syytä kiinnittää huomiota. Lisäksi koodin peitto yritetään saada mahdollisimman laajaksi (polkutestaus). 9.4. Rajoitukset Määritellään myöhemmin.

15 9.5. Regressiotestaus Jos A-luokan testitapauksen hylkäämisen jälkeen ongelma on saatu ratkaistua, tulisi tapaus regressiotestata. Alemman tärkeysluokan tapaukset testataan, jos resurssit antavat myöten.

16 10. Testin hyväksymis- ja hylkäämiskriteerit 10.1. Hyväksymiskriteerit Moduuli- ja integrointivaiheessa testi voidaan hyväksyä vain, jos kaikki testitapaukset on suoritettu hyväksytysti. Järjestelmätestauksessa sallitaan C-luokan testitapauksissa 20%:lle epäonnistuminen (B- tai C-luokan virhe) testauksen saadessa silti hyväksynnän. Jos suurempi osa C-luokan testitapauksista hylätään, katsotaan tuotteen laadun olevan jo liian heikko. Korkeamman luokituksen testeistä kaikki B-luokankin testitapaukset pitää läpäistä. 10.2. Hylkäämiskriteerit Jos testitapaus on selvästi luotu väärin, se voidaan hylätä. Tällöin sen laatineet / siitä vastuussa olevat henkilöt joko korjaavat testin, tai joissain tapauksessa testitapaus voidaan päättää poistettavaksi suunnitelmasta. Hylkäys tapahtuu myös, jos testitapahtuman laitteisto ja ohjelmisto ei ole vaaditulla tasolla. Joissain järjestelmätestauksen vaiheissa saatetaan tarvitaan enemmän käyttäjiä kuorman lisäämiseksi. Jos tarvittavaa (ilmoitetaan näissä tapauksissa testikohtaisesti) kuormaa ei saada aikaiseksi A-luokan testitapauksia tehdessä, testi hylätään. 10.3. Vaatimukset testauksen keskeyttämiselle Testaus keskeytetään, jos A-luokan testitapauksessa havaitaan virhe, joka estää testin jatkamisen. Myös jos havaitaan virhe, jota ei välttämättä ole sidottu mihinkään testiin, mutta aiheuttaa kuitenkin välittömiä muutospaineita, voidaan testi keskeyttää. 10.4. Vaatimukset testauksen jatkamiselle Keskeytetyn testin jatkaminen on mahdollista, jos esimerkiksi testiympäristön puutteet on saatu korjattua vastaamaan suunniteltua alustaa. Jos edellisessä kohdassa mainitun kaltainen virhe on saatu korjattua, voidaan testiä jatkaa. Tällöin pitää ottaa huomioon myös regressiotestaus. 10.5. Vaatimukset testauksen lopettamiselle Testi lopetetaan kun kaikki testitapaukset on suoritettu kuten kohdassa 9.3. on mainittu. Muussa tapauksessa testauksen voi lopettaa omalla päätöksellään projektipäällikkö tai testausvastaava. Lopettavaan päätökseen johtavia syitä voivat olla esim. järjestelmätestauksessa puutteellinen testiympäristö, resurssipula, jos testaukseen käytetty aika lähestyy kohtuutonta. Tarkennetaan myöhemmissä versioissa.

17 11. Riskien hallinta Projektisuunnitelmassa koko projektille määritetyt riskit huomioidaan myös testauksen osalta. Alla on lisäksi kuvattu testaukselle ominaisia selvimpiä riskitekijöitä: Riskin kuvaus Testaukseen suunniteltu laitteisto ei ole saatavilla ylläpidon puuttumisen tai laitteistovian takia Koko testauksen suorittamiseksi ennen palautusdeadlinea ei ole riittävästi aikaa Testaukselle sovittu toteuttaja tai vastaava estyy Sovellukseen on jäänyt pahempi virhe, jota ei saada korjattua ja uudelleentestattua Testitapauksia ei ole osattu suunnitella oikein Varasuunnitelma Testeille rakennetaan uusi ympäristö, tai vanha korjataan laitteistovian tapauksessa Testiresurssien uudelleenharkinnalla voidaan yrittää nopeuttaa testauksen kulkua (esim. kokemus) Joistain testitapauksista voidaan luopua Projektipäällikkö tai testausvastaava voivat päättää testin lopetettavaksi Projektipäällikkö määrää henkilölle sijaisen, jos tarvittavaa asiantuntemusta testauskohteesta suinkin löytyy Projektipäällikkö ja testausvastaava voivat harkita testauksen keskeyttämistä ja muutosta ohjelmistoon Ongelmaa voidaan lähestyä uudelleen niin että ensisijaiset tavoitteet ainakin saavutettaisiin Testitapaukset voidaan suunnitella uudelleen, jotta testaus saadaan suoritettua Joissain tapauksissa voidaan testitapaus poistaa

18 12. Aikataulu Aikataulu moduuli- ja integrointitestauksille voidaan määrätä, kun toteutuksessa saadaan järjestelmään toiminnallisuutta. Järjestelmätestauksen aikataulua mietitään myöhemmin.

19 13. Hyväksyjät 13.1. Testit ja testitapaukset Testin hyväksyy sille määrätty vastuuhenkilö. Yksittäisen testitapauksen hyväksyntä on sen suorittajan (/suorittajien) käsissä. 13.2. Koko testaus Koko testauksen hyväksyvät projektipäällikkö Antti Tuomaala, testausvastaava Niko Stenberg ja laatupäällikkö Harri Kauhanen. Kyseisiltä henkilöiltä vaaditaan testauksen hyväksymisestä loppuraporttiin allekirjoitukset päivämäärineen.