Testaussuunnitelma. Dokumentti: Testaussuunnitelma.doc Päiväys: Projekti: AgileElephant
|
|
- Timo Lehtonen
- 6 vuotta sitten
- Katselukertoja:
Transkriptio
1 AgilElephant Tekijä: Petri Kalsi ja Heikki Salminen Omistaja: ElectricSeven Dokumentti:.doc Päiväys: Aihe: Sivu 1 / 11
2 Dokumenttihistoria Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä Ensimmäinen versio, dokumentin rakenne Petri Kalsi I1-vaiheen suunnitelmaa täydennetty Heikki Salminen Tuotokset, kirjoitusvirheitä korjattu Petri Kalsi I2-vaiheen suunnitelmaa päivitetty Heikki Salminen Dokumentin rakennetta muutettu Esa Mommo I2-vaiheen suunnitelmaan muutoksia, HTTPUnit pois Petri Kalsi 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: Aihe: Sivu 2 / 11
3 Sisällysluettelo 1. Esittely Tarkoitus Kuvaus Viittaukset Testauslähestymistapa Menetelmät Automaattiset yksikkötestit Automatisoitu toiminnallinen testaus HTTPUnitilla Käsin tehtävä toiminnallinen testaus Staattiset menetelmät ohjelmakoodin analysoinnissa Heuristinen käytettävyyden arviointi Vertaistestaus Työkalut Resurssit ja työnjako Testitapausten hallinta ja dokumentointi Vikojen hallinta ja dokumentointi Testauksen lopetuskriteerit Testidata ja -aineistot Testauksen keskeytys- ja uudelleenaloituskriteerit Tuotokset Testauksen suorittaminen I1-vaihe Testausperiaatteet Resurssit ja työnjako Tavoitteet Yksikkötestaus Käsin tehtävä toiminnallinen testaus Muut menetelmät I2-vaihe Yksikkötestaus Automatisoitu toiminnallinen testaus HTTPUnitilla Käsin tehtävä toiminnallinen testaus FD-vaihe Testikäyttö Vertaistestaus Hyväksymistestaus Dokumentti:.doc Päiväys: Aihe: Sivu 3 / 11
4 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: Aihe: Sivu 4 / 11
5 2. Testauslähestymistapa 2.1 Menetelmät Testauksessa käytettävät menetelmät on esitelty alla 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 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 Dokumentti:.doc Päiväys: Aihe: Sivu 5 / 11
6 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 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 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 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: Aihe: Sivu 6 / 11
7 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: Aihe: Sivu 7 / 11
8 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: Aihe: Sivu 8 / 11
9 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 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 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 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 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: Aihe: Sivu 9 / 11
10 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 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 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 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 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 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: Aihe: Sivu 10 / 11
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 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 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 Hyväksymistestaus Lopullisen hyväksymistestauksen suorittaa asiakas projektin lopussa, 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: Aihe: Sivu 11 / 11
Testaussuunnitelma. Dokumentti: Testaussuunnitelma.doc Päiväys: Projekti: AgileElephant Versio: V0.4
AgilElephant Tekijä: Petri Kalsi ja Heikki Salminen Omistaja: ElectricSeven Dokumentti:.doc Päiväys: 30.11.2004 Aihe: Sivu 1 / 11 Dokumenttihistoria Muutoshistoria Revision päiväys: 30.11.2004 Seuraavan
Lisätiedotdokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant
AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan
LisätiedotSEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: 26.10.2004 Projekti : AgileElephant Versio: V0.9
AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 6 Dokumentti Historia Revisio Historia Revision päiväys: 26.10.2004
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant Versio: V0.2
AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 7 Dokumenttihistoria Muutoshistoria Revision päiväys: 1.11.2004
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 8 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys
LisätiedotTestaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan
LisätiedotHirviö Laadunvarmistussuunnitelma
Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 30. marraskuuta 2004 1 Sisältö 1 Johdanto 3 1.1 Testauksen tavoitteet
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotTestausraportti. Dokumentti: Testausraportti_I2.doc Päiväys: Projekti : AgileElephant
AgilElephant I2 Tekijä: Heikki Salminen Omistaja: ElectricSeven Aihe: Sivu 1 / 8 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 1.0 7.2.2004
LisätiedotHirviö Laadunvarmistussuunnitelma
Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 8. helmikuuta 2005 1 Sisältö 1 Johdanto 3 1.1 Testauksen tavoitteet
LisätiedotLaadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versio Päiväys Tekijä Kuvaus 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto
LisätiedotTestausraportti. Oppimistavoitteiden hallintajärjestelmä harri
Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
LisätiedotLaadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versi Päiväys Tekijä Kuvaus o 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto
LisätiedotConvergence of messaging
Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
LisätiedotVersio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio
Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista
LisätiedotOhjelmistojen mallintaminen. Luento 11, 7.12.
Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,
LisätiedotAutomaattinen yksikkötestaus
Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
LisätiedotTestausraportti. Dokumentti: Testausraportti_FD.doc Päiväys: Projekti: AgileElephant
AgilElephant FD Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Sivu 1 / 8 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 1.0 7.3.2005 Ensimmäinen
LisätiedotSEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant Versio: V0.93
AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 7 Dokumentti Historia Revisio Historia Revision päiväys: 29.11.2004
LisätiedotTestaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
LisätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
LisätiedotTestaussuunnitelma. Ohjelmistotuotantoprojekti Nero. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Ohjelmistotuotantoprojekti Nero Helsinki 5.11.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä
LisätiedotTestausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
LisätiedotUCOT-Sovellusprojekti. Testausraportti
UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe LU. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T3
T-76.115 Tietojenkäsittelyopin ohjelmatyö Testiraportti, vaihe LU Sisältö Tästä dokumentista ilmenee LU-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 14.4.2003
LisätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
LisätiedotT SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B
T-76.5158 SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B T-76.5158 SEPA - Pariohjelmointi 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 5.12.2006 Tuomas Tolvanen Ensimmäinen
LisätiedotHirviö Testausraportti I2
Hirviö Testausraportti I2 Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 8. helmikuuta 2005 1 Sisältö 1 Johdanto 3 1.1 Järjestelmätestaus.................................
LisätiedotLaadunvarmistusdokumentti
Laadunvarmistusdokumentti Dokumentin historia Versio Päiväys Muokkaaja Kuvaus Hyväksytty 1.10 07.11.2005 Rönkkö Kirsi Erotettu omaksi dokumentikseen Sisällysluettelo 1. Koko projektissa...2 1.1. Tavoitteet...2
Lisätiedot58160 Ohjelmoinnin harjoitustyö
58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Testauksen loppuraportti v. 1.0 Päivitetty 23.4.2001 klo 19:05 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0
LisätiedotOhjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
LisätiedotTestaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PULSU Syksy 2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Heikki Manninen Noora Joensuu
LisätiedotSEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant
AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 8 Dokumentti Historia Revisio Historia Revision Numero Revision
LisätiedotL models. Testisuunnitelma. Ryhmä Rajoitteiset
Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Testisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset
LisätiedotKuopio Testausraportti Asiakkaat-osakokonaisuus
Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki
LisätiedotTESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - VYM JA KANTA Versio 1.0 i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen
LisätiedotYksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }
Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.
LisätiedotTestaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza
Testaussuunnitelma Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Versio 1.0 Ehdotus Laatija Raine Kauppinen VERSIOHISTORIA Versionotyyppi Versio- Päiväys Tekijä
LisätiedotTestaussuunnitelma. Asdf. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Asdf Helsinki 22.2.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Kuisma Sami Louhio
Lisätiedot0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen
Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 24.10.2005 Elina Kontro Laatuasiat siirretty omaan dokumenttiin jatkotyöstetty 0.2 27.10.2005 Santeri Saarinen Bugien elinkaari yms. asioita jatkettu 0.3 28.10.2005
LisätiedotT Testiraportti - järjestelmätestaus
T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria
LisätiedotGood Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu
LisätiedotTESTIRAPORTTI - XMLREADER LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - XMLREADER LUOKKA i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen
LisätiedotOnnistunut SAP-projekti laadunvarmistuksen keinoin
Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.
LisätiedotTIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 27.10.2014 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus
LisätiedotTIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori
TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 28.10.2013 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus
LisätiedotTyökalut ohjelmistokehityksen tukena
1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan
LisätiedotTestaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PUSU-ryhmä Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Jussi Hynninen
LisätiedotTestausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter
LisätiedotCoMa - Testausdokumentti
CoMa - Testausdokumentti Mindmap - Kari Velling Helsinki 16.12.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä
LisätiedotTestaaminen ohjelmiston kehitysprosessin aikana
Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/
LisätiedotProjektisuunnitelma. (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena
LisätiedotJReleaser Yksikkötestaus ja JUnit. Mikko Mäkelä 6.11.2002
JReleaser Yksikkötestaus ja JUnit Mikko Mäkelä 6.11.2002 Sisältö Johdanto yksikkötestaukseen JUnit yleisesti JUnit Framework API (TestCase, TestSuite) Testien suorittaminen eri työkaluilla Teknisiä käytäntöjä
LisätiedotOnnistunut Vaatimuspohjainen Testaus
Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen
LisätiedotMihin kaikkeen voit törmätä testauspäällikön saappaissa?
Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tieran toiminta perustuu osaamisverkoston rakentamiseen, mikä
LisätiedotLAATURAPORTTI Iteraatio 1
LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja
LisätiedotKäyttötapausanalyysi ja testaus tsoft
Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten
LisätiedotProjektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Projektisuunnitelma KotKot Helsinki 22.9.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 + 1 op) Projektiryhmä Tuomas Puikkonen
LisätiedotLAATUDOKUMENTTI
LAATUDOKUMENTTI LAATUDOKUMENTTI 2 (15) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 11.10.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 17.10.2006 Kaarlo Lahtela Lauri Kiiski 0.3 24.10.2006 Kaarlo Lahtela
LisätiedotTIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
LisätiedotProject-TOP QUALITY GATE
Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä
LisätiedotT Projektikatselmus
T-76.115 Projektikatselmus Projektityöryhmä GenCode I3-iteraatio 17.3.2004 Agenda Tavoitteiden toteutuminen (5 min) Resurssien käyttö (5 min) Iteraation tulokset (10 min) Riskit (5min) +Kokemuksia työskentelymenetelmistä
LisätiedotWCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma
TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/jekahkon/wclique/testplan.html WCLIQUE Ohjelmistoprojekti Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com, 75014C,
LisätiedotOhje kehitysympäristöstä. Dokumentti: Ohje kehitysympäristöstä.doc Päiväys: 15.03.2005 Projekti : AgileElephant
AgilElephant Tekijä: Petri Kalsi Omistaja: ElectricSeven Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 1 of 6 Dokumenttihistoria Muutoshistoria Revision Revision Yhteenveto muutoksista Revision tekijä
LisätiedotTESTIRAPORTTI - JÄRJESTELMÄ, ADMIN Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - JÄRJESTELMÄ, ADMIN i Sisällysluettelo DUMENTIN VERSIOT 1 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI
LisätiedotLohtu-projekti. Testaussuunnitelma
Lohtu-projekti Testaussuunnitelma Versiohistoria: 1.0 19.2.2003 1. versio Mari 1.1 20.2.2003 Muutoksia Mari 1.2 25.2.2003 Katselmoinnissa esiin tulleet Mari muutokset 1.3 17.3.2003 2. syklissä tehtävät
LisätiedotKuopio Testausraportti Kalenterimoduulin integraatio
Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio, testausraportti, 22.4.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 22.4.2002 Matti Peltomäki Ensimmäinen versio 0.9 22.4.2002 Matti
LisätiedotHYVÄKSYMISTESTAUS- RAPORTTI - HAKEUTUJAN PALVELUT JA TODENNETUN OSAAMISEN REKISTERI
HYVÄKSYMISTESTAUS- RAPORTTI - HAKEUTUJAN PALVELUT JA TODENNETUN OSAAMISEN REKISTERI 13.5.2013 Dokumentin tallennuspaikka Sivu 1/8 SISÄLLYSLUETTELO 1 DOKUMENTIN TARKOITUS... 3 2 TESTAUKSEN TILANNE... 3
LisätiedotAutomaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure
Automaattinen regressiotestaus ilman testitapauksia Pekka Aho, VTT Matias Suarez, F-Secure 2 Mitä on regressiotestaus ja miksi sitä tehdään? Kun ohjelmistoon tehdään muutoksia kehityksen tai ylläpidon
LisätiedotOhjelmistotestaus -09
Ohjelmistotestaus Testaustyökalut- ja automaatio Testaustyökalut ja -automaatio Testaustyökaluilla tuetaan testaustyötä sen eri vaiheissa Oikea työkalu oikeaan tarkoitukseen Testausautomaatio perustuu
LisätiedotOpetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen
Opetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen Toiminnallinen määrittely: Työsuunnitelma TYÖSUUNNITELMAN TIEDOT Versio 0.1 Laatija Ulla Angervo Laatimispäivämäärä Hyväksyjä Hyväksymispäivämäärä
LisätiedotT Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
LisätiedotKontrollipolkujen määrä
Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät
LisätiedotProjektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena on luoda valmis sekvenssiohjelma säätötekniikan
LisätiedotGood Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi
Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.
LisätiedotYlläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
LisätiedotHarjoitustyön testaus. Juha Taina
Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida
LisätiedotTESTIRAPORTTI - XMLREADER-LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)
TESTIRAPORTTI - XMLREADER-LUOKKA Versio 1.0 (luonnos 2) Copyright Comptel Oyj i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin
LisätiedotSALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti
Järjestelmäprojekti 1 projektisuunnitelma ICT4TN007-2 SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti Versio 0.1 Tekijät Keijo Nykänen Tarkastanut Hyväksynyt HAAGA-HELIA
Lisätiedot11. PALAVERIN PÖYTÄKIRJA. Jyväskylän Yliopisto Tietotekniikan laitos CONCEPT-projekti Paikka ja aika
Paikka ja aika Kokoustila Ag C223.1 tiistai klo 13:33-16:07 Läsnä Jouni Kallio(JK), liikuntabiologian laitoksen edustaja Lari Kannisto(LK), vastaava ohjaaja Petteri Kela(KELA), tekninen ohjaaja Pekka Kuuva(PK),
LisätiedotOhjelmiston testaus ja laatu. Testausmenetelmiä
Ohjelmiston testaus ja laatu Testausmenetelmiä Testausmenetelmiä - 1 Testauksen menetelmien päälähestymistapoina ovat black-box testi testaaja ei voi tutkia lähdekoodia testaus perustuu sovellukselle suunnitteluvaiheessa
LisätiedotVakuutusyhtiöiden testausinfo
Vakuutusyhtiöiden testausinfo ATJ:n ulkoisten liittymien testaaminen Jonna Hannukainen ja Markku Noukka 12. ja 17.5.2006 (Päivitetty 18.5.2006) ATJ:n integraatiotestaus vakuutusyhtiöiden kanssa Testauksen
LisätiedotTapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
LisätiedotTESTIRAPORTTI - JÄRJESTELMÄ, PORTAL Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL i Sisällysluettelo DUMENTIN VERSIOT 1 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI
LisätiedotOodin versiot, havaittujen virheiden korjaus sekä kehitysehdotusten eteneminen
Oodin versiot, havaittujen virheiden korjaus sekä kehitysehdotusten eteneminen Laura Vuorinen 17.4.2007 Kehittämisosasto / Opiskelijarekisteri Oodin kehitystarpeet käytännöt muuttuvat, alkuperäiset (1995)
LisätiedotMihin kaikkeen voit törmätä testauspäällikön saappaissa?
Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tiera on vuonna 2010 perustettu yli 200:n kuntatoimijan omistama
LisätiedotLaadunvarmistuksen loppuraportti
Laadunvarmistuksen loppuraportti Dokumentin historia Versio Päiväys Muokkaaja Kuvaus Hyväksytty 1.2 26.02.06 Rönkkö Kirsi Päivitetty viimeiset data dokumenttiin 1.1 24.02.06 Rönkkö Kirsi Liitetty muilta
LisätiedotTämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:
Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus
LisätiedotTestauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
LisätiedotHyväksymistestauksen tarkistuslista järjestelmän hankkijalle
Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle Tarkistuslista on suunniteltu käytettäväksi hyväksymistestauksen suunnittelussa, valmiuksien arvioinnissa ja katselmoinnissa.tämä tarkistuslista
LisätiedotAgilElephant ja CruiseControl
AgilElephant ja CruiseControl Tekijä: Juha Kaarlas Omistaja: ElectricSeven Aihe: CruiseControl ja AgilElephant Sivu 1 of 9 Dokumentti Historia Muutoshistoria Revision Revision Yhteenveto muutoksista Revision
LisätiedotCT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)
LisätiedotSopimus Asiakas- ja potilastietojärjestelmästä. Liite N: Kielivaatimukset
Sopimus Asiakas- ja potilastietojärjestelmästä Liite N: Kielivaatimukset VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 12.3.15 3.0 Tarjouspyynnön liitteeksi 2 (6) SISÄLLYSLUETTELO 1 JOHDANTO... 4 2 JÄRJESTELMÄN
LisätiedotValtioneuvoston kanslia VAIN VIRKAKÄYTTÖÖN Hallinto- ja palveluosasto/hallintoyksikkö Terja Ketola PTJ2008-työsuunnitelma 1 (5)
Terja Ketola PTJ2008-työsuunnitelma 1 (5) AIKATAULU JA TEHTÄVÄT / PTJ2008 VALMIS MENOSSA MYÖHÄSSÄ ALOITTAMATTA ALUSTAVA AJANKOHTA EI PIDETTY / TEHTY 1 Määrittelyn läpikäynti PTi, TKe, IHa, TRö 34 23.8.2007
LisätiedotTestaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri
Testaussuunnitelma Oppimistavoitteiden hallintajärjestelmä harri Helsinki 15.11.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
Lisätiedot