Testaussuunnitelma Kuopio

Testaussuunnitelma Kuopio

Kuopio, Testaussuunnitelma, 11.12.2001 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 29.11.2001 Matti Peltomäki Ensimmäinen versio 0.2 5.12.2001 Matti Peltomäki Sisäisen katselmoinnin korjaukset. 1.0 10.12.2001 Ossi Jokinen Asiakaskatselmoinnin korjaukset. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 2

SISÄLLYSLUETTELO 1. JOHDANTO...6 1.1 TESTAUKSEN TARKOITUS...6 1.2 TUOTE...6 1.3 TESTAUSYMPÄRISTÖ LYHYESTI...7 1.4 TERMIT...7 1.5 VIITTEET...9 1.6 YLEISKATSAUS DOKUMENTTIIN...9 1.6.1 Johdanto...9 1.6.2 Testausympäristö...9 1.6.3 Henkilöstö- ja koulutusvaatimukset...9 1.6.4 Vastuualueet...9 1.6.5 Tehtäväjärjestys ja testausmenettely...9 1.6.6 Regressiotestaus...10 1.6.7 Testitapaukset...10 1.6.8 Tulosaineisto...10 1.6.9 Testauksen hyväksyminen...10 1.6.10 Riskien hallinta...10 2. TESTAUSYMPÄRISTÖ...10 2.1 PALVELIN...10 2.2 TYÖASEMA...11 2.3 TURVALLISUUSNÄKÖKOHTIA...11 2.4 APUVÄLINEET JA TYÖKALUT...12 3. HENKILÖSTÖ- JA KOULUTUSVAATIMUKSET...12 4. VASTUUALUEET...13 4.1 TESTIRYHMÄ...13 4.2 MODUULITESTAUS...13 4.3 INTEGROINTITESTAUS...13 5. TEHTÄVÄJÄRJESTYS JA TESTAUSMENETTELY...13 5.1 TESTAUKSEN LUONTEESTA...13 5.2 TESTAUSTA ALUSTAVAT TOIMENPITEET...13 5.3 TEHTÄVÄJÄRJESTYS...14 5.3.1 Moduulitasolla...14 5.3.2 Testitapaustasolla...14 5.4 TESTITAPAUSLUOKAT JA TESTITAPAUSTEN NUMEROINTI...15 5.5 VIRHELUOKAT...15 5.6 MENETELMÄT JA TEKNIIKAT...16 5.7 KATTAVUUS...17 6. REGRESSIOTESTAUS...17 7. TESTITAPAUKSET...18 7.1 MODUULITESTAUS...18 7.1.1 Henkilöt-osakokonaisuus...18 Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 3

7.1.2 Asiakkaat-osakokonaisuus...18 7.1.3 Projektit-osakokonaisuus...18 7.2 INTEGROINTITESTAUS...18 7.3 TIETOJEN SIIRRON TESTAUS...18 8. TULOSAINEISTO...18 9. TESTAUKSEN HYVÄKSYMINEN...19 9.1 ALOITUSKRITEERIT...19 9.2 LOPETUSKRITEERIT...19 9.3 HYVÄKSYMISKRITEERIT...19 9.4 HYLKÄÄMISKRITEERIT...20 9.5 KESKEYTTÄMISKRITEERIT...20 10. RISKIEN HALLINTA...20 11. AIKATAULU JA TYÖMÄÄRÄT...22 Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 4

TAULUKOT JA KUVAT Table 1 Termit... 7 Table 2 Virheluokat... 15 Table 3 Keskeyttämiskriteerit... 20 Table 4 Testauksen riskit... 20 Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 5

1. JOHDANTO 1.1 Testauksen tarkoitus 1.2 Tuote Tämän testaussuunnitelman tarkoituksena on määrittää Kuopio-projektin testaus. Tämä dokumentti on tarkoitettu projektiryhmän sisäiseen käyttöön, asiakkaalle sekä kurssin edustajille. Testausprojekti määritellään siten, että toiminnanohjausjärjestelmän Kuopio-projektin puitteissa toteutettavat moduulit ja integraatiot tulevat testatuiksi. Jo valmiina olevia moduuleita ei testata integraatiotestausta lukuunottamatta, eikä niiden testausta dokumentoida Kuopio-projektissa. Projektin ulkopuolelle jäävien osakokonaisuuksien moduulitestausta tai integraatiotestausta ei suunnitella. Järjestelmätestausta ei suoriteta, koska toiminnanohjausjärjestelmää ei kokonaisuudessaan toteuteta Kuopio-projektin puitteissa eikä sen aikana. Dokumentin tavoitteena on määritellä testausprojekti siten, että testattavan järjestelmän vastaavuus projektin vaatimusmäärittelyyn varmistetaan. Testattavia kohteita on priorisoitu niiden tärkeyden mukaan. Testauksessa kerätään tietoa virheistä, ja jaetaan tätä tietoa eteenpäin mahdollisimman tehokkaasti. Tarkoitus on reagoida löydettyihin virheisiin, korjata niitä ja suorittaa regressiotestausta nopeassa tahdissa; niin että löydetyt virheet saadaan suurimmaksi osaksi korjattua jo saman toteutusvaiheen tai viimeistään seuraavan toteutusvaiheen aikana. Testausorganisaatio koostuu Kuopio-projektiryhmästä kokonaisuudessaan, kurssin mentorista sekä asiakkaasta. Käytännössä testausta suorittaa jokainen projektiryhmän jäsen. Kuopio on PK-yritysten toiminnanohjausjärjestelmän luontiin Innofactor Oy:n toimeksiannosta tähtäävä projekti. Se on Teknillisen korkeakoulun kurssin Tietojenkäsittelyopin Ohjelmatyö (T-76.115) harjoitustyö. Testauksen kohteena on Kuopio-projektissa toteutettavat järjestelmän osat ja osien väliset integraatiot. Testattavat osakokonaisuudet ovat Henkilöt, Asiakkaat ja Projektit, näiden integraatio toisiinsa sekä olemassaoleviin osakokonaisuuksiin Kalenteri, Tuotteet, Dokumentit ja Talous. Osakokonaisuuksien tarkempi määrittely löytyy Kuopio-projektin projektisuunnitelmasta ja vaatimusmäärittelystä. Kuopio-projekti vaiheistetaan kurssin vaatimusten mukaisesti. Toteutusvaiheita on kolme, joista jokaisessa toteutetaan yksi osakokonaisuus. Jokainen osakokonaisuus testataan pääsääntöisesti siinä toteutusvaiheessa, jossa se toteutetaan. Mahdollisesti testaus jatkuu myös seuraavaan vaiheeseen, mikäli tulee ongelmia testaukseen käytössä olevan ajan suhteen tai löytyvien virheiden määrä ja/tai niiden korjaukseen kuluva aika on huomattavasti ennakoitua pidempi. Testauksen riskien hallintaa käsitellään tarkemmin luvussa 9. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 6

1.3 Testausympäristö lyhyesti 1.4 Termit Table 1 Termit Testausta varten ohjelmiston toteutuksen tietystä vaiheesta tehdään CVS:n avulla testauskopio, joka asetetaan erikseen määrättävään testauspalvelimeen Innofactorille. Vastaavasti järjestelmän käyttämästä tietokannasta tehdään erillinen testauskopio, joka asetetaan erikseen määrättävään Innofactorin SQL-palvelimeen. Testaus suoritetaan vain tietyllä käyttäjän selain- ja käyttöjärjestelmäkonfiguraatiolla. Termi Kuopio Moduuli Moduulitestaus Selitys Toteutettavan ohjelmistoprojektin nimi. Geneerinen järjestelmän osakomponentti. Yksittäisen moduulin testaus. Integrointitestaus Yhdistetään yhteen moduuleita tai moduuliryhmiä (osajärjestelmiä) ja testataan niiden välisten rajapintojen toimivuutta sekä yhteensopivuutta. Järjestelmätestaus Regressiotestaus Toiminnallinen vaatimus Testauksen kohteena on koko järjestelmä ja tuloksia verrataan vaatimusdokumentaatioon. Uudelleentestausta jota suoritetaan löydetyn virheen korjaamisen jälkeen. Varmistetaan, että virheen korjaus ei ole aiheuttanut virheitä jo kerran toimiviksi testattuihin järjestelmän osiin. Asiakkaan vaatimus siitä miten järjestelmän tulisi toimia. Ei ota kantaa siihen miten vaatimus teknisesti täytetään. Testausosuus Yleisnimitys yksittäisen moduulin moduulitestaukselle, integrointitestaukselle, järjestelmätestaukselle tai tietojen siirron testaukselle. Testitapaus Testiraportti Projektiryhmä Yksittäinen käyttäjälähtökohtainen tapaus, jonka testaaja suorittaa sovellukselle. Testitapaukset ja niiden suorittaminen muodostavat testausprosessin rungon. Testauksen tuloksena syntyvä määrämuotoinen dokumentti. Tarkoittaa projektin toteuttavaa ryhmää Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 7

Termi Asiakas Mentor Innofactor Oy SQL IIS Selitys opiskelijoita. Se henkilö tai taho, jolle projektiryhmä projektin loppuessa luovuttaa projektin lopputuotteen. Asiakkaalla voidaan viitata joko henkilöön (Tik- 76.115 kurssin rooli "asiakas") tai yleisesti asiakkaana toimivan yrityksen edustajaan. Kurssin puolesta projektille määrätty henkilö, joka valvoo projektin kulkua ja neuvoo matkalla tulevissa ongelmissa. Asiakkaan työllistävä yritys, jolle projekti tehdään. Structured Query Language. Tietokantajärjestelmien kyselykieli. Microsoft Internet Information Server, Internetpalvelinsovellus. CVS Concurrent Versioning System. Versionhallintaan käytettävä ilmainen ohjelmisto. Kehitysympäristö Palvelinkoneympäristö, jossa varsinainen ohjelmointi tapahtuu. Testausympäristö Burana Palvelinkoneympäristö, jossa testaus tapahtuu. Kurssin puolesta järjestetty virheiden ja niiden korjauksen raportointiin sekä koodin koon seurantaan tarkoitettu työkalu. Rational Coverage Koodikattavuuden tutkitaan tarkoitettu työkaluohjelmisto. Rational Robot Testitapausten automatisointiin tarkoitettu työkaluohjelmisto. Rational SiteCheck WWW-palveluiden testaukseen suunniteltu työkaluohjelmisto. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 8

1.5 Viitteet Tässä dokumentissa viitataan muihin Kuopio-projektin projektinhallinnallisiin dokumentteihin. Nämä dokumentit sijaitsevat Innofactorin tiedostopalvelimella hakemistossa InnoShare/2 Customer Process/CU145 Kuopio/. Dokumentteja, joihin viitataan, ovat projektisuunnitelma, vaatimusmäärittely, toiminnallinen määrittely, tekninen määrittely ja projektin laatukäsikirja. Dokumentissa viitataan myös testausraporttiin, joka on testauksen kuluessa syntyvä dokumentti, joka tulee sijaitsemaan samassa paikassa. 1.6 Yleiskatsaus dokumenttiin 1.6.1 Johdanto Johdantokappaleessa luonnehditaan projektin testausta, sen suorittamista ja testausympäristöä. Johdannossa kerrotaan lyhyesti, miksi testausta tehdään, mitä testausprosessin keräämällä tiedolla tehdään ja miten siihen reagoidaan. Lisäksi esitellään sellainen dokumentin sisältämä terminologia, jonka ei voi välttämättä olettaa olevan tuttua lukijalle, ja annetaan yleiskatsaus tähän dokumenttiin. 1.6.2 Testausympäristö Kappaleessa kuvataan yksityiskohtaisesti ympäristö, jossa testaus suoritetaan. Kuvattavaan ympäristöön kuuluu sekä palvelin/palvelimet, joilla sovellusta ajetaan, sekä työasema, jolta sovellusta käytetään. Lisäksi kuvataan kaikki testauksessa käytetyt apuvälineet ja työkalut. 1.6.3 Henkilöstö- ja koulutusvaatimukset 1.6.4 Vastuualueet Kappaleessa kerrotaan, mitä vaatimuksia järjestelmän testaaminen ja testaamisen tukitoimintojen suorittaminen aiheuttavat niihin osallistuville henkilöille ja heidän koulutukselleen. Kappaleessa kiinnitetään testaukseen osallistuvien henkilöiden vastuualueen testauksen eri vaiheissa. Periaattena on, että alustavaa testausta tekevät kaikki ohjelmoijat oman työnsä osalta, integraatiotestaukseen osallistuu koko projektiryhmä ja moduulitestaukseen allokoidaan pääsääntöisesti eri resursseja kuin vastaavan moduulin ohjelmointiin tarkempien määrittelyjen mukaisesti. 1.6.5 Tehtäväjärjestys ja testausmenettely Kappaleessa kuvataan, missä järjestyksessä testaus suoritetaan sekä testausta alustavat toimenpiteet kuten testauskonfiguraation luonti. Kappaleessa käsitellään myös yksityiskohtaisesti testitapausten ja ilmenevien virheiden luokittelu vakavuuden ja vaativuuden mukaan, sekä testitapausten numerointi. Lisäksi täydennetään näiden valossa kuvaa testauksessa käytettävistä menetelmistä ja työkaluista. Kappaleessa käsitellään myös testauksen kattavuutta. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 9

1.6.6 Regressiotestaus Kappaleessa kuvataan yksityiskohtaisesti projektissa käytettävän regressiotestauksen periaatteet ja toteutus. 1.6.7 Testitapaukset 1.6.8 Tulosaineisto Kappale sisältää luettelon testitapauksista. Luettelo on yksityiskohtainen ja esittelee testitapaukset ja ennakoitavissa olevat virheet vakavuus- ja vaatimuusluokitusten valossa. Testitapauksen numeroidaan kappaleessa 5 esitettyjen periaatteiden mukaan. Tässä testaussuunnitelman versiossa testitapausluetteloa ei ole. Se laaditaan vaiheessa T2. Kappale kuvaa, millaista tulosaineistoa testauksesta halutaan. Tulosaineistoa on mm. testausraportti ja bugienhallintajärjestelmän sisältämä historiatieto toteutuksen virheiden tilasta. 1.6.9 Testauksen hyväksyminen Kappaleessa kuvataan kriteerit tilanteille, milloin testaus aloitetaan ja lopetetaan, hyväksytään, hylätään tai keskeytetään hyväksymättä tai hylkäämättä. 1.6.10 Riskien hallinta Kappale kertoo, millaisia riskiä projektissa liittyy nimenomaan testaukseen, miten niiden todennäköisyyttä ja vakavuutta on arvioitu. Lisäksi kuvataan, millaisia ennaltaehkäiseviä toimenpiteitä riskeihin liittyy, sekä millaisia suunnitelmia toteutuneiden riskitilanteiden varalle on. 2. TESTAUSYMPÄRISTÖ 2.1 Palvelin Testauspalvelimina toimii fyysisesti eri palvelimet kuin missä ohjelmiston kehitystyö tapahtuu. Palvelimet, joihin testausympäristö luodaan ja konfiguroidaan määrätään myöhemmin. Palvelimina käytetään Innofactorin palvelimia. Testauspalvelimilla pyörivät samat sovelluksen kannalta olennaiset palvelinohjelmistot kuin kehityspalvelimilla. Ohjelmistoina käytetään Microsoft Windows 2000 Advanced Server -käyttöjärjestelmää Microsoft Internet Information Server -www-palvelinohjelmistoa.netlisämoduleineen Microsoft SQL Enterprise -tietokantapalvelinohjelmistoa. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 10

2.2 Työasema Integraatiotestauksessa katetaan sekä konfiguraatiot joissa IIS ja SQL suoritetaan fyysisesti eri palvelinkoneilla että konfiguraatiot, joissa molempia ohjelmistoja pyörittää sama fyysinen palvelinkone. Palvelimien tarkempi laitteisto- ja ohjelmistokokoonpano selviää, kun päätetään mitä Innofactorin palvelimista testaukseen käytetään. Modulitestauksessa tyydytään käyttämään jompaakumpaa em. konfiguraatioista. Testaustyöasemana käytetään samaan lähiverkkoon testauspalvelimien kanssa liitettyä Microsoft Windows 2000 -työasemaa. WWW-selaimena ensisijaisesti Microsoft Internet Explorer 5.5 -selainta, jolla ohjelmiston toimivuus ensisijaisesti varmistetaan. Lisäksi raportointityökalu Burana toimii selainen kautta. Muita tarvittavia ohjelmistoja ovat Microsoft SQL Server Enterprise Manager (alustavassa testauksessa) Rational Coverage (mahdollisesti vaiheesta T2 eteenpäin) Rational Robot (mahdollisesti vaiheesta T2 eteenpäin) Rational SiteCheck (mahdollisesti vaiheesta T2 eteenpäin) Testaustyökalujen käyttötarkoituksia ja -tapoja kuvataan tarkemmin luvussa 2.4. 2.3 Turvallisuusnäkökohtia Testauksen turvallisuudella ymmärretään sitä, että testaus toteutetaan siten, että se aiheuttaa mahdollisimman vähän häiriöitä yrityksen muulle toiminnalle sekä Kuopioprojektissa että muissa projekteissa. Tätä varten toteutetaan muutama lähinnä palvelinjärjestelyihin liittyvä toimenpide, jotka on kuvattu tässä luvussa. Kyseessä on hyvin tietokantaintensiivinen ohjelmisto, jonka kehitysvaiheessa on tarpeen tutkia ja muokata käsin kehitysversion tietokantaa. Tämä aiheuttaa tietokannan epäintegriteettiä, joka saattaa sotkea ohjelman toimintaa ilman, että varsinaisessa ohjelmassa on vikaa. Tästä taas voi aiheutua testitapauksia, joissa havaitaan virheellistä toimintaa em. syistä, jolloin testauksen tuottama tieto järjestelmän toimivuudesta vääristyy. Tilanne korjataan käyttämällä testauksessa erillistä testaustietokantaa, joka luodaan rakenteeltaan identtiseksi kehitysversion tietokannan kanssa. Microsoft IIS -www-palvelinohjelmisto voi myös aiheuttaa palvelinkoneiden jumiutumista etenkin, jos ajetaan tietyllä tavalla virheellistä ohjelmakoodia. Kokemus on osoittanut yhdeksi pahimmista tapauksista nk. ikuiset silmukat, joita saattaa esiintyä. Näissä tilanteissa kokemusten mukaan ikuisessa silmukassa oleva prosessi jää pyörimään palvelimelle pitkäksikin aikaa, mikä hidastaa palvelimen muuta toimintaa haitallisesti. Nämä haitat ehkäistään käyttämällä testauksessa www-palvelinta, jolla ei ajeta yrityksen toiminnan kannalta oleellisia palveluita. Varotoimenpiteistä huolimatta testauksen aikana ja sen takia voi esiintyä ongelmia etenkin palvelimien toiminnassa. Jotta kaikki voisi jatkua ongelmatilanteissa ja niiden jälkeen mahdollisimman häiriöittä, on testauksen ollessa käynnissä aina paikalla oltava Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 11

joku palvelinylläpidon työntekijä päivystämässä ongelmatilanteiden varalta. Mikäli saatavilla ei ole ylläpitäjää, täytyy testausta suorittävassa ryhmässä olla mukana henkilö, joka hallitsee palvelimien toiminnan korjaamisen ongelmatilanteissa. 2.4 Apuvälineet ja työkalut Bugiraportoinnin apuvälineenä projektissa käytetään Burana-raportointityökalua. Se löytyy www-osoitteesta http://www.soberit.hut.fi/t-76.115/01-02/raportointi/burana/ ja sen käyttäminen vaatii www-selaimen, joka jokaisessa testaukseen käytetyssä työasemassa on jo itse ohjelmiston käytön puolesta. Buranassa jokainen raportti kuuluu tiettyyn kategoriaan (subsystem). Kategoriat luodaan järjestelmään ennen testauksen aloittamista testausvastaavan toimesta. Luotavat kategoriat Kuopio-projektin puitteissa ovat: Henkilöt osakokonaisuus Asiakkaat osakokonaisuus Projektit osakokonaisuus Mahdollisesti luodaan myös integrointitestauksen ja tietojen siirron testauksen raporteille oma kategoria. Tästä päätetään myöhemmin. Jokainen uusi testauksessa löydetty järjestelmävirhe aiheuttaa uuden raportin luomisen. Ohjelmoijan kirjoittama korjausmerkintä ja regressiotestauksen raportit ovat päivityksiä olemassaolevaan raporttiin. Raporteissa on alasvetovalikoilla täytettäviä tietoja sekä useita vapaita tekstikenttiä. Myöhemmin tässä dokumentissa (kappaleessa 5.5.) määritetään tarkasti, millaista tietoa kenttiin täytetään. Vaiheessa T2 tutkitaan mahdollisuutta soveltaa Rationalin testaustyökaluohjemistoja projektin tarpeisiin ja päätetään käyttää niitä, mikäli ne katsotaan soveltuviksi. Soveltuvuustutkimuksen tekee testausvastaava. Tutkittavat testaustyökalut ovat: Rational Coverage Rational Robot Rational SiteCheck 3. HENKILÖSTÖ- JA KOULUTUSVAATIMUKSET Kaikilla testaukseen osallistuvilla on tarvittavat pohjatiedot ohjelmistotuotannosta ja Kuopio-järjestelmästä. Jokainen testaukseen osallistuva tutustuu huolellisesti ennen testausta testaussuunnitelmaan ja käytettäviin työkaluihin, niiden käyttöohjeiden avulla omatoimisesti. Käytettävät käyttöohjeet ja muut testauksen esitiedot on kuvattu tarkemmin luvussa 5.1. Testausta alustavat toimenpiteet. Varsinaista koulutusta testaukseen henkilöstölle ei siis ole tarvetta järjestää. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 12

4. VASTUUALUEET 4.1 Testiryhmä Testiryhmä muodostuu koko Kuopio-projektin henkilöstöstä. Testausvastaavana on Matti Peltomäki, ja testausta suorittavat erikseen projektisuunnitelmassa ja kokouspöytäkirjoissa annettujen tehtäväjakojen mukaisesti nimetyt henkilöt. 4.2 Moduulitestaus Jokaisen moduulin ohjelmoi projektisuunnitelmassa määrättävä koko projektiryhmää pienempi ohjelmoijien joukko. Moduulitestaajien joukko määritellään erikseen jokaista modulia kohden siten, että ohjelmoijat ja testaajat ovat eri henkilöt. Testaajia kullekin moduulille voidaan määrätä yksi tai useita. 4.3 Integrointitestaus Integrointitestaukseen tullaan nimeämään integrointitestausryhmä, johon kuuluu ainakin testausvastaava. 5. TEHTÄVÄJÄRJESTYS JA TESTAUSMENETTELY 5.1 Testauksen luonteesta Testaus jaetaan kolmeen osaan: alustavaan testaukseen, modulitestaukseen ja integrointitestaukseen. Osiot toteutetaan valkolaatikkotestauksena. Tämä tarkoittaa sellaista testausta, jossa testitapaukset valitaan testattavan ohjelman toiminnallisten ja teknisten spesifikaatioiden sekä mahdollisesti lähdekoodin mukaan. Myös lähdekoodin kommentointia käytetään hyväksi. Alustavassa testauksessa tutkitaan lisäksi tietokannan sisältöä ennen ohjelmiston toimintoja ja niiden jälkeen. 5.2 Testausta alustavat toimenpiteet Ennen testausta jokainen testaukseen osallistuva päivittää tietonsa Kuopio-projektin testaamisesta ja käytettävistä työkaluista ja niiden käyttötarkoituksesta sekä käyttöohjeista. Jokainen testaaja lukee läpi ja ymmärtää testaussuunnitelman. Lisäksi jokainen tutustuu huolellisesti Burana-raportointityökalun käyttöohjeisiin (http://www.soberit.hut.fi/t- 76.115/01-02/ohjeet/burana_user_guide.html). Buranan ohjeisiin tutustuminen on tärkeää. Ohjelmisto ei aseta henkilökohtaisiin käyttäjätunnuksiin perustuvia rajoituksia sille, mitä käyttäjä saa tai voi tehdä, eikä raporttien poisto ole mahdollista, ja kategorioiden poisto on mahdollista vain kun niihin ei kuulu yhtään raporttia. Ilman kurinalaista käyttöä Buranan tietosisällöstä voi tulla varsin sekavaa, mille on minimalistiset korjausmahdollisuudet. Kategoriat määrätään testaussuunnitelmassa ja ne luo testausvastaava. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 13

Mikäli Rationalin työkaluja päätetään käyttää, testaajat opiskelevat myös Rational Coveragen, Robotin ja SiteCheckin käyttöä tarvittavissa määrin ohjelmistojen käyttöohjeista. Ennen testausta luodaan myös testausympäristö. Sovelluksesta sijoitetaan testipalvelimelle testikopio, joka saadaan CVS-ohjelmiston avulla. Testattavaksi valmista sovellusversiota merkitään CVS-versionhallinnassa tietyllä laatukäsikirjan määrittämällä CVS-tagilla, jonka perusteella sovelluksen testikopioksi saadaan oikea versio. Tietokannan testikopio luodaan testipalvelimelle. Testikannasta tehdään rakenteeltaan samanlainen kuin kehitysversion kannasta teknisen määrittelyn mukaan. 5.3 Tehtäväjärjestys 5.3.1 Moduulitasolla Jokainen ohjelmoija suorittaa alustavaa testausta jatkuvasti ohjelmoinnin yhteydessä. Alustavassa testauksessa on erittäin olennaista tarkastaa huolellisesti tietokannan integriteetin säilyminen eli tutkia tarkkaan, millaista tietoa tietokantaan tallentuu eri suoritusvaiheiden aikana. Epäloogisesti tai vastoin teknistä määrittelyä tallentuva tieto aiheuttaa myöhemmissä vaiheissa pahoja ongelmia, ellei tällaisia tapauksia löydetä kunkin toiminnon toteutuksen aikana. Alustavassa testauksessa ohjelmoija siis varmistaa tekemänsä koodin toimivuuden etenkin tietokannan osalta. Jokaisen toteutettavan moduulin kohdalla moduulitestaus suoritetaan samassa toteutusvaiheessa kuin moduulin toteutus. Moduulit testataan siis: Henkilöt-osakokonaisuus vaiheessa T2 Asiakkaat-osakokonaisuus vaiheessa T2 Projektit-osakokonaisuus vaiheessa T3 Testauksessa löytyneiden virheiden korjaus ja siihen liittyvä regressiotestaus voi kuitenkin siirtyä seuraavan toteutusvaiheen puolelle. Tähän on varauduttu projektin suunnittelussa. Lisäksi lievemmät virheluokat ovat sellaisia, että virheiden korjaus siirtyy seuraavaan vaiheeseen virheluokan määritelmän mukaan. Vaiheissa T3 ja LU suoritetaan lisäksi integraatiotestausta toteutettujen integraatioiden osalta. Sekä moduuli- että integraatiotestauksessa testitapausten keskinäinen järjestys (prioriteetteihin perustuva) löytyy testitapausluettelosta, luokitteluperusteet kerrotaan seuraavassa luvussa. 5.3.2 Testitapaustasolla Yksittäinen testitapaus suoritetaan seuraavan käytännön mukaisesti: testaaja lukee testitapauksen läpi ja ymmärtää sen testaaja alustaa skenaarion kuten testitapauksessa on määritetty testaaja suorittaa testitapauksen toistoineen Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 14

testaaja kirjoittaa testiraporttiin testitapauksen suoritetuksi ja sen tuloksen tässä dokumentissa määritetyn testiraporttiohjeen mukaisesti mikäli testitapaus päättyi virheeseen, testaaja luo uuden tai päivittää vanhaa Buranaraporttia tässä dokumentissa määriteltyjen Burana-raportointiohjeiden mukaisesti testaaja jatkaa seuraavaan testitapaukseen Mikäli tässä dokumentissa määritetyt testauksen keskeytyskriteerit täyttyvät, testaaja ottaa välittömästä yhteyttä ensisijaisesti testausvastaavaan ja testausvastaavan ollessa saavuttamattomissa projektipäällikköön. 5.4 Testitapausluokat ja testitapausten numerointi 5.5 Virheluokat Table 2 Virheluokat Testitapaukset luokitellaan prioriteettijärjestyksessä. Prioriteettejä on kolme: järjestelmän toiminnan kannalta kriittiset ominaisuudet, toiminnan kannalta tärkeät ominaisuudet ja muut ominaisuudet. Testitapausluettelossa jokainen testauslaji (modulitestaus moduleittain, integrointitestaus) on esitetty omana lukunaan, ja jokaisen luvun sisällä testitapaukset numeroidaan ensisijaisesti prioriteetin mukaan. Esimerkiksi Henkilöt-osakokonaisuuden testitapausluettelossa voi olla testitapaukset 1.1-1.38 (kriittisen ominaisuuden prioriteetti), 2.1-2.10 (tärkeän ominaisuuden prioriteetti) ja 3.1-3.42 (matalin prioriteetti). Mikäli kesken testauksen ilmenee tarvetta uusien testitapausten luomiselle, voidaan uusi testitapaus numeroida kahdella eri tavalla. Mikäli uusi tapaus on selkeästi korjaus tai lisäys jo olemassaolevaan tapaukseen (esim. 1.23), nimetään se tapaukseksi 1.23b. Mikäli uusi tapaus on olennaisesti uusi, lisätään se omaan osioonsa prioriteettinsä mukaiselle paikalle seuraavalle vapaalle numerolle. Esimerkiksi jos viimeinen kriittisen ominaisuuden prioriteetillä merkitty testitapaus on 1.32. ja uusi tapaus on samaa prioriteettiä, tulee numeroksi 1.33. Testauksessa havaitut ohjelmiston virheet luokitellaan lähinnä niiden vakavuuden mukaan. Toissijainen luokitteluperuste on se, kuinka nopeasti virhe on saatava korjattua. Nämä vastaavat Buranan raporttilomakkeen alasvetovalikoita Severity ja Internal Priority. Virheluokat, niiden kuvaukset ja vastaavat merkinnät Buranan raporttilomakkeessa on esitetty seuraavassa taulukossa. Virheluokka Kuvaus Esimerkki Severity Internal Priority Kriittinen Estää näkymän toimintojen käytön kokonaan Vakava Estää tietyn toiminnon Sisäänkirjautumine n ei toimi Uuden työntekijän tiedot eivät tallennu Critical Serious Urgent Tilanteesta riippuen Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 15

Virheluokka Kuvaus Esimerkki Severity Internal Priority käytön tai tietokantaan Urgent tai toiminto toimii High virheellisesti haitaten oleellisesti ohjelmiston käyttöä Normaali Mikä tahansa muu kuin kriittinen, vakava tai lievä virhe Tyhjäksi jätetty päivämääräkenttä aiheuttaa ajonaikaisen virheen tallennettaessa Normal Lievä Kirjoitusvirhe Presons Minor Low Tilanteesta riippuen High, Before Release tai Semilow Oikeat Severity ja Internal Priority -määreet Burana-raporteissa ovat olennaisia toimivalle testaus-korjaus-prosessille, koska ne toimivat raporttihakujen hakukriteereinä ja järjestelyperusteina Buranassa. Testitapausluettelossa (luku 7) kerrotaan testitapauskohtaisesti mihin virheluokkaan arvattavissa olevat mahdolliset virheet kuuluvat. Lisäksi siinä tarkennetaan testitapauskohtaisesti Internal Priority -määreen käyttöä. 5.6 Menetelmät ja tekniikat Testausta varten testaaja luo itselleen tarvittavan määrän erilaisia käyttäjätunnuksia Microsoft SQL Server Enterprise Manager -ohjelman avulla. Tunnusten määrä riippuu olennaisesti läpikäytävistä testitapauksista. Etenkin modulitestauksessa voi olla myös, että testaukseen ei tarvita käyttäjätunnuksia. Yksityiskohdat tunnusten luomiseen ovat teknisen suunnitelman tietokantaa käyttävässä osuudessa. Testitapaukset käydään läpi huolellisesti yksi kerrallaan. Toistoja tehdään testitapausluettelon määrittämä määrä ja niissä käytetään mahdollisesti apuna Rational Robot -testaustyökalua. Jossain testitapauksissa määritetään myös yksityiskohtainen testauspolku. Jokaisen testitapauksen läpikäymisen jälkeen kirjoitetaan testiraporttia kyseiseen tapaukseen liittyviltä osin. Mikäli testitapaus aiheutti virheen, kirjoitetaan siitä raportti Buranaan. Raportin kirjoittamisessa on otettava huomioon testaus- ja toteutusvaihe. Mikäli kyseessä on ensimmäinen havainto kyseisestä virheestä, luodaan uusi raportti. Mikäli kyseinen virhe on jo raportoitu, päivitetään olemassaolevaa raporttia. Raportin päivitys tulee kyseeseen etenkin regressiotestauksessa, ja voi olla varsin minimaalinen, mikäli havaitusta virheestä ei saatu olennaista uutta tietoa olemassaolevan lisäksi. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 16

5.7 Kattavuus Burana-raportin sisältö ja muoto ovat olennaisia tekijöitä, joihin kiinnitetään huomiota. Päivittäjän ja raportin luojan henkilöllisyys on ehdottomasti talletettava oikein. Olennaista on liittää raporttiin kaikki tarpeellinen virheeseen liittyvä tieto. Nyrkkisääntönä voidaan pitää, että tieto, jonka tarpeellisuudesta testaaja ei ole varma, sisällytetään raporttiin. Raportin tiedot kirjoitetaan niin yksityiskohtaisesti, että korjauksesta vastaava ohjelmoija pystyy toistamaan virhetilanteen niiden avulla. Koodikatselmoinnit pidetään moduleittain ennen modulitestausta laatukäsikirjan mukaisesti. Kattavuutta säädellään testitapausten luonnin kriteereillä. Tässä testauksessa pyritään mahdollisimman suureen kattavuuteen laadun varmistamiseksi. Toistokerrat säädetään testitapauskohtaisesti ottaen huomioon vakavuusaste. Toistojen määrä pidetään kuitenkin järkevänä käytössä olevat resurssit huomioiden. Erityinen huomio asetetaan dynaamisten tietorakenteiden testaukselle. Dynaamisia tietorakenteita koskevissa testitapauksissa määritetään useita toistokertoja hieman toisistaan poikkeavalla testidatalla, pyrkien samalla mahdollisimman suureen koodikattavuuteen. Tässä käytetään testitapaussuunnittelun apuvälineenä toiminnallisen määrittelyn lisäksi teknistä määrittelyä. Myös raja-arvojen testaukseen kiinnitetään erityistä huomioita testitapausten laadinnassa. Raja-arvolla ymmärretään tilannetta, jossa vapaassa tekstikentässä sallittuina syötteinä ovat numerot 1..100. Tällöin raja-arvosyötteitä, joilla toimintaa testataan ovat 0,1,100 ja 101. 6. REGRESSIOTESTAUS Regressiotestauksen tavoite on varmistua, että aiemmin raportoidut virheet ovat todella korjaantuneet siinä versiossa, jossa ne on määritelty korjatuiksi ja että korjaus ei ole tuottanut uusia virheitä. Tässä projektissa regressiotestausta tehdään aina, kun sovelluksesta on tuotettu uusi korjattu versio. Versioinnin määrittää projektin laatukäsikirja. Regressiotestauksessa testataan edellisessä versiossa virheelliseksi raportoitu testitapaus uudestaan siten, että sen esivaatimuksina olevat testitapaukset tulevat läpikäydyksi rekursiivisesti aina sellaisiin testitapauksiin asti, joilla ei ole esivaatimuksia. Jokaiselle testitapaukselle määritetään yksikäsitteiset esivaatimukset testitapausluettelossa (tämän dokumentin luku 7). Vaiheessa T2 tutkitaan mahdollisuutta käyttää testauksessa apuna testausta automatisoivia työkaluja. Testaus on tärkeää automatisoida niin pitkälle kuin mahdollista, jotta projektiin kiinnitetyillä resursseilla pystytään myös toteuttamaan regressiotestaus mahdollisimman pitkälle. Lisäksi mahdollisissa tulevissa ei Kuopioprojektin puitteissa toteutettavissa versioissa voidaan haluta varmistua sovelluksen toiminnasta useissa eri selaimissa ja käyttöjärjestelmissä. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 17

Testaus pyritään toteuttamaan siten, että kaikki regressiotestauskierrokset jokaisen modulin osalta on ajettu loppuun ts. mikään määritelty testitapaus ei aiheuta virhettä regressiotestatessa ennen integrointitestauksen aloittamista, ettei integrointitestaus havaitse virheiksi yhden modulin virheitä, mikä aiheuttaisi turhaa resursseja kuluttavaa lisätyötä projektin loppuvaiheessa. 7. TESTITAPAUKSET Testitapaukset luodaan ja kirjataan myöhemmin, kun toiminnallinen ja tekninen määrittely ovat siinä määrin valmistuneita, että niiden pohjalta on mielekästä laatia testitapauksia. Tämä tehdään projektisuunnitelman mukaan vaiheessa T2. 7.1 Moduulitestaus 7.1.1 Henkilöt-osakokonaisuus 7.1.2 Asiakkaat-osakokonaisuus 7.1.3 Projektit-osakokonaisuus 7.2 Integrointitestaus 7.3 Tietojen siirron testaus 8. TULOSAINEISTO Burana-raporttien lisäksi testauksen tulosaineisto kerätään testausraportteihin, joihin pyritään saamaan tarkka kronologinen kuvaus testauksen tuloksista. Jokaisen testausosuuden (modulitestaus moduleittain, integrointitestaus, tietojen siirron testaus) tuloksista kirjoitetaan erillinen testausraportti. Testausraportin kirjoittavat testauksen suorittavat henkilöt. Testausraportti sisältää seuraavat yleiset tiedot: testiympäristö testausosuus Lisäksi jokaisesta suoritetusta testitapauksesta kirjataan jokaista testauskierrosta kohden erikseen seuraavat tiedot: testitapauksen numero testaajan nimi toteutusvaihe (PS,T1,...) päivämäärä testattu versio tulos (hyväksytty/hylätty) mahdollisen kirjoitetun Burana-raportin raporttinumero Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 18

Testitapauskohtaiset tiedot kirjoitetaan testiraporttiin testitapausten suoritusjärjestyksessä kronologisesti. Raporttia kirjoitetaan jokaisen suoritetun testitapauksen jälkeen, jotta jatkuvasti on olemassa dokumentaatiota siitä, mitkä testitapaukset on suoritettu. Testausraportin rakenne on esitetty testausraporttimallineessa, joka löytyy Innofactorin tiedostopalvelimelta hakemistosta InnoShare/2 Customer Process/CU145 Kuopio/. Testausraportin valmistuttua testausvastaava viimeistelee testausraportin. Tämä tarkoittaa lukujen Johdanto, Kattavuus ja Yhteenveto tarkoituksenmukaista kirjoittamista. Testitapauskohtaiset tiedot menevät vain pieneltä osin päällekkäin Burana-raportin sisältämien tietojen kanssa. Molempiin on syytä kirjata testitapauksen numero ja testauksen kohteena ollut versio, jotta kyseiset tiedot ovat tarvittaessa mahdollisimman helposti saatavilla. Hyväksytystä ja hylätystä testitapauksesta testausraporttiin kirjatut tiedot eroavat vain siten, että hyväksytystä testitapauksesta kirjata Burana-raportin numeroa. Tarkempi kuvaus mahdollisesta virheestä on aina Burana-raportissa eikä sitä sisällytetä testausraporttiin. 9. TESTAUKSEN HYVÄKSYMINEN 9.1 Aloituskriteerit Modulitestaus voidaan aloittaa jokaisen modulin kohdalta silloin, kun modulista on valmistunut ensimmäinen versio, jonka ohjelmoijat ilmoittavat alustavasti testanneensa. Integrointitestaus voidaan aloittaa kun kaikki modulitestaukset ovat valmistuneet tai keskeytetty siten, että on päätetty jatkaa integrointitestaukseen. Tietojen siirron onnistumisen testaus voidaan aloittaa, kun integrointitestaus on saatu päätökseen ja siirto on toteutettu. 9.2 Lopetuskriteerit Yksittäisen moduulin testaus lopetetaan, kun sen testaus on saatu hyväksyttävästi loppuun tai moduulitestaus on päätetty keskeyttää. Integrointitestaus lopetetaan, kun se on saatu hysäksyttävästi loppuun tai se on päätetty keskeyttää. Tietojen siirron testaus lopetetaan kun se hyväksytään tai keskeytetään. 9.3 Hyväksymiskriteerit Yksittäisen moduulin testaus katsotaan hyväksytyksi, kun uusimpaan versioon, jossa kaikki raportoidut virheet on saatu korjatuksi, on suoritettu testaussuunnitelman mukainen regressiotestaus, joka on todennut raportoidut virheet korjatuksi, eikä löydä uusia. Testaus voidaan myös hyväksyä, kun uusin regressiotestauskierros on löytänyt vain vähäisiä virheitä. Tällaisen päätöksen voi tehdä projektipäällikkö. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 19

Integrointitestauksen hyväksymiskriteerit ovat samat kuin yksittäisellä modulilla. Tietojen siirron testaus luokitellaan hyväksytyksi, kun siirrolle määritellyt testitapaukset on suoritettu hyväksytysti. 9.4 Hylkäämiskriteerit Yksittäinen testausosuus hylätään, kun tietyn vakavuusluokan virheitä on esiintynyt yli sallitun määrän. Kun testaus hylätään, kaikki virheet raportoidaan sekä Buranaan että testiraporttiin. Testiraporttiin tehdään merkintä testauksen hylkäämisestä. Testaus aloitetaan uudestaan, kun sovelluksesta on luotu uusi versio, jossa raportoidut virheet on korjattu. Eri virheluokkien sallitut määrät on esitetty seuraavassa taulukossa jokaiselle testitapausluokalle erikseen. 9.5 Keskeyttämiskriteerit Jos toiminnan kannalta kriittisissä ominaisuuksissa esiintyy kriittisiä virheitä, keskeytetään testauksen kohteena olevan version testaus välittömästi ja testausta jatketaan vasta, kun kriittinen virhe on saatu korjatuksi ja sovelluksesta on luotu uusi versio. Tällöin testaus aloitetaan kyseisen testausosuuden alusta uudestaan. Table 3 Keskeyttämiskriteerit Kriittinen ominaisuus Tärkeä ominaisuus Kriittinen 0 0 0 Vakava 0 1 3 Normaali 0 3 5 Muu ominaisuus Lievä 3 rajoittamaton rajoittamaton 10. RISKIEN HALLINTA Testauksen määrä on aina kompromissi käytettävissä olevien resurssien (aika, raha, välineet, ym.) ja luotettavuudesta saadun varmuuden välillä. Muun muassa resurssien vähyyden selkeä mahdollisuus aiheuttaa huomattavia riskejä. Seuraavassa taulukossa on esitetty nimenomaan Kuopio-projektin testaamiseen liittyvät tärkeimmät riskit, niiden vaikutukset sekä ennaltaehkäisy ja vaikutusten pienentäminen: Table 4 Testauksen riskit Numero Riski Vaikutus Ennaltaehkäisy ja vaikutusten pienentäminen 1 Testausprojektia ei saada riittävän pitkälle projektin puitteissa ja Innofactor joutuu Ohjelmiston valmistumisaikataulu n ylittyminen. Testaus suunnitellaan tarpeeksi hyvin, että toteutunut testauksen määrä ja laatu saadaan maksimoiduksi Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 20

Numero Riski Vaikutus Ennaltaehkäisy ja vaikutusten pienentäminen käyttämään arvioitua selkeästi enemmän rahaa ja resursseja testauksen saamiseksi loppuu, mikä on edellytys halutun luotettavuustason varmistamiselle. 2 Testauksessa löydettävien virheiden korjaamiseen tarvittava aika ylittää selkeästi kurssin aikataulun. 3 Projektiryhmän motivaatio suuntautuu luvattoman vähän testaukseen, koska projektissa on mielenkiintoisempiaki n osa-alueita. Projektille varatut resurssit eivät riitä projektin testauksen läpiviemiseen tyydyttävällä tasolla. Aikataulu Asiakas tyytymätön. pettää. on Testausta ei suoriteta huolellisesti tai testaussuunnitelman mukaan. Aikataulu lipsuu. Testauksen tuottama tieto on ainakin osittain hyödytöntä tai ei tarpeeksi yksityiskohtaista. käytettävissä olevilla resursseilla. Käytännössä ja etenkin jos riski toteutuu, testaus tulee keskittymään vain kaikista olennaisimpiin asioihin ja oikeassa suhteessa projektin kokonaislaatutavoitteisii n. Testaussuunnitelmassa tehdään ohjelmiston ominaisuuksille selkeä priorisointijärjestys, jolla varmistetaan tärkeimpien ominaisuuksien valmiiksi saattaminen ensin. Näin siis olemassa olevat resurssit kohdennetaan priorisoidusti tärkeinä pidettyihin tavoitteeseen. Testaukseen ei välttämättä tarvitse osallistua koko projektiryhmän. Vastuujako ja tehtäväjako on jo tehty ja pyritään jatkossakin tekemään yksittäisten projektiryhmän jäsenten mielenkiinnon ja toivomusten mukaan. Testaustehtäviin asetetaan päällekkäisyyksiä; kukaan ei toimi yksin. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 21

11. AIKATAULU JA TYÖMÄÄRÄT Testauksen aikataulu ja sen vaatima työmäärä on esitetty yksityiskohtaisesti projektisuunnitelmassa. Kuopio2001, vain kurssin T-76.115 arvostelun vaatimaan käyttöön Sivu 22