Tik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Transkriptio

1 Tik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTAUSSUUNNITELMA LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 2.1 Tila: hyväksytty Päivämäärä: Tekijä: Niko Tolvanen Kommentit: Hyväksyi: Maaret Pyhäjärvi, Katariina Ylinen

2 VERSIOHISTORIA Versio Päivämäärä Muutokset Muuttaja Alustava versio Niko Tolvanen Sisäisen katselmoinnin korjaukset tehty Niko Tolvanen Viimeistelty palautukseen ja lisätty sisällysluettelo Niko Tolvanen Muunnettu Word-muotoon. Lisätty tietoturvan testaaminen ominaisuutena. Niko Tolvanen Katselmointikorjaukset tehty Niko Tolvanen Asiakaskatselmoinnin korjaukset tehty Niko Tolvanen

3

4 1. JOHDANTO MÄÄRITELMÄT, TERMIT JA LYHENTEET 1 2. TESTAUKSEN KOHDE 1 3. TESTATTAVAT OMINAISUUDET 1 4. OMINAISUUDET, JOITA EI TESTATA 3 5. MENETELMÄT MODUULITESTAUS TIETOKANNAN TESTAAMINEN JÄRJESTELMÄTESTAUS REGRESSIOTESTAUS HYVÄKSYNTÄTESTAUS EI-TOIMINNALLISTEN OMINAISUUKSIEN TESTAAMINEN KÄYTETTÄVYYSTESTAUS Ryhmäläpikäynti Heuristinen analyysi Käytettävyystesti Tulosten arviointi Testaussuunnitelman muutokset TIETOTURVA TESTATTAVAN KOHTEEN HYVÄKSYMIS-/HYLKÄÄMISKRITEERIT11 7. ALOITUS-, KESKEYTYS- JA JATKAMISKRITEERIT ALOITUSKRITEERIT KESKEYTYSKRITEERIT JATKAMISKRITEERIT TESTAUKSESSA TUOTETTAVA MATERIAALI TARVITTAVA TESTAUSYMPÄRISTÖ VIRHERAPORTOINTI HENKILÖSTÖ, VASTUUT, KOULUTUS AIKATAULU RISKIANALYYSI 15

5 1. JOHDANTO Tämä dokumentti on LiKe-järjestelmän yleinen testaussuunnitelma. Järjestelmän tarkempi kuvaus on järjestelmän toiminnallisessa määrittelyssä ja käyttötapauskuvauksissa. Järjestelmän testaaminen on osa projektissa käytettävää laadunvarmistusprosessia, jonka tavoitteena on asiakastyytyväisyyden aikaansaaminen. Lisätietoja laatuprosessista on projektin laatukäsikirjassa. Testaussuunnitelma ja muu testauksessa tuotettava dokumentointi noudattaa IEEE:n standardia , joka määrittää testauksen hallinnoinnin ja suunnittelun dokumentoinnissa noudatettavat käytännöt. 1.1 MÄÄRITELMÄT, TERMIT JA LYHENTEET LiKe-projektissa käytetyt määritelmät, termit ja lyhenteet on selitetty projektin laatukäsikirjassa. 2. TESTAUKSEN KOHDE Testauksen kohde on liiketoiminnan kehityksen tukijärjestelmä LiKe sen kaikissa vaiheissa. Koska järjestelmä toteutetaan USDP-prosessin mukaan iteratiivisesti ja inkrementaalisesti, testattava kohde laajenee ja sen toiminnallisuus tarkentuu vaihe vaiheelta. 3. TESTATTAVAT OMINAISUUDET Järjestelmästä testattavat toiminnallisuudet perustuvat järjestelmän käyttötapauksiin, jotka määrittävät, millaisia toimintoja järjestelmässä on. Kukin käyttötapaus testataan siten, että varmistetaan sen toiminta sekä oikeilla syötteillä että väärillä syötteillä. Testattavat toiminnot voidaan jakaa korkeimmalla tasolla järjestelmää muokkaaviin ja järjestelmää käyttäviin toimintoihin. Nämä luokat jaetaan edelleen projekteja, dokumentteja ja käyttäjiä koskeviin toimintoihin. Testattavat toiminnot määritetään edellä kuvatulla tavalla ryhmiteltyinä testitapauskuvauksissa, jotka kirjoitetaan Toteutus 2 - vaiheen aikana. Toisaalta toiminnot on jaettava järjestelmän toteutuksen ja hyväksymisen 1

6 kannalta pakollisiin ja suositeltaviin toimintoihin sekä lisäominaisuuksiin. Toimintojen käyttötapauskuvaukset on lueteltu vaatimusmäärittelyssä. Tällä jaolla on merkitystä erityisesti testauksen ja järjestelmän hyväksymisen kannalta: mikäli testauksessa havaitaan pakollisten toimintojen toteutuksen epäonnistuneen, koko järjestelmää ei voida hyväksyä. Toiminnallisuuden lisäksi testataan järjestelmän käytettävyyttä ja luotettavuutta. Näitä mitataan asiakkaan kokeman laadun perusteella, joka on koko projektin laadunvarmistuksen lähtökohta. Järjestelmän tietoturva on myös testauksen kohteena, mutta tietoturvan testaamisen lähtökohtana on tietoturvaan liittyvää toiminnallisuutta toteuttavien komponenttien ja toimintojen testaaminen. Järjestelmä testataan koko laajuudessaan seuraavissa ympäristöissä: Taulukko 1. Koko järjestelmän testaukseen käytettävät ympäristöt Käyttöjärjestelmä Käyttöjärjestelmän kieli Selain Selaimen kieli Internet Explorer Microsoft Windows 98 FI 4.01 (eli Windows98:n FI mukana tuleva IE) Microsoft Windows NT 4 WKS EN Netscape Navigator 4.7 EN Tämän lisäksi järjestelmä testataan perusominaisuuksien suhteen seuraavissa ympäristöissä: 2

7 Taulukko 2. Järjestelmän perustoiminnallisuuden testaukseen käytettävät ympäristöt Käyttöjärjestelmä Käyttöjärjestelmän kieli Selain Selaimen kieli Microsoft Windows 98 FI Netscape Navigator 4.7 EN Microsoft Windows NT 4 WKS EN Internet Explorer 5.5 EN Windows 2000 Professional EN Internet Explorer 5.5 EN Perustoiminnallisuuden testaamiseen vaadittavat testitapaukset määritetään Toteutus 2 - vaiheessa määritetyissä testitapausten kuvauksessa. Mikäli LiKe-järjestelmään toteutetaan käyttäjäsovellus, joka asennetaan erikseen selaimen lisäksi käyttäjän koneelle, tätä sovellusta on testattava Win95 (FI & EN)/Win98 (FI & EN)/NT4 WKS (FI&EN)/NT4 SRV(EN)/Win2k Professional (EN). Palvelinympäristönä käytetään projektin toiminnallisessa määrittelyssä määritettyä ympäristöä. 4. OMINAISUUDET, JOITA EI TESTATA Koska järjestelmälle ei ole asetettu suuria suorituskykyvaatimuksia, sen suorituskykyä ei testata muuten kuin käytettävyyden ja toiminnallisuuden testauksen yhteydessä. Sama pätee virhetilanteista toipumiseen: tämän ominaisuuden toteutumista mitataan asiakkaan subjektiivisen näkemyksen perusteella, sillä järjestelmää ei nähdä organisaatiolle kriittisenä sovelluksena. Organisaation on mahdollista korjata järjestelmää virhetilanteissa manuaalisesti. Järjestelmää ei testata kaikilla mahdollisilla käyttöjärjestelmän kieliversioiden ja selaimen kieliversioiden yhdistelmillä. Testaus rajataan koskemaan kohdassa 3 mainittuja yhdistelmiä. 3

8 5. MENETELMÄT Järjestelmän testaus ei ole laadunvarmistusprosessin ensimmäinen vaihe, vaan projektissa on tavoitteena, että virheet tulisivat esille jo ennen testausvaihetta esimerkiksi katselmointien kautta. Lisäksi käytettävyyttä testataan jo ennen järjestelmän toteuttamista, joten tässäkin pyritään minimoimaan vasta testausvaiheessa esille tulevien korjaustarpeiden ja virheiden määrää. Asiakkaan rooli testauksessa on merkittävä: ryhmä rohkaisee asiakasta testaamaan järjestelmää mahdollisimman aikaisessa vaiheessa ja raportoimaan löytämänsä virheet. Tämä laajentaa projektissa käytössä oleva asiakaskatselmointikäytäntöjä kattamaan myös itse tuotteessa olevien virheiden havaitsemiseen ja raportointiin mahdollisimman aikaisessa vaiheessa. Testaus jakautuu kuuteen osaan: moduulitestaukseen, integrointitestaukseen, järjestelmätestaukseen, käyttöliittymätestaukseen ja regressiotestaukseen sekä asiakkaan suorittamaan hyväksyntätestaukseen. Seuraavassa kutakin osaa käsitellään erikseen. Laatuvastaava kerää tiedot suoritetusta testauksesta, löydetyistä virheistä sekä saavutetusta kattavuudesta ohjelmointivastuullisilta ja koostaa testausraportin. 5.1 MODUULITESTAUS Moduulitestaus kohdistuu järjestelmän osiin itsenäisinä komponentteina. Testauksen toteutuksesta vastaa kunkin osan vastaava ohjelmoija. Moduulien testaamisessa pyritään 90 % kattavuuteen. Mikäli tällainen kattavuus ei ole saavutettavissa, ohjelman koodin rakenteeseen voidaan vielä tehdä tarvittavia muutoksia siten että kuolleen koodin määrää saadaan pienennettyä. Moduulitestaus ajoittuu moduulin koodaamisen perään ennen moduulin tuomista osaksi järjestelmää. Kunkin moduulin kohdalla moduulitestaus tapahtuu ohjelmoijien toimesta siten, että moduulin toiminnallisuutta testataan seuraavissa tapauksissa sen saamien syötteiden suhteen. Oletuarvoiset syötteet. Moduulin normaali käyttö ilman käyttäjän tai muiden osien tekemiä muutoksia moduulin oletuskutsuun. 4

9 Kunkin syötteen ja syötteiden yhdistelmistä ekvivalenssiluokittain hyväksyttävät (normaalit) arvot, hyväksyttävien arvojen ylä- ja alarajoilla olevia arvoja, eihyväksyttäviä arvoja (esim. liian suuria tai pieniä arvoja), ei-sallittuja arvoja (virheellisiä syötteitä). Tässä dokumentissa esitetyt moduulitestauksen periaatteet ovat yleisen tason periaatteita; kunkin moduulin varsinainen testaamistapa esim. eri syötteillä ja eri toiminnallisuuksien suhteen riippuu moduulin sisältämästä toiminnallisuudesta, joten tämän testauksen tarkempi määrittäminen jää moduulin toteuttavan ohjelmoijan omalle vastuulle. Moduulitestauksesta ei kirjoiteta erillisiä testitapauksia, vaan ohjelmoijien suorittama moduulitestaus noudattaa ohjelmiston yleisiä testitapauksia kuhunkin moduuliin soveltuvin osin Tietokannan testaaminen Tietokannan osalta moduulitestaus tapahtuu lähes kokonaan katselmointien kautta, sillä kun tietokantaan ei ole luotu kyselyjä ohjelmallisesti toteuttavia moduuleita, tietokannan testaaminen kirjoittamalla SQL-lauseita on varsin virhealtista eikä tuota parempaa tulosta kuin huolellinen katselmointi tarvittavaan työmäärään nähden. Tietokannan tarkempi testaus tapahtuu siinä vaiheessa, kun tietokantaan kyselyjä ja muutoksia tekevät moduulit on luotu; samalla, kun moduulien toiminta yhdessä tietokannan kanssa testataan, saadaan testattua myös se, että tietokanta toimii määritetyllä tavalla. Tällainen moduulien ja tietokannan yhdessä testaaminen on välttämätöntä koko järjestelmän toiminnan testaamiseksi, ja koska se on myös luotettavin tapa itse tietokannan testaamiseen, tietokannan manuaalinen testaaminen SQL-lauseilla tuo turhaa työtä varmistamatta tietokannan oikeanlaista toimintaa osana koko järjestelmää. 5.2 JÄRJESTELMÄTESTAUS Järjestelmätestauksessa testataan järjestelmää kokonaisuutena toteutetuin osin. Järjestelmätestauksesta vastaa laatuvastaava yhdessä järjestelmäarkkitehdin kanssa. Järjestelmätestausta ei tehdä ennen Toteutus 3 -vaihetta. Tässä projektissa järjestelmätestaus kattaa myös perinteisen integrointitestauksen, jossa 5

10 testataan useiden toimintojen yhdistelmiä; kehitysprosessin ollessa iteratiivinen, järjestelmätestaus kattaa kussakin vaiheessa niin monta toimintoa kuin järjestelmään on siihen mennessä toteutettu. 5.3 REGRESSIOTESTAUS Regressiotestauksen tavoitteena on varmistaa, että aiemmin raportoidut virheet ovat todella korjaantuneet siinä versiossa, jossa ne on määritetty korjatuiksi ja että korjaus ei ole tuottanut uusia virheitä. Tässä projektissa regressiotestausta suoritetaan aina, kun järjestelmästä on luotu uusi versio. Tällöin testataan uudelleen korjatuiksi määritetyt virheet tuottaneet ominaisuudet sekä tehdään uudelleen muuttuneisiin moduuleihin/toimintoihin liittyvät testitapaukset. Regressiotestausta varten testitapausten automatisointi mahdollisimman pitkälle on tärkeää, sillä se nopeuttaa regressiotestausta huomattavasti. Tarkoitus on, että kullekin moduulille/toiminnolle automatisoidaan sen perustoiminnallisuutta testaavat testitapaukset, jotta nämä voidaan suorittaa regressiona kunkin uuden version kohdalla sen mukaan, mitä moduuleja/toimintoja kuhunkin versioon on muutettu. Automatisointia puoltaa myös se, että Web-pohjaisen sovelluksen toiminnallisuutta on testattava useissa eri ympäristöissä (sekä käyttöjärjestelmä- että selainversioiden suhteen). Näin ollen automatisointi voi pienentää testaukseen kuluvaa aikaa merkittävästi. Lisäksi ennen tuotteen hyväksyntätestauksen aloittamista käydään läpi kaikki raportoidut prioriteetin 2 tai sitä korkeamman prioriteetin virheet, jotta voidaan olla varmoja siitä, että nämä virheet on korjattu hyväksyntätestaukseen menevässä versiossa. 5.4 HYVÄKSYNTÄTESTAUS Hyväksyntätestaus ajoittuu Toteutus 4 -vaiheen loppuun ja sen suorittaa asiakas. Hyväksyntätestisuunnitelma laaditaan yhteistyössä asiakkaan kanssa. Hyväksyntätestauksella todennetaan järjestelmän pakollisten ominaisuuksien toteuttaminen ja oikeanlainen toiminta. 6

11 5.5 EI-TOIMINNALLISTEN OMINAISUUKSIEN TESTAAMINEN Järjestelmän ei-toiminnallisista ominaisuuksista testataan lähinnä käytettävyyttä ja tietoturvaa. Järjestelmän suorituskyvylle ja luotettavuudelle asetetut vaatimukset on määritetty käytettävyysominaisuuksien kautta, joten käytettävyystestaus kattaa LiKejärjestelmän tapauksessa myös näiden ominaisuuksien testaamisen Käytettävyystestaus Käyttöliittymätestauksella pyritään varmistumaan asiakkaan tarpeet käyttöliittymän osalta täyttävän järjestelmän tekemisestä. Käyttöliittymätestauksesta vastaa projektin käyttöliittymävastaava Ryhmäläpikäynti Ryhmäläpikäynti yhdistää asiantuntija-arvioiden ja käyttäjätestien ominaisuuksia. Siihen osallistuu asiakkaan eli käyttäjän edustajia, järjestelmän suunnittelijoita sekä käytettävyys asiantuntija. Istunnon aikana järjestelmä käydään läpi paperiproton avulla simuloiden oikeaa järjestelmää. Osallistujat suorittavat heille annettuja tehtäviä ja merkitsevät papereihin ratkaisunsa. Jokainen suorittaa tehtävät ensin itsenäisesti, jonka jälkeen ratkaisuista keskustellaan ryhmässä niin, että käyttäjät puhuvat ensin ja vasta heidän jälkeensä suunnittelijat ja käytettävyyden asiantuntijat voivat esittää omat mielipiteensä. Kaikki paperit kerätään talteen, jolloin niistä voidaan jälkikäteen vielä analysoida mahdollisia ongelmatilanteita. Ensimmäinen ryhmäläpikäynti järjestettiin asiakkaan luona perjantaina Läpikäyntiin osallistui kolme asiakkaan edustajaa, kaksi järjestelmän suunnittelijaa sekä käyttöliittymävastaava. Läpikäynnissä suoritetiin seuraavat tehtävät: 1. Olet juuri palannut viikon talvilomalta takaisin töihin. Haluat selvittää minkäläisiä muutoksia projektien dokumentteihin on tullut. Etsit kaikki muuttuneet dokumentit ja luet ne, jonka jälkeen poistat ne listalta. 2. Yrityksesi liiketoiminnan kehitysprojekti on lähtenyt liikkeelle ja haluat tutustua lukemalla projektiin sisällytettyyn dokumentaatioon. 7

12 3. Kuulut yrityksessäsi tietojärjestelmien kehitysryhmään. Aiemmin laadit muistion, jossa käsiteltiin eri PDM-järjestelmien mahdollisuuksia. Nyt olet saanut tarjoukset kolmelta järjestelmäntoimittajalta ja haluat lisätä hintatiedot aiemmin laatimaasi dokumenttiin. 4. Yrityksessäsi on perustettu uusi projekti, jonka projektipäällikkönä toimit. Haluat perustaa projektille oman dokumentaation ja lisätä siihen haluamasi dokumentit. 5. Huomaat jättäneesi erään tärkeän dokumentin pois projektin dokumenteista ja haluat lisätä sen jälkikäteen mukaan. Haluat myös samalla poistaa kaksi dokumenttia, jotka olet havainnut ylimääräisiksi projektissa. Toinen ryhmäläpikäynti järjestettiin 14.10, jolloin käytiin läpi koko käyttöliittymä yhdessä asiakkaan kanssa ja keskusteltiin järjestelmän toiminnallisuuksista ja niiden toteutuksesta. Näiden ryhmäläpikäyntien perusteella on järjestelmää ja sen käyttöliittymää muokattu vastaamaan paremmin asiakkaan tarpeita Heuristinen analyysi Heuristinen analyysi on asiantuntijamenetelmä, jossa käyttöliittymää arvioidaan ennalta määrättyjä suunnittelusääntöjä vastaan. Käyttöliittymän eri osia verrataan näihin sääntöihin ja tarkistetaan, onko sen suunnittelussa noudatettu suunnitteluohjeita. Heuristisen analyysin tarkoituksena on löytää käyttöliittymästä ongelmia, jotka liittyvät esimerkiksi epäyhteneväisyyksiin (termit, painikkeiden ja toimintojen sijoittelu), toimintojen perumiseen, palautteen puuttumiseen ja virheilmoituksiin. Menetelmässä käytetään Nielsenin kymmentä heuristista sääntöä, joiden avulla sovelluksen eri ikkunoita arvioidaan: 1. Käytä yksinkertaista ja luonnollista dialogia 2. Käytä käyttäjän omaa kieltä 3. Minimoi käyttäjän muistikuorma 4. Ole johdonmukainen 8

13 5. Anna käyttäjälle palautetta 6. Anna selkeät poistumistiet 7. Tarjoa oikopolkuja kokeneille käyttäjille 8. Käytä selkeitä ja havainnollisia virheilmoituksia 9. Vältä virheitä 10. Tarjoa selkeä apu Heuristisen analyysin suorittaa käyttöliittymän suunnittelija ja mahdollisesti myös muita ryhmän jäsenia riippuen ajankohdasta. Jokainen havaittu ongelma arvioidaan asteikolla 1-3 (1=kosmeettinen ongelma, 2=käyttöä haittaava ongelma, 3=käyttöä estävä ongelma) Käytettävyystesti Järjestelmän varsinainen käytettävyystestaus suoritetaan tammi-joulukuussa. Testit suoritetaan asiakkaan edustajilla ja tarkoituksena on testata tyypillisten tehtävien sujumista lopullista järjestelmää simuloivilla staattisilla www-sivuilla. Testeissä tullaan kiinnittämään huomioita erityisesti ryhmäläpikäynnin perusteella löydettyihin ongelmiin ja niihin tehtyihin muutoksiin. Johtuen projektin tiukasta aikataulusta emme tule toteuttamaan suuria muutoksia järjestelmän tekniseen toteutukseen testien pohjalta, vaan ne tulevat toimimaan lähinnä suuntaa antavina vinkkeinä asiakkaalle, siitä miten järjestelmää tulisi kehittää eteenpäin. Testien tarkempi suunnitelma tehdään siinä vaiheessa, kun suunnitteluprosessi asiakkaan kanssa on viety loppuun Tulosten arviointi Tulosten arvioinnin hoitaa käyttöliittymävastaava. Yleiset periaatteet ja rajoitteet projektin puolelta sovitaan projektipäällikön kanssa, joka koordinoi vaatimusten oikeantasoisuuden asiakkaan kanssa. 9

14 Testaussuunnitelman muutokset Alkuperäisen testaussuunnitelman käyttöliittymän testauksen piti tapahtua kolmessa vaiheessa, joista ensimmäinen olisi ollut käyttöliittymän heuristinen analyysi ryhmän sisällä. Toisessa vaiheessa tarkoituksena oli suorittaa ryhmäläpikäynti asiakkaan kanssa ja lopuksi järjestää käyttöliittymälle täysimittainen käytettävyystesti. Koska asiakkaan on ollut vaikeaa hahmottaa järjestelmää erilaisten määrittelyjen pohjalta, olemme suorittaneet käyttöliittymän suunnittelun mahdollisimman pitkälle yhteistyössä. Käytännössä tämä on tarkoittanut sitä, että olemme järjestäneet useampia ryhmäläpikäyntejä asiakkaan kanssa, joissa olemme käyneet läpi järjestelmän toiminnallisuudet käyttöliittymän avulla. Ryhmäläpikäyntien tulosten pohjalta olemme muokanneet käyttöliittymää vastaamaan paremmin asiakkaan tarpeita, jonka jälkeen käyttöliittymän uusi paperiproto on luovutettu asiakkalle arvioitavaksi. Tämän vuoksi olemme joutuneet miettimään käyttöliittymän testauksen uudelleen uuden suunnitteluprosessin pohjalta. Käyttöliittymän testaus tapahtuu edelleen kolmessa vaiheessa käyttäen samoja menetelemiä kuin alkuperäisessä suunnitelmassa, mutta testauksen aikataulua ja järjestelyjä on muutettu. Käyttöliittymän testauksen ensimmäisenä vaiheena ovat toimineet järjestetyt ryhmäläpikäynnit asiakaan luona. Toisessa vaiheessa tullaan suorittamaan heuristinen analyysi ja kolmanneksi käyttöliittymän käytettävyystesti Tietoturva Järjestelmän tietoturvan testaaminen rajoittuu järjestelmän oman tietoturvaan liittyvän toiminnallisuuden (eli tietoturvamoduulin) toimivuuden testaamiseen. Järjestelmän tietoturva testataan testitapausten mukaisesti. Koska käyttäjien autentikointi ja tietoliikenteen salaaminen tapahtuu Web-palvelimen ja selaimen toiminnallisuuksien kautta, näitä ei testata erikseen tietoturvan kannalta. Myöskään palvelinten tietoturvaan ei oteta kantaa, koska tämä riippuu käyttäjäorganisaation tietoturvapolitiikasta: palvelimiin on pääsy organisaation määrittämillä henkilöillä, ja näiden rajoitusten asettamiseen ei oteta kantaa järjestelmää toteutettaessa. 10

15 6. TESTATTAVAN KOHTEEN HYVÄKSYMIS-/HYLKÄÄMISKRITEERIT Testattavan kohteen hyväksyminen perustuu järjestelmän pakollisten ominaisuuksien oikeanlaisen toiminnan toteutumiseen. Vakavana pidettäviä virheitä ei saa jäädä järjestelmän pakollisiin ominaisuuksiin. Virhekategoriat ja niiden käyttö määritetään Toteutus 2 -vaiheen aikana projektin laatukäsikirjassa. Samassa vaiheessa määritellään hyväksymiskriteeri virhemäärien ja pakollisten käyttötapausten suhteena yhdessä asiakkaan kanssa. Mikään toiminto (riippumatta siitä, onko kyseessä suositeltava vai pakollinen ominaisuus vai lisäominaisuus) ei saa kaataa järjestelmää. Tällaisessa tapauksessa ko. virhe on korjattava, ennen kuin järjestelmä voidaan hyväksyä. 7. ALOITUS-, KESKEYTYS- JA JATKAMISKRITEERIT 7.1 ALOITUSKRITEERIT Jotta järjestelmätestauksessa tai asiakkaan testauksessa ei käytetä aikaa turhaan, järjestelmälle on suoritettava ennen testauksen aloittamista tietyt perustoiminnallisuuden varmistavat testit. Nämä testit kuvataan tarkemmin projektin laatukäsikirjassa Toteutus 3 - vaiheen aikana. Kun nämä kriteerit täyttyvät, järjestelmän buildin testaaminen voidaan aloittaa. Ennen testauksen aloittamista testausympäristö on saatettava määritettyyn alkutilaan, jossa järjestelmän komponentteja ei ole asennettu. 7.2 KESKEYTYSKRITEERIT Testaaminen keskeytetään siinä tapauksessa, että kohdataan sellainen virhe, joka estää etenemisen testitapausjoukon loppuun saakka. Koska järjestelmässä ei ole useita tiloja, testaus voidaan keskeyttää minkä tahansa testitapauksen loppuun suorittamisen jälkeen. Näin ollen testauksen lopettamiseen esim. työpäivän päätteeksi ja jatkamiseen seuraavana päivänä ei tarvitse määrittää erillisiä kriteereitä. 7.3 JATKAMISKRITEERIT Mikäli testaus on keskeytetty järjestelmässä olevan testauksen estävän virheen (tai jonkin 11

16 odottamattoman ulkoisen ongelman) vuoksi, testausta jatketaan, kun ko. virhe on korjattu. Tässä tapauksessa ei suoriteta uudelleen muita testitapauksia kuin ne, jotka testaavat järjestelmästä virheen korjaamiseksi muutettuja osia. Tämä määritys tehdään yhteistyössä järjestelmän ohjelmoijien kanssa. Ulkoisen virheen tapauksessa mitään loppuun suoritettuja testitapauksia ei suoriteta uudelleen. 8. TESTAUKSESSA TUOTETTAVA MATERIAALI Testausprosessin aikana tuotetaan seuraavat dokumentit vaiheittain: Toteutus 1: Testaussuunnitelma (versio 1) Toteutus 2: Testaussuunnitelma (versio 2) Laatukäsikirjan testausta käsittelevät osat (virheraportointiohje, työkaluohjeet) Testitapaukset Testausraportti (moduulitestauksen ja integrointitestauksen osalta) Virheraportit Toteutus 3: Testaussuunnitelma (versio 3) Testitapaukset Testausraportti (moduulitestauksen, integrointitestauksen, järjestelmätestauksen ja käyttöliittymätestauksen osalta) Virheraportit Hyväksyntätestaussuunnitelma (yhteistyössä asiakkaan kanssa) 12

17 Toteutus 4: Testaussuunnitelma (versio 4) Testitapaukset Testausraportti (moduulitestauksen, integrointitestauksen, järjestelmätestauksen ja käyttöliittymätestauksen osalta) Virheraportit Luovutus: Hyväksyntätestausraportti Virheraportit Opponointiraportti 9. TARVITTAVA TESTAUSYMPÄRISTÖ Tarvittava testausympäristö on järjestelmän vaatimukset täyttävä laitteisto ja yllä kohdassa 3 määritetyt käyttöjärjestelmä- ja selainversiot. Näiden lisäksi käytetään taulukossa 3 lueteltuja työkaluja. Taulukko 3. Testaustyökalut Tarkoitus Työkalu Dokumentointi Microsoft Word, Rational Test Manager, Rational Requisite Pro Testauksen hallinnointi Rational Test Manager Kattavuuden määrittäminen Rational Pure Coverage (soveltuvin osin) Ohjelman tehokkuuden mittaaminen Rational Quantify (soveltuvin osin) 13

18 Automatisointi Rational Robot, SiteCheck, Test Factory (soveltuvin osin) Muistivuotojen ja poikkeusten Rational Purify testaaminen Testiympäristön palauttaminen Norton Ghost Testauksessa käytetään erilaisia työkaluja niin paljon kuin on mahdollista, mutta käytännössä testaus tapahtuu tässä projektissa suurimmaksi osin manuaalisesti. Projektin laajuus ei edellytä testauksen laajamittaista automatisointia, vaan se todennäköisesti aiheuttaa työtä, joka ei luo asiakkaalle lisäarvoa. Erilaisia työkaluja käytetään lähinnä oppimistarkoituksessa kurssin luonne huomioiden. 10. VIRHERAPORTOINTI Virheiden raportointiin käytetään kurssin Burana-järjestelmää. Virheraportoinnista on kirjoitettu erillinen ohje, josta käy ilmi Burana-järjestelmän käyttö, virheiden kohdistaminen eri moduuleihin/toimintoihin, niiden vakavuuden määrittäminen sekä osoittaminen vastuuhenkilöille. 11. HENKILÖSTÖ, VASTUUT, KOULUTUS Testaukseen osallistuvat kaikki projektiryhmän jäsenet, asiakas, kurssin henkilökunta ja opponenttiryhmä. Päävastuu testauksesta on projektin laatuvastaavalla, ja suurin osa testauksen työstä suoritetaan luonnollisesti projektiryhmän toimesta. Kukin ohjelmoija on moduulitestausvaiheessa vastuussa omien moduuliensa testauksesta; tämän jälkeen testauksen resursointi tapahtuu projektipäällikön ja laatuvastaavan toimesta. Projektiryhmän jäsenille ei pidetä erityistä koulutusta vaan testaustyökalujen ja -tapojen opettelu tapahtuu työn ohessa. Kukin ryhmän jäsen tukee toisia jäseniä työn läpisaattamisessa. Asiakkaalle järjestetään tarpeen mukaan koulutusta testauksen yleisiä periaatteita ja virheraportointia koskien. 14

19 12. AIKATAULU Testauksen aikataulu on määritetty projektisuunnitelmassa. 13. RISKIANALYYSI Testauksen riskianalyysi noudattaa projektin yleistä laatukäsikirjassa määritettyä lähestymistapaa. Projektille kokonaisuutena määritetyt riskit on huomioitava myös testauksen osalta. Näiden riskien lisäksi on nimen omaan testaukseen liittyviä riskejä, joista viisi tärkeintä on lueteltu alla taulukossa 4. Taulukko 4. Testaukselle ominaiset riskit Riski Varautuminen Todennäköisyys Vaikutus Kokonaisvaikutus Seurataan järjestelmän toteutusta verrattuna aikatauluun. Hyödynnetään iteratiivisuutta ja 1. Järjestelmätestaus ei pääse alkamaan, koska järjestelmän toteuttaminen ei ole edennyt tarpeeksi inkrementaalisuutta aloittaen toteutuksesta, jolla on eniten merkitystä järjestelmän testaukselle. Mikäli riski toteutuu, keskitetään 0, ,2 testaukseen kokeneimmat testausresurssit (henkilöt, joilla on eniten aiempaa testauskokemusta). Käytetään testaukseen Resursseja ei voida käyttää kokeneimpia 2. testaukseen, koska ne tarvitaan testausresursseja, jolloin 0,5 5,21 2,61 järjestelmän toteuttamiseen testaus saadaan suoritettua pienemmässä ajassa. 3. Järjestelmätestausvaiheessa löytyy niin merkittäviä virheitä, että Katselmoidaan tuotettava dokumentaatio projektin joka 0,23 8,5 1,98 järjestelmää on muutettava vaiheessa. Määritellään 15

20 huomattavasti järjestelmää käyttöliittymän kautta, jotta voidaan varmistua oikean asian toteuttamisesta. Testaustyökalut eivät tarjoa 4. riittävästi apua testaukseen vaan kaikki testaus on suoritettava Varaudutaan testaamaan manuaalisesti. 0,77 1 0,77 manuaalisesti 5. Testausympäristöä ei ole käytettävissä tarvittavana aikana Huolehditaan järjestelmän varmuuskopioinnista ja ylläpidetään järjestelmän pystyttämisohjetta, jotta järjestelmä voidaan tarvittaessa asentaa uuteen ympäristöön. Varmistutaan siitä, että ympäristöjä voidaan pystyttää tarvittaessa nopeasti. 0,13 4,86 0,65 16