Testausraportti v1.0. HOHTO - Henkilöstön osaamisen hallinnan työkalu

Transkriptio

1 Tampere University of Technology Department of Pervasive Computing TIE Project Work on Pervasive Systems Mahtirojekti (4) HOHTO - Henkilöstön osaamisen hallinnan työkalu Testausraportti v1.0 Jussi Tuurinkoski: Taina Peltonen: Juho Teperi: Oskari Ruutiainen: Niko Junkala:

2 Version history Version Date Author Description Matti Vuori First draft Outi Sievi-Korte Styling Tensu Tuurinkoski, Peltonen Header and footer fine-tuning Ensimmäinen versio Tuurinkoski Kappale Tuurinkoski Peltonen Tuurinkoski Tuurinkoski Kappale 4 Kappale 3 Kappaleet 5 ja 6 Johdanto ja oikoluku 2/8

3 Sisällys 1 Johdanto Testauksen yleinen kuvaus Matalan tason testaaminen (yksikkö- ja integraatiotestaus) Vaatimusten testaaminen Toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset Käyttökokemus ja käytettävyys Tietoturva Suorituskyky Luotettavuus Vikalista Yhteenveto tuotteen laadusta... 6 Viitteet... 7 LIITTEET /8

4 1 Johdanto Tämän dokumentin tarkoituksena on kuvata testauksen eri vaiheita projektissa. Luvuissa käydään läpi yleinen kuvaus testausmenetelmistä, mitä testattiin ja missä vaiheessa. Testausraportin liitteissä on lisäksi markdown-tiedosto, joka tarjoaa listan keskeneräisistä toiminnallisuuksista, joita ei ehditty toteuttaa tai testata halutulla tavalla. 2 Testauksen yleinen kuvaus Tuotteen testaamisen voisi jakaa seuraaviin osa-alueisiin projektissamme: yksikkötestaaminen implementointivaiheessa koodin tekijän toimesta, yksikkötestaaminen automaattitestien avulla, e2e-testaaminen sekä automaattitestein että manuaalisesti, järjestelmän toiminallinen testaaminen manuaalisesti pilvipalveluun ladatulla julkaisulla sekä käytettävyystestaaminen pilvipalvelujulkaisun avulla. Testausvastuu jakautui ryhmän sisällä siten, että jokainen vastasi omasta koodistaan, ja automaattitestit toimivat regressiotestauksen työkaluna. Järjestelmän toiminnallinen testaaminen toteutettiin tutkivana testaamisena, josta vastasi pääasiassa Jussi Tuurinkoski. Toiminnot käytiin läpi yksitellen kokeilemalla eri skenaarioita, joista muodostettiin testausloki. Lokin pohjaa käyttämällä testit toteutettiin uudelleen jokaisen uuden julkaisun jälkeen. Ensimmäinen koko järjestelmän toiminnallinen testaus suoritettiin Käytettävyystestaukseen osallistui koko Mahtirojekti-ryhmä ja lisäksi yhdeksän henkeä asiakkaan puolesta. Pilvipalveluun ladatun julkaisun testaamisessa käytettiin itse populoitua tietokantaa, joka sisälsi valmiit listat esimerkkikäyttäjistä, -taidoista, -projekteista ja ryhmistä. Tämän lisäksi käyttäjät pystyivät itse rekisteröitymään palveluun ja näin tekemään oman tunnuksen. Lisäksi taitoja, projekteja ja ryhmiä pystyi lisäämään, muokkaamaan ja poistamaan toiminnallisen määrittelyn mukaisesti[1]. Populoitu tietokanta helpotti testaamista valmiiksi löytyvän datan ansiosta. Samalla saatiin varmistus siitä, miten järjestelmä toimii tuotantoa vastaavalla tietomäärällä, kun käyttäjiä ja muita instansseja löytyy useita kymmeniä. 3 Matalan tason testaaminen (yksikkö- ja integraatiotestaus) Backendin malleille kirjoitettiin yksikkötestit[3] käyttäen Mochaa. Mocha on JavaScript testikehys, joka pyörii node.js-alustalla. Mochan kanssa käytettiin Chai-kirjastoa ja sen Should-rajapintaa väitteiden kirjoittamiseen. Testeillä testattiin, että malleihin voisi tallentaa vain oikeellista tietoa ja että niiden poistaminen ja päivittäminen toimisi. Yksikkötestit ajettiin uuden ominaisuuden lisäämisen tai korjauksen jälkeen. Automaattisia yksikkötestejä ei tehty muille kuin malleille, ja niistä pois lukien accesstoken.js, auth.js, imgs.js, log.js, recoverytoken.js, role.js, tag.js, usergroup.js, userproject.js ja userskillproject.js. E2e-testit[4] tehtiin Mochalla. Niissä testattiin tietokannan tyhjentämistä, rekisteröitymistä ja kirjautumista. Muita testejä ei kirjoitettu automaattisiksi, vaan jokainen testasi aina manuaalisesti omista lisäyksistään, että uudet asiat näyttävät toimivan järjestelmässä ja eivät riko vanhoja, ennen kuin lisäsi muutokset yhteiseen tietovarastoon. Lisäksi testauksessa käytettiin avuksi http-asiakasohjelmaa nimeltä 4/8

5 Postman, jolla pystyttiin tekemään helposti pyyntöjä ja näkemään, että vastaus on halutunlainen. 4 Vaatimusten testaaminen Vaatimusten testaaminen jaettiin kahteen kategoriaan: toiminnallisten ja eitoiminnallisten vaatimuksien testaamiseen. Toiminnalliset vaatimukset löytyvät HOHTO:n määrittelydokumentista[1]. Ei-toiminnallisten vaatimusten testaaminen kattoi laatuvaatimusten[1] testaamisen. 4.1 Toiminnalliset vaatimukset Toiminnallisten vaatimusten testaaminen toteutettiin tutkivana testaamisena. Testauskohteena oli aina uusin julkaisu, joka oli ladattuna Heroku-pilvipalveluun. Testidatana käytettiin valmiiksi populoitua tietokantaa ja testaamisen yhteydessä annettuja syötteitä testiskenaariosta riippuen. HOHTO:n toiminnot käytiin läpi näkymä kerrallaan testauslokin[2] mukaisesti. Testauslokit tarjoavat tarkemman kuvan siitä, mitä toiminnallisella puolella testattiin ja miten työ eteni testaamisen alkuvaiheista loppuun saakka. 4.2 Ei-toiminnalliset vaatimukset Ei-toiminnallisten vaatimusten testaaminen kattoi määrittelydokumentissa mainittujen laatuvaatimuksien testaamisen. Näitä olivat käytettävyys, tietoturva, suorituskyky sekä luotettavuus. Kaikkien näiden osa-alueiden testaaminen toteutettiin käyttöliittymän kautta järjestelmätasolla Käyttökokemus ja käytettävyys Käyttökokemusta ja käytettävyyttä testattiin heti ensimmäisistä versioista lähtien. Kehityksen luonne oli ketterää ja muutoksia tehtiin lähes päivittäin. Viikkopalavereissa tehtiin pääasiallinen suunnittelutyö käyttöllittymästä, joka kehittyi nykyiseen muotoonsa useiden iteraatioiden kautta. Palautetta saatiin myös asiakkaalta jokaisessa asiakastapaamisessa. Tammikuun päivinä suoritettiin myös erillinen käytettävyystestaus, johon osallistui yhdeksän Goforen työntekijää. Kommentit olivat arvokkaita, mutta julkaistu versio oli paikoittain hyvin buginen, mikä vaikutti negatiivisesti testauskokemukseen eikä käyttäjä selvästi pystynyt keskittymään vain ja ainoastaan käytettävyysratkaisujen testaamiseen. Tämä oli selvästi osa-alue, jonka olisi jälkeenpäin voinut suorittaa paremmin. Tammikuu ajanjaksona oli aivan liian lyhyt, joten lopullisempi versio olisi pitänyt olla jo joulukuun loppuun mennessä julkaistuna ja käytettävyystestaus suorittaa ainakin viikkoa aiemmin, jotta kaikkiin seikkoihin olisi ehditty reagoida. Järjestetyn käytettävyystestauksen jälkeen ehdittiin kuitenkin tehdä vielä useita uusia suunnitteluratkaisuja ja toteuttaa ne, ja muutos olikin huomattava viimeisen puolentoista viikon aikana. Merkittävimmät muutokset koskivat kuvan lataamista profiileihin sekä varmistusdialogeja taitojen, avainsanojen ja projektiroolien yhdistämisessä. 5/8

6 4.2.2 Tietoturva Tietoturvan testaaminen keskittyi siihen, että tietokanta ei päästä tietoa rajapinnan läpi ilman asianmukaista pääsyä (accesstoken). Tämä koski lähinnä testitapauksia, joilla yritettiin saada salasanoja tai päästä tiloihin muokkaamalla osoitekenttää. Määrittelyvaiheessa todettiin, että käyttäjäryhmille ei ole tarvetta, joten jokainen käyttäjä on kykenevä tekemään muutoksia myös muiden henkilöiden profiileihin. Tätä toimintamallia ei nähdä ongelmallisena, sillä kaikista muutoksista jää kuitenkin aina jälki järjestelmälokiin Suorituskyky HOHTO:n suorituskykyä ei testattu erillisillä työkaluilla. Kuormitusta ja suorituskykyä on testattu valmiiksi populoidulla tietokannalla, joka sisälsi yli sata käyttäjää, kymmeniä taitoja ja muutaman projektin. Järjestelmän käyttö perustuu kuitenkin yksinkertaisiin sivuston eri näkymien latauksiin eikä suuria tietomääriä käsitellä kerrallaan missään päin palvelua Luotettavuus Palvelun luotettavuuden testaaminen kulki rinnalla muun järjestelmätestauksen kanssa. Luotettavuutta arvioitiin testauksen aikana havainnoimalla mahdollisia vikatiloja. Toiminnallisen testauksen aikana HOHTO ei mennyt perätilaan yhdenkään testauskerran aikana. Myös kaikki käyttöliittymän kautta oikeellisessa muodossa syötetty tieto tallentui aina tietokantaan. 5 Vikalista Tarkempi listaus tiedostetuista vioista löytyy liitteenä olevasta ZIP-paketista (vikalista.md). Viat ovat luonteeltaan pääasiassa kosmeettisia eivätkä näin vaikuta palvelun toimivuuteen. 6 Yhteenveto tuotteen laadusta Testauksen perusteella HOHTO ei sisällä merkittäviä bugeja toiminnallisella puolella ja täyttää laatuvaatimukset. Ennen tuotantoon vientiä Goforen tulee asettaa omat konfiguraatiot järjestelmään koskien esimerkiksi asianmukaista salasanakäytäntöä ja rekisteröitymisessä sallittuja sähköpostiosoitteita. Muilta osin palvelu on valmis tuotantoon. Tarkemmat yksityiskohdat käydään läpi asiakkaan kanssa ja tarvittava ohjeistus luovutetaan myös kirjallisena ylläpitodokumentin muodossa. 6/8

7 Viitteet [1] HOHTO Määrittelydokumentti ver Viitattu Saatavilla: [2] HOHTO Testauslokit. Viitattu Saatavilla: ZIP-paketti liitteenä. [3] HOHTO Backend yksikkötestit. Viitattu Saatavilla: ZIP-paketti liitteenä. [4] HOHTO E2E-testit. Viitattu Saatavilla: ZIP-paketti liitteenä. 7/8

8 LIITTEET 1. ZIP-paketti, joka sisältää järjestelmätestauksen testauslokit, käytettävyystestauksen palautteiden yhteenvedon, backendin yksikkötestit, e2e-testit sekä vikalistan. 8/8