Testaussuunnitelma Kuopio
|
|
- Ella Tamminen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Testaussuunnitelma Kuopio
2 Kuopio, Testaussuunnitelma, Versiohistoria: Versio Pvm Laatija Muutokset Matti Peltomäki Ensimmäinen versio Matti Peltomäki Sisäisen katselmoinnin korjaukset Ossi Jokinen Asiakaskatselmoinnin korjaukset. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 2
3 SISÄLLYSLUETTELO 1. JOHDANTO TESTAUKSEN TARKOITUS TUOTE TESTAUSYMPÄRISTÖ LYHYESTI TERMIT VIITTEET YLEISKATSAUS DOKUMENTTIIN Johdanto Testausympäristö Henkilöstö- ja koulutusvaatimukset Vastuualueet Tehtäväjärjestys ja testausmenettely Regressiotestaus Testitapaukset Tulosaineisto Testauksen hyväksyminen Riskien hallinta TESTAUSYMPÄRISTÖ PALVELIN TYÖASEMA TURVALLISUUSNÄKÖKOHTIA APUVÄLINEET JA TYÖKALUT HENKILÖSTÖ- JA KOULUTUSVAATIMUKSET VASTUUALUEET TESTIRYHMÄ MODUULITESTAUS INTEGROINTITESTAUS TEHTÄVÄJÄRJESTYS JA TESTAUSMENETTELY TESTAUKSEN LUONTEESTA TESTAUSTA ALUSTAVAT TOIMENPITEET TEHTÄVÄJÄRJESTYS Moduulitasolla Testitapaustasolla TESTITAPAUSLUOKAT JA TESTITAPAUSTEN NUMEROINTI VIRHELUOKAT MENETELMÄT JA TEKNIIKAT KATTAVUUS REGRESSIOTESTAUS TESTITAPAUKSET MODUULITESTAUS Henkilöt-osakokonaisuus...18 Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 3
4 7.1.2 Asiakkaat-osakokonaisuus Projektit-osakokonaisuus INTEGROINTITESTAUS TIETOJEN SIIRRON TESTAUS TULOSAINEISTO TESTAUKSEN HYVÄKSYMINEN ALOITUSKRITEERIT LOPETUSKRITEERIT HYVÄKSYMISKRITEERIT HYLKÄÄMISKRITEERIT KESKEYTTÄMISKRITEERIT RISKIEN HALLINTA AIKATAULU JA TYÖMÄÄRÄT...22 Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 4
5 TAULUKOT JA KUVAT Table 1 Termit... 7 Table 2 Virheluokat Table 3 Keskeyttämiskriteerit Table 4 Testauksen riskit Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 5
6 1. JOHDANTO 1.1 Testauksen tarkoitus 1.2 Tuote Tämän testaussuunnitelman tarkoituksena on määrittää Kuopio-projektin testaus. Tämä dokumentti on tarkoitettu projektiryhmän sisäiseen käyttöön, asiakkaalle sekä kurssin edustajille. Testausprojekti määritellään siten, että toiminnanohjausjärjestelmän Kuopio-projektin puitteissa toteutettavat moduulit ja integraatiot tulevat testatuiksi. Jo valmiina olevia moduuleita ei testata integraatiotestausta lukuunottamatta, eikä niiden testausta dokumentoida Kuopio-projektissa. Projektin ulkopuolelle jäävien osakokonaisuuksien moduulitestausta tai integraatiotestausta ei suunnitella. Järjestelmätestausta ei suoriteta, koska toiminnanohjausjärjestelmää ei kokonaisuudessaan toteuteta Kuopio-projektin puitteissa eikä sen aikana. Dokumentin tavoitteena on määritellä testausprojekti siten, että testattavan järjestelmän vastaavuus projektin vaatimusmäärittelyyn varmistetaan. Testattavia kohteita on priorisoitu niiden tärkeyden mukaan. Testauksessa kerätään tietoa virheistä, ja jaetaan tätä tietoa eteenpäin mahdollisimman tehokkaasti. Tarkoitus on reagoida löydettyihin virheisiin, korjata niitä ja suorittaa regressiotestausta nopeassa tahdissa; niin että löydetyt virheet saadaan suurimmaksi osaksi korjattua jo saman toteutusvaiheen tai viimeistään seuraavan toteutusvaiheen aikana. Testausorganisaatio koostuu Kuopio-projektiryhmästä kokonaisuudessaan, kurssin mentorista sekä asiakkaasta. Käytännössä testausta suorittaa jokainen projektiryhmän jäsen. Kuopio on PK-yritysten toiminnanohjausjärjestelmän luontiin Innofactor Oy:n toimeksiannosta tähtäävä projekti. Se on Teknillisen korkeakoulun kurssin Tietojenkäsittelyopin Ohjelmatyö (T ) harjoitustyö. Testauksen kohteena on Kuopio-projektissa toteutettavat järjestelmän osat ja osien väliset integraatiot. Testattavat osakokonaisuudet ovat Henkilöt, Asiakkaat ja Projektit, näiden integraatio toisiinsa sekä olemassaoleviin osakokonaisuuksiin Kalenteri, Tuotteet, Dokumentit ja Talous. Osakokonaisuuksien tarkempi määrittely löytyy Kuopio-projektin projektisuunnitelmasta ja vaatimusmäärittelystä. Kuopio-projekti vaiheistetaan kurssin vaatimusten mukaisesti. Toteutusvaiheita on kolme, joista jokaisessa toteutetaan yksi osakokonaisuus. Jokainen osakokonaisuus testataan pääsääntöisesti siinä toteutusvaiheessa, jossa se toteutetaan. Mahdollisesti testaus jatkuu myös seuraavaan vaiheeseen, mikäli tulee ongelmia testaukseen käytössä olevan ajan suhteen tai löytyvien virheiden määrä ja/tai niiden korjaukseen kuluva aika on huomattavasti ennakoitua pidempi. Testauksen riskien hallintaa käsitellään tarkemmin luvussa 9. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 6
7 1.3 Testausympäristö lyhyesti 1.4 Termit Table 1 Termit Testausta varten ohjelmiston toteutuksen tietystä vaiheesta tehdään CVS:n avulla testauskopio, joka asetetaan erikseen määrättävään testauspalvelimeen Innofactorille. Vastaavasti järjestelmän käyttämästä tietokannasta tehdään erillinen testauskopio, joka asetetaan erikseen määrättävään Innofactorin SQL-palvelimeen. Testaus suoritetaan vain tietyllä käyttäjän selain- ja käyttöjärjestelmäkonfiguraatiolla. Termi Kuopio Moduuli Moduulitestaus Selitys Toteutettavan ohjelmistoprojektin nimi. Geneerinen järjestelmän osakomponentti. Yksittäisen moduulin testaus. Integrointitestaus Yhdistetään yhteen moduuleita tai moduuliryhmiä (osajärjestelmiä) ja testataan niiden välisten rajapintojen toimivuutta sekä yhteensopivuutta. Järjestelmätestaus Regressiotestaus Toiminnallinen vaatimus Testauksen kohteena on koko järjestelmä ja tuloksia verrataan vaatimusdokumentaatioon. Uudelleentestausta jota suoritetaan löydetyn virheen korjaamisen jälkeen. Varmistetaan, että virheen korjaus ei ole aiheuttanut virheitä jo kerran toimiviksi testattuihin järjestelmän osiin. Asiakkaan vaatimus siitä miten järjestelmän tulisi toimia. Ei ota kantaa siihen miten vaatimus teknisesti täytetään. Testausosuus Yleisnimitys yksittäisen moduulin moduulitestaukselle, integrointitestaukselle, järjestelmätestaukselle tai tietojen siirron testaukselle. Testitapaus Testiraportti Projektiryhmä Yksittäinen käyttäjälähtökohtainen tapaus, jonka testaaja suorittaa sovellukselle. Testitapaukset ja niiden suorittaminen muodostavat testausprosessin rungon. Testauksen tuloksena syntyvä määrämuotoinen dokumentti. Tarkoittaa projektin toteuttavaa ryhmää Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 7
8 Termi Asiakas Mentor Innofactor Oy SQL IIS Selitys opiskelijoita. Se henkilö tai taho, jolle projektiryhmä projektin loppuessa luovuttaa projektin lopputuotteen. Asiakkaalla voidaan viitata joko henkilöön (Tik kurssin rooli "asiakas") tai yleisesti asiakkaana toimivan yrityksen edustajaan. Kurssin puolesta projektille määrätty henkilö, joka valvoo projektin kulkua ja neuvoo matkalla tulevissa ongelmissa. Asiakkaan työllistävä yritys, jolle projekti tehdään. Structured Query Language. Tietokantajärjestelmien kyselykieli. Microsoft Internet Information Server, Internetpalvelinsovellus. CVS Concurrent Versioning System. Versionhallintaan käytettävä ilmainen ohjelmisto. Kehitysympäristö Palvelinkoneympäristö, jossa varsinainen ohjelmointi tapahtuu. Testausympäristö Burana Palvelinkoneympäristö, jossa testaus tapahtuu. Kurssin puolesta järjestetty virheiden ja niiden korjauksen raportointiin sekä koodin koon seurantaan tarkoitettu työkalu. Rational Coverage Koodikattavuuden tutkitaan tarkoitettu työkaluohjelmisto. Rational Robot Testitapausten automatisointiin tarkoitettu työkaluohjelmisto. Rational SiteCheck WWW-palveluiden testaukseen suunniteltu työkaluohjelmisto. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 8
9 1.5 Viitteet Tässä dokumentissa viitataan muihin Kuopio-projektin projektinhallinnallisiin dokumentteihin. Nämä dokumentit sijaitsevat Innofactorin tiedostopalvelimella hakemistossa InnoShare/2 Customer Process/CU145 Kuopio/. Dokumentteja, joihin viitataan, ovat projektisuunnitelma, vaatimusmäärittely, toiminnallinen määrittely, tekninen määrittely ja projektin laatukäsikirja. Dokumentissa viitataan myös testausraporttiin, joka on testauksen kuluessa syntyvä dokumentti, joka tulee sijaitsemaan samassa paikassa. 1.6 Yleiskatsaus dokumenttiin Johdanto Johdantokappaleessa luonnehditaan projektin testausta, sen suorittamista ja testausympäristöä. Johdannossa kerrotaan lyhyesti, miksi testausta tehdään, mitä testausprosessin keräämällä tiedolla tehdään ja miten siihen reagoidaan. Lisäksi esitellään sellainen dokumentin sisältämä terminologia, jonka ei voi välttämättä olettaa olevan tuttua lukijalle, ja annetaan yleiskatsaus tähän dokumenttiin Testausympäristö Kappaleessa kuvataan yksityiskohtaisesti ympäristö, jossa testaus suoritetaan. Kuvattavaan ympäristöön kuuluu sekä palvelin/palvelimet, joilla sovellusta ajetaan, sekä työasema, jolta sovellusta käytetään. Lisäksi kuvataan kaikki testauksessa käytetyt apuvälineet ja työkalut Henkilöstö- ja koulutusvaatimukset Vastuualueet Kappaleessa kerrotaan, mitä vaatimuksia järjestelmän testaaminen ja testaamisen tukitoimintojen suorittaminen aiheuttavat niihin osallistuville henkilöille ja heidän koulutukselleen. Kappaleessa kiinnitetään testaukseen osallistuvien henkilöiden vastuualueen testauksen eri vaiheissa. Periaattena on, että alustavaa testausta tekevät kaikki ohjelmoijat oman työnsä osalta, integraatiotestaukseen osallistuu koko projektiryhmä ja moduulitestaukseen allokoidaan pääsääntöisesti eri resursseja kuin vastaavan moduulin ohjelmointiin tarkempien määrittelyjen mukaisesti Tehtäväjärjestys ja testausmenettely Kappaleessa kuvataan, missä järjestyksessä testaus suoritetaan sekä testausta alustavat toimenpiteet kuten testauskonfiguraation luonti. Kappaleessa käsitellään myös yksityiskohtaisesti testitapausten ja ilmenevien virheiden luokittelu vakavuuden ja vaativuuden mukaan, sekä testitapausten numerointi. Lisäksi täydennetään näiden valossa kuvaa testauksessa käytettävistä menetelmistä ja työkaluista. Kappaleessa käsitellään myös testauksen kattavuutta. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 9
10 1.6.6 Regressiotestaus Kappaleessa kuvataan yksityiskohtaisesti projektissa käytettävän regressiotestauksen periaatteet ja toteutus Testitapaukset Tulosaineisto Kappale sisältää luettelon testitapauksista. Luettelo on yksityiskohtainen ja esittelee testitapaukset ja ennakoitavissa olevat virheet vakavuus- ja vaatimuusluokitusten valossa. Testitapauksen numeroidaan kappaleessa 5 esitettyjen periaatteiden mukaan. Tässä testaussuunnitelman versiossa testitapausluetteloa ei ole. Se laaditaan vaiheessa T2. Kappale kuvaa, millaista tulosaineistoa testauksesta halutaan. Tulosaineistoa on mm. testausraportti ja bugienhallintajärjestelmän sisältämä historiatieto toteutuksen virheiden tilasta Testauksen hyväksyminen Kappaleessa kuvataan kriteerit tilanteille, milloin testaus aloitetaan ja lopetetaan, hyväksytään, hylätään tai keskeytetään hyväksymättä tai hylkäämättä Riskien hallinta Kappale kertoo, millaisia riskiä projektissa liittyy nimenomaan testaukseen, miten niiden todennäköisyyttä ja vakavuutta on arvioitu. Lisäksi kuvataan, millaisia ennaltaehkäiseviä toimenpiteitä riskeihin liittyy, sekä millaisia suunnitelmia toteutuneiden riskitilanteiden varalle on. 2. TESTAUSYMPÄRISTÖ 2.1 Palvelin Testauspalvelimina toimii fyysisesti eri palvelimet kuin missä ohjelmiston kehitystyö tapahtuu. Palvelimet, joihin testausympäristö luodaan ja konfiguroidaan määrätään myöhemmin. Palvelimina käytetään Innofactorin palvelimia. Testauspalvelimilla pyörivät samat sovelluksen kannalta olennaiset palvelinohjelmistot kuin kehityspalvelimilla. Ohjelmistoina käytetään Microsoft Windows 2000 Advanced Server -käyttöjärjestelmää Microsoft Internet Information Server -www-palvelinohjelmistoa.netlisämoduleineen Microsoft SQL Enterprise -tietokantapalvelinohjelmistoa. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 10
11 2.2 Työasema Integraatiotestauksessa katetaan sekä konfiguraatiot joissa IIS ja SQL suoritetaan fyysisesti eri palvelinkoneilla että konfiguraatiot, joissa molempia ohjelmistoja pyörittää sama fyysinen palvelinkone. Palvelimien tarkempi laitteisto- ja ohjelmistokokoonpano selviää, kun päätetään mitä Innofactorin palvelimista testaukseen käytetään. Modulitestauksessa tyydytään käyttämään jompaakumpaa em. konfiguraatioista. Testaustyöasemana käytetään samaan lähiverkkoon testauspalvelimien kanssa liitettyä Microsoft Windows työasemaa. WWW-selaimena ensisijaisesti Microsoft Internet Explorer 5.5 -selainta, jolla ohjelmiston toimivuus ensisijaisesti varmistetaan. Lisäksi raportointityökalu Burana toimii selainen kautta. Muita tarvittavia ohjelmistoja ovat Microsoft SQL Server Enterprise Manager (alustavassa testauksessa) Rational Coverage (mahdollisesti vaiheesta T2 eteenpäin) Rational Robot (mahdollisesti vaiheesta T2 eteenpäin) Rational SiteCheck (mahdollisesti vaiheesta T2 eteenpäin) Testaustyökalujen käyttötarkoituksia ja -tapoja kuvataan tarkemmin luvussa Turvallisuusnäkökohtia Testauksen turvallisuudella ymmärretään sitä, että testaus toteutetaan siten, että se aiheuttaa mahdollisimman vähän häiriöitä yrityksen muulle toiminnalle sekä Kuopioprojektissa että muissa projekteissa. Tätä varten toteutetaan muutama lähinnä palvelinjärjestelyihin liittyvä toimenpide, jotka on kuvattu tässä luvussa. Kyseessä on hyvin tietokantaintensiivinen ohjelmisto, jonka kehitysvaiheessa on tarpeen tutkia ja muokata käsin kehitysversion tietokantaa. Tämä aiheuttaa tietokannan epäintegriteettiä, joka saattaa sotkea ohjelman toimintaa ilman, että varsinaisessa ohjelmassa on vikaa. Tästä taas voi aiheutua testitapauksia, joissa havaitaan virheellistä toimintaa em. syistä, jolloin testauksen tuottama tieto järjestelmän toimivuudesta vääristyy. Tilanne korjataan käyttämällä testauksessa erillistä testaustietokantaa, joka luodaan rakenteeltaan identtiseksi kehitysversion tietokannan kanssa. Microsoft IIS -www-palvelinohjelmisto voi myös aiheuttaa palvelinkoneiden jumiutumista etenkin, jos ajetaan tietyllä tavalla virheellistä ohjelmakoodia. Kokemus on osoittanut yhdeksi pahimmista tapauksista nk. ikuiset silmukat, joita saattaa esiintyä. Näissä tilanteissa kokemusten mukaan ikuisessa silmukassa oleva prosessi jää pyörimään palvelimelle pitkäksikin aikaa, mikä hidastaa palvelimen muuta toimintaa haitallisesti. Nämä haitat ehkäistään käyttämällä testauksessa www-palvelinta, jolla ei ajeta yrityksen toiminnan kannalta oleellisia palveluita. Varotoimenpiteistä huolimatta testauksen aikana ja sen takia voi esiintyä ongelmia etenkin palvelimien toiminnassa. Jotta kaikki voisi jatkua ongelmatilanteissa ja niiden jälkeen mahdollisimman häiriöittä, on testauksen ollessa käynnissä aina paikalla oltava Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 11
12 joku palvelinylläpidon työntekijä päivystämässä ongelmatilanteiden varalta. Mikäli saatavilla ei ole ylläpitäjää, täytyy testausta suorittävassa ryhmässä olla mukana henkilö, joka hallitsee palvelimien toiminnan korjaamisen ongelmatilanteissa. 2.4 Apuvälineet ja työkalut Bugiraportoinnin apuvälineenä projektissa käytetään Burana-raportointityökalua. Se löytyy www-osoitteesta ja sen käyttäminen vaatii www-selaimen, joka jokaisessa testaukseen käytetyssä työasemassa on jo itse ohjelmiston käytön puolesta. Buranassa jokainen raportti kuuluu tiettyyn kategoriaan (subsystem). Kategoriat luodaan järjestelmään ennen testauksen aloittamista testausvastaavan toimesta. Luotavat kategoriat Kuopio-projektin puitteissa ovat: Henkilöt osakokonaisuus Asiakkaat osakokonaisuus Projektit osakokonaisuus Mahdollisesti luodaan myös integrointitestauksen ja tietojen siirron testauksen raporteille oma kategoria. Tästä päätetään myöhemmin. Jokainen uusi testauksessa löydetty järjestelmävirhe aiheuttaa uuden raportin luomisen. Ohjelmoijan kirjoittama korjausmerkintä ja regressiotestauksen raportit ovat päivityksiä olemassaolevaan raporttiin. Raporteissa on alasvetovalikoilla täytettäviä tietoja sekä useita vapaita tekstikenttiä. Myöhemmin tässä dokumentissa (kappaleessa 5.5.) määritetään tarkasti, millaista tietoa kenttiin täytetään. Vaiheessa T2 tutkitaan mahdollisuutta soveltaa Rationalin testaustyökaluohjemistoja projektin tarpeisiin ja päätetään käyttää niitä, mikäli ne katsotaan soveltuviksi. Soveltuvuustutkimuksen tekee testausvastaava. Tutkittavat testaustyökalut ovat: Rational Coverage Rational Robot Rational SiteCheck 3. HENKILÖSTÖ- JA KOULUTUSVAATIMUKSET Kaikilla testaukseen osallistuvilla on tarvittavat pohjatiedot ohjelmistotuotannosta ja Kuopio-järjestelmästä. Jokainen testaukseen osallistuva tutustuu huolellisesti ennen testausta testaussuunnitelmaan ja käytettäviin työkaluihin, niiden käyttöohjeiden avulla omatoimisesti. Käytettävät käyttöohjeet ja muut testauksen esitiedot on kuvattu tarkemmin luvussa 5.1. Testausta alustavat toimenpiteet. Varsinaista koulutusta testaukseen henkilöstölle ei siis ole tarvetta järjestää. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 12
13 4. VASTUUALUEET 4.1 Testiryhmä Testiryhmä muodostuu koko Kuopio-projektin henkilöstöstä. Testausvastaavana on Matti Peltomäki, ja testausta suorittavat erikseen projektisuunnitelmassa ja kokouspöytäkirjoissa annettujen tehtäväjakojen mukaisesti nimetyt henkilöt. 4.2 Moduulitestaus Jokaisen moduulin ohjelmoi projektisuunnitelmassa määrättävä koko projektiryhmää pienempi ohjelmoijien joukko. Moduulitestaajien joukko määritellään erikseen jokaista modulia kohden siten, että ohjelmoijat ja testaajat ovat eri henkilöt. Testaajia kullekin moduulille voidaan määrätä yksi tai useita. 4.3 Integrointitestaus Integrointitestaukseen tullaan nimeämään integrointitestausryhmä, johon kuuluu ainakin testausvastaava. 5. TEHTÄVÄJÄRJESTYS JA TESTAUSMENETTELY 5.1 Testauksen luonteesta Testaus jaetaan kolmeen osaan: alustavaan testaukseen, modulitestaukseen ja integrointitestaukseen. Osiot toteutetaan valkolaatikkotestauksena. Tämä tarkoittaa sellaista testausta, jossa testitapaukset valitaan testattavan ohjelman toiminnallisten ja teknisten spesifikaatioiden sekä mahdollisesti lähdekoodin mukaan. Myös lähdekoodin kommentointia käytetään hyväksi. Alustavassa testauksessa tutkitaan lisäksi tietokannan sisältöä ennen ohjelmiston toimintoja ja niiden jälkeen. 5.2 Testausta alustavat toimenpiteet Ennen testausta jokainen testaukseen osallistuva päivittää tietonsa Kuopio-projektin testaamisesta ja käytettävistä työkaluista ja niiden käyttötarkoituksesta sekä käyttöohjeista. Jokainen testaaja lukee läpi ja ymmärtää testaussuunnitelman. Lisäksi jokainen tutustuu huolellisesti Burana-raportointityökalun käyttöohjeisiin ( /01-02/ohjeet/burana_user_guide.html). Buranan ohjeisiin tutustuminen on tärkeää. Ohjelmisto ei aseta henkilökohtaisiin käyttäjätunnuksiin perustuvia rajoituksia sille, mitä käyttäjä saa tai voi tehdä, eikä raporttien poisto ole mahdollista, ja kategorioiden poisto on mahdollista vain kun niihin ei kuulu yhtään raporttia. Ilman kurinalaista käyttöä Buranan tietosisällöstä voi tulla varsin sekavaa, mille on minimalistiset korjausmahdollisuudet. Kategoriat määrätään testaussuunnitelmassa ja ne luo testausvastaava. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 13
14 Mikäli Rationalin työkaluja päätetään käyttää, testaajat opiskelevat myös Rational Coveragen, Robotin ja SiteCheckin käyttöä tarvittavissa määrin ohjelmistojen käyttöohjeista. Ennen testausta luodaan myös testausympäristö. Sovelluksesta sijoitetaan testipalvelimelle testikopio, joka saadaan CVS-ohjelmiston avulla. Testattavaksi valmista sovellusversiota merkitään CVS-versionhallinnassa tietyllä laatukäsikirjan määrittämällä CVS-tagilla, jonka perusteella sovelluksen testikopioksi saadaan oikea versio. Tietokannan testikopio luodaan testipalvelimelle. Testikannasta tehdään rakenteeltaan samanlainen kuin kehitysversion kannasta teknisen määrittelyn mukaan. 5.3 Tehtäväjärjestys Moduulitasolla Jokainen ohjelmoija suorittaa alustavaa testausta jatkuvasti ohjelmoinnin yhteydessä. Alustavassa testauksessa on erittäin olennaista tarkastaa huolellisesti tietokannan integriteetin säilyminen eli tutkia tarkkaan, millaista tietoa tietokantaan tallentuu eri suoritusvaiheiden aikana. Epäloogisesti tai vastoin teknistä määrittelyä tallentuva tieto aiheuttaa myöhemmissä vaiheissa pahoja ongelmia, ellei tällaisia tapauksia löydetä kunkin toiminnon toteutuksen aikana. Alustavassa testauksessa ohjelmoija siis varmistaa tekemänsä koodin toimivuuden etenkin tietokannan osalta. Jokaisen toteutettavan moduulin kohdalla moduulitestaus suoritetaan samassa toteutusvaiheessa kuin moduulin toteutus. Moduulit testataan siis: Henkilöt-osakokonaisuus vaiheessa T2 Asiakkaat-osakokonaisuus vaiheessa T2 Projektit-osakokonaisuus vaiheessa T3 Testauksessa löytyneiden virheiden korjaus ja siihen liittyvä regressiotestaus voi kuitenkin siirtyä seuraavan toteutusvaiheen puolelle. Tähän on varauduttu projektin suunnittelussa. Lisäksi lievemmät virheluokat ovat sellaisia, että virheiden korjaus siirtyy seuraavaan vaiheeseen virheluokan määritelmän mukaan. Vaiheissa T3 ja LU suoritetaan lisäksi integraatiotestausta toteutettujen integraatioiden osalta. Sekä moduuli- että integraatiotestauksessa testitapausten keskinäinen järjestys (prioriteetteihin perustuva) löytyy testitapausluettelosta, luokitteluperusteet kerrotaan seuraavassa luvussa Testitapaustasolla Yksittäinen testitapaus suoritetaan seuraavan käytännön mukaisesti: testaaja lukee testitapauksen läpi ja ymmärtää sen testaaja alustaa skenaarion kuten testitapauksessa on määritetty testaaja suorittaa testitapauksen toistoineen Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 14
15 testaaja kirjoittaa testiraporttiin testitapauksen suoritetuksi ja sen tuloksen tässä dokumentissa määritetyn testiraporttiohjeen mukaisesti mikäli testitapaus päättyi virheeseen, testaaja luo uuden tai päivittää vanhaa Buranaraporttia tässä dokumentissa määriteltyjen Burana-raportointiohjeiden mukaisesti testaaja jatkaa seuraavaan testitapaukseen Mikäli tässä dokumentissa määritetyt testauksen keskeytyskriteerit täyttyvät, testaaja ottaa välittömästä yhteyttä ensisijaisesti testausvastaavaan ja testausvastaavan ollessa saavuttamattomissa projektipäällikköön. 5.4 Testitapausluokat ja testitapausten numerointi 5.5 Virheluokat Table 2 Virheluokat Testitapaukset luokitellaan prioriteettijärjestyksessä. Prioriteettejä on kolme: järjestelmän toiminnan kannalta kriittiset ominaisuudet, toiminnan kannalta tärkeät ominaisuudet ja muut ominaisuudet. Testitapausluettelossa jokainen testauslaji (modulitestaus moduleittain, integrointitestaus) on esitetty omana lukunaan, ja jokaisen luvun sisällä testitapaukset numeroidaan ensisijaisesti prioriteetin mukaan. Esimerkiksi Henkilöt-osakokonaisuuden testitapausluettelossa voi olla testitapaukset (kriittisen ominaisuuden prioriteetti), (tärkeän ominaisuuden prioriteetti) ja (matalin prioriteetti). Mikäli kesken testauksen ilmenee tarvetta uusien testitapausten luomiselle, voidaan uusi testitapaus numeroida kahdella eri tavalla. Mikäli uusi tapaus on selkeästi korjaus tai lisäys jo olemassaolevaan tapaukseen (esim. 1.23), nimetään se tapaukseksi 1.23b. Mikäli uusi tapaus on olennaisesti uusi, lisätään se omaan osioonsa prioriteettinsä mukaiselle paikalle seuraavalle vapaalle numerolle. Esimerkiksi jos viimeinen kriittisen ominaisuuden prioriteetillä merkitty testitapaus on ja uusi tapaus on samaa prioriteettiä, tulee numeroksi Testauksessa havaitut ohjelmiston virheet luokitellaan lähinnä niiden vakavuuden mukaan. Toissijainen luokitteluperuste on se, kuinka nopeasti virhe on saatava korjattua. Nämä vastaavat Buranan raporttilomakkeen alasvetovalikoita Severity ja Internal Priority. Virheluokat, niiden kuvaukset ja vastaavat merkinnät Buranan raporttilomakkeessa on esitetty seuraavassa taulukossa. Virheluokka Kuvaus Esimerkki Severity Internal Priority Kriittinen Estää näkymän toimintojen käytön kokonaan Vakava Estää tietyn toiminnon Sisäänkirjautumine n ei toimi Uuden työntekijän tiedot eivät tallennu Critical Serious Urgent Tilanteesta riippuen Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 15
16 Virheluokka Kuvaus Esimerkki Severity Internal Priority käytön tai tietokantaan Urgent tai toiminto toimii High virheellisesti haitaten oleellisesti ohjelmiston käyttöä Normaali Mikä tahansa muu kuin kriittinen, vakava tai lievä virhe Tyhjäksi jätetty päivämääräkenttä aiheuttaa ajonaikaisen virheen tallennettaessa Normal Lievä Kirjoitusvirhe Presons Minor Low Tilanteesta riippuen High, Before Release tai Semilow Oikeat Severity ja Internal Priority -määreet Burana-raporteissa ovat olennaisia toimivalle testaus-korjaus-prosessille, koska ne toimivat raporttihakujen hakukriteereinä ja järjestelyperusteina Buranassa. Testitapausluettelossa (luku 7) kerrotaan testitapauskohtaisesti mihin virheluokkaan arvattavissa olevat mahdolliset virheet kuuluvat. Lisäksi siinä tarkennetaan testitapauskohtaisesti Internal Priority -määreen käyttöä. 5.6 Menetelmät ja tekniikat Testausta varten testaaja luo itselleen tarvittavan määrän erilaisia käyttäjätunnuksia Microsoft SQL Server Enterprise Manager -ohjelman avulla. Tunnusten määrä riippuu olennaisesti läpikäytävistä testitapauksista. Etenkin modulitestauksessa voi olla myös, että testaukseen ei tarvita käyttäjätunnuksia. Yksityiskohdat tunnusten luomiseen ovat teknisen suunnitelman tietokantaa käyttävässä osuudessa. Testitapaukset käydään läpi huolellisesti yksi kerrallaan. Toistoja tehdään testitapausluettelon määrittämä määrä ja niissä käytetään mahdollisesti apuna Rational Robot -testaustyökalua. Jossain testitapauksissa määritetään myös yksityiskohtainen testauspolku. Jokaisen testitapauksen läpikäymisen jälkeen kirjoitetaan testiraporttia kyseiseen tapaukseen liittyviltä osin. Mikäli testitapaus aiheutti virheen, kirjoitetaan siitä raportti Buranaan. Raportin kirjoittamisessa on otettava huomioon testaus- ja toteutusvaihe. Mikäli kyseessä on ensimmäinen havainto kyseisestä virheestä, luodaan uusi raportti. Mikäli kyseinen virhe on jo raportoitu, päivitetään olemassaolevaa raporttia. Raportin päivitys tulee kyseeseen etenkin regressiotestauksessa, ja voi olla varsin minimaalinen, mikäli havaitusta virheestä ei saatu olennaista uutta tietoa olemassaolevan lisäksi. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 16
17 5.7 Kattavuus Burana-raportin sisältö ja muoto ovat olennaisia tekijöitä, joihin kiinnitetään huomiota. Päivittäjän ja raportin luojan henkilöllisyys on ehdottomasti talletettava oikein. Olennaista on liittää raporttiin kaikki tarpeellinen virheeseen liittyvä tieto. Nyrkkisääntönä voidaan pitää, että tieto, jonka tarpeellisuudesta testaaja ei ole varma, sisällytetään raporttiin. Raportin tiedot kirjoitetaan niin yksityiskohtaisesti, että korjauksesta vastaava ohjelmoija pystyy toistamaan virhetilanteen niiden avulla. Koodikatselmoinnit pidetään moduleittain ennen modulitestausta laatukäsikirjan mukaisesti. Kattavuutta säädellään testitapausten luonnin kriteereillä. Tässä testauksessa pyritään mahdollisimman suureen kattavuuteen laadun varmistamiseksi. Toistokerrat säädetään testitapauskohtaisesti ottaen huomioon vakavuusaste. Toistojen määrä pidetään kuitenkin järkevänä käytössä olevat resurssit huomioiden. Erityinen huomio asetetaan dynaamisten tietorakenteiden testaukselle. Dynaamisia tietorakenteita koskevissa testitapauksissa määritetään useita toistokertoja hieman toisistaan poikkeavalla testidatalla, pyrkien samalla mahdollisimman suureen koodikattavuuteen. Tässä käytetään testitapaussuunnittelun apuvälineenä toiminnallisen määrittelyn lisäksi teknistä määrittelyä. Myös raja-arvojen testaukseen kiinnitetään erityistä huomioita testitapausten laadinnassa. Raja-arvolla ymmärretään tilannetta, jossa vapaassa tekstikentässä sallittuina syötteinä ovat numerot Tällöin raja-arvosyötteitä, joilla toimintaa testataan ovat 0,1,100 ja REGRESSIOTESTAUS Regressiotestauksen tavoite on varmistua, että aiemmin raportoidut virheet ovat todella korjaantuneet siinä versiossa, jossa ne on määritelty korjatuiksi ja että korjaus ei ole tuottanut uusia virheitä. Tässä projektissa regressiotestausta tehdään aina, kun sovelluksesta on tuotettu uusi korjattu versio. Versioinnin määrittää projektin laatukäsikirja. Regressiotestauksessa testataan edellisessä versiossa virheelliseksi raportoitu testitapaus uudestaan siten, että sen esivaatimuksina olevat testitapaukset tulevat läpikäydyksi rekursiivisesti aina sellaisiin testitapauksiin asti, joilla ei ole esivaatimuksia. Jokaiselle testitapaukselle määritetään yksikäsitteiset esivaatimukset testitapausluettelossa (tämän dokumentin luku 7). Vaiheessa T2 tutkitaan mahdollisuutta käyttää testauksessa apuna testausta automatisoivia työkaluja. Testaus on tärkeää automatisoida niin pitkälle kuin mahdollista, jotta projektiin kiinnitetyillä resursseilla pystytään myös toteuttamaan regressiotestaus mahdollisimman pitkälle. Lisäksi mahdollisissa tulevissa ei Kuopioprojektin puitteissa toteutettavissa versioissa voidaan haluta varmistua sovelluksen toiminnasta useissa eri selaimissa ja käyttöjärjestelmissä. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 17
18 Testaus pyritään toteuttamaan siten, että kaikki regressiotestauskierrokset jokaisen modulin osalta on ajettu loppuun ts. mikään määritelty testitapaus ei aiheuta virhettä regressiotestatessa ennen integrointitestauksen aloittamista, ettei integrointitestaus havaitse virheiksi yhden modulin virheitä, mikä aiheuttaisi turhaa resursseja kuluttavaa lisätyötä projektin loppuvaiheessa. 7. TESTITAPAUKSET Testitapaukset luodaan ja kirjataan myöhemmin, kun toiminnallinen ja tekninen määrittely ovat siinä määrin valmistuneita, että niiden pohjalta on mielekästä laatia testitapauksia. Tämä tehdään projektisuunnitelman mukaan vaiheessa T Moduulitestaus Henkilöt-osakokonaisuus Asiakkaat-osakokonaisuus Projektit-osakokonaisuus 7.2 Integrointitestaus 7.3 Tietojen siirron testaus 8. TULOSAINEISTO Burana-raporttien lisäksi testauksen tulosaineisto kerätään testausraportteihin, joihin pyritään saamaan tarkka kronologinen kuvaus testauksen tuloksista. Jokaisen testausosuuden (modulitestaus moduleittain, integrointitestaus, tietojen siirron testaus) tuloksista kirjoitetaan erillinen testausraportti. Testausraportin kirjoittavat testauksen suorittavat henkilöt. Testausraportti sisältää seuraavat yleiset tiedot: testiympäristö testausosuus Lisäksi jokaisesta suoritetusta testitapauksesta kirjataan jokaista testauskierrosta kohden erikseen seuraavat tiedot: testitapauksen numero testaajan nimi toteutusvaihe (PS,T1,...) päivämäärä testattu versio tulos (hyväksytty/hylätty) mahdollisen kirjoitetun Burana-raportin raporttinumero Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 18
19 Testitapauskohtaiset tiedot kirjoitetaan testiraporttiin testitapausten suoritusjärjestyksessä kronologisesti. Raporttia kirjoitetaan jokaisen suoritetun testitapauksen jälkeen, jotta jatkuvasti on olemassa dokumentaatiota siitä, mitkä testitapaukset on suoritettu. Testausraportin rakenne on esitetty testausraporttimallineessa, joka löytyy Innofactorin tiedostopalvelimelta hakemistosta InnoShare/2 Customer Process/CU145 Kuopio/. Testausraportin valmistuttua testausvastaava viimeistelee testausraportin. Tämä tarkoittaa lukujen Johdanto, Kattavuus ja Yhteenveto tarkoituksenmukaista kirjoittamista. Testitapauskohtaiset tiedot menevät vain pieneltä osin päällekkäin Burana-raportin sisältämien tietojen kanssa. Molempiin on syytä kirjata testitapauksen numero ja testauksen kohteena ollut versio, jotta kyseiset tiedot ovat tarvittaessa mahdollisimman helposti saatavilla. Hyväksytystä ja hylätystä testitapauksesta testausraporttiin kirjatut tiedot eroavat vain siten, että hyväksytystä testitapauksesta kirjata Burana-raportin numeroa. Tarkempi kuvaus mahdollisesta virheestä on aina Burana-raportissa eikä sitä sisällytetä testausraporttiin. 9. TESTAUKSEN HYVÄKSYMINEN 9.1 Aloituskriteerit Modulitestaus voidaan aloittaa jokaisen modulin kohdalta silloin, kun modulista on valmistunut ensimmäinen versio, jonka ohjelmoijat ilmoittavat alustavasti testanneensa. Integrointitestaus voidaan aloittaa kun kaikki modulitestaukset ovat valmistuneet tai keskeytetty siten, että on päätetty jatkaa integrointitestaukseen. Tietojen siirron onnistumisen testaus voidaan aloittaa, kun integrointitestaus on saatu päätökseen ja siirto on toteutettu. 9.2 Lopetuskriteerit Yksittäisen moduulin testaus lopetetaan, kun sen testaus on saatu hyväksyttävästi loppuun tai moduulitestaus on päätetty keskeyttää. Integrointitestaus lopetetaan, kun se on saatu hysäksyttävästi loppuun tai se on päätetty keskeyttää. Tietojen siirron testaus lopetetaan kun se hyväksytään tai keskeytetään. 9.3 Hyväksymiskriteerit Yksittäisen moduulin testaus katsotaan hyväksytyksi, kun uusimpaan versioon, jossa kaikki raportoidut virheet on saatu korjatuksi, on suoritettu testaussuunnitelman mukainen regressiotestaus, joka on todennut raportoidut virheet korjatuksi, eikä löydä uusia. Testaus voidaan myös hyväksyä, kun uusin regressiotestauskierros on löytänyt vain vähäisiä virheitä. Tällaisen päätöksen voi tehdä projektipäällikkö. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 19
20 Integrointitestauksen hyväksymiskriteerit ovat samat kuin yksittäisellä modulilla. Tietojen siirron testaus luokitellaan hyväksytyksi, kun siirrolle määritellyt testitapaukset on suoritettu hyväksytysti. 9.4 Hylkäämiskriteerit Yksittäinen testausosuus hylätään, kun tietyn vakavuusluokan virheitä on esiintynyt yli sallitun määrän. Kun testaus hylätään, kaikki virheet raportoidaan sekä Buranaan että testiraporttiin. Testiraporttiin tehdään merkintä testauksen hylkäämisestä. Testaus aloitetaan uudestaan, kun sovelluksesta on luotu uusi versio, jossa raportoidut virheet on korjattu. Eri virheluokkien sallitut määrät on esitetty seuraavassa taulukossa jokaiselle testitapausluokalle erikseen. 9.5 Keskeyttämiskriteerit Jos toiminnan kannalta kriittisissä ominaisuuksissa esiintyy kriittisiä virheitä, keskeytetään testauksen kohteena olevan version testaus välittömästi ja testausta jatketaan vasta, kun kriittinen virhe on saatu korjatuksi ja sovelluksesta on luotu uusi versio. Tällöin testaus aloitetaan kyseisen testausosuuden alusta uudestaan. Table 3 Keskeyttämiskriteerit Kriittinen ominaisuus Tärkeä ominaisuus Kriittinen Vakava Normaali Muu ominaisuus Lievä 3 rajoittamaton rajoittamaton 10. RISKIEN HALLINTA Testauksen määrä on aina kompromissi käytettävissä olevien resurssien (aika, raha, välineet, ym.) ja luotettavuudesta saadun varmuuden välillä. Muun muassa resurssien vähyyden selkeä mahdollisuus aiheuttaa huomattavia riskejä. Seuraavassa taulukossa on esitetty nimenomaan Kuopio-projektin testaamiseen liittyvät tärkeimmät riskit, niiden vaikutukset sekä ennaltaehkäisy ja vaikutusten pienentäminen: Table 4 Testauksen riskit Numero Riski Vaikutus Ennaltaehkäisy ja vaikutusten pienentäminen 1 Testausprojektia ei saada riittävän pitkälle projektin puitteissa ja Innofactor joutuu Ohjelmiston valmistumisaikataulu n ylittyminen. Testaus suunnitellaan tarpeeksi hyvin, että toteutunut testauksen määrä ja laatu saadaan maksimoiduksi Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 20
21 Numero Riski Vaikutus Ennaltaehkäisy ja vaikutusten pienentäminen käyttämään arvioitua selkeästi enemmän rahaa ja resursseja testauksen saamiseksi loppuu, mikä on edellytys halutun luotettavuustason varmistamiselle. 2 Testauksessa löydettävien virheiden korjaamiseen tarvittava aika ylittää selkeästi kurssin aikataulun. 3 Projektiryhmän motivaatio suuntautuu luvattoman vähän testaukseen, koska projektissa on mielenkiintoisempiaki n osa-alueita. Projektille varatut resurssit eivät riitä projektin testauksen läpiviemiseen tyydyttävällä tasolla. Aikataulu Asiakas tyytymätön. pettää. on Testausta ei suoriteta huolellisesti tai testaussuunnitelman mukaan. Aikataulu lipsuu. Testauksen tuottama tieto on ainakin osittain hyödytöntä tai ei tarpeeksi yksityiskohtaista. käytettävissä olevilla resursseilla. Käytännössä ja etenkin jos riski toteutuu, testaus tulee keskittymään vain kaikista olennaisimpiin asioihin ja oikeassa suhteessa projektin kokonaislaatutavoitteisii n. Testaussuunnitelmassa tehdään ohjelmiston ominaisuuksille selkeä priorisointijärjestys, jolla varmistetaan tärkeimpien ominaisuuksien valmiiksi saattaminen ensin. Näin siis olemassa olevat resurssit kohdennetaan priorisoidusti tärkeinä pidettyihin tavoitteeseen. Testaukseen ei välttämättä tarvitse osallistua koko projektiryhmän. Vastuujako ja tehtäväjako on jo tehty ja pyritään jatkossakin tekemään yksittäisten projektiryhmän jäsenten mielenkiinnon ja toivomusten mukaan. Testaustehtäviin asetetaan päällekkäisyyksiä; kukaan ei toimi yksin. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 21
22 11. AIKATAULU JA TYÖMÄÄRÄT Testauksen aikataulu ja sen vaatima työmäärä on esitetty yksityiskohtaisesti projektisuunnitelmassa. Kuopio2001, vain kurssin T arvostelun vaatimaan käyttöön Sivu 22
Kuopio 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ä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ä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ätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria
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ä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ätiedotTestaussuunnitelma Versio Päiväys Tekijä Kuvaus
Testaussuunnitelma Versio Päiväys Tekijä Kuvaus 0.1 15.11.01 Ville Vaittinen Ensimmäinen luonnos 0.2 10.12.01 Ville Vaittinen Kevyet päivitykset kommenttien perusteella Sisällysluettelo 1. Johdanto...3
LisätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 22. maaliskuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 22.03.2002 Jani Myyry Versiohistoria
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ä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ä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ätiedotTESTAUSSUUNNITELMA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)
TESTAUSSUUNNITELMA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2) 2 1. JOHDANTO 5 1.1. Tarkoitus ja kattavuus 5 1.2. Tuote 5 1.3. Määritelmät, termit ja lyhenteet 5 1.4. Viitteet 5 2. YMPÄRISTÖVAATIMUKSET
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ä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ä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ä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ä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ätiedotTestaussuunnitelma Luuppi-projekti http://code.google.com/p/luuppi/
Testaussuunnitelma Luuppi-projekti http://code.google.com/p/luuppi/ versio 1.0 Projektiryhmä: Panu Tunttunen Petri Ikävalko Mikko Kuivanen Johannes Lampela Eero Jaakonaho Kari Jussila Saila Oldén Päiväys
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ä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ätiedotKuopio. Testitapausluettelo: Projektit-osakokonaisuus
Kuopio Testitapausluettelo: Projektit-osakokonaisuus Kuopio, testitapausluettelo, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 19.3.2002 Matti Peltomäki Kriittisen prioriteetin testitapaukset
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ätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTAUSSUUNNITELMA LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 2.1 Tila: hyväksytty Päivämäärä: 12.12.2000
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ätiedotOhjelmiston testaussuunnitelma
Ohjelmiston testaussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä lukaa antaa yleiskuvan koko testausdokumentista.
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ä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ä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ätiedotOhjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu
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ätiedotTESTAUSSUUNNITELMA Virtuaaliyhteisöjen muodostaminen Versio 1.1
TESTAUSSUUNNITELMA Virtuaaliyhteisöjen muodostaminen Versio 1.1 2 DOKUMENTIN VERSIOT 4 Jakelu 4 1. JOHDANTO 5 1.1. Tarkoitus ja kattavuus 5 1.2. Tuote 5 1.3. Määritelmät, termit ja lyhenteet 5 1.4. Viitteet
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ätiedotOhjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
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ä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ätiedotPS-vaiheen edistymisraportti Kuopio
PS-vaiheen edistymisraportti Kuopio Kuopio, PS-vaiheen edistymisraportti, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 30.10.2001 Ossi Jokinen Kuopio2001, vain kurssin T-76.115 arvostelun
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ä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. 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ätiedotTestaussuunnitelma. Polku http://code.google.com/p/polku-projekti/ versio 1.0. Projektiryhmä. Janne Pihlajaniemi. Antti Jämsén.
Testaussuunnitelma Polku http://code.google.com/p/polku-projekti/ versio 1.0 Projektiryhmä Janne Pihlajaniemi Antti Jämsén Maria Hartikainen Pekka Kallioniemi Jorma Laajamäki Panu Tunttunen Nina Tyni Joonas
LisätiedotKuopio. Testitapausluettelo: Henkilöt-osakokonaisuus
Kuopio Testitapausluettelo: Henkilöt-osakokonaisuus Kuopio, testitapausluettelo, 3.1.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 3.1.2002 Matti Peltomäki Ensimmäinen versio. 0.2 Matti Peltomäki
LisätiedotMäärittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli
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ätiedotCoMa - Testausdokumentti
CoMa - Testausdokumentti Mindmap - Kari Velling Helsinki 16.12.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä
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ä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ä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ä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ä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ä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ätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite
LisätiedotVerkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008
Verkkopokerijärjestelmä Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008 Projektiryhmä Samuli Aalto-Setälä Jukka Kekälainen Jarno Kyykkä Mika Mielonen Mårten Smeds Otto Waltari Ohjaaja
LisätiedotLohtu-projekti. Testiraportti. Versiohistoria: syklin toteutuksen testit. 1. ajo Virve
Lohtu-projekti Testiraportti Versiohistoria: 1.0 6.5.2003 2. syklin toteutuksen testit. 1. ajo Virve Helsinki 6. toukokuuta 2003 Kimmo Airamaa, Andreas Asuja, Mari Muuronen, Seppo Pastila, Virve Taivaljärvi
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ätiedotWCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma
TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/~jekahkon/wclique/testplan.pdf WCLIQUE Ohjelmistoprojekti WCLIQUE_TP Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com
LisätiedotMenetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
LisätiedotTestiraportti - Koordinaattieditori
Testiraportti - Koordinaattieditori Versio Päiväys Tekijä Kuvaus 3.1 22.03.02 Ville Vaittinen T3 vaiheen 1. testattava editori Sisällysluettelo 1. Testien suoritus... 3 2. Testitapaukset... 4 2.1 Uuden
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ä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ä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ätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
LisätiedotFuturaPlan. Järjestelmävaatimukset
FuturaPlan Järjestelmävaatimukset 25.1.2017 2.2 Hermiankatu 8 D tel. +358 3 359 9600 VAT FI05997751 33720 Tampere fax. +358 3 359 9660 www.dbmanager.fi i Versiot Versio Päivämäärä Tekijä Kommentit 1.0
LisätiedotTik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu VIRHERAPORTOINTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 12.12.2000
LisätiedotLiite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu
Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu
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ä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ä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ä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ätiedotUutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3
Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2
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ä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ä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ätiedotTik Projektiryhmä: TeamAhma. Projektin HAYABUSA opponointi. Opponointisuunnitelma
TeamAhma Projektin HAYABUSA opponointi Opponointisuunnitelma Päivitetty 25.3.2001 klo 12:08 Projektin HAYABUSA opponointi Mikko Viljainen 2 (5) Sisällys 1. JOHDANTO...3 2. YMPÄRISTÖ...3 3. HENKILÖSTÖ...4
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ätiedotTIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21201 Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 20.9.2016 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
LisätiedotProjektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma
Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 2(6) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja (projektisuunnitelman
LisätiedotToteutusvaihe T2 Edistymisraportti
Toteutusvaihe T2 Edistymisraportti Sisällysluettelo 1. Projektin tila...3 1.1. Suoritetut tehtävät...4 1.2. Käytetyt menetelmät...5 1.3. Ongelmat...6 1.4. Jatkosuunnitelmat...6 Versio- ja muutoshistoria
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ä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ätiedotTOIMINNALLINEN MÄÄRITTELY MS
TOIMINNALLINEN MÄÄRITTELY 11.11.2015 MS YLEISTÄ 1/2 jäsennelty etenee yleiskuvauksesta yksityiskohtiin kieliasultaan selkeä kuvaa myös tulevan järjestelmän ympäristöä tarpeellisella tarkkuudella kuvaa
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ätiedotTik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTITAPAUKSET LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 2.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
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ätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
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ätiedotAineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille
TraFin ulkoinen integraatio Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille Ohje 26.2.2014 Versio 1.1, Hyväksytty Luottamuksellinen Vastuutaho Trafi MUUTOSHISTORIA Versio Päiväys
Lisätiedot@Tampereen Testauspäivät (2012-06)
@Tampereen Testauspäivät (2012-06) Testausodotukset räätälöityjen järjestelmien projekteissa Maaret Pyhäjärvi, testausasiantuntija Twitter: maaretp Testausvastaava @ Granlund Oy Yrittäjä
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ätiedotTestaussuunnitelma. Ohjelmistotuotantoprojekti XPerf. Helsingin yliopisto. Tietojenkäsittelytieteen laitos
Helsingin yliopisto Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti XPerf Testaussuunnitelma Tommi Koivula Antti Levomäki Juha Mondolin Timo Suomela Versio 1.0 28. maaliskuuta 2003 Versiohistoria
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ä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ätiedotVisma Software Oy
pidättää itsellään oikeuden mahdollisiin parannuksiin ja/tai muutoksiin tässä oppaassa ja/tai ohjelmassa ilman eri ilmoitusta. Oppaan ja siihen liittyvän muun materiaalin kopiointi on kielletty ilman :n
LisätiedotOhjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA
Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta
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ätiedotTestausdokumentti. Sivu: 1 / 10. Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto. Versiohistoria
Sivu: 1 / 10 Testausdokumentti Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto Versiohistoria Versio Päivitykset 0.4 Lisätty mod_form.php -tiedostoon liittyvät testit 0.5 Lisätty johdanto 1.0 Dokumentti
LisätiedotSoft QA. Vaatimusten muutostenhallinta. Ongelma
Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei
Lisätiedot