Laadunvarmistussuunnitelma CoSCA-simulaattorin jatkokehitysprojekti TeamDC
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 Elina Kontro Lähdeluettelo, viitteet, (muutama vastaus) 0.4 30.10.2005 Santeri Saarinen Lisätty I1-suunnitelma ja korjauksia 0.41 30.10.2005 Santeri Saarinen Lisätty katselmoinnissa ehdotettuja korjauksia 0.42 8.11.2005 Elina Kontro Tarkennusta laatutavoitteisiin. 0.43 11.11.2005 Elina Kontro Tarkennusta laatutavoitteisiin, korjauksia. 0.44 14.11.2005 Santeri Saarinen Tarkennuksia ja korjauksia 0.45 24.11.2005 Elina Kontro Testausaikataulupävitetty, korjaksia 0.46 26.11.2005 Elina Kontro Laatutavoitteita korjattu 0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen 0.48 2.12.2005 Santeri Saarinen Lisätty testiraportti, muutettu testiaikataulu testilokiksi, tehty Samuelin katselmoinnissa esittämät muutokset. 0.49 3.12.2005 Santeri Saarinen Lisätty I1:n vaadittuja liitteitä ja tehty muutamia korjauksia 0.50 4.12.2005 Elina Kontro Liitteet korjattu 1
Sisällysluettelo 1 Johdanto...1 1.1 Terminologia ja määritykset 1 2 Laadunvarmistus...2 2.1 Projektin laatutavoitteet 2 2.2 Testaussuunnitelma 2 2.2.1 Testaustasot 2 2.2.2 Testaustyypit 3 2.2.3 Laadunvarmistuksen organisointi 3 2.2.4 Testauksenhallinta 4 2.2.5 Virheidenhallinta 4 2.2.6 Laadunvarmistuksen mittarit 5 2.2.7 Laadunvarmistuksen dokumentit 5 2.3 Testaus 1. iteraatiossa 6 2.3.1 Laatutavoitteet I1 iteraatiossa 6 2.3.2 Testauksen rajaaminen 6 2.3.3 Testaukset ja niiden aikataulu 6 2.3.4 Muut käytännöt 6 2.3.5 Testiraportti 1. iteraatiosta 6 2.4 Testaus I2-iteraatiossa 8 2.5 Muut laadunvarmistuksen menetelmät 8 3 Lähdeluettelo...9 Liitteet...10 1
1 Johdanto Tämä dokumentti on TeamDC -projektiryhmän laadunvarmistussuunnitelma Teknillisen Korkeakoulun kurssilla T- 76.4115 Ohjelmistoprojekti I. Dokumenttia päivitetään koko projektin ajan. 1.1 Terminologia ja määritykset Seuraavassa taulukossa 1 on kuvattu tässä dokumentissa ja projektissa käytettäviä termejä ja lyhenteitä. Taulukko 1. Projektissa käytettäviä lyhenteitä ja terminologiaa Termi tai lyhyenne Kuvaus CoSCA Coordination of Supply Chain Activities CoSCA järjestelmä Tässä projektissa kehitettävä järjestelmä, joka käsittää sekä jo kehitetyn simulaattorin, että siihen kehitettävän käyttöliittymän. CosCA simulaattori HKKK:ssa kehitetty CoSCA simulaattori, jossa ei toistaiseksi ole varsinaista käyttöliittymää. HKKK Helsingin Kauppakorkeakoulu I1 1. Toteutusiteraatio (Implementation 1) I2 2. Toteutusiteraatio (Implementation 2) LOC Lines of Code Koodirivien määrä Management ryhmä Projektin johtoryhmä, johon kuuluvat projektipäällikkö (Elina), vaatimusmäärittelijä (Laura) sekä pääsuunnittelija(kari). NCLOC Lines of code without comments and blank lines Koodirivien määrä, poislukien kommenttirivit ja tyhjät rivit PP Projektisuunnittelu iteraatio Projektiryhmä Projektin toteuttava ryhmä (management ryhmä + suunnittelijat), jossa on seitsemän jäsentä. SEPA Software Engineering Practice Assignment, erillinen projektin ohessa pääasiassa parityönä toteutettava työ Suunnittelijat Projektin 4 jäsentä (Santeri, Samuel, Aleksi ja Vesa), joiden päävastuulla on järjestelmän tekninen suunnittelu, ohjelmointi ja testaus. TKK Teknillinen korkeakoulu XML Extensible Markup Language, tiedostoformaatti 1
2 Laadunvarmistus Laadunvarmistuksen tavoitteena on varmistaa projektin tuotosten laatu eli se, että projektisuunnitelmassa asetetut tavoitteet saavutetaan ja vaatimusmäärittelyn mukaiset vaatimukset tulevat toteutettua. Seuraavissa luvuissa kuvataan projektin laatutavoitteet sekä laadunvarmistukseen käytettäviä menetelmiä. 2.1 Projektin laatutavoitteet Projektissa kehitettävällä tuotteelle on määritelty seuraavat projektitason laatutavoitteet: Tuote täyttää sille vaatimusmäärittelydokumentissa [2] toteutettavaksi sovitut vaatimukset Tuotteessa ei ole kriittisiä virheitä, jotka estäisivät tuotteen käytön. Tuotteen ohjelmakoodin rakenteen tulee olla modulaarinen, noudattaa olio-ohjelmointi periaatteita ja sen tulee olla sovitun koodauskäytönnön mukaisesti kommentoitu, jotta jatkokehitettävyydelle on hyvät edellytykset. Tuotteen ja siihen liittyvän dokumentaation on oltava käytettävyydeltään sellainen, että suunniteltuihin käyttäjäryhmiin kuuluva pystyy sitä käyttämään. 2.2 Testaussuunnitelma Tässä luvussa kuvataan mitä eri testauksen tasoja, testauskäytäntöjä ja muita laadunhallinnan työkaluja projektissa tullaan käyttämään tuotteen laadun varmistamiseksi. 2.2.1 Testaustasot Projektissa tullaan käyttämään seuraavia testaustasoja. Tämän projektin testit suoritetaan neljällä eri tasolla. Yksikkötestaus, jossa tuotteesta testataan metodi- tai luokkatason yksiköitä. Koska tuotteelle asetetut vaatimukset kohdistuvat pääasiassa käyttöliittymään ja sen toimintaan, yksikkötestejä suoritetaan projektissamme rajoitetusti. Integraatiotestaus, jossa testataan uusien toiminnallisuuksien liittämistä ohjelmistoon. Systeemitestaus, jossa testataan tuotetta kokonaisuudessaan siinä laajuudessa, jossa tuote kulloinkin on. Hyväksymistestaus, jossa tuotetta testataan asiakkaan sille asettamia vaatimuksia vasten. Tämä testaus suoritetaan yhteistyössä asiakkaan kanssa. 2
2.2.2 Testaustyypit Ohjelmiston testaus on mahdollista suorittaa montaa eri testaustyyppiä hyväksikäyttäen. Tässä projektissa testauksessa käytetään seuraavia testaustyyppejä: Funktionaalinen testaus, jonka avulla varmistutaan tuotteen vaatimusmäärittelyjen mukaisista toiminnallisista ominaisuuksista. Funktionaalinen testaus aloitetaan mahdollisimman varhaisessa vaiheessa kehitystyötä. Katselmointi, jossa tutkitaan kirjoitettua lähdekoodia. Käytetään vastaavaa käytäntöä kuin dokumenttikatselmoinnissakin [1]. Käytettävyyden arviointi - Käytettävyyden arvioinnin tavoitteena on testata ja parantaa tuotteen käytettävyyttä käyttäjien näkökulmasta. Käytettävyystestaus - Tuotteelle tullaan tekemään kaksi käytettävyystestiä käyttäjien kanssa. Ensimmäinen testi tullaan tekemään I1 iteraation alkupuolella paperiprototyyppiä käyttäen ja toinen toimivalla sovelluksella I1 iteraation lopussa. Tarkemmat kuvaukset testeistä kuvataan Käytetävyydenarvointi SEPAssa[4]. Heuristinen arviointi - Toisena käytettävyyden arvointimenetelmänä käytetään heuristista arviota, joka tullaan tekemään kerran kummassakin iteraatiossa. Tarkemmat kuvaukset testeistä kuvataan Käytetävyydenarvointi SEPAssa[4]. Tuotetun lähdekoodin analysoiminen staattisesti, jonka avulla voidaan osaltaan varmistua lähdekoodin selkeydestä ja luettavuudesta. Tämä testityyppi aloitetaan samaan aikaan itse ohjelmoinnin kanssa ja testien tuloksista raportoidaan viikkopalavereissa. Tutkiva testaus, jossa tuotetta testataan ilman tarkkaa testisuunnitelmaa. Tätä testityyppiä käytetään ensimmäisen ja toisen iteraatiovaiheen lopussa. Vertaistestaus, jonka suorittaa kurssin Neptunus-ryhmä. Tämä testi suoritetaan tutkivan testauksen menetelmin 17.-21.2.2006. 2.2.3 Laadunvarmistuksen organisointi Tuotteen laadunvarmistussuunnitelmasta vastaa erityisesti QA-vastaava, Santeri Saarinen, jonka vastuulla on: Testitapausten suunnitteleminen Laadunvarmistukseen liittyvän dokumentaation pitäminen ajan tasalla Testaamiseen liittyvien työtehtävien organisoiminen ryhmän jäsenille 3
2.2.4 Testauksenhallinta Tuotteen testauksessa noudatetaan seuraavia käytäntöjä: Testikirjanpitoon käytetään excel-taulukoita, jotka pidetään kaikkien ryhmän jäsenten saatavilla ryhmän TikiWikissä. QA-ryhmä luo nämä Excel-taulukot iteraation 1 alussa. Testit luokitellaan aihealueittain testiryhmiin niin, että testiryhmät muodostavat loogisia kokonaisuuksia ja helpottavat testien organisointia sekä suorittamista. Yksikkötestauksesta vastaavat kaikki kehittäjät omien tuottamiensa tai muokkaamiensa lähdekoodien osalta. Tätä testaus suoritetaan ristiintestauksena siten, etteivät kehittäjät testaa omia lähdekoodejaan. Kaikesta muusta testauksesta vastaa QA-ryhmä, erityisesti QA-vastaava. Testitapaukset jaetaan niiden prioriteetin mukaan 3 luokkaan, jossa 1. luokan testit ovat tärkeimpiä. Prioriteettia käytetään hyväksi siten, että eniten testausresursseja keskitetään tärkeimpiin testeihin. 2.2.5 Virheidenhallinta Projektin virheidenhallintaan käytetään kurssin puolesta tarjottua Bugzilla-työkalua seuraavalla tavalla: Bugien raportoinnin Bugzillaan voi suorittaa kuka tahansa ryhmän jäsen löytäessään tuotteesta bugin jota ei heti voida korjata. Havaitun Bugin ilmoittaminen Bugzillaan on pakollista. Bugien vakavuuden luokituksessa käytetään Bugzillan tarjoamista vaihtoehdoista neljää: 1.Blocker, jota käytetään bugeissa jotka estävät testin jatkamisen tai tuotteen kehittämisen. 2.Major, jota käytetään muista vakavista bugeista. 3.Minor, jota käytetään jos bugin vaikutukset ovat vähäisiä mutta tuotteelle esitettyjen vaatimusten vastaisia. 4.Enhancement, jota käytetään jos löydetty bugi ei ole ristiriidassa tuotteen vaatimusten kanssa, mutta sen korjaaminen parantaisi tuotteen toiminnallisuutta. Bugien prioriteetin luokituksessa käytetään vastaavasti kolmea Bugzillan vaihtoehdoista: 1.P1, jos bugi pyritään korjaamaan välittömästi 2.P3, jos bugin korjaaminen voidaan laittaa tavalliseen työjonoon. 3.P5, jos bugin nopea korjaus ei ole tarpeellinen Bugien elinkaari Bugzillassa: 1. Bugin löytäjä asettaa bugin tilaksi aluksi NEW 2. Bugin löytäjä ilmoittaa bugista ko. ohjelman osasta vastaavalle henkilölle, joka asettaa bugin tilaksi ASSIGNED. Tarvittaessa bugin löytäjä konsultoi QA-vastaavaa tai pääsuunnittelijaa löytääkseen bugille vastaavan henkilön bugin korjaamiseen. 3. Kun bugi on korjattu, korjaaja asettaa sen tilaksi RESOLVED. Kun QA-vastaava on vahvistanut että bugi on korjattu, sen tilaksi muutetaan VERIFIED. 4
2.2.6 Laadunvarmistuksen mittarit Laadunvarmistus tarjoaa joukon mittareita, joiden avulla voidaan seurata ja tilastoida tuotteen laadunvarmistuksen tilaa projektin aikana. Tässä projektissa käytetään seuraavia laadunvarmistuksen mittareita: Testauksen kattavuus arvioidaan moduuleittain. Kattavuutta mitataan kolmiportaisella asteikolla 1-3, jossa 1 tarkoittaa hyvin vähäistä testausta ja 3 kattavaa testausta. Bugistatistiikka kootaan ryhmän Bugzillasta. Tässä mittarissa analysoidaan löydettyjen ja korjattujen bugien lisäksi bugien vakavuutta. Laatustatistiikka saadaan lähdekoodille suoritetuista staattisista testeistä. Mitataan ainakin käytettyjen metodien syklomaattista kompleksisuutta (Cyclomatic Complexity Number). Heuristinen arvio käyttäliittymää arvoidaan Nielsenin heuristiikkoja vasten ja havaitut ongelmat luokitellaan tarkemmin SEPA:ssa.[4] Käytettävyystesteissä arvoidaan käyttäliittymän opittavuutta ja miellyttävyyttä, joille määritellään tarkemmat mittarit SEPA:ssa. [4] Dokumenttikatselmoinnit, projektisuunnitelmassa kuvataan dokumentit, joille katselmoinnit tehdään sekä katselmointivastuulliset. 2.2.7 Laadunvarmistuksen dokumentit Laadunvarmistuksen dokumenttien avulla suunnitellaan, toteutetaan ja dokumentoidaan ohjelmiston testausta. Kaikki mainitut dokumentit pidetään ryhmä jäsenten saatavilla TikiWikissä. Dokumenttien päivityksestä vastaa Santeri. Testitapaukset jaettuna loogisiin kokonaisuuksiin testipaketteihin. Testiloki, jossa yksityiskohtaiset tiedot suoritetuista testeistä. Matriisit vastaavat testipaketteja. Testilokit esitetään pääasiassa matriisimuodossa, mutta esimerkiksi käytettävyystestien tulokset voidaan esittää myös tekstidokumentteina. Testiraportti, eli yhteenveto testauksen tuloksista sekä tuotteen laadusta. Vertaistestauksen sessiokuvaukset, joissa yleinen informaatio testauksen suunnasta Vikaraportti, kootaan bugistatistiikasta ja sisältää yhteenvedon tuotteen bugeista ja niiden korjaamisesta. Katselmointidokumentaatio, joita ovat mahdollisten katselmointipalavereiden pöytäkirjat sekä kevyessä katselmoinnissa sähköpostitse lähetetyt kommentit. 5
2.3 Testaus 1. iteraatiossa Seuraavissa kappaleissa kuvataan 1. Toteutusiteraation, I1, testausuunnitelmaa. 2.3.1 Laatutavoitteet I1 iteraatiossa Laatutavoitteena I1-iteraatiossa ovat Ohjelmaversiossa ei ole yhtään sellaista avointa virhettä, joka estäisi vaatimusten mukaisen käytön iteraation lopussa, Laatusuunnitelma on dokumentoitu I1 iteraation testaussuunnitelma dokumentoitu. 2.3.2 Testauksen rajaaminen Testiympäristönä toimii ainoastaan Windows XP ja JRE 5.0 Vanhaan CoSCA-simulaattoriin tehtäviä muutoksia ei testata. Mahdollisista vanhasta simulaattorista löydetyistä bugeista informoidaan Lauri Svania. Tuotteen testaamisessa painotetaan systeemitestausta. Yksikkötestausta suoritetaan ohjelmiston facade-luokille ja integraatiotestaus suoritetaan samanaikaisesti systeemitestauksessa. Automatisoituja testejä ei tehdä, poislukien JUnitilla tehtävät yksikkötestit 2.3.3 Testaukset ja niiden aikataulu 1. iteraation aikana suoritetun testauksen aikataulu selviää liitteenä olevasta testilokista. 2.3.4 Muut käytännöt QA-vastaava huolehtii testipakettien ja testien kuvausten luomisesta ryhmän TikiWikiin vuorokautta ennen ko. testien alkua. Varsinaisia regressio- tai smoke-testejä ei tehdä, mutta testipaketteja suoritetaan uudelleen mahdollisten bugikorjausten jälkeen. 2.3.5 Testiraportti 1. iteraatiosta 1. iteraation testauksessa suoritettiin seuraavat testit: Lähdekoodin staattinen analysointi viikon välein ohjelmoinnin aikana, yhteensä 3 kertaa. 6
Facade-luokkien Junit-yksikkötestaus Käyttöliittymän käytettävyystestaus Käyttöliittymän kautta toteutettu systemaattinen funktionaalinen systeemitestaus. Käyttöliittymän kautta toteutettu tutkiva testaus Kaikki testit suoritettiin hyväksytysti, eikä testauksen aikana löydetty ainoatakaan kriittistä bugia. Yhteensä testauksen aikana löydettiin 10 bugia, joista saatiin korjattua 5. Jäljelle jääneet bugit jakautuvat ohjelman komponenttien ja vakavuuden mukaan seuraavasti (löydetty bugien määrä suluissa): Komponentti Major Minor Enhancement Yhteensä GUI 1 (3) 3 (4) 4 Faceda-luokat 1 (1) 1 Yhteensä 1 1 3 5 Ainoata löydettyä Major-luokan bugia ei pystytty korjaamaan 1. iteraation aikana, mutta kyseinen bugi ei estä ohjelman ajamista vaan ainoastaan antaa harhaanjohtavaa tietoa käyttäjälle simulaatioajon aikana. Bugilla ei myöskään ole vaikutusta simulaatioajon lopputuloksiin. Muutkaan bugit eivät ole niin vakavia, että aiheuttaisivat laatuongelmia 1. iteraatiossa tuotetulle ohjelmistolle. Iteraation testaus painottui jonkinverran käyttöliittymän puolelle, joka voitiinkin testata todella perusteellisesti. Facade-luokkien systeemitestaus suoritettiin käyttöliittymän kautta, jolloin niiden testauksen kattavuudesta ei voida olla yhtä varmoja. Suurin haaste facade-luokkien testauksessa on niiden oikean toiminnan varmistaminen, sillä työryhmän jäsenet eivät ole alan asiantuntijoita, eivätkä siten pysty varmistamaan että simulaatio tuottaa oikeita tuloksia suhteessa sille syötettyyn tietoon. Käytettävyystestissä mitattiin opittavuutta ja miellyttävyyttä. Opittavuuden osalta testeissä saavutettiin paras mahdollinen taso ja miellyttävyyden osalta tavoitetaso. Testikäyttäjille epäselvyyttä aiheutti lähinnä käytety lyhenteet ja osa termeistä. Osa ongelmast aon nyt ratkaistu ns. tool tippien avulla, eli kun kursori on lyhenteen päällä, tulee näkyviin tooll tip teksti, jossa lyhenne on kirjoitettu auki. Muutoinkin termistöön ja sen oikeellisuuteen tulee jatkossa kiinnitää huomiota. Lisätietoja käytettävyystesteistä löytyy omasta SEPApäiväkirjasta [4]. Lähdekoodin staattisessa analysoinnissa havaittiin yksittäisiä ongelmia luokkien kompleksisuuden vuoksi. Muutamaa poikkeusta lukuunottamatta ohjelmiston luokat ovat kuitenkin käytetyn kehitysympäristön (Together Architect) suosittelemien metriikkojen raja-arvojen sisäpuolella ja mitattujen metriikoiden osalta ohjelmiston laatu on vähintään yhtä hyvää, kuin valmiissa simulaattorin luokissakin. Lisätietoja metriikoista löytyy omasta SEPA-päiväkirjasta [3]. 7
2.4 Testaus I2-iteraatiossa Mitä testataan/mitä ei Mitä ja miten käytäntöjä käytetään Testien priorisointi Kuinka usein ja milloin tietyt testit suoritetaan Tehtävät ja aikataulu (resurssit ja vastuut, tuotokset) 2.5 Muut laadunvarmistuksen menetelmät Koodauskäytäntö, jossa kaikki tuotettu lähdekoodi kirjoitetaan ja kommentoidaan projektisuunnitelmassa määritellyllä tavalla. Dokumenttikatselmoinnit suoritetaan projektisuunnitelmassa kuvatulla tavalla. Tällä varmistetaan tuotetun dokumentaation laatu. 8
3 Lähdeluettelo [1]TeamDC. CoSCA Simulaattorin jatkokehitysprojektin Projektisuunnitelma v.1.0 (2005) [2]TeamDC. CoSCA-Vaatimusmäärittely v.1.3 (2005) [3] Saarinen, Santeri. SEPA päiväkirja: Staattiset Menetelmät(2005 ) [4] Airola, Aleksi Haukkavaara, Vesa Kontro, Elina. SEPA päiväkirja: Käytettävyyden arviointi (2005) [5] Bach, James. Good Enough Quality Beoynd the Buzzword. IEEE Computer (1997) vol. 30, no. 8, pp. 96-98. [6]Nielsen, Jakob. Usability Engineering. AP Professional, Boston (1993) [7] Svan, Lauri. CoSCA -Tekninen määrittely v.0.4 (2005) 9
Liitteet [1] I1-iteraation testiloki [2] I1-iteraation testitapaukset [3] I1-iteraation bugien yhteenveto 10
Liite 1 I1 iteraation testiloki 1. iteraatio Testitapa Kohde Testitapaukset Tekijä Aika/h Testin tulos Suoritettu Käytettävyystesti Ryhmäläpikäynti Käyttöliittymäproto Elina, Aleksi, Vesa 9 31.10.2005 Lähdekoodin analysointi Staattinen analyysi koko lähdekoodi Santeri 1 Hyväksytty, ei bugeja 14.11.2005 Lähdekoodin analysointi Staattinen analyysi koko lähdekoodi Santeri 1 Hyväksytty, löydetty bugit 3 ja 4 21.11.2005 yksikkötason testaus Yksikkötesti (Junit) Facade-luokat Kari 5 Jatkuva testaus Systeemitestaus Systemaattinen testaus Koko ohjelma I 1.1 - I 1.8 Elina 4,5 Hyväksytty, löydetty bugit 5, 6, 7 ja 8 29.11.2005 Systeemitestaus Tutkiva testaus Koko ohjelma ET I1-1.1 ja ET I1-1.2 Santeri 5 Hyväksytty, löydetty bugit 10, 11 ja 12 1.12.2005 Lähdekoodin analysointi Staattinen analyysi koko lähdekoodi Santeri 1 29.11.2005 Käytettävyyden arvionti Heuristinen arvio Käyttöliittymä Aleksi, Elina 4 5.12.2005 Käytettävyyden arvionti Käytettävyystesti Käyttöliittymä Vesa, Elina 4 8.12.2005 1
Liite 2 I1 iteraation testitapaukset Testitapaukset Use cases TestitapauksetPri Kuvaus Syötteet Odotetut tulokset I1 I1.1 1sulkeminen Ohjelman käynnistäminen ja Käynnistä ja sulje ohjelma ohjeen mukaisesti Ohjelman käynnistys ja sulkeminen onnistuu UC1.1, UC2.1, UC3.1, UC4.1, UC5.1 I1.2 1 Simuloitavan systeemin määrittämien Wizardin avulla Valitse erilaisia kombinaatiota wizardin tarjoamista esimerkkivaihtoehdoista Valinnat onnistuvat ja niiden mukainen systeemi näkyy sekä kuvana että puurakenteena wizardin sulkeuduttua. I1 I1 UC1.1, UC2.1, UC3.1, UC4.1, UC5.1 I1.3 2 Wizardissa liikkuminen ja valintojen vaihtaminen Liiku Wizardissa edestakaisin Back ja Next napeilla. Vaihda tehtyjä valintoja. Liikkuminen onnistuu silloin kun se on sallittua ja valintoja voi muuttaa. I1 UC5.1 I1.4 1 Aikajänteen määrittäminen Käytä aikajänteen (time frame) määrittämiseen negatiivisia tai muutoin epärealistisia syötteitä. Sovellus antaa virheilmoituksen Määritä raportointivälit siten, ettei sopimattomista valinnoista eikä "kaadu" aikajänne oli sillä jaollinen (esim 5 ja 2) 2
Liite 2 I1 iteraation testitapaukset Testitapaukset Use cases TestitapauksetPri Kuvaus Syötteet Odotetut tulokset I1 UC7.1, UC7.3 I1.5 1 Määritellyn simulaation ajaminen Simulaatioajon hallinta painikkeilla. Aja simulaatiota osissa ja kokonaan Simulaatio ajaminen sekä osissa että kokonaan onnistuu I1 UC5.1 I1.6 1 Päätösäännön vaihtaminen välitarkastuspisteessä Vaihda päätössääntöjä välitarkastuspisteessä ja jatka ajoa Päätössääntöjen vaihtaminen onnistuu ja ajonjatkaminen on mahdollista. Tarkastele simulaation tuloksia sekä Tulosten tarkastelu onnistuu sekä ajon UC6.1, UC6.2 1 Ajetun simulaation tulosten tarkasteluvälitarkastuspisteissä että lopussa, että valituissa I1 I1.7 simulaation lopussa. välitarkastuspisteissä I1 I1.8 2 Toimintojen käyttö valikosta Kokeile valikossa tarjolla olevia toimintoja Valittavissa olevat toiminnot toimivat ET ET-I1.1 1 Charterin (ET_Charter1.doc) mukainen tutkiva testaus ET ET-I1.2 1 Charterin (ET_Charter2.doc) mukainen tutkiva testaus 3
Liite 3 I1-iteraation bugien yhteenveto bug_id bug_severity priority rep_platform assigned_to bug_status resolution short_short_desc 3 enhancement P5 PC tpsaarin@cc.hut.fi ASSIGNED DAC-value too high in the SimulatioFrame-class 4 enhancement P5 PC tpsaarin@cc.hut.fi VERIFIED FIXED Metric value WMPC1 is too high for ResourceObjectFacade 5 enhancement P3 PC tpsaarin@cc.hut.fi NEW Tulosikkunassa sliderin teksti epäselvää, jos paljon välipisteitä 6 minor P1 PC tpsaarin@cc.hut.fi VERIFIED FIXED Open parent -painike edelleen näkyvissä 7 major P5 PC tpsaarin@cc.hut.fi NEW Information-ikkuna jaa nakyviin 8 enhancement P5 PC tpsaarin@cc.hut.fi VERIFIED FIXED Tulosten katselu lista-isommaksi 9 enhancement P5 PC tpsaarin@cc.hut.fi ASSIGNED Response for class-value in SimulationFrame is 105 10 minor P3 PC vthaukka@cc.hut.fi VERIFIED FIXED View-valikko ei toimi odotetusti 11 minor P3 PC tpsaarin@cc.hut.fi VERIFIED FIXED Tools-valikon komennot toimivat vain ensimmäisessä simulaatioajossa. 12 minor P3 PC tpsaarin@cc.hut.fi RESOLVED DUPLICATE Jos simulaatiotion ajon aloittaa tools-valikosta, "simulation running"-ikkuna jää näkyviin. 13 minor P1 PC tpsaarin@cc.hut.fi NEW Onko kuormitusaste oikein 1