AgilElephant Tekijä: Petri Kalsi ja Heikki Salminen Omistaja: ElectricSeven Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 1 / 11
Dokumenttihistoria Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 0.1 04.11.04 Ensimmäinen versio, dokumentin rakenne Petri Kalsi 0.2 06.11.04 I1-vaiheen suunnitelmaa täydennetty Heikki Salminen 0.3 07.11.04 Tuotokset, kirjoitusvirheitä korjattu Petri Kalsi 0.4 29.11.04 I2-vaiheen suunnitelmaa päivitetty Heikki Salminen 0.5 09.01.05 Dokumentin rakennetta muutettu Esa Mommo 0.6 02.02.05 I2-vaiheen suunnitelmaan muutoksia, HTTPUnit pois Petri Kalsi 0.7 21.02.05 FD-vaiheen suunnitelmaa täydennetty Petri Kalsi Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Juha Kaarlas Tehtävä Projektipäällikkö Katselmoinnit Tämä dokumentti vaatii seuraavien henkilöiden katselmoinnin Nimi Tehtävä Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Tehtävä Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 2 / 11
Sisällysluettelo 1. Esittely...4 1.1 Tarkoitus...4 1.2 Kuvaus...4 1.3 Viittaukset...4 2. Testauslähestymistapa...5 2.1 Menetelmät...5 2.1.1 Automaattiset yksikkötestit... 5 2.1.2 Automatisoitu toiminnallinen testaus HTTPUnitilla... 5 2.1.3 Käsin tehtävä toiminnallinen testaus... 6 2.1.4 Staattiset menetelmät ohjelmakoodin analysoinnissa... 6 2.1.5 Heuristinen käytettävyyden arviointi... 6 2.1.6 Vertaistestaus... 6 2.2 Työkalut...6 2.3 Resurssit ja työnjako...7 2.4 Testitapausten hallinta ja dokumentointi...7 2.5 Vikojen hallinta ja dokumentointi...7 2.6 Testauksen lopetuskriteerit...7 2.7 Testidata ja -aineistot...7 2.8 Testauksen keskeytys- ja uudelleenaloituskriteerit...8 2.9 Tuotokset...8 3. Testauksen suorittaminen...9 3.1 I1-vaihe...9 3.1.1 Testausperiaatteet... 9 3.1.2 Resurssit ja työnjako... 9 3.1.3 Tavoitteet... 9 3.1.4 Yksikkötestaus... 9 3.1.5 Käsin tehtävä toiminnallinen testaus... 10 3.1.6 Muut menetelmät... 10 3.2 I2-vaihe...10 3.2.1 Yksikkötestaus... 10 3.2.2 Automatisoitu toiminnallinen testaus HTTPUnitilla... 10 3.2.3 Käsin tehtävä toiminnallinen testaus... 10 3.3 FD-vaihe...11 3.3.1 Testikäyttö... 11 3.3.2 Vertaistestaus... 11 3.3.3 Hyväksymistestaus... 11 Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 3 / 11
1. Esittely 1.1 Tarkoitus Tässä dokumentissa kuvataan AgilElephant-tuotteen kehityksen yhteydessä käytettävät testausmenetelmät ja niiden aikataulu eri iteraatioissa. 1.2 Kuvaus Testauksen luonne on jokaisessa iteraatiossa erilainen menetelmiltään ja painotuksiltaan. Lähestymistapa ja käytetyt menetelmät kuvataan ensin yleisesti luvussa 2. Luvussa Error! Reference source not found. on kuvattu aikataulu jokaiselle iteraatiolle erikseen, ja miten eri menetelmiä käytetään kyseisessä iteraatiossa. 1.3 Viittaukset SEPA_diary_PK_RI.doc: SEPA-tehtävä staattisesta analyysistä SEPA_diary_EM_PV.doc: SEPA-tehtävä heuristisesta arvioinnista Projektisuunnitelma.doc: Sisältää muiden tehtävien ohella myös testauksen tuntiaikataulun Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 4 / 11
2. Testauslähestymistapa 2.1 Menetelmät Testauksessa käytettävät menetelmät on esitelty alla. 2.1.1 Automaattiset yksikkötestit Yksikkötestaus tehdään järjestelmän tärkeimmälle matalan tason toiminnallisuudelle ja ulkoisille rajapinnoille. Yksikkötestien kirjoittamiselle rajataan kiinteä osa vastaavan toiminnallisuuden implementointiin kuluvasta ajasta. Testeissä pyritään keskittymään luokkien tärkeimpään toiminnallisuuteen, niin että samalla saavutetaan kohtuullinen lausekattavuus muutamalla testitapauksella. Testit ajetaan CruiseControl-järjestelmässä automaattisen buildin yhteydessä. Testaus pyritään tekemään ristiin, parijako on sama kuin SEPA-tehtävissäkin. Tarkoituksena on, että jokaisen kriittisen luokan toteutukseen on perehtynyt vähintään kaksi ryhmän jäsentä, toinen ohjelmoijan ja toinen testaajan näkökulmasta. Testien integroinnista build-skripteihin vastaa Heikki Salminen. Työn helpottamiseksi tulee kaikki testiluokat nimetä samalla tavalla, <testattava_luokka>test.java. Yksikkötestausta tehdään rinnakkain itse ohjelmoinnin kanssa, kuitenkin siten että testattavan luokan suunnittelun tulisi olla pääpiirteittäin valmis ennen yksikkötestien kirjoittamista. Tämä tarkoittaa, että luokan metodit on nimetty, ja niille on kirjoitettu Javadocit, joiden perusteella testit voidaan luoda. Automaattisten yksikkötestitapausten suunnitteluun ja toteutukseen pyritään käyttämään 20% testattavan toiminnallisuuden suunnitteluun ja toteuttamiseen käytetystä ajasta. Jos toiminnallisuutta muutetaan, laajennetaan tai korjataan, testitapausten muuttamiseen ja lisäämiseen käytetään taas 20% toteutuksen muutokseen käytetystä ajasta. Muutosten ja korjausten yhteydessä testitapaukset päivittää muutoksen tekijä eli niitä ei edes pyritä tekemään ristiin. Keskeisimpiin ja monimutkaisimpiin toimintoihin voidaan käyttää suhteessa enemmän yksikkötestausaikaa, mutta se pyritään tekemään yksinkertaisimpien ja toteutukseltaan suoraviivaisimpien toimintojen testauksen kustannuksella. 2.1.2 Automatisoitu toiminnallinen testaus HTTPUnitilla Myös toiminnalliset testit ajetaan öisin buildin yhteydessä. Testit ovat luonteeltaan integrointi- ja järjestelmätestausta. Toiminnallista testausta varten toteutetaan erillinen www-käyttöliittymä. Käyttöliittymän navigointi tehdään HTTPUnitilla, ja vastauksena saatua sivua verrataan CVS:stä löytyvään haluttuun lopputulokseen. Järjestelmään kehitetään erillinen, mahdollisimman yksinkertainen, selkeärakenteinen ja muuttumaton www-käyttöliittymä automatisoitua funktionaalista testausta varten. Erillinen ulkoasultaan karsittu käyttöliittymä syntyy osittain muun kehitystyön lomassa alkuvaiheen prototyyppikäyttöliittymästä, joka jätetään talteen, kun käyttöliittymän ulkoasua aletaan muokata käytettävyyden kannalta. HTTPUnitilla toteutetaan käyttöliittymän navigointi ja tietokannan alkuarvojen alustus. Navigoinnin lopputuloksena saatua www-sivua verrataan diff-työkalulla haluttuun lopputulokseen. Automaattiset testit ajetaan aina buildin yhteydessä. Päivitys: HTTPUnit-testausta ei järjestetä, kts. luku 3.2.2. Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 5 / 11
2.1.3 Käsin tehtävä toiminnallinen testaus Pääosa toiminnallisesta järjestelmätestauksesta tehdään käsin. Testitapauksista ylläpidetään kompaktia listaa Excel-taulukkona. Testitapausten kuvaus, suoritusohje ja toivottu lopputulos pidetään yksinkertaisena ajan säästämiseksi, sillä testien suunnittelija ja suorittaja on sama henkilö. Osa näin säästetystä ajasta käytetään laadukkaisiin bugiraportteihin, joihin kirjataan tarkka toistosekvenssi, havaittu lopputulos sekä testaajan odottama lopputulos. Testitapaukset ryhmitellään testijaksoihin sen mukaan, mihin käyttötapaukseen testit liittyvät. Testit priorisoidaan jakson sisällä ja suoritetaan aina prioriteettijärjestyksessä. Myös testijaksot priorisoidaan noudattaen käyttötapausten ja vaatimusten priorisointia. Testisarjojen ja testien suoritusjärjestys joutuu tietenkin joskus noudattamaan testattavien ominaisuuksien toteutusjärjestystä. Testitapaukset ja suorituksen tulokset kirjataan Excel-taulukkoon. Samassa taulukossa pidetään kirjaa myös siitä, mitkä testit on suoritettu (koska ja kuka), kuinka moneen kertaan ne on suoritettu onnistuneesti ja kuinka paljon virheitä niiden seurauksena on löydetty. 2.1.4 Staattiset menetelmät ohjelmakoodin analysoinnissa Ohjelmakoodista generoituja tunnuslukuja, kuten metodien pituutta ja kompleksisuutta analysoimalla pyritään löytämään kohtia koodista, joissa virheiden esiintymistodennäköisyys on erityisen suuri. Lisäksi virheitä etsitään katselmointien ja ohjelmallisten työkalujen avulla. Staattisten menetelmien käyttöönotto on kuvattu SEPA-päiväkirjassa SEPA_diary_PK_RI.doc. Projektissa käytetään myös koodausohjesääntöä, ks. koodaus_ohjeet.doc. 2.1.5 Heuristinen käytettävyyden arviointi Varsinaiseen käyttäjien kanssa tehtävään käytettävyystestaukseen ei ole aikaa, joten käyttöliittymän käytettävyyttä pyritään arvioimaan järjestelmällisellä katselmoinnilla. Arvioinnissa käytetään useita arvioijia, joista jokainen ensin suorittaa arvioinnin yksin ja vasta sen jälkeen arvioijat voivat keskustalla ja koota löydetyt havainnot yhteen. Tällä varmistetaan se, että toisten arvioijien löytämät viat eivät vaikuta muiden arviointeihin. Kukin katselmoija kirjoittaa omat havaintonsa arviointitilaisuuden aikana ja yhteenvedon eri havainnoista tekevät tilaisuuden järjestäjät. Heuristisen arvioinnin käyttöönotto on kuvattu SEPA-päiväkirjassa SEPA_diary_EM_PV.doc. 2.1.6 Vertaistestaus Kurssin puitteissa järjestetään FD-vaiheessa järjestelmän testaus vertaisryhmän toimesta. Vertaisryhmämme on hutiko, joka toteuttaa DiMaS-järjestelmää HIIT:lle 2.2 Työkalut Testauksen ja raportoinnin apuna käytetään seuraavia työkaluja: Bugzilla: Virheiden raportointi ja seuranta Excel: Testitapausten ja -tulosten kirjaaminen JUnit: Yksikkötestauksen sovelluskehys HTTPUnit: Funktionaalinen testaus WWW-käyttöliittymän läpi FindBugs: Automaattinen työkalu yleisten ohjelmointivirheiden löytämiseen JavaNcss: Laskee ohjelmakoodista kompleksisuustunnuslukuja Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 6 / 11
Mozilla Firefox: Käytetään referenssiselaimena käyttöliittymää testatessa 2.3 Resurssit ja työnjako Testaukseen osallistuvat kaikki projektiryhmän jäsenet projektipäällikköä lukuun ottamatta. Päävastuu testauksen järjestelyistä, testisuunnittelusta ja toiminnallisen testauksen suorituksesta on Petri Kalsilla ja Heikki Salmisella. Aikataulutuksen, tarkan resursoinnin ja testauksen priorisoinnin muihin toimiin verrattuna hoitaa projektipäällikkö. 2.4 Testitapausten hallinta ja dokumentointi Testitapaukset dokumentoidaan Excel-taulukkona. Jokaista testijaksoa varten tehdään erillinen taulukko erillisenä dokumenttina. Testien suorituksen etenemistä seurataan samojen taulukoiden avulla. Dokumentteja säilytetään projektin yleisessä CVS:ssä. Tarkempi suunnittelu tehdään iteraation I1 aikana. 2.5 Vikojen hallinta ja dokumentointi Kaikki käsin tehtävässä testauksessa havaittujen vikojen hallinnointi ja dokumentointi tehdään Bugzillajärjestelmän avulla. Viat kirjataan järjestelmään heti, kun ne havaitaan. Vikojen vakavuusluokittelu tehdään Bugzillan normaalin käytännön mukaisesti. Kohtiin platform ja operating system kirjataan oletusarvoisesti all. Prioriteetti määritellään vain erikoistapauksissa, normaalitapauksissa kaikki viat kirjataan arvolla P3. Samalla prioriteetilla olevat viat korjataan oletusarvoisesti vakavuusjärjestyksessä. Vian kuvauksen yhteyteen kirjataan tieto siitä, minkä testitapauksen yhteydessä se löydettiin. Käännösvirheiden ja automatisoiduissa testeissä havaittujen vikojen hallinnassa käytetään kevyintä mahdollista prosessia, koska niitä ei pitäisi tapahtua lainkaan versionhallinnasta peräisin olevilla versioilla. Öisin tapahtuvan automaattisen käännöksen ja testauksen virheilmoitukset lähetetään sähköpostilla projektiryhmän postituslistalle. Ensimmäisenä ehtivä korjaa virheen niin pian kuin mahdollista. 2.6 Testauksen lopetuskriteerit Testauksen lopetuskriteerit ovat ajankohtaisia vasta iteraatiosta I2 eteenpäin, joten ne päätetään myöhemmin. Iteraatiossa I1 testausaika loppuu kuitenkin kesken sellaisella tavalla, että lopettamista ei tarvitse suunnitella. 2.7 Testidata ja -aineistot Kaikessa automatisoidussa testauksessa tarvitaan järjestelmän tietokantaan vakioitu testidata, jota käytetään testauksen pohjana. Testidataa ei ladata suoraan tietokantaan, vaan se muodostetaan järjestelmän rajapinnan kautta. Näin kannan rakenteen muuttaminen on mahdollista testidataa muuttamatta. Samalla rajapinta tulee testattua. Testidata saadaan tietokantaan tyhjentämällä kanta ja ajamalla datan muodostava JUnit-pohjainen skripti. Testidataa hallinnoidaan siis kyseistä skriptiä muokkaamalla. Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 7 / 11
2.8 Testauksen keskeytys- ja uudelleenaloituskriteerit Iteraatiossa I1 testausaika loppuu kuitenkin kesken sellaisella tavalla, että keskeytystä ei tarvitse suunnitella ja järjestelmällisiä uudelleenaloituksia ei tehdä. Iteraatiosta I2 eteenpäin sovellettavat käytännöt päätetään myöhemmin. 2.9 Tuotokset Testauksen yhteydessä tuotetaan seuraavat kurssin vaatimat dokumentit: Vaihe Dokumentti Huomioita I1 Päivitetään myöhemmissä iteraatioissa Testitapaukset ja testilogi Testausraportti I2 Testitapaukset ja testilogi Testausraportti FD Testitapaukset ja testilogi Testausraportti Bugiraporttien yhteenveto Vertaistestauksen ohjeet Vertaistestauksen testausraportti Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 8 / 11
3. Testauksen suorittaminen 3.1 I1-vaihe I1-vaiheen tärkein testausmenetelmä on automaattiset yksikkötestit. Toteutettavaksi valitut käyttötapausten skenaariot testataan erikseen käsin. Testitapaukset säilytetään seuraaviin iteraatioihin, joissa vanha perustoiminnallisuus testataan toistamiseen. 3.1.1 Testausperiaatteet Vaiheessa I1 toteutetaan tuotteen tärkeimmät hallinnointiominaisuudet priorisoidussa järjestyksessä. Ominaisuuksien testaus tehdään samassa järjestyksessä niin pian kuin mahdollista. Ominaisuuksia ei ole vielä suunniteltu tarkasti. Tässä vaiheessa luotettavuutta ja suorituskykyä ei testata lainkaan ja käytettävyyttäkin vain vähän. Testauksessa keskitytään toiminnallisiin ominaisuuksiin ja niiden virheettömyyteen ja määrittelynmukaisuuteen. 3.1.2 Resurssit ja työnjako Yksikkötestien suunnitteluun osallistuvat sekä testitapausten toteuttaja että testausvastaavat Kalsi ja Salminen. Testitapausten toteutuksen tekee joko toiminnallisuuden toteuttajan pari tai aikataulusyistä toteuttaja itse. Toiminnallisen testauksen suunnittelun tekevät yhteystyönä Kalsi ja Salminen. Testien suorittamiseen osallistuvat kaikki ryhmän jäsenet, mutta Kalsi ja Salminen käyttävät siihen suuremman työpanoksen kuin muut. Ainakin vaiheen alussa kukin suorittaa testauksen omalla koneellaan. On vielä epäselvää, saadaanko yhteiseen käyttöön sopiva palvelin järjestettyä ja voidaanko sitä käyttää testauksessa. Jos testitulokset vaihtelevat eri koneilla, referenssiympäristö pyritään järjestämään. 3.1.3 Tavoitteet Iteraation päättyessä tuotteeseen ei jää lainkaan löydettyjä mutta korjaamattomia tai tarkastamattomia vakavuusluokkien blocking ja critical vikoja Iteraation aikana tuotteesta löydetään korkeintaan kolme vakavuusluokkien blocking ja critical vikaa Järjestelmän ytimen muodostaville luokille ja tärkeimmän iteraatiossa toteutetun toiminnallisuuden toteuttaville luokille saadaan tehtyä yksikkötestit Iteraation päättyessä kaikki toteutetut yksikkötestit menevät läpi virheettömästi Iteraatiossa toteutetun toiminnallisuuden kattavat testitapaukset saadaan suunniteltua Vähintään 75% suunnitelluista testitapauksista saadaan suoritettua 3.1.4 Yksikkötestaus Yksikkötestitapausten suunnittelu aloitetaan mahdollisimman pian sen jälkeen kun testattavan ominaisuuden tekninen määrittely on valmis. Yksikkötestitapausten toteutus aloitetaan mahdollisimman pian sen jälkeen kun luokkien rakenne ja javadoc-dokumentointi on valmis. Toteutuksen valmistuessa Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 9 / 11
yksikkötestit viimeistellään ja testataan. Kaikkeen tähän pyritään käyttämään yhteensä noin 20% toteutusajasta kuten edellä on mainittu. Yksikkötesteissä havaitut virheet korjataan nopeasti, korjaukset priorisoidaan uuden toiminnallisuuden toteutuksen edelle. 3.1.5 Käsin tehtävä toiminnallinen testaus Kaikki I1-vaiheessa toteutettavat käyttötapausten skenaariot testataan käsin. Käsin tehtävä testaus suoritetaan iteraation loppuvaiheessa, kun kaikki suunnitellut toiminnallisuudet on saatu toteutettua. Testitapausten suunnittelu aloitetaan mahdollisimman pian sen jälkeen kun testattavan ominaisuuden toiminnallinen määrittely on valmis. Toiminnallinen testaus suunnitellaan etukäteen ja toteutetaan, kun yksikkötesteissä havaitut virheet on korjattu. Tässä vaiheessa toiminnalliseen testaukseen pyritään käyttämään kokonaisuudessaan noin 20% työajasta. 3.1.6 Muut menetelmät Automaattisten staattisten analyysimenetelmien käyttöä aloitellaan jo tässä vaiheessa. Katselmointien tarve tämän iteraation aikana harkitaan vasta myöhemmin. Jos virheitä löydetään runsaasti, rutiinikatselmoinnit aloitetaan. Ikonen ja Kallioniemi järjestävät vähintään yhden yleisen koodikatselmointitilaisuuden. Käytettävyyden heuristinen arviointi järjestetään kerran aivan iteraation lopussa. 3.2 I2-vaihe I2-vaiheessa siirrytään laajempaan järjestelmätestaukseen. Vanhat automatisoidut yksikkötestit pyörivät edelleen, mutta uusia yksikkötestejä kirjoitetaan harkitusti. Vanhoja testejä päivitetään, jos luokkien toiminnallisuus muuttuu. Matalan tason toteutuksen muuttamista I1-vaiheen jälkeen pyritään välttämään. 3.2.1 Yksikkötestaus Vanhoja yksikkötestejä ajetaan edelleen buildien yhteydessä. Uusia testejä voidaan kirjoittaa kattavuuden parantamiseksi, mikäli jonkin yksittäisen luokan epäillään sisältävän virheitä. Testien kirjoittamiseen varattu aika on kuitenkin I2-vaiheessa hyvin rajallinen. 3.2.2 Automatisoitu toiminnallinen testaus HTTPUnitilla HTTPUnitilla tehtävästä testauksesta päätettiin I2-vaiheessa luopua ajanpuutteen takia. Yksikkötestit jäivät I1-vaiheessa puutteelliseksi, ja niitä parannetaan HTTPUnit-testauksen kustannuksella. Yksikkötestit olivat yksi asiakkaan vaatimuksista projektille. 3.2.3 Käsin tehtävä toiminnallinen testaus Samoin kuin I1-vaiheessa, kaikki toteutettavat ominaisuudet testataan myös käsin www-käyttöliittymän kautta. Ajanpuutteen takia osa aikaisemmin toteutetusta toiminnallisuudesta voidaan joutua testaamaan vasta I2-vaiheessa. Testauksesta päätettiin tehdä exploratory-tyyppistä, jolloin testitapaukset ovat suuntaa-antavia lähestymistapoja testauksen suorittamiselle. Yksityiskohtaisten testien kirjoittaminen huomattiin vaikeaksi, Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 10 / 11
sillä järjestelmän korkean tason toiminnallisuuksia ei ollut vielä tässä vaiheessa dokumentoitu testausta varten riittävällä tarkkuudella. Tarkkojen testitapausten kirjoittaminenkin perustuisi siis testaajan intuitioon. 3.3 FD-vaihe 3.3.1 Testikäyttö Asiakkaan pyynnöstä ElectricSeven-ryhmä ottaa koko järjestelmän käyttöön FD-vaiheen tuntiseurannan ja suunnittelun välineenä. Jokainen jäsen kirjaa tekemiään tehtäviä järjestelmään, ja päivittää jäljellä olevien työmäärien arvioita, kuten Trapolissa. Tällä voidaan korvata erikseen tehtävä toiminnallinen testaus, ja käytettävyyden arviointi ja korjaaminen on helpompaa. Tuntiraportointia tehdään varmuuden vuoksi samanaikaisesti myös Trapoli-järjestelmään. 3.3.2 Vertaistestaus Vertaistestaukseen on käytettävissä vähintään 8 tuntia vertaisryhmän aikaa FD-vaiheen aikana. Vertaistestausta varten suunnitellaan ohjeet erilliseen dokumenttiin käyttäen kurssin määrittelemää mallia, joka löytyy osoitteesta http://www.soberit.hut.fi/t-76.115/04-05/ohjeet/template/testchartertemplate.doc. 3.3.3 Hyväksymistestaus Lopullisen hyväksymistestauksen suorittaa asiakas projektin lopussa, 1.-3.3. Tuotetta esitellään asiakkaalle projektin aikana niin usein, että sisällön ja toiminnallisuuden pitäisi tässä vaiheessa olla asiakkaan toiveiden mukainen. Hyväksymistestaus aikataulutetaan siten, että siinä löydetyt pienet virheet ehditään vielä korjata. Jos suuritöisiä virheitä löytyy vielä hyväksymistestauksessa, ne joudutaan jättämään korjaamatta. Asiakkaalla ei ole mahdollisuutta varsinaisesti hyväksyä tai hylätä tuotetta, mutta hyväksymistestauksen tulos vaikuttanee ryhmän saamaan arvosteluun. Asiakkaalle tarjotaan mahdollisuus kokeilla tuotetta omatoimisesti jo ennen sen lopullista valmistumista. Asiakkaalle järjestetään myös mahdollisuus raportoida havaitsemansa virheet suoraan Bugzillaan. Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 11 / 11