Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Transkriptio

1 Testaussuunnitelma v. 1.1 Päivitetty klo 12:03

2 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite Mikko Viljainen, Janne Kankaanpää Täydennetty teknisten määritelmien perusteella, muutoksia lähes jokaisessa luvussa Janne Kankaanpää Kappalenumerointi ja kappaleiden tasaus Mikko Viljainen, Janne Kankaanpää Projektin testaussuunnitelman ensimmäinen versio TESTAUSSUUNNITELMA 2

3 Mikko Viljainen 3 (14) Sisällys DOKUMENTIN VERSIOHISTORIA JOHDANTO VIITTEET TESTAUKSEN KOHTEET TESTATTAVAT OMINAISUUDET SOVELLUSKEHIKKO DEMOSOVELLUS TESTAAMATTA JÄTETTÄVÄT OMINAISUUDET MENETELMÄT YKSIKKÖTESTAUS INTEGRAATIOTESTAUS JÄRJESTELMÄTESTAUS REGRESSIOTESTAUS HYVÄKSYMISTESTAUS HYVÄKSYMIS-/HYLKÄYSKRITEERIT TESTAUKSEN KESKEYTTÄMISKRITEERIT SEKÄ UUDELLEENALOITUS TESTAUKSEN TUOTTAMAT DOKUMENTIT TESTAUKSEN TOIMENPITEET TESTAUSPROSESSI YMPÄRISTÖVAATIMUKSET VASTUUT HENKILÖSTÖ JA KOULUTUSTARPEET AIKATAULU RISKIENHALLINTA HYVÄKSYMINEN...12 LIITE 1. TESTAUKSEN FOLLOW-UP -POHJA...13 LIITE 2. TESTIRAPORTIN KANSILEHTI TESTAUSSUUNNITELMA 3

4 Mikko Viljainen 4 (14) 1. Johdanto Tämä testaussuunnitelma liittyy TKK:n kurssiin Tik , ohjelmistoprojektiin. Tämä testaussuunnitelma on A-Ware Oy:n tilaamaa -ryhmän projektityötä, " ", 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 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ä Viitteet [1] IEEE std [2] Tik Software Testing and Validation Luentomonisteet, syksy 2000, Jukka Paakki [3] Tik Projektisuunnitelma v. 2.2; käyttöoikeuksien hallintahajautetussa, Päivitetty , Jussi Isotupa [4] ; Vaatimusmäärittely v. 1.0, Päivitetty , Tomas Björnfot. [5] ; Tekninen määrittely v. 1.5, Päivitetty , Tomas Björnfot. [6] ; Demosovelluksen tekninen määrittely v. 0.6, Päivitetty , Mickey Shroff. [7] ; Riskienhallintasuunnitelma v. 1.0, Päivitetty , Jussi Isotupa. [8] ; Toiminnallinen määrittely v. 1.0, Päivitetty [9] ; Demosovelluksen toiminnallinen määrittely v. 1.1, Päivitetty , Timo Lämsä [10] Sovelluskehikon UML-malli TESTAUSSUUNNITELMA 4

5 Mikko Viljainen 5 (14) 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 Sovelluskehikko 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 Pakkaus: fi.aware.ahma.commandmap GetTarget -metodilla pyydetään referenssi: a) olemassa olevaan komentoon, jonka se palauttaa b) olemattomaan komentoon, jolloin se nostaa poikkeuksen 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. TESTAUSSUUNNITELMA 5

6 Mikko Viljainen 6 (14) IsValid -metodi palauttaa totuusarvon: a) tosi kysyttäessä voimassaolevaa tapausta b) epätosi kysyttäessä ei-voimassaolevaa tapausta Pakkaus: fi.aware.ahma.exceptions Pakkauksesta ei ole dokumentin tässä versiossa vielä suunnitelmaa 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 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 Pakkaus: fi.aware.ahma.log Pakkauksesta ei ole dokumentin tässä versiossa vielä suunnitelmaa Demosovellus Worktime-moduuli Testataan normaali toiminta, poikkeukset sekä se, että tarkistetaan, että wwwselaimesta saatu data on tietokannan määrittelyn mukainen Report-moduuli Testataan ohjelman normaali toiminta sekä poikkeukset Authority-moduuli Testataan ohjelman normaali toiminta, poikkeustilanteet sekä se, että tarkistetaan välitettävän datan oikeellisuus. TESTAUSSUUNNITELMA 6

7 Mikko Viljainen 7 (14) 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 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 TESTAUSSUUNNITELMA 7

8 Mikko Viljainen 8 (14) 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ö 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ä 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 n 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ää 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, TESTAUSSUUNNITELMA 8

9 Mikko Viljainen 9 (14) mikäli mahdollista, käyttää vanhoja, JUnitilla tallennettuja testitapauksia. Testin suunnittelevat testauspäällikkö sekä bugin korjaaja. Testi suoritetaan vapailla resursseilla 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. TESTAUSSUUNNITELMA 9

10 Mikko Viljainen 10 (14) 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 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. TESTAUSSUUNNITELMA 10

11 Mikko Viljainen 11 (14) 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 Käyttöjärjestelmänä on Windows NT 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: Testaussuunnitelma (tämä dokumentti) Vaihe T2: Täydennetty testaussuunnitelma Prototyypin toimivuuden todentaminen Testausta 48 h Vaihe T3: Testausta 54 h, TESTAUSSUUNNITELMA 11

12 Mikko Viljainen 12 (14) johon sisältyy 30 h sovelluskehikon testausta, 16 h demosovelluksen testausta sekä 8 h testiraporttien kirjoittamista. Vaihe T4: Testausta Vaihe Luovutus: 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. TESTAUSSUUNNITELMA 12

13 Mikko Viljainen 13 (14) 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. TESTAUSSUUNNITELMA 13

14 Mikko Viljainen 14 (14) Liite 2. Testiraportin kansilehti Case #N: <Test-Case:n nimi, Testattava ominaisuus> [1] Tuote: Sovelluskehikko / Demosovellus [2] Versio: <version numero> [3] Testin #: <testin järjestysnumero> [4] Testausympäristö: <määrittele testausympäristö> [5] Käytetyt ohjelmat: <testauksessa käytetyt ohjelmat.: työkalut, selaimet jne.> [6] Käytetyt tyngät/ajurit: <nimeä ja määrittele käytetyt ajurit> [7] Päivämäärä:..200 <testauspäivämäärä> [8] Aloitusaika: : <tarkka testauksen aloitusaika> [9] Lopetusaika: : <tarkka testauksen lopetusaika> [10] Testaaja: [11] Muuta: TESTAUSSUUNNITELMA 14