Hirviö Vertaistestausraportti

Transkriptio

1 Hirviö Vertaistestausraportti Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 8. maaliskuuta

2 Sisältö 1 Johdanto 3 2 Testauksen kattavuus Käytetyt resurssit Testauksen painopiste Testauksen tulokset 3 4 Arviointi Malliperheen omien laadullisten tavoitteiden täyttyminen Asiakkaan tavoitteiden täyttyminen Vertaistestausryhmän arvio Havaitut ongelmat 5 2

3 1 Johdanto Vertaistestauksessa testauksen kohteena oli Malliperheen Kumbang-mallinnustyökalu. Testausmenetelmänä käytettiin Session Based Test Management -menetelmää, johon liittyen Malliperhe toimitti kaksi test session charter -lomaketta. Nämä lomakkeet määrittelivät testauksen painopisteen. Testauksen kohdetta testattiin ja analysoitiin teknologiademona. Tästä johtuen tuote sisälsi paljon ominaisuuksia, jotka olisi katsottu vioiksi lopullista tuotetta arvioitaessa. Hirviöryhmällä ei ollut kuitenkaan käytössä mitään laatukriteereitä, joiden perusteella ryhmä olisi voinut arvioida tuotteen laatua teknologiademona. Tästä johtuen tässä dokumentissa testauksen kohdetta on pyritty arvioimaan asiakkaan näkökulmasta vaatimusmäärittelyssä esitettyjä asiakkaan tavoitteita (business goal) hyväksi käyttäen, sekä kehittäjien näkökulmasta laadunvarmistussuunnitelman laatukriteereitä hyväksi käyttäen. Tämän vuoksi Malliperheen tulee tulkita tätä raporttia kriittisesti, ja päättää itse mitkä esitetyistä ongelmista voidaan laskea teknologiademon ominaisuuksiksi ja mitkä varsinaisiksi vioiksi. 2 Testauksen kattavuus 2.1 Käytetyt resurssit Vertaistestaukseen osallistui neljä testaajaa Hirviö-ryhmästä, sekä yksi ohjaaja Malliperheestä. Testaus järjestettiin yksittäisenä kaksi tuntia kestäneenä tilaisuutena, jolloin testaajien käyttämä kokonaisaika oli vaadittu ja suunniteltu 8 tuntia. 2.2 Testauksen painopiste Malliperhe toimitti testaajille etukäteen kaksi test session charter -lomaketta, joita molempia suoritti kaksi testaajaa. Test session charter -lomakkeet olivat: General Test Session charter - yleinen charter, jossa painopisteenä on sovelluksen ydintoiminnallisuuden testaaminen käyttäjän näkökulmasta. Reading Model Test Session Charter - charter, jossa painopisteenä on ominaisuus, jota käyttäen malleja ladattiin sovellukseen. Molempien lomakkeiden suorittamiseen käytettiin yhteensä 4 työtuntia. (tarkempi erittely lomakkeissa). Testaus keskittyi yleisen toiminnallisuuden testaukseen (lataus / tallennus / muokkaus) sekä käyttöliittymän virheiden etsimiseen. Varsinainen aihealue, kumbang-kieli ja sovelluskonfiguraatioit eivät olleet testaajille tuttuja (eikä niiden opetteluun ollut mahdollista käyttää aikaa varatun ajan puitteissa), joten niiden toimivuutta ei voitu varmistaa. Tämän vuoksi vertaistestaus ei kattanut varsinaista ydintoiminnallisuutta kovin laajasti. 3 Testauksen tulokset Testauksen kulku on esitetty vastaavissa test session charter -lomakkeissa. Havaitut ongelmat on esitetty dokumentin lopussa. 3

4 4 Arviointi Tuotetta on arvioitu vaatimusmäärittelyssä esitettyjen business goalien perusteella, sekä laadunvalvontasuunnitelmassa iteraatiolle I2 (FD-suunnitelmaa ei ollut saatavissa) asetettujen tavoitteiden (kappaleen 4. alku) suhteen. 4.1 Malliperheen omien laadullisten tavoitteiden täyttyminen Testauksen kohde ei täytä iteraation 2 päätteeksi asetettuja tavoitteita hyvälle laadulle. Asetetut tavoitteet eivät salli yhtään avointa kriittistä bugia, mutta jo Malliperheen itsensä toimittama lista avoimista vioista sisältää kaksi blocker-tason vikaa, kaksi critical-tason vikaa, sakä yhden major-tason vian. Malliperheen omien laadullisten tavoitteiden täyttyminen vaatii vielä melko paljon työtä. 4.2 Asiakkaan tavoitteiden täyttyminen Vertaistestauksen puitteissa oli mahdollista arvioida ainoastaan vaatimusmäärittelyssä esitettyjä asiakkaan tavoitteita (business goal) CG1, CG5, CG6, CG7 ja CG8. CG1 - Kumbang-kielellä luotuja malleja voidaan ladata sovellukseen: Malleja on mahdollista ladata sovellukseen, joskin sovellus toimii vain täysin valideilla tiedostoilla. Tämä tavoitteen saavuttaminen on hyvin lähellä. CG5 - Mahdollisuus luoda mallin perustyyppejä, komponetteja sekä ominaisuuksia: Tämä on saavutettu osittain, ominaisuuksia (properties) ei testikappaleessa ollut vielä mahdollista asettaa. Tämän tavoitteen saavuttaminen vaatii vielä jonkin verran työtä. CG6 - Käyttäjä voi luoda konfiguraation käyttäen sovellusta: Tämän tavoitteen tilanne on testaajille epäselvä. Esitelymielessä konfiguraation luominen todennäköisesti onnistuu, todellisen konfiguraation luominen ei puutteista johtuen onnistu. CG7 - Käyttäjä voi tallentaa luomansa mallin: Tämä tavoite on saavutettu osittain, suuri osa muutoksista ei vielä tallennu. Tämän tavoitteen saavuttaminen vaatinee vielä kohtuullisen määrän työtä. CG8 - Selkeä käyttöliittymä: Käyttöliittymässä on vielä paljon puutteita, epäloogisuuksia sekä virheitä (joista osa voidaan kyllä laskea teknologiademon ominaisuuksiksi). Tavoitteen evaluointikriteeriksi on mainittu heuristisessa arvioinnissa löydetyttyjen virheiden määrä. Tätä ei tulla todennäköisesti saavuttamaan tämän kurssin puitteissa. Asiakkaan tavoitteet täyttyvät välttävästi. Tätä on mahdollista parantaa korjaamalla osa esitetyistä ongelmista. 4.3 Vertaistestausryhmän arvio Kirjattuja ongelmia on yhteensä 23, joka tarkoittaa noin 3 havaittua ja kirjattua vikaa tunnissa (todellisuudessa enemmän, koska kaikkea käytössä ollutta aikaa ei käytetty varsinaiseen testaukseen). Ottaen huomioon testauksen suppeuden voidaan olettaa, että vikoja löytyisi tarkemmassa testauksessa lisää. Jos Malliperheen tavoitteena on tarjota asiakkaalle laadultaan hyvä, mutta toiminnallisuudeltaan suppea tuote, on testausta ehdottomasti jatkettava lisää. Sovelluksessa on vielä selkeästi vakavia ongelmia jotka tulisi ratkaista. 4

5 5 Havaitut ongelmat Testaajilla ei ollut käytössä ohjeistusta vikojen raportointiin (tilaisuudessa raportoitiin osa vioista suoraan ohjaajalle, joka kirjasi ne itse ryhmän käyttämällä tavalla), eikä laatukriteereitä joiden perusteella vikojen vakavuutta olisi voitu arvioida. Näiden seikkojen vuoksi havaitut ongelmat on listattuna alla sanallisesti ja niiden tarkempi analyysi (hyväksyminen / hylkääminen, vakavuusaste) jätetään Malliperheelle. 1. Jos ladattava tiedosto ei ole validia Kumbang-kieltä, siitä ei ilmoiteta millään tavoin. Tästä aiheutuu se, että yksittäisiä syntaksivirheitä on erittäin vaikea havaita. 2. Jos ladataan tiedosto, joka ei sisällä validia Kumbang-kieltä, tree view sisältää edellisen validin tiedoston sisällön. 3. Äärettömät silmukat komponettien ja osien (components, parts) välillä ovat mahdollisia. 4. Muutokset puunäkymissä eivät näy koodissa, ellei mallia tallenneta ja ladata uudelleen. 5. Sovellus sallii komponettien lisäilyn vääriin haaroihin puunäkymissä (esimerkiksi featureja components-haaraan). Tämä rikkoo koodin ja estää tallentamisen, mutta ei kuitenkaan varoita tästä millään tavoin lisäysvaiheessa. 6. Jos luodaan interface ja annetaan sille jo olemassaolevan interfacen nimi, vanha interface tulee korvatuksi. Tästä ei varoiteta millään tavoin. 7. Koodiin ei ole mahdollista lisätä kommentteja. Lisätyt kommentit poistetaan tallennuksen yhteydessä 8. Diagram View päivittyy vain mallitiedoston uudelleen avauksen jälkeen 9. Jos vaaditaan eri rajapintoja samalla nimellä, Diagram View on tyhjä 10. Jos mallitiedostossa on komponentin sisällä samannimisiä komponentteja, Diagram View eikä Tree View mallinna tiedostoa. 11. Jos mallitiedostossa on määrittelemättömiä rajapintoja, Diagram ja Tree View ovat tyhjiä, eikä virheilmoitusta virheen paikasta ilmoiteta. Tällöin virhettä on vaikea paikallistaa, jos mallitiedosto on pitkä. 12. Jos ruudulla on suuri määrä osia (part), osa niistä menee piirtoruudun ulkopuolelle käyttäjän ulottumattomiin. 13. Virhelokiin ei tullut testien aikana ilmoituksia yhdestäkään virheestä. 14. Ominaisuuden uudelleen nimeäminen ei aina toiminut toivotulla tavalla. Jos ominaisuuden nimesi Type Tree View ssä (TTV), ei muutos aina propagoitunut Structure Type View iin (STV). Bugin toistaminen ei onnistunut joka kerta. Jos epäonnistuneen nimeämisen jälkeen yritti nimeämistä uudelleen TTV:ssä, heitti ohjelma joka kerta poikkeuksen. 15. Mikäli osaan (part) yrittää lisätä komponentin tai ominaisuuden, jota ei ole olemassa, tai jättää lisäysrivin tyhjäksi, ilmestyy osaan RootOfAllThings. 16. Viimeisen komponentin tai ominaisuuden poisto osasta johti RootOfAllThingsin ilmestymiseen, mikäli poisto tehtiin osan ominaisuusikkunan kautta. 17. Jos lisätään elementti type tree view:n kautta ja suljetaan malli, sovellus ei kysy halutaanko muutos tallentaa (ei tallenna). 18. Jos puunäkymästä poistetaan komponetti ja tämän jälkeen käytetään rename-toimintoa, sovellus aiheuttaa poikkeuksen 19. Juurielementin poistoyritys puunäkymässä aiheuttaa unexpected error -virheilmoituksen. 5

6 20. Elementin uudelleen nimeäminen puunäkymästä ei säily tallentamisen (ja lataamisen) jälkeen. 21. Diagramminäkymä päivittyy vasta mallin tallentamisen ja lataamisen jälkeen. 22. Koodinäkymän tulisi näyttää puunäkymästä valittu elementti (tai tähän olisi oltava mahdollisuus, esimerkiksi Java-näkymässä koodista näytetään aina valittu luokka/metodi/muuttuja) 23. Diagramminäkymää on hankala käyttää. Käyttäjälle ei ole selvää mihin hän voi vaikuttaa, ja millä tavoin. 6