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