Testaussuunnitelma v. 1.1 - Niksula

Tik-76.115 Projektiryhmä: 

TeamAhma 

www.niksula.cs.hut.fi/~jjkankaa/TeamAhma/ 

Käyttäjien tunnistaminen ja 

käyttöoikeuksien hallinta hajautetussa 

ympäristössä 

Testaussuunnitelma v. 1.1 

Päivitetty 12.12.2000 klo 12:03


TeamAhma 

Projekti: Tekijä: Sivu: 




Mikko Viljainen 2 (14) 

Dokumentti: Versio: Päivämäärä: 

TESTAUSSUUNNITELMA 1.1 12.12.2000 

Dokumentin versiohistoria 

Versio Päivämäärä Tekijä / muutoksen tekijä Selite 

1.1 12.12.2000 Mikko Viljainen, Janne 

Kankaanpää 

Täydennetty teknisten 

määritelmien perusteella, 

muutoksia lähes jokaisessa 

luvussa 

1.01 9.11.2000 Janne Kankaanpää Kappalenumerointi ja 

kappaleiden tasaus 

1.0 6.11.2000 Mikko Viljainen, Janne 

Kankaanpää 

Projektin testaussuunnitelman 

ensimmäinen versio 


TESTAUSSUUNNITELMA 2


TeamAhma 








Sisällys 

DOKUMENTIN VERSIOHISTORIA ................................................................................................................... 2 

1. JOHDANTO........................................................................................................................................ 4 

1.1. VIITTEET ....................................................................................................................................... 4 

2. TESTAUKSEN KOHTEET.................................................................................................................. 5 

3. TESTATTAVAT OMINAISUUDET...................................................................................................... 5 

3.1. SOVELLUSKEHIKKO......................................................................................................................... 5 

3.2. DEMOSOVELLUS............................................................................................................................. 6 

4. TESTAAMATTA JÄTETTÄVÄT OMINAISUUDET ............................................................................. 7 

5. MENETELMÄT ................................................................................................................................... 7 

5.1. YKSIKKÖTESTAUS........................................................................................................................... 7 

5.2. INTEGRAATIOTESTAUS .................................................................................................................... 8 

5.3. JÄRJESTELMÄTESTAUS.................................................................................................................... 8 

5.4. REGRESSIOTESTAUS ...................................................................................................................... 8 

5.5. HYVÄKSYMISTESTAUS ..................................................................................................................... 9 

6. HYVÄKSYMIS-/HYLKÄYSKRITEERIT............................................................................................... 9 

7. TESTAUKSEN KESKEYTTÄMISKRITEERIT SEKÄ UUDELLEENALOITUS.................................... 9 

8. TESTAUKSEN TUOTTAMAT DOKUMENTIT .................................................................................... 9 

9. TESTAUKSEN TOIMENPITEET .......................................................................................................10 

9.1. TESTAUSPROSESSI........................................................................................................................10 

10. YMPÄRISTÖVAATIMUKSET.........................................................................................................11 

11. VASTUUT ......................................................................................................................................11 

12. HENKILÖSTÖ JA KOULUTUSTARPEET .....................................................................................11 

13. AIKATAULU...................................................................................................................................11 

14. RISKIENHALLINTA.......................................................................................................................12 

15. HYVÄKSYMINEN...........................................................................................................................12 

LIITE 1. TESTAUKSEN FOLLOW-UP -POHJA .......................................................................................13 

LIITE 2. TESTIRAPORTIN KANSILEHTI.................................................................................................14 




TeamAhma 








1. Johdanto 

Tämä testaussuunnitelma liittyy TKK:n kurssiin Tik-76.115, ohjelmistoprojektiin. 

Tämä testaussuunnitelma on A-Ware Oy:n tilaamaa TeamAhma -ryhmän 

projektityötä, "Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa 

ympäristössä", varten. Itse tuote tulee koostumaan kahdesta erillisestä osasta. 

Toinen on sovelluskehikko, varsinainen asiakkaan tilaama tuote, joka huolehtii 

käyttäjien todentamisesta. Toinen on ryhmän itse laatimasta demosovellus, joka 

on projektinhallintaohjelma. Tämä dokumentti kattaa kaiken ryhmän puolesta 

tehtävän testaustoiminnan ja se on laadittu noudattaen IEEE:n standardia IEEE 

Std 829-1998 soveltuvin osin. Testauksessa tuotetta verrataan ryhmän laatimiin 

määritelmiin sekä vaatimusmäärittelyihin tarkoituksena varmistaa testattavan 

ohjelmiston laatu. 

Tässä dokumentissa kuvataan testauksen laajuus, resurssit, riskit, aikataulu sekä 

testattavat ominaisuudet ja testausmenetelmät. 

Tätä dokumenttia tullaan tarpeen mukaan päivittämään projektin jokaisessa 

vaiheessa. Erityisesti muutoksen kohteina tulevat olemaan luku 3, joka muuttuu 

teknisiä määrittelyjä parannettaessa, luku 9, joka muuttuu testausprosessin 

kehittyessä sekä Liitteet samasta syystä. 

1.1. Viitteet 

[1] IEEE std 829-1998 

[2] Tik-76.613 Software Testing and Validation Luentomonisteet, syksy 2000, 

Jukka Paakki 

[3] Tik-76.115 Projektisuunnitelma v. 2.2; Käyttäjien tunnistaminen ja käyttöoikeuksien 

hallintahajautetussa ympäristössä, Päivitetty 7.11 2000, Jussi 

Isotupa 

[4] Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä; 

Vaatimusmäärittely v. 1.0, Päivitetty 16.10.2000, Tomas Björnfot. 


Tekninen määrittely v. 1.5, Päivitetty 12.12.2000, Tomas Björnfot. 


Demosovelluksen tekninen määrittely v. 0.6, Päivitetty 11.12.2000, Mickey 

Shroff. 


Riskienhallintasuunnitelma v. 1.0, Päivitetty 12.12.2000, Jussi Isotupa. 


Toiminnallinen määrittely v. 1.0, Päivitetty 


Demosovelluksen toiminnallinen määrittely v. 1.1, Päivitetty 11.12.2000, 

Timo Lämsä 

[10] Sovelluskehikon UML-malli 




TeamAhma 








2. Testauksen kohteet 

Testattavana ovat käyttäjien todentamiseen luotava sovelluskehikko, sekä tämän 

päälle tehtävä projektinhallinta-demosovellus. Testaus perustuu dokumentteihin, 

jotka määrittelevät ohjelman toiminnan, kuten vaatimusmäärittelyyn sekä teknisiin 

määritelmiin. 

3. Testattavat ominaisuudet 

Kaikki määritellyt ominaisuudet testataan. Järjestelmästä testataan niin demosovelluksen 

ominaisuudet kuin itse tuotteen toiminta ja geneerisyys. 

Seuraavassa esitettyä osuutta tullaan vielä päivittämään projektin myöhemmissä 

vaiheissa. 

3.1. Sovelluskehikko 

3.1.1. Pakkaus: fi.aware.AHMA 

CreateCommand -metodilla luodaan: 

a) sallittu komento 

b) jo olemassa oleva komento. 

Execute -metodilla kysytään käyttöoikeuksia: 

a) Olemassa olevaan komentoon, johon käyttäjällä on oikeus. Ohjelma 

reitittää komennon edelleen. 

b) Olemassa olevaan komentoon, johon käyttäjällä ei ole oikeuksia. Ohjelma 

nostaa SecurityExeption -poikkeuksen 

c) Olemattomaan komentoon, jolloin ohjelma nostaa poikkeuksen. 

3.1.2. Pakkaus: fi.aware.AHMA.commandmap 

GetTarget -metodilla pyydetään referenssi: 

a) olemassa olevaan komentoon, jonka se palauttaa 

b) olemattomaan komentoon, jolloin se nostaa poikkeuksen. 

3.1.3. Pakkaus: fi.aware.AHMA.securitymanager 

CreateSession -metodilla luodaan istunto. Palauttaa Principal -olion 

PasswordAuthenticationCommand pyritään todentamaan: 

a) olemassa oleva salasana, jolloin palautetaan 

PasswordAuthenticationResponse, joka sisältää käyttäjäolion 

b) virheellinen salasana, jolloin PasswordAuthenticationResponse palautetaan 

ilman käyttäjäoliota. 




TeamAhma 








IsValid -metodi palauttaa totuusarvon: 

a) tosi kysyttäessä voimassaolevaa tapausta 

b) epätosi kysyttäessä ei-voimassaolevaa tapausta 

3.1.4. Pakkaus: fi.aware.AHMA.exceptions 

Pakkauksesta ei ole dokumentin tässä versiossa vielä suunnitelmaa. 

3.1.5. Pakkaus: fi.aware.AHMA.config 

GetValue -metodilla annetaan: 

a) olemassa olevan komennon nimi ja ohjelma palauttaa sitä vastaavan 

parametrin 

b) olemattoman komennon ja ohjelma nostaa poikkeuksen. 

3.1.6. Pakkaus: fi.aware.AHMA.datasources 

Authenticate -metodille annetaan: 

a) tunnistetiedot, jotka löytyvät tietolähteestä. Tällöin palautetaan Principal 

olio 

b) tunnistetiedot, jotka eivät löydy tietolähteestä. Tällöin nostetaan poikkeus 

3.1.7. Pakkaus: fi.aware.AHMA.log 

Pakkauksesta ei ole dokumentin tässä versiossa vielä suunnitelmaa. 

3.2. Demosovellus 

3.2.1. Worktime-moduuli 

Testataan normaali toiminta, poikkeukset sekä se, että tarkistetaan, että wwwselaimesta 

saatu data on tietokannan määrittelyn mukainen. 

3.2.2. Report-moduuli 

Testataan ohjelman normaali toiminta sekä poikkeukset. 

3.2.3. Authority-moduuli 

Testataan ohjelman normaali toiminta, poikkeustilanteet sekä se, että tarkistetaan 

välitettävän datan oikeellisuus. 




TeamAhma 








4. Testaamatta jätettävät ominaisuudet 

Kaikki määritellyt ominaisuudet tullaan testaamaan. 

5. Menetelmät 

Jokainen koodaaja on itse vastuussa koodinsa virheettömyydestä ja laadusta. 

Koodin tulee olla hyvin kommentoitua ja selkeää. Koodin oikeellisuudelle 

minimivaatimus on se, että ohjelma voidaan kääntää. Mitä vakaampi ohjelma on, 

sitä tehokkaammin testaus onnistuu. Siihen, miten kukin koodaaja toteuttaa 

käytännössä koodinsa laadun ja virheettömyyden, ei tässä dokumentissa puututa. 

Tähän vastuuseen kuuluu myös se, että kukin koodaaja debuggaa oman koodinsa. 

Testaamiseen käytettävät työkalut ovat JUnit -testausohjelma, josta saatavilla on 

versio 3.2. Tällä ohjelmalla nauhoitetaan testitapauksia. Kuormitus- ja vastaavaan 

testaukseen Microsoft Web Application Stress tool. Bugien raportointiin käytetään 

Burana -ohjelmistoa. A-Ware tarjoaa ryhmän käyttöön testiympäristön. 

Testauksen vastuu on testauspäälliköllä. Kustakin testitapauksesta hän laatii 

yhdessä kunkin osion vastaavan (moduulitestauksessa koodaajan, 

integraatiotestauksessa arkkitehtuuripäällikön jne.) henkilön kanssa 

tapauskohtaisen suunnitelman sekä toimintaohjeet, jotka toimitetaan testaajalle. 

Näiden dokumenttien tulee olla niin selkeitä, että kuka tahansa ryhmän jäsen 

pystyy suorittamaan testauksen niiden perusteella. 

5.1. Yksikkötestaus 

Tässä testaamisen vaiheessa testataan jokainen yksikkö erikseen. Koska yksiköt 

eivät ole yksinään toimivia, saatetaan tarvita ajureita ja tynkiä simuloimaan muita 

yksiköitä, joiden kanssa kyseisellä yksiköllä on vuorovaikutusta. Tämä 

testaaminen muodostaa perustan seuraaville testeille ja näin ollen tulisi toteuttaa 

erityisen huolellisesti. Yksikkötestauksessa ei moduuleita ole mielekästä viedä 

testiympäristöön testattavaksi, vaan ne voidaan testata esimerkiksi koneella, jolla 

ne on koodattu. Järjestelmäriippumattomuus todennetaan testauksen 

myöhemmissä vaiheissa. Jotta yksikkötestaus olisi inhimillisesti mahdollista, tulisi 

yksiköiden olla reippaasti alle 1000 rivin mittaista, hyvin kommentoituja ja selkeää 

koodia. Suunnitteluvaiheessa myös moduuleihin jakoperusteissa sekä niiden 

suunnittelussa tulisi ottaa huomioon niiden testattavuus. 

Varsinainen testaaminen alkaa lasilaatikkotestauksella. Vaiheen yksiköiden koko 

on luokkatasoa. Tässä testauksessa tarkastellaan koodia metoditasolla ja sen 

perusteella kirjoitetaan testitapaukset, joilla tulisi käydä läpi kaikki ohjelman iflauseet, 

while-silmukat ja vastaavat. Kattavuus tulisi olla, mikäli mahdollista 

100%. 

Yksikkötestauksen toisena osana on mustalaatikkotestaus, jossa yksiköiden koko 

on enemmänkin pakettitasoa. Tämä on siis eräänlaista integraatiotestausta (katso 

seuraava kohta) suhteessa lasilaatikkotestaukseen. Tässä testaustavassa 

annetaan valittuja syötteitä ohjelmalle ja vertaillaan yksikön palauttamaa tietoa 




TeamAhma 








yksikön määrittelyihin. Testaustapaukset tulisi olla seuraavanlaisia: normaali 

syöte, virheellinen syöte sekä rajatapaukset. 

Nämä kaksi vaihetta yhdistetään suunnittelutasolla siten, että jokaiselle 

pakkaukselle laaditaan oma testaussuunnitelma. Tässä suunnitelmassa tehdään 

kuitenkin 2 erillistä osiota, joista toisessa testaus tehdään koodin ja toisessa 

toiminnan suhteen. Tämän jälkeen voidaan samat tapaukset poistaa toisesta. 

Yksikkötestauksen suunnittelee koodaaja itse yhdessä testauspäällikön kanssa. 

Itse testauksen suorittaa vapaana oleva koodaaja tai testauspäällikkö. 

5.2. Integraatiotestaus 

Integraatiotestauksen tarkoituksena on tarkastaa alijärjestelmien toimivuus 

moduulien kompositiona. Vaikka kaikki yksiköt on jo testattu tässä vaiheessa, on 

tärkeää kuitenkin todentaa yksiköiden välisen kommunikaation oikeellisuus sekä 

laitteistoriippumattomuus. Tämän vuoksi ohjelman moduulit viedään 

testiympäristöön ja testataan siellä. Testauksessa käytetään bottom-up - 

kokoonpanomenetelmää, eli siis arkkitehtuuria lähdetään toteuttamaan ikään kuin 

alhaalta päin. Testaus tehdään mustalaatikko-menetelmällä ja siinä käytetään 

arkkitehtuuriin liittyvää dokumenttiaineistoa (katso [10] sovelluskehikon UML-malli) 

sekä jossain määrin toiminnallisia määrittelyjä (katso [8,9]). Tämä testaus voidaan 

suorittaa, ja tulisi aloittaa vielä, kun koodaaminen on kesken. Testin suunnittelevat 

arkkitehtuuripäällikkö ja testauspäällikkö. Itse testaus suoritetaan vapailla 

resursseilla. Tässä vaiheessa luodaan myös sovelluskehikon testaamiseen 

tarkoitettu Testaussovellus-niminen tynkä. 

5.3. Järjestelmätestaus 

Tässä testin vaiheessa on tarkoitus testata koko järjestelmä. Tässä vaiheessa 

tuotetta verrataan vaatimusmäärittelyyn. Tässä vaiheessa testataan 

laatuatribuutteja ainakin seuraavilla testeillä: 

Luotettavuustestaus 

Turvallisuustestaus 

Rasitustestaus 

Voluumitestaus 

Geneerisyystestaus 

Kuten aiemmin jo mainittiin, koostuu TeamAhman tuote kahdesta erillisestä 

osasta: sovelluskehikosta ja demosovelluksesta. Tällä pyritään varmistamaan 

sovelluskehikon riippumattomuus demosovelluksesta. Jotta sovelluskehikko olisi 

testattavissa, sille tehdään yksi tai useampi tynkä, testaussovellus. 

Tämä testaus tehdään käyttäen mustalaatikko-menetelmää. 

5.4. Regressiotestaus 

Debuggausten jälkeen tulee tarkastaa, että suoritetut korjaukset ovat riittävät, 

eivätkä muuttaneet jonkun muun koodin osan toimintaa. Tämän testauksen nimi 

on regressiotestaus. Regressiotestauksen laajuus ei pidä olla liian suuri, koska se 

varsinkin myöhemmissä vaiheissa on aikaa vievää, mutta kuitenkin riittävän laaja, 

jotta tuotteen toimivuudesta voidaan olla varmoja. Regressiotestauksessa tulisi, 




TeamAhma 








mikäli mahdollista, käyttää vanhoja, JUnitilla tallennettuja testitapauksia. Testin 

suunnittelevat testauspäällikkö sekä bugin korjaaja. Testi suoritetaan vapailla 

resursseilla. 

5.5. Hyväksymistestaus 

Asiakas suorittaa hyväksymistestauksen kurssin päätteeksi ja se ei kuulu tämän 

dokumentin aihepiiriin. 

6. Hyväksymis-/hylkäyskriteerit 

Kun kaikki sovelluskehikon testitapaukset sekä testit mukaan lukien 

regressiotestaus on käyty läpi ja hyväksytty ja kaikki tunnetut korjaamattomat bugit 

ovat merkityksettömiä (minor) (katso luku 9), voidaan tuote hyväksyä. 

Demosovelluksen luonteen vuoksi voidaan tuote hyväksyä vaikka 

Demosovelluksessa olisi kriittisiäkin (critical) bugeja. Käytännössä tottakai nämä 

tullaan korjaamaan. Tuotteen määritelmien perusteella määritellään/ryhmitellään 

testattavat ominaisuudet ja näille kullekin omat hyväksymis-/hylkäämiskriteerit. 

7. Testauksen keskeyttämiskriteerit sekä 

uudelleenaloitus 

Testaus voidaan lopettaa työpäivän päättyessä arkipäivinä, joskin osapuolten 

suostumuksella sitä voidaan jatkaa. Laitteisto-, ohjelmisto- sekä ulkopuoliset 

häiriöt, kuten luonnonmullistukset keskeyttävät testauksen, kuin myös testaajien 

uupumus. Testaus keskeytetään lisäksi, kun bugi estää testaamisen jatkamisen. 

Tällöin bugi määritellään kriittiseksi (critical) (katso luku 9). Testausta voidaan 

jatkaa, kun testauksen keskeyttänyt olosuhde on poistunut. Testausta uudelleen 

käynnistettäessä tulee käynnistää ja testata testiympäristö. Tämä käy siten, että 

Websphere on päällä ja toimii oikein sekä että tietolähteet toimivat oikein. Nämä 

voidaan varmentaa ajamalla vanhoja nauhoitettuja testejä. Tämän jälkeen kaikki 

keskeytyneet testit sekä niihin liittyvät muut testit on tehtävä uudelleen. 

8. Testauksen tuottamat dokumentit 

Testaussuunnitelman (tämä dokumentti) tarkoituksena on määritellä testaaminen 

ja testaamisen tarkoitus. 

Lisäksi jokainen testaus tuottaa seuraavat dokumentit: 

Testitapauskohtainen suunnitelma, testiraportti (sisältäen kansilehden, follow-upin 

ja lyhyen kuvauksen) ja työkalujen kuvaus. 

Sekä mahdollisesti seuraavat: 

Burana-bugiraportti, syöte- ja tulostedata. 

Kun ohjelma on saatu valmiiksi ja testattu, kirjoitetaan testauksen loppuraportti. 




TeamAhma 








9. Testauksen toimenpiteet 

Ennen varsinaista testausta, prototyyppivaiheessa, testataan demosovellusta ja 

sovelluskehikkoa vain prototyypissä sovellettavin osin eräänlaisella 

integraatiotestauksella. Testauksen tarkoituksena on välttyä demottaessa ikäviltä 

kömmähdyksiltä. Tätä testausta ei toteuteta aivan tarkasti muitten, virallisempien 

testausten malliin, joskin se dokumentoidaan kunnolla, sillä sitä tullaan 

mahdollisesti käyttämään varsinaisessa testausvaiheessa. 

Varsinainen testaus alkaa yksikkötestauksella, jossa lasi- ja 

mustalaatikkotestauksin varmistetaan jokaisen moduulin toimivuus, mahdolliset 

bugit korjataan ja suoritetaan regressiotestaus. Tämän jälkeen, osittain 

samanaikaisesti edellisen vaiheen kanssa aloitetaan järjestelmän kokoaminen ja 

sen toimivuus varmistetaan integraatiotestauksella. Jälleen bugit korjataan ja 

korjaukset varmistetaan regressiotestauksella. Tämän jälkeen/osittain 

samanaikaisesti laatuatribuutit varmennetaan järjestelmätestauksella, puutteet 

korjataan ja korjaukset varmennetaan regressiotestauksella. 

9.1. Testausprosessi 

Kaiken testaustoiminnan aluksi testaus suunnitellaan kunnolla. Testauksen 

suunnittelu aloitetaan kirjoittamalla ja tarkastamalla testaussuunnitelma (tämä 

dokumentti). Koodaajan toimitettua ja selvitettyä valmiin koodin testauspäällikölle 

kirjoitetaan testille tapauskohtainen suunnitelma. Suunnitelman ja määritelmien 

perusteella laaditaan JOKAISELLE testitapaukselle oma Follow-up -kaavio (kts. 

Liite 1). Kaavion tulee olla niin yksityiskohtainen, että sen perusteella pystyy testin 

suorittamaan ja toistamaan ilman erityistä perehtymistä. Tämä Follow-up 

toimitetaan varsinaiselle testaajalle, joka ensimmäisenä täyttää 

testaussuunnitelman kansilehden (kts. Liite 2). Tämän dokumentin merkitys on 

identifioida paitsi testattava ohjelma, sen versio ja testattava ominaisuus, niin 

myös itse testi. Tämän tehtyään testaaja tarkastaa testiympäristön. Testin hän 

suorittaa follow-up -listan mukaan merkiten läpimenneet ja hylätyt tapaukset ja 

raportoi tarpeen mukaan Buranaan. Burana jakaa bugit neljään luokkaan 

seuraavasti: 

Minor = Lähinnä kosmeettinen virhe. Ei vaikutusta ohjelman 

toiminnallisuuteen 

Normal = Normaali virhe. 

Serious = Huomattava virhe, joka ei kuitenkaan estä testauksen testaamisen 

jatkamista 

Critical = Huomattava virhe, joka estää ohjelman testauksen jatkamisen (kts. 

Luku 7 Testauksen keskeyttämiskriteerit sekä uudelleenaloitus) 

Muista tapauksessa mahdollisesti käytettävistä työkaluista kuin Buranasta on 

maininta tapauskohtaisessa testaussuunnitelmassa. Testauksen päätyttyä testaaja 

kirjoittaa pienen yhteenvedon testistä ja täyttää kansilehden. Nämä hän sitten 

toimittaa testauspäällikölle. 

Testaamisen päätyttyä testauspäällikkö kirjoittaa testauksen loppuraportin, jonka 

projektipäällikkö hyväksy. 

Testiympäristön ylläpidosta huolehtii A-Ware. 




TeamAhma 








10. Ympäristövaatimukset 

Ohjelma toimii Java 2 -yhteensopivassa Java-virtuaalikoneessa. Se tarvitsee 

J2EE-kirjaston toimiakseen. Sovelluspalvelimen tulee toteuttaa vähintään Java 

Servlet Development Kit 2.1:n, Java Server Pages 1.0:n ja Enterprise Java Beans 

1.1:n. 

A-Ware tarjoaa ryhmän käyttöön testausympäristön. Se sisältää IBM Websphere 

Application Server 3.5, HTTP-serverinä Apachen ja tietolähteenä Oracle 8.1.16. 

Käyttöjärjestelmänä on Windows NT 2000. 

11. Vastuut 

Ryhmän jokaiselle jäsenelle on jaettu oma vastuualueensa ja testaus on 

testauspäällikön vastuulla. Aiemmin, luvussa 5 määritellyt testauspäällikköä 

avustavat henkilöt toimivat testaajina. Testauspäällikkö on vastuussa kaikesta 

testaukseen liittyvästä dokumentaatiosta, joiden oikeellisuudesta vastaa 

dokumentointipäällikkö. Koodin saatavuudesta vastaa kukin koodaaja itse. 

Testiympäristön toimivuudesta vastaa projektipäällikkö A-Waren edustajana. 

12. Henkilöstö ja koulutustarpeet 

Henkilöstö koostuu kuudesta TKK:n opiskelijasta. Testaukseen suorittamiseen 

tarvittavan koulutuksen/opastuksen antaa testauspäällikkö. Tämä koostuu 

esimerkiksi käytettävien työkalujen käyttöohjeina ja on tyypiltään itseopiskelua. 

13. Aikataulu 

Seuraavia deadlineja noudatetaan: 

Vaihe T1: 19.10.-10.11.2000 

Testaussuunnitelma (tämä dokumentti) 07.11.2000 

Vaihe T2: 11.11.-15.12.2000 

Täydennetty testaussuunnitelma 

Prototyypin toimivuuden todentaminen 

Testausta 48 h 

Vaihe T3: 17.12. 2000-16.2.2001 

Testausta 54 h, 




TeamAhma 








johon sisältyy 30 h sovelluskehikon testausta, 16 h demosovelluksen testausta 

sekä 8 h testiraporttien kirjoittamista. 

Vaihe T4: 17.2.-23.3.2001 

Testausta 

Vaihe Luovutus: 24.3.-27.4.2001 

Testauksen loppuraportti 

Tässä vaiheessa tuntiarviot ovat vielä niin arvauksenomaisia, että niitä ei tähän 

ole kirjattu. Periaatteena kuitenkin on, että testaamiseen tulee varata vähintään 

yhtä paljon aikaa kuin koodaamiseen. 

14. Riskienhallinta 

Testauksen suhteen projektissa on monia riskejä. Aikatauluun liittyvät riskit ovat 

se, että joku aiempi työvaihe, kuten koodaus venyy taikka testaus myöhästyy. 

Näitä riskejä voidaan eliminoida aikatauluttamalla ja suunnittelemalla hyvin, sekä 

mikäli riski on toteutumassa, voidaan ainakin testaukseen tuoda lisää henkilöstöä, 

koska uusien henkilöiden tuonti, toisin kuin esim. koodauksessa ei vaadi 

kovinkaan suurta perehdyttämistä ja näin sido resursseja. Ohjelman geneerinen 

luonne ja sen testaus myös synnyttää riskin. Geneerisyyttä on vaikea ja työläs 

testata. Tämä saattaa aiheuttaa sen, että testaus myöhästyy. Tämän vuoksi tulee 

geneerisyyden testaus aloittaa tärkeimmistä ympäristöistä ja edetä sitten ajan 

puitteissa. Testaamatta jääneet/testatut osat tulee sitten raportoida loppuraporttiin. 

Lisäksi turvallisuuden testaus luo samankaltaisen riskin, mutta sen testaaminen 

voidaan aloittaa jo aikaisemmassa vaiheessa. Myöhäisessä vaiheessa havaitut 

bugit ovat myös riski, koska niiden korjaus/korjauksen tarkastus vievät aikaa. 

Tämän välttämiseksi ohjelma tulee suunnitella ja testata aiemmissa vaiheissa 

hyvin. Ohjelman abstraktius luo myös riskin, koska sitä ei välttämättä ole helppo 

testata. Tämä riski huomioidaan ottamalla jo suunniteltaessa testattavuus 

huomioon. Riskejä on myös avainhenkilöiden äkillinen sairastuminen, jota varten 

on luotu työparijärjestelmä. Muita riskejä olisi luonnonmullistukset ym. Force 

Mayor-riskit, joihin ei ole mielekästä varautua. Projektiin liittyviä riskejä on 

käsitelty tarkemmin riskienhallintasuunnitelmassa [7]. 

15. Hyväksyminen 

Projektipäällikkö hyväksyy tämän suunnitelman. 




TeamAhma 








Liite 1. Testauksen Follow-up -pohja 

Testattava ohjelma: ____Demosovellus______ 

Testattava ominaisuus: Käyttäjän login______ 

(virheellinen login) 

Askel Nro. Kuvaus Toimenpide/syöte Odotettu tulos Hyväksytty(V) / 

hylätty(X) 

1 Login-sivun lataus Kirjoita URL 

selaimen 

osoitekenttään. 

2 Virheellinen login Kirjoita 

käyttäjätunnukseksi 

illegal ja 

salasanaksi 

donthave. 

Login sivu latautuu 

Virheilmoitus "login 

incorrect". 

Kentässä 1 on-- kunkin askeleen numero (1, 2, 3…). Kenttässä 2 kirjoitetaan lyhyt 

kuvaus askeleen toimenpiteestä. Kenttä 3 on tarkka ja yksityiskohtainen 

toimintaohje. Kentässä 4 on odotettavissa oleva, määritelmien mukainen tulos ja 

kenttään 5 merkitsee testaaja V:llä, mikäli saatu tulos vastasi odotettua ja X:llä, 

mikäli ei. Tällöin tulee myös täyttää Burana-raportti. 




TeamAhma 








Liite 2. Testiraportin kansilehti 

Case #N: 

[1] Tuote: Sovelluskehikko / Demosovellus 

[2] Versio: 

[3] Testin #: 

[4] Testausympäristö: 

[5] Käytetyt ohjelmat: 

[6] Käytetyt tyngät/ajurit: 

[7] Päivämäärä: ____.____.200__ 

[8] Aloitusaika: ____:____ 

[9] Lopetusaika: ____:____ 

[10] Testaaja: _____________ 

[11] Muuta:

Testaussuunnitelma v. 1.1 - Niksula

Create successful ePaper yourself

Delete template?

Save as template?