LAATUDOKUMENTTI
|
|
- Pirjo Hovinen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 LAATUDOKUMENTTI
2 LAATUDOKUMENTTI 2 (15) VERSION HALLINTA Versio Päivä Tekijä Kuvaus Kaarlo Lahtela Ensimmäinen versio Kaarlo Lahtela Lauri Kiiski Kaarlo Lahtela runko Kaarlo Lahtela Projektitason suunnitelmaa Aleksi Airola Dokumentin katselmointi Kaarlo Lahtela Dokumentointikäytäntöjä Lauri Kiiski Iteraatio 1 tason suunnitelmia Lauri Kiiski SEPA:ien tekstit lisätty. 0.9 Lauri Kiiski I1 Aikataulu ja henkilöresurssit 0.10 Aleksi Airola Katselmointi 1.0; I1 palautus Kaarlo Lahtela Viimeistely
3 LAATUDOKUMENTTI 3 (15) SISÄLLYS 1. JOHDANTO PROJEKTI TASON SUUNNITELMA Laatutavoitteet Laatupaletti Toimintatavat Testaamisen laajuus Testitasot Testi tyypit Laadunvarmistusmenetelmät Laatuparametrit Laatumittarit Refaktorointi Testityngät Laadunvarmistuskäytännöt Jatkuva integrointi Pariohjelmointi Staattiset menetelmät Henkilövastuut Testitapauksien dokumentointi Testien kirjaaminen Virheiden seuranta ja reagointi Laitteisto- ja ohjelmistoresurssit Standardit Tuotokset Testien keskeytys- ja jatkamisehdot Testauksen lopetuskriteerit ITERAATIOTASON SUUNNITELMAT Ensimmäinen iteraatio Testattavat toiminnot Ei-testattavat toiminnot Laadunvarmistuskäytäntöjen käyttäminen Testi ympäristö ja testidata Aikataulu ja henkilöresurssit Testikierrokset Toinen iteraatio Testattavat toiminnot Ei-testattavat toiminnot Laadunvarmistuskäytäntöjen käyttäminen Laitteisto- ja ohjelmistoresurssit...15
4 LAATUDOKUMENTTI 4 (15) 1. JOHDANTO Tässä dokumentissa kuvataan projektin laatuun liittyviä käytäntöjä Dentegovälityspalvelimen toteutuksessa. Järjestelmän toteuttaa Dentego-ryhmä, Teknillisen korkeakoulun T kurssilla vuosina Laatudokumenttia pidetään yllä kurssin aikana, siten miten se vaatii, aina kurssin loppuun asti. Projektin tavoitteet on kerrottu projektisuunnitelmassa 1 ja vaatimukset on kirjattu vaatimusmäärittelyssä 2. Alussa käsittelemme projektintason asioita ja lopussa on iteraatiotason asioita. 1 Projektisuunnitelma: 2 Vaatimusmäärittely:
5 LAATUDOKUMENTTI 5 (15) 2. PROJEKTI TASON SUUNNITELMA 2.1. Laatutavoitteet Tärkeimmät asiakkaan laatutavoitteet kehitettävästä järjestelmästä ovat: Laatupaletti Menetelmät Tavoitteet Järjestelmä on tietoturvallinen Turvallisuus otetaan huomioon jo suunnittelussa. Käytetään valmiita tekniikoita, jotka ovat olleet yleisesti käytössä ja testattuna. Tiedon pitää olla siis turvallista, eheää ja sen pitää olla saatavissa. Järjestelmä on vikasietoinen Järjestelmän on pysyttävä toiminnassa pitkiä aikoja, eikä sitä saa lamauttaa virheellisillä viesteillä. Järjestelmän on oltava luotettava, eikä se saa menettää tietoa. Järjestelmä on jatkokehitettävä Jatkokehitettävyys on yksi tärkeistä laatutavoitteista. Tarkoituksena on lisätä ominaisuuksia järjestelmään jatkossa, jotta yhteistyökumppanien kanssa siirrettävät tiedot voidaan siirtää tietoverkkoon. Projektissa pyritään Good Enough Quality 3 :yn. Tällä tarkoitetaan, että projektista on riittävästi hyötyä, eikä siinä ole kriittisiä ongelmia. Tehtävän hyöty pitää olla suurempi, kuin sen tuottama vaiva. Ja kehitys lopetetaan, kun kaikki asiat huomioon ottaen jatkokehitys olisi enemmän haitaksi kuin hyödyksi. Taulu 1 Laatupaletti Järjestelmä on tietoturvallinen Järjestelmä on vikasietoinen Järjestelmä on jatkokehitettävä Riskit Vähäinen Java kokemus Käytössä on uusia tekniikoita JUnit testit Proto Katselmointi Rasitustesti Staattiset analyysit EP & BVA (ks ) Pariohjelmointi Jatkuva integrointi Pitkä testiajo Refactorointi 3 Good Enough Quality, Defined by James Bach; IEEE Computer, 1997, vol. 30, no. 8, pp
6 LAATUDOKUMENTTI 6 (15) 2.2. Toimintatavat Seuraavassa on kuvattu laadunvarmistamisessa käytettyjä toimintatapoja, joilla varmistetaan tuotteen laatu Testaamisen laajuus Kaikki tuotettu koodi testataan. Koodilla ja testeillä on prioriteettitasoja, joilla saadaan painotettua tärkeämpien elementtien laatua Testitasot Testi tyypit Testausta tehdään neljällä eri tasolla. Kehittäjät käyttävät JUnit testejä yksikkötestaukseen. Tällä saavutetaan aikainen bugien havainnointi, joten ongelmat on helppo korjata jo aikaisessa vaiheessa kehitystä. Yksikkötestit ovat tehokkaita, toistettavia, ylläpidettäviä ja kustannustehokkaita. Yksikkötestiä tehdään suurimmalle osalle koodia. Osassa koodia käytetään myös laadunvarmistusmenetelmänä: Test Driven Development (TTD), jossa yksikkötestit tehdään ennen varsinaisen koodin tekemistä. Integraatiotestausta tehdään kehittäjien toimesta. Tällä saavutetaan, että komponentit toimivat keskenään. Integraatiotestauksella saadaan varmistettua, että arkkitehtuuri on toteutettu oikein kaikissa komponenteissa. Systeemitestaus tehdään testaustiimin puolesta. Testauksella saavutetaan, että järjestelmä vastaa toiminnallisia vaatimuksia. Hyväksymistestauksella testataan, että järjestelmä toteuttaa asiakkaan vaatimukset. Kriteerit määritellään asiakkaan kanssa myöhemmin ensimmäisessä iteraatiossa. Kehityksessä käytämme useaa testityyppiä, joilla varmistetaan tuotteen laatu usealla eri osa-alueella. Funktionaalinen testaus, jolla varmistetaan, että tuote vastaa vaatimusmäärittelyn mukaisia toiminnallisia ominaisuuksia. Funktionaalinen testaus aloitetaan jo ohjelmoinnin alkuvaiheista asti. Tehokkuustestaus toteutetaan kokonaisuudessaan toisessa iteraatiossa. Tehokkuustesteissä testataan, että välityspalvelimemme pystyy käsittelemään vaatimuksien mukaisen määrän tietoliikennettä. Rasitustestillä testataan, miten järjestelmä käyttäytyy suurissa tietoliikenteen määrissä. Pitkät testiajot testaavat, että järjestelmä on vikasietoinen. Järjestelmää ei päivitetä, ja sitä pidetään pitkä aika yllä rasituksessa, ja samalla seurataan, ettei synny virheitä. Yhteensopivuustestaus jää vähäiseksi. Ohjelmisto testataan parin eri tietokannan kanssa. Itse webservices alustaa ei testata eri ympäristöissä, vaan alusta toimii kolmansien osapuolien määrittelemien laitteistojen päällä, johon emme vaikuta.
7 LAATUDOKUMENTTI 7 (15) Heuristisia arvioita tehdään minimaalisesti ylläpitotyökaluun. Tällä selvitetään pahimpia käytettävyysongelmia. Painotus on kuitenkin välityspalvelimen toiminnassa. Katselmointi on menetelmä, jossa tutkitaan lähdekoodia. Tällä parannetaan tuotteen laatua ja varsinkin kokemattomimpien Java-ohjelmoijien koodista saadaan perus suunnitteluvirheitä karsittua. Näin uudet ohjelmoijat myös oppivat hyviä ohjelmointitekniikoita. Näin myös ohjelmiston tehokkuus parantuu. Lähdekoodin analysoimisella staattisesti varmistetaan, että koodi on selkeää luettavaa, eikä koodissa ole liian monimutkaisia toteutuksia. Vertaistestaus suoritetaan kurssin ryhmä 8 Noin seitsemän veljestä kanssa siten, että suoritamme testit toistemme järjestelmiin. Vertaistestaus suoritetaan Laadunvarmistusmenetelmät Seuraavia laadunvarmistusmenetelmiä käytetään projektissa koko sen kehityselinkaaren aikana: Equivalence Partition (EP). Tällä jaetaan syötteet ja tulostukset alueisiin, jotka ovat samoja. Oletus on, jos jokin alueella oleva arvo toimii, toimii koko alue oikein. Boundary Value Analysis (BVA). Tällä tarkastetaan syötteitä ja tulosteita lähellä raja-arvoa, jotka ovat yleisimpiä virheitä. Test Driven Development (TDD). Tässä on tarkoituksena tehdä yksikkötestit ennen varsinaista koodia. Näin saadaan suunniteltua, mitä koodin pitäisi tehdä, ja toteutuksesta pitäisi tulla parempi, koska se on mietitty kahteen kertaan. Tätä menetelmää käytetään alussa kahden kehittäjän kanssa, ja analysoidaan miten paljon projektissa kannattaa panostaa tähän. Exploratory Testing (ET). Tutkiva testaus on menetelmä, jossa testataan ilman ennalta tehtyjä tarkkoja suunnitelmia. Tätä käytetään iteraatioiden loppuvaiheissa. Tätä käytetään myös pääsääntöisesti käyttöliittymän testauksessa. Pairwise Testing (PT). Tällä saadaan rajattua tutkittavan syötteen ja tulosteen määrää heikentämättä testauksen laajuutta haitallisesti. Soveltuu hyvin EP:n ja BVA:n kanssa yhdessä käytettäväksi. Test Case Based Testing (TCB). Testitapauksiin perustuva testaus antaa hyvän peruspohjan järjestelmään kriittisimpien vaatimuksien testaamiseen. Tällä saavutetaan kaikkien tärkeimpien vaiheiden läpikäynti ja testaus aina. Tätä testaus tyyppiä tukee hyvin tutkiva testaus Laatuparametrit ISO 9126 määrittelee laatuparametreiksi toiminnallisuuden, luotettavuuden, käytettävyyden, tehokkuuden, ylläpidettävyyden ja siirrettävyyden. Näistä oleellisimpia projektissamme ovat toiminnallisuus, luotettavuus ja ylläpidettävyys. Järjestelmämme saatavuudella ja oikealla ja luotettavalla
8 LAATUDOKUMENTTI 8 (15) toiminnalla on kovat vaatimukset. Vaatimukset selviävät vaatimusmäärittelyssä Laatumittarit Projektissa laadun tavoitteena on suorittaa mahdollisimman paljon testeistä hyväksytysti. Vähintään kriittiset ja suuren prioriteetin testitapaukset on mentävä läpi. Pienemmän prioriteetin testitapauksista on suoritettava hyväksytysti vähintään 80%. Ohjelmistolle tehtävistä JUnit yksikkötesteistä pitää suorittaa hyväksytysti 98% Refaktorointi Koodin refaktoroinnilla varmistetaan koodin laadukkuus, mikä mm. helpottaa ylläpidettävyyttä. Jokainen kehittäjä käyttää viikoittain koodinsa refaktorointiin omatoimisesti noin tunnin. Lisäksi projektissa käytettävien staattisten menetelmien avulla saadaan selville ongelmakohtia, joissa tarvitaan refaktorointia Testityngät Ohjelmistossamme on useita rajapintoja. Osa rajapinnoista on ohjelmistomme adaptereiden välisiä ja osa tarjoaa muille järjestelmille rajapinnan viestintään ohjelmistomme kanssa. Koska muut järjestelmät eivät ole meillä testauksessa käytettävissä, teemme niiden viestintää simuloivat stubit eli tyngät. Käytämme tynkiä samoin myös ohjelmistomme komponenttien välisillä rajapinnoilla, jotta kehitystyö ei riipu liikaa muiden komponenttien kehitystahdista. Tynkiä voidaan komentaa simuloimaan ja testaamaan normaalin toiminnan lisäksi myös erilaisia poikkeavia tilanteita. Tynkien avulla voimme suorittaa automatisoidusti etukäteen suunniteltuja testejä. Käytännössä tyngät toteutetaan junitin yksikkötesteillä. Testeissä tyngät lähettävät testattavalle komponentille erilaisia ML-muotoisia viestejä Laadunvarmistuskäytännöt Käytämme laadunvarmistuksessa erityisesti seuraavia käytäntöjä. Näistä käytännöistä tehdään lisäksi SEPA-päiväkirjat ennen käytäntöjen käyttöönottoa Jatkuva integrointi Käytämme projektissa jatkuvaa integrointia. Jatkuvalla integroinnilla tarkoitetaan projektin kokoonpanojen jatkuvaa ja automaattista rakentamista, testaamista ja tulosten raportointia. Tavoitteena jatkuvan integroinnin käytössä on varmistaa ohjelman toimiminen kokonaisuutena ja edesauttaa virheiden havaitsemista. Automaattisen raportoinnin avulla pyritään lisäämään näkyvyyttä ohjelmistokokonaisuuden laatuun ja tilaan Pariohjelmointi Projektissa käytetään pariohjelmointia kehitysmenetelmänä, millä pyritään parantamaan tuotettavan koodin tasoa. Pariohjelmointi myös edistää hajautetussa projektissa kommunikointia ja nopeuttaa havaittuihin ongelmiin
9 LAATUDOKUMENTTI 9 (15) reagointia. Pariohjelmoinnin vaikutusta koodin laatuun pyritään arvioimaan, sekä staattisten menetelmien avulla että kehittäjien arvioiden perusteella Staattiset menetelmät Käytämme projektissa staattisia menetelmiä ohjelmakoodin laadunvarmistukseen. Menetelmät jakautuvat ohjelmakoodin automatisoituun analysointiin ja koodikatselmointikäytäntöihin. Automaattisessa analysoinnissa käytetään Javalle suunniteltuja analysointityökaluja, jotka analysoivat ohjelmakoodissa olevia ohjelmointivirheitä ja ohjelman kompleksisuutta. Työkalujen avulla saatujen tulosten perusteella tehdään koodiin tarvittaessa muutoksia. Analysointi pyritään integroimaan CruiseControl -järjestelmään, jolloin se voidaan suorittaa yksikkötestien yhteydessä säännöllisesti automatisoituna. Katselmointikäytäntöihin kuuluu koodikatselmus, joka järjestetään ohjelman logiikan kannalta tärkeimmille komponenteille, kuten sovellusadapterin ja tietoliikenneadapterin keskeisimmille osille. Katselmointien tavoitteena on löytää komponenttien toteutuksesta mahdollisia ongelmia, jotka eivät ole tulleet ilmi muilla laadunvarmistusmenetelmillä. Katselmointi toteutetaan formaalina koodikatselmointina, jossa katselmointiin osallistuvat henkilöt tutustuvat katselmuksen kohteena olevaan koodiin ennen katselmointia. Katselmointitilaisuudessa katselmoinnin tulokset käydään läpi luokka ja metodi kerrallaan ja päätetään vaativatko löytyneet ongelmat jatkotoimenpiteitä. Katselmoinnin tulokset kirjataan ylös ja niiden perusteella tutkitaan SEPA:ssa katselmointikäytännön tehokkuutta Henkilövastuut Laadunvarmistuksen vastuut on jaettu eri henkilöille alla olevan taulukon mukaisesti. Taulu 2 Henkilövastuut Henkilö Tehtävä Vastuualue Aleksi Airola Katselmoija Projektipäällikkö, dokumenttien katselmointi Antti Kauppinen Testaaja Testidata, pariohjelmointi Kaarlo Lahtela Laatupäällikkö Dokumentit, laadunvalvonta Lari Ahti Testaaja Testidata, pariohjelmointi Lauri Kiiski Laatuassistentti Ohjeistus, testiloki, testien automatisointi Olli Vanhapiha Testaaja Testien automatisointi Timo Töyry Testaaja Staattiset menetelmät Tuomas Tolvanen Katselmoija Staattiset menetelmät 2.5. Testitapauksien dokumentointi JUnit testit dokumentoidaan JavaDoceilla. Niitä ei dokumentoida millään muulla tavalla. Testitapaukset listataan taulukkoon. Testitapaukset sisältävät seuraavat asiat: Testitapaus ID yksilöi testitapauksen. Nimi kertoo mitä testitapaus käsittelee.
10 LAATUDOKUMENTTI 10 (15) Prioriteetti kertoo miten tärkeä testitapaus on. Tämän perusteella päätetään miten paljon aikaa tähän käytetään. Eri tasot ovat pakollinen, korkea ja matala. Kuvaus kertoo tarkemmin mitä testitapauksessa tehdään. Oletettu tulos kertoo miten testitapauksen pitäisi käyttäytyä. Syöte käytetyt parametrit. Tuloste mitä saadaan ulos. Vaatimusmäärittely mihin vaatimuksiin testitapaus viittaa. Taulu 3 Testitapauksien dokumenttipohja Testitapaus ID Nimi Prioriteetti Kuvaus Oletettu tulos Syöte Tuloste Vaatimusmäärittely Kaikki pakollisen ja korkean tason prioriteetilla olevat testitapaukset suoritetaan aina. Seuraavaksi pyritään suorittamaan matalan tason testitapauksia vähintään kerran Testien kirjaaminen Testien tekemisen jälkeen, testeistä tehdään myös testilokit. Testilokissa kuvataan testien onnistuminen. Loki on vasemmalta puoleltaan samanlainen kuin testitapauksien dokumentoinnin vasen puoli testitapauksen ID, nimi ja prioriteetti. Onnistuneet testitapaukset merkitään vihreällä ja epäonnistuneet merkitään punaisella. Kun testejä tehdään useaan kertaan, niin tuloksia kerätään aina oikealle puolelle lisää. Joka kerrasta kerrotaan aina minä päivänä se on tehty ja mitä build-versiota on testattu. Taulu 4 Testilokin dokumenttipohja Build Build 1283 Testitapaus ID Nimi Prioriteetti Tulos Kommentit Tulos Kommentit 1 FAIL PASS Virheiden seuranta ja reagointi Virheiden seurantaan käytetään projektiryhmän palvelimella JIRAjärjestelmää. Virheet täytyy kirjata järjestelmään, jos Virhettä ei korjata heti Virhe löytyy järjestelmä- tai hyväksymistestauksessa Vertaisryhmä tai asiakas löytää sen Virhettä ei kirjata järjestelmään, jos Virhe havaitaan toteutuksen yhteydessä ja se korjataan heti Virhettä raportoitaessa täytyy mahdollisimman hyvin kuvata virhe ja ympäristö, jossa virhe ilmenee. Lisäksi täytyy kuvata virheen
11 LAATUDOKUMENTTI 11 (15) ilmentymistiheys ja miten sen pystyy tuottamaan uudestaan, sekä työmääräarvion. Laatupäällikkö antaa virheelle vakavuusluokituksen viisiportaisella asteikolla: 1. Estävä virhe (Blocker) Estää ohjelman käytön. Kehitystyö on keskeytettävä komponentissa ohjelmiston korjaamisen ajaksi. 2. Kriittinen (Critical) Vaikeuttaa vakavasti ohjelman käyttöä. Kehitystyötä voidaan jatkaa, mutta virheestä vastuullinen ei jatka kehitystyötä ennen kuin virhe on korjattu. 3. Korkea (Major) Vaikeuttaa ohjelman käyttöä, mutta ohjelman saa toimimaan jollakin muulla tavalla. Virhe tulee korjata ennen iteraatioiden loppua. 4. Pieni (Minor) Häiritsee käyttöä. Virheen pyritään korjaamaan iteraatiossa, jos ei ole suurempia ongelmia. 5. Triviaali (Trivial) Virhe on kosmeettinen, eikä vaikeuta ohjelmiston käyttöä. Korjataan, jos aikaa riittää. Virheiden seurannasta on vastuussa QA-ryhmä (Kaarlo Lahtela ja Lauri Kiiski). QA-ryhmä asettaa kullekin virheelle vastuullisen, ellei raportoija ole ottanut sitä omalle vastuulleen. Lisäksi QA-ryhmä seuraa virheiden tilaa ja tarvittaessa korjaa myös työmäärä arvioita. Kaikille ryhmän jäsenille luodaan tunnukset JIRA:an, kuten myös asiakkaalle, mentorille ja vertaistestaajille Laitteisto- ja ohjelmistoresurssit Kehittäjät käyttävät omilla työasemillaan testauksessa ja kehityksessä Eclipse 3.2:ta. Eclipse 3.2:ssa on kaikilla kehittäjillä käytössä yksikkötestausta varten junit ja Coverclipse Microsoft SQL Server 2005 on käytettävissä projektiryhmän Windows P -palvelimella niille kehittäjille, jotka eivät käytä omalla koneellaan Microsoft SQL Server 2005 Express Editionia. Asiakas ylläpitää omissa tiloissaan Windows 2003 Server -testauspalvelinta, joka on tuleva tuotantopalvelin. Testauspalvelimella on käytössä SQL Server Testauspalvelinta käytetään systeemitestaukseen ja se tulee ryhmälle käytettäväksi viikolla 47. Projektiryhmän Debian-palvelimella ajetaan CruiseControl 2.5:tä jatkuvaan integrointiin (ks ). Virheiden raportointiin ja tehtävien jakamiseen, sekä manageritason seurantaan käytetään JIRA:a Standardit Tuotokset IEEE Std , IEEE Standard for Software Test Documentation ISO 9126 Testauksen ja laadunvarmistuksen tuotokset: Laatudokumentti, joka kuvaa laatutavoitteet ja käytännöt niiden varmistamiseen. Yksikkötestit, JUnit-testit, jotka dokumentoidaan JavaDoceissa.
12 LAATUDOKUMENTTI 12 (15) Testitapaukset, jotka dokumentoidaan testitapausdokumenttiin Ohjelmiston testit, jotka dokumentoidaan testilokiin. Testien lopuksi tehdään testiraportti, jossa on kuvattuna yhteenveto testeistä. SEPA-päiväkirjat Vertaistestausohjeet ja -raportit Testien keskeytys- ja jatkamisehdot Testaaminen keskeytetään, jos sovellus- tai tietoliikenneadapterin rajapinta ei pysty vastaanottamaan viestejä. Testaaminen keskeytetään myös, jos testauksen aikana ilmenee vakavia ongelmia, jotka estävät järkevän testauksen. Keskeytynyttä testaamista jatketaan, kun testattavasta komponentista tai järjestelmästä toimitetaan korjattu versio. Ensimmäisenä ajetaan regressiotestit ja sitten jatketaan muilla testeillä Testauksen lopetuskriteerit Testaaminen lopetetaan, kun testauksen tavoitteet ovat täyttyneet. Testaaminen lopetetaan laatupäällikön ja projektipäällikön harkinnan mukaan, jos testaamiseen käytettävä aika loppuu. Ajan loppumista pyritään välttämään riittävillä resursseilla ja testien priorisoinnilla.
13 LAATUDOKUMENTTI 13 (15) 3. ITERAATIOTASON SUUNNITELMAT 3.1. Ensimmäinen iteraatio Testattavat toiminnot Taulu 5 Testattavat toiminnat Tunniste Toiminto Tärkeys Viittaus vaatimuksiin TF1 Viestin vastaanotto Pieni UC6.1, FR3 TF2 Viestin välitys Pieni UC6.2, FR3 TF3 Adapterikuittaus Tärkeä UC6.1 TF4 Siirtoprotokollatason kuittaus Pakollinen UC6.1 TF5 Tietoliikenneadapteri vastaanottaa viestin Pakollinen UC6.1, FR3 TF6 Tietoliikenneadapteri välittää datan sovellusadapterille. Tärkeä UC6.1, FR3 TF7 Sovellusadapteri jakaa datan oikealle messagehandlerille. Pakollinen UC6.1, FR3 TF8 Sovellusadapteri tallentaa datan Tärkeä UC6.1, FR3 TF9 Sovellusadapteri toimittaa tietoliikenneadapterille dataa Tärkeä UC6.2, FR3 TF10 Tietoliikenneadapteri toimittaa sovellusadapterilta saadun datan eteenpäin. Tärkeä UC6.*, FR Ei-testattavat toiminnot Emme testaa kolmansien osapuolien koodia. Luotamme, että käyttämämme kirjastot ovat toimivia. Testaamme kuitenkin käyttämiemme komponenttien konfiguraation oikeellisuuden Laadunvarmistuskäytäntöjen käyttäminen Iteraatio I:ssä tullaan ottamaan vaiheittain käyttöön CruiseControl jatkuvan integraation työkaluna. Ohjelmointityö aloitetaan rakentamalla projektien rungot ja niille rakennusskriptit. Välittömästi tämän jälkeen voidaan ottaa käyttöön automaattinen kokoonpano ja versioiden merkintä CruiseControltyökalulla. Seuraavaksi jatkuvaan integrointiin lisätään automaattinen yksikkötestien suoritus sekä ajan ja tarpeiden sanelemana muita työkaluja. Pariohjelmointia käytetään heti projektin alusta lähtien. Alussa pariohjelmoinnin avulla tutustutaan lyhyesti käytännössä TDD:iin. Jatkossa pariohjelmointia käytetään komponentteihin, joiden toteutus on haastavinta tai riskialteinta. Ennen Iteraatio I:n päätöstä suoritetaan koodikatselmointi Tietoliikenneadapterin tietoliikenne-toiminnallisuudelle sekä Sovellusadapterin viestinkäsittely-toiminnoille. Iteraatio I:n lopussa syntyneelle koodille suoritetaan myös ohjelmallinen staattinen analysointi. Iteraatio I:n jälkeen menetelmä integroidaan osaksi CruiseControljärjestelmää. Katselmointikäytännöistä järjestetään ryhmälle koulutus ennen ensimmäisen katselmoinnin suorittamista.
14 LAATUDOKUMENTTI 14 (15) Testi ympäristö ja testidata Jokaisella kehittäjällä on omalla työasemallaan kehitysympäristö, jolla ohjelma pystytään kääntämään. Kehittäjät käyttävät omia työasemiaan kehityksen aikaiseen yksikkötestaukseen ja integraatiotestaukseen. Asiakas tarjoaa systeemi- ja integraatiotestaukseen testauspalvelimen. Testidata on välitettäviä ML-dokumentteja. ML Schema -ryhmä tuottaa testidokumentteja saadun teknisen dokumentaation perusteella ja muokkaamalla valmiita esimerkkidokumentteja. Testidokumentit eivät sisällä luonnollisten henkilöiden tietoja Aikataulu ja henkilöresurssit Testaus jatkuu läpi koko projektin rinnakkain kehitystyön kanssa. Ohjelmiston varsinaiset testaus- ja korjausjaksot ovat ja , joissa varmistetaan, että demossa ohjelmiston laatu vastaa odotettua. Tehtävistä vastuulliset valitsevat tehtävien toteuttamiseen avukseen tilanteen mukaan siihen parhaiten sopivat henkilöt. Taulu 6 Aikataulu ja henkilöresurssit Nro Tehtävä Edeltävä tehtävä Vastuulliset Työmäärä (h) Määräaika 1 Testitapausten suunnittelu Laatusuunnitelman välidemoon palautus Kaarlo, Lauri Testitynkien suunnittelu Kaarlo, Tuomas, Laatu-suunnitelma välidemoon Lauri Ohjeistus välidemoon 1 Lauri Testidatan tuottaminen välidemoon 1 Tuomas Testauksen SEPApäiväkirjat SEPA-ryhmät CruiseControlin Ohjelmoinnin käyttöönotto aloitus Lauri, Olli Työkalujen lisäys CruiseControliin 6 Lauri, Olli Välidemossa tarvittavien testitynkien ensimmäiset Lauri, Olli versiot 9 Tietoliikenneadapterin testaus 8 Kaarlo, Olli Sovellusadapterin testaus 8 Kaarlo, Tuomas Testituloksien analysointi Kaarlo, Tuomas, 9, 10 ja reagointi Lauri Tehtävien (9-11) toisto 11 Kaarlo Testauksen yhteenveto 12 Kaarlo Välidemo 2 15 Testitapausten suunnittelu 13 Kaarlo, Lauri Testitynkien suunnittelu 13 Kaarlo, Tuomas, Lauri Ohjeistus 15 Lauri Testidatan tuottaminen 15 Tuomas
15 LAATUDOKUMENTTI 15 (15) Testauspalvelimen käyttöönotto ja valmistelu systeemitestaukseen Sovellusadapterin koodikatselmointi Tietoliikenneadapterin koodikatselmointi Tietoliikenneadapterin Asiakas antaa pääsyn palvelimelle Kaarlo, Lauri Tuomas Kaarlo Kaarlo testaus 23 Sovellusadapterin testaus 17 Tuomas Integraatiotestaus 22, 23 Lauri, Tuomas Systeemitestaus 24 Kaarlo, Lauri Testituloksien analysointi Kaarlo, Lauri, ja reagointi Olli Tehtävien (22-26) toisto 26 Kaarlo Testiraportointi 27 Kaarlo, Lauri Dokumenttien katselmointi 28 Kaarlo Dokumenttien korjaukset 29 Aleksi, Kaarlo, Lauri Testausdokumenttien Kaarlo 0,5 palautus klo 11:00 32 Iteraatiodemo Testikierrokset CruiseControlilla ajetaan yksikkötestejä jatkuvasti kerran vuorokaudessa. Ensimmäisellä testikierroksella testitynkien testit suoritetaan manuaalisesti. Testityngät automatisoidaan suorittamaan kertaalleen läpäisseet testit kerran vuorokaudessa. Muut testit suoritetaan aikataulun mukaan. Testikierroksia suoritetaan kunnes testauksen lopetusehdot täyttyvät Toinen iteraatio Tämä kappale tullaan kokonaisuudessaan tarkentamaan toisen iteraation alussa Testattavat toiminnot Ylläpitäjän käyttöliittymä Ei-testattavat toiminnot Laadunvarmistuskäytäntöjen käyttäminen Suoritetaan katselmointi tärkeimmille uusille toiminnoille Laitteisto- ja ohjelmistoresurssit Emma otetaan käyttöön toiseen iteraatioon, jos Coverclipsen tulokset ja niistä raportoiminen ei vastaa odotuksia. CruiseControliin otetaan käyttöön lisää plugineja.
T 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ä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ä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ä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ä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. 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ä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ä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ätiedot11.12.2006 VAATIMUSMÄÄRITTELY
VAATIMUSMÄÄRITTELY Vaatimusmäärittely 2 (18) VERSIONHALLINTA Versio Päivä Tekijä Kuvaus 0.1 4.10.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 4.10.2006 Kaarlo Lahtela kohdat 7 (tominnalliset vaatimukset)
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ä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ä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ä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ä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ätiedotTestaussuunnitelma. 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ä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ä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ä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ätiedotLaaturaportti [iteraatio 2] Ryhmä 14
Laaturaportti [iteraatio 2] Ryhmä 14 Versio Pvm Tekijä Kuvaus 1.0 2.3.2008 Luukkonen Ensimmäinen versio Sisältö 1. Käytetyt laatumenetelmät... 1 1.1 Automaattiset yksikkötestit, tutkiva testaus ja jatkuva
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ä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ä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ä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ä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ä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ätiedotVERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D
VERSIONHALLINTA PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D Versio Päivä Tekijä Kuvaus 0.1 26.10.2005 Kaarlo Lahtela Ensimmäinen versio 0.2 10.12.2006 Lauri Kiiski Suomennettu 3 (8 ) SISÄLLYS
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ä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ä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ätiedotTestaussuunnitelma. Dokumentti: Testaussuunnitelma.doc Päiväys: Projekti: AgileElephant
AgilElephant Tekijä: Petri Kalsi ja Heikki Salminen Omistaja: ElectricSeven Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 1 / 11 Dokumenttihistoria Muutoshistoria Revision Numero Revision Päiväys Yhteenveto
LisätiedotOhjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
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ä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. 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ä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ätiedotTutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
LisätiedotTestaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science
Testaustyökalut Luento 11 Antti-Pekka Tuovinen 25 April 2013 1 Tavoitteet Työkalutyyppejä Testauksen hallinta Testien määrittely Staattinen analyysi Dynaaminen testaus 25 April 2013 2 1 Työkalut ja testaus
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ä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ätiedot22.10.2006 VAATIMUSMÄÄRITTELY
VAATIMUSMÄÄRITTELY Vaatimusmäärittely 2 (18) VERSIONHALLINTA Versio Päivä Tekijä 0.1 4.10.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 4.10.2006 Kaarlo Lahtela kohdat 7 (tominnalliset vaatimukset) Aleksi
Lisätiedot4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T
SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen
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ä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ä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ä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ä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ä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ä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ä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. 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ä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ä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ätiedotTest-Driven Development
Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole
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ä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ä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ä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ä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ä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ä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ätiedotTestausraportti. Oppimistavoitteiden hallintajärjestelmä harri
Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
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ä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ätiedotTDD Käytännössä Todellinen työkalu vai lehmipoikien laukkaa? Harri Kulmala Solita Oy
www.solita.fi solita@solita.fi TDD Käytännössä Todellinen työkalu vai lehmipoikien laukkaa? Harri Kulmala Solita Oy 1 TDD Käytännössä Test Driven Development yleisesti Lupaukset Esimerkki Projektin ja
LisätiedotTest-Driven Development
Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia
LisätiedotSEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus
SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön
LisätiedotTestiraportti 2. iteraatiosta
Testiraportti 2. iteraatiosta TeamDC - CoSCA-simulaattorin jatkokehitysprojekti Versio Päiväys Tekijä Kuvaus 0.1 20.2.2006 Santeri Saarinen Muokattu templatesta, aloitettu kirjoittaminen 0.2 20.2.2006
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ä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ätiedotTestaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille
1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei
LisätiedotSEPA päiväkirja. Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T Ohjelmistoprojekti I
SEPA päiväkirja Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T-76.4110 Ohjelmistoprojekti I Sisällysluettelo Sisällysluettelo...2 1. Johdanto...3 2.
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ätiedotT Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2)
T-76.4110 Ohjelmistoprojekti I 25.2.2006 T-76.4115 Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2) Versio Päiväys Muokkaaja Kuvaus 2.0 25.2.2006 Markus Kattilamäki Päivämäärien tarkennus, viimeistely
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ä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ä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ätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
Lisätiedotstatbeatmobile PROJECT REVIEW iteration 1
statbeatmobile PROJECT REVIEW iteration 1 agenda Projekti Status Käytännöt Tulokset Katsaus eteenpäin PROJEKTI / mikä on statbeat? Sosiaalinen joukkueurheilupalvelu Keskustelu, fanit, kavereiden joukkueet,
LisätiedotI2 -Iteraatiosuunnitelma. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
I2 -Iteraatiosuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC Sisällysluettelo 1 Johdanto 2 1.1 Tavoitteet 3 1.2 Tuotokset 4 1.3 Tehtävät ja työmääräarviot 6 1.4 Vaiheistus ja aikataulutus 8
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ä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ätiedotI1 Iteraatiosuunnitelma. CoSCA-simulaattorin jatkokehitysprojekti. TeamDC
I1 Iteraatiosuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC Sisällysluettelo 1 Johdanto 2 1.1 Tavoitteet 3 1.2 Tuotokset 4 1.3 Tehtävät ja työmääräarviot 6 1.4 Vaiheistus ja aikataulutus 9
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ätiedotSEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T. Sisällysluettelo. 1 Johdanto. 2 SEPA harjoittelu käytännössä.
Sivu 1 (5) SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T Versio Päiväys Tekijä Kuvaus 0.1 27.10.2004 Timo Sallinen Ensimmäinen versio 1.0 31.10.2004 Timo Sallinen Korjauksia,
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ä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ätiedotTestiautomaatio tietovarastossa. Automaattisen regressiotestauksen periaate ja hyödyt
Testiautomaatio tietovarastossa Automaattisen regressiotestauksen periaate ja hyödyt Sisältö 2 Testaus kiinteänä osana DW-toteutusta Regressiotestauksen merkitys Robot Framework Automatisoitu DW:n regressiotestaus:
LisätiedotTARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
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ätiedotTestilähtöinen ohjelmistokehitys. Testilähtöinen ohjelmistokehitys. TDD Testilähtöinen ohjelmistokehitys. Testi! Testi
Testilähtöinen ohjelmistokehitys Kevät 2008 Jonne Itkonen Jyväskylän yliopisto Testilähtöinen ohjelmistokehitys Test-Driven Development, TDD Tehdään ensin testi, sitten vasta koodi. TDD Testilähtöinen
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ätiedotT-76.5158 SEPA päiväkirja
T-76.5158 SEPA päiväkirja Ryhmä 14 Automatisoitu yksikkötestaus Mikko Luukkonen, 60549T Lauri Helkkula, 62820H Matti Eerola, 60686A Versiohistoria Versio Pvm Tekijä(t) Kuvaus 0.3 25.11.2007 Luukkonen,
LisätiedotT 76.115 Tietojenkäsittelyopin ohjelmatyö Hirviöryhmä loppukatselmointi. Hirviö. Projektikatselmointi
Hirviö Projektikatselmointi Mikä Hirviö on? Hajautettu muistikirja Professoreille Muistiinpanoja keskusteluista opiskelijan kanssa Diplomitöiden ja jatko opintojen seuranta Raportointi Opetushenkilökunnalle
LisätiedotOhjelmistotekniikan menetelmät, toteutuksesta ja testauksesta
582101 - Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 1 Toteutuksesta ja testauksesta Suunnitteluprosessista Tarkan tason luokkasuunnittelu Siirtyminen UML-kaavioista Java-toteutukseen
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ätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
LisätiedotOhjelmiston toteutussuunnitelma
Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,
LisätiedotELM GROUP 04. Teemu Laakso Henrik Talarmo
ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................
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ätiedotA4.1 Projektityö, 5 ov.
A4.1 Projektityö, 5 ov. Kurssin esitietovaatimuksia Kurssin tavoitteista Kurssin sisällöstä Luentojen tavoitteista Luentojen sisällöstä Suoritustavoista ja -vaatimuksista Arvostelukriteereistä Motivointia
Lisätiedot