LAATUDOKUMENTTI

LAATUDOKUMENTTI

LAATUDOKUMENTTI 2 (15) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 11.10.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 17.10.2006 Kaarlo Lahtela Lauri Kiiski 0.3 24.10.2006 Kaarlo Lahtela runko 0.4 30.10.2006 Kaarlo Lahtela Projektitason suunnitelmaa 0.5 31.10.2006 Aleksi Airola Dokumentin katselmointi 0.6 2.11.2006 Kaarlo Lahtela Dokumentointikäytäntöjä. 0.7 2.11.2006 Lauri Kiiski Iteraatio 1 tason suunnitelmia. 0.8 2.11.2006 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

LAATUDOKUMENTTI 3 (15) SISÄLLYS 1. JOHDANTO...4 2. PROJEKTI TASON SUUNNITELMA...5 2.1. Laatutavoitteet...5 2.1.1. Laatupaletti...5 2.2. Toimintatavat...6 2.2.1. Testaamisen laajuus...6 2.2.2. Testitasot...6 2.2.3. Testi tyypit...6 2.2.4. Laadunvarmistusmenetelmät...7 2.2.5. Laatuparametrit...7 2.2.6. Laatumittarit...8 2.2.7. Refaktorointi...8 2.2.8. Testityngät...8 2.3. Laadunvarmistuskäytännöt...8 2.3.1. Jatkuva integrointi...8 2.3.2. Pariohjelmointi...8 2.3.3. Staattiset menetelmät...9 2.4. Henkilövastuut...9 2.5. Testitapauksien dokumentointi...9 2.6. Testien kirjaaminen...10 2.7. Virheiden seuranta ja reagointi...10 2.8. Laitteisto- ja ohjelmistoresurssit...11 2.9. Standardit...11 2.10. Tuotokset...11 2.11. Testien keskeytys- ja jatkamisehdot...12 2.12. Testauksen lopetuskriteerit...12 3. ITERAATIOTASON SUUNNITELMAT...13 3.1. Ensimmäinen iteraatio...13 3.1.1. Testattavat toiminnot...13 3.1.2. Ei-testattavat toiminnot...13 3.1.3. Laadunvarmistuskäytäntöjen käyttäminen...13 3.1.4. Testi ympäristö ja testidata...14 3.1.5. Aikataulu ja henkilöresurssit...14 3.1.6. Testikierrokset...15 3.2. Toinen iteraatio...15 3.2.1. Testattavat toiminnot...15 3.2.2. Ei-testattavat toiminnot...15 3.2.3. Laadunvarmistuskäytäntöjen käyttäminen...15 3.2.4. Laitteisto- ja ohjelmistoresurssit...15

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-76.4115-kurssilla vuosina 2006-2007. 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: https://svn.dentego.com/dokumentit/projektisuunnitelma.pdf 2 Vaatimusmäärittely: https://svn.dentego.com/dokumentit/vaatimusmaarittely.pdf

LAATUDOKUMENTTI 5 (15) 2. PROJEKTI TASON SUUNNITELMA 2.1. Laatutavoitteet Tärkeimmät asiakkaan laatutavoitteet kehitettävästä järjestelmästä ovat: 2.1.1. 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. 2.2.4) Pariohjelmointi Jatkuva integrointi Pitkä testiajo Refactorointi 3 Good Enough Quality, Defined by James Bach; IEEE Computer, 1997, vol. 30, no. 8, pp. 96-98

LAATUDOKUMENTTI 6 (15) 2.2. Toimintatavat Seuraavassa on kuvattu laadunvarmistamisessa käytettyjä toimintatapoja, joilla varmistetaan tuotteen laatu. 2.2.1. Testaamisen laajuus Kaikki tuotettu koodi testataan. Koodilla ja testeillä on prioriteettitasoja, joilla saadaan painotettua tärkeämpien elementtien laatua. 2.2.2. Testitasot 2.2.3. 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.

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 17. 21.2.2007. 2.2.4. 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. 2.2.5. 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

LAATUDOKUMENTTI 8 (15) toiminnalla on kovat vaatimukset. Vaatimukset selviävät vaatimusmäärittelyssä. 2.2.6. 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%. 2.2.7. 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. 2.2.8. 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ä. 2.3. 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. 2.3.1. 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. 2.3.2. 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

LAATUDOKUMENTTI 9 (15) reagointia. Pariohjelmoinnin vaikutusta koodin laatuun pyritään arvioimaan, sekä staattisten menetelmien avulla että kehittäjien arvioiden perusteella. 2.3.3. 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. 2.4. 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.

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. 2.6. 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 10.12.2006 Build 867 14.1.2007 Build 1283 Testitapaus ID Nimi Prioriteetti Tulos Kommentit Tulos Kommentit 1 FAIL PASS 2 2.7. 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

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. 2.8. 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 3.8.1 ja Coverclipse 0.9.5.2. 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 2005. 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. 2.3.1). Virheiden raportointiin ja tehtävien jakamiseen, sekä manageritason seurantaan käytetään JIRA:a. 2.9. Standardit 2.10. Tuotokset IEEE Std 829-1998, 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.

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. 2.11. 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ä. 2.12. 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.

LAATUDOKUMENTTI 13 (15) 3. ITERAATIOTASON SUUNNITELMAT 3.1. Ensimmäinen iteraatio 3.1.1. 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.*, FR3 3.1.2. 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. 3.1.3. 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.

LAATUDOKUMENTTI 14 (15) 3.1.4. 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. 3.1.5. Aikataulu ja henkilöresurssit Testaus jatkuu läpi koko projektin rinnakkain kehitystyön kanssa. Ohjelmiston varsinaiset testaus- ja korjausjaksot ovat 9.-20.11.2006 ja 29.11.-9.12.2006, 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 6 9.11.2006 2 Testitynkien suunnittelu Kaarlo, Tuomas, Laatu-suunnitelma välidemoon Lauri 5 7.11.2006 3 Ohjeistus välidemoon 1 Lauri 2 9.11.2006 4 Testidatan tuottaminen välidemoon 1 Tuomas 2 15.11.2006 5 Testauksen SEPApäiväkirjat SEPA-ryhmät 18 9.11.2006 6 CruiseControlin Ohjelmoinnin käyttöönotto aloitus Lauri, Olli 10 16.11.2006 7 Työkalujen lisäys CruiseControliin 6 Lauri, Olli 8 30.11.2006 8 Välidemossa tarvittavien testitynkien ensimmäiset Lauri, Olli 7 10.11.2006 versiot 9 Tietoliikenneadapterin testaus 8 Kaarlo, Olli 2 10.11.2006 10 Sovellusadapterin testaus 8 Kaarlo, Tuomas 2 10.11.2006 11 Testituloksien analysointi Kaarlo, Tuomas, 9, 10 ja reagointi Lauri 3 1 12 Tehtävien (9-11) toisto 11 Kaarlo 20.11.2006 13 Testauksen yhteenveto 12 Kaarlo 2 22.11.2006 14 Välidemo 2 15 Testitapausten suunnittelu 13 Kaarlo, Lauri 4 24.11.2006 16 Testitynkien suunnittelu 13 Kaarlo, Tuomas, Lauri 3 24.11.2006 17 Ohjeistus 15 Lauri 1 28.11.2006 18 Testidatan tuottaminen 15 Tuomas 2 28.11.2006

LAATUDOKUMENTTI 15 (15) 19 20 21 22 Testauspalvelimen käyttöönotto ja valmistelu systeemitestaukseen Sovellusadapterin koodikatselmointi Tietoliikenneadapterin koodikatselmointi Tietoliikenneadapterin Asiakas antaa pääsyn palvelimelle Kaarlo, Lauri 8 30.11.2006 Tuomas 5 30.11.2006 Kaarlo 4 30.11.2006 17 Kaarlo 2 29.11.2006 testaus 23 Sovellusadapterin testaus 17 Tuomas 2 29.11.2006 24 Integraatiotestaus 22, 23 Lauri, Tuomas 3 29.11.2006 25 Systeemitestaus 24 Kaarlo, Lauri 3 30.11.2006 26 Testituloksien analysointi Kaarlo, Lauri, 22-25 ja reagointi Olli 3 1.12.2006 27 Tehtävien (22-26) toisto 26 Kaarlo 5.12.2006 28 Testiraportointi 27 Kaarlo, Lauri 8 7.12.2006 29 Dokumenttien katselmointi 28 Kaarlo 3 7.12.2006 30 Dokumenttien korjaukset 29 Aleksi, Kaarlo, Lauri 6 8.12.2006 Testausdokumenttien 11.12.2006 31 30 Kaarlo 0,5 palautus klo 11:00 32 Iteraatiodemo 12.12.2006 3.1.6. 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. 3.2. Toinen iteraatio Tämä kappale tullaan kokonaisuudessaan tarkentamaan toisen iteraation alussa. 3.2.1. Testattavat toiminnot Ylläpitäjän käyttöliittymä. 3.2.2. Ei-testattavat toiminnot 3.2.3. Laadunvarmistuskäytäntöjen käyttäminen Suoritetaan katselmointi tärkeimmille uusille toiminnoille. 3.2.4. 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.