Hirviö Laadunvarmistussuunnitelma

Transkriptio

1 Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 30. marraskuuta

2 Sisältö 1 Johdanto Testauksen tavoitteet ja laajuus Implementaatiokierros Viittaukset muihin dokumentteihin Testauksen kohde Testattavat ominaisuudet Implementaatiokierros Ominaisuudet joita ei testata Implementaatiokierros Testauslähestymistavat Testausmenetelmät Yksikkötestaus Integraatiotestaus Systeemitestaus Hyväksymistestaus Regressiotestaus Katselmoinnit Käyttöliittymän heuristinen arviointi Testaustyökalut Testitapausten hallinta ja dokumentointi Vikojen hallinta ja dokumentointi Etenemisen seuranta ja mittarit Testidata ja aineistot Testien läpäisy- ja hylkäyskriteerit Testauksen keskeytys- ja uudelleenaloituskriteerit Testauksen lopetuskriteerit Resurssit Vastuut ja henkilöstö Testausympäristö Tehtävät ja aikataulu Testaustehtävät Implementaatiokierros Aikataulu Tuotokset

3 1 Johdanto Tässä laadunvarmistussuunnitelmassa kuvataan testaus- ja laadunvalvontamenetelmät, joita käytetään Hirviö-järjestelmän kehityksessä. Jokaiselle implementaatiokierrokselle eritellään järjestelmän testattavat ominaisuudet, resurssit, testauksen tavoitteet sekä tehtävät ja aikataulut. 1.1 Testauksen tavoitteet ja laajuus Testauksen tavoitteena on jokaisella kierroksella taata asiakkaalle toimitettavan järjestelmän ja vaatimusten vastaavuus, löytää ja ratkaista kriittiset ongelmat sekä varmistaa testaus- ja muiden laatukriteerien täyttyminen Implementaatiokierros 1 Implementaatiokierroksella 1 laadunvarmistuksen ensisijaisena tavoitteena on varmistaa riittävä luotettavuus, tietoturva ja suorituskyky sovelluksen perusarkkitehtuurille ja alustalle. Toissijainen tavoite on varmistaa riittävä toimivuus niille järjestelmän osille, jotka näkyvät käyttäjille. Tämän lisäksi implementaatiokierroksella 1 on tarkoitus kartoittaa ryhmän yleinen osaamistaso virheiden tuottamisen ja niiden löytämisen kannalta. Tästä saatavaa tietoa käytetään mittareiden tarkentamiseen myöhemmillä kierroksilla. 1.2 Viittaukset muihin dokumentteihin Projektisuunnitelma - Projektisuunnitelmassa on kuvattu projektin eri osapuolet, resurssit ja aikataulut. Vaatimusmäärittely - Vaatimusmäärittelyssä on kuvattu järjestelmän vaatimukset, joihin testaus tulee perustumaan. 2 Testauksen kohde Testauksen kohteena on Hirviö-järjestelmä ja siihen liittyvä dokumentaatio. Jokaisella kierroksella kohteena on toteutettu järjestelmän osa-alue ja sitä vastaava dokumentaatio. 2.1 Testattavat ominaisuudet Jokaisen kierroksen testattavat asiat on listattuna alla. Testausprioriteetti on merkitty listoihin testattavan asian jälkeen asteikolla Implementaatiokierros 1 Implementaatiokierroksella 1 testataan katselmoimalla seuraavat iteraatiosuunnitelmassa mainitut dokumentit: Päivitetty vaatimusmäärittely (2) Arkkitehtuurikuvaus (1) Testaussuunnitelma (1) Implementaatiokierroksella 1 testataan myöhemmin dokumentissa mainituilla tavoilla seuraavat iteraatiosuunnitelmassa toteuttettavaksi merkityt järjestelmän osa-alueet: 3

4 Tietokanta-moduli (1) AAA-moduli (1) Sisään- ja uloskirjautuminen (1) Yksinkertaisen muistiinpanon kirjaus (1) Työryhmän muistiinpanojen katselu (2) 2.2 Ominaisuudet joita ei testata Implementaatiokierros 1 Implementaatiokierroksella 1 ei testata seuraavaa järjestelmään liittyvää dokumentointia: Päivitetty projektisuunnitelma. Tilannekatsaus. Testiraportti. Kaikki yllä listatut dokumentit jätetään testaamatta, koska niitä tai niiden päivityksiä ei katsota merkittäviksi Hirviön laatutekijöiden kannalta. Implementaatiokierroksella 1 ei testata seuraavia järjestelmään toteutettavia osa-alueita. Tietokantarakenne. Testioraakkelia on vaikea määritellä, koska mitään tietokantarakennetta hyödyntävää, ja samalla testausta helpottavaa, toiminnallisuutta ei toteuteta implementaatiokierroksella 1. Testaaminen jätetään myöhemmille kierroksille. Käyttöliittymä. Käyttöliittymästä puuttuu lähes kaikki ydintoiminnallisuus, joten sen testaaminen siirretään myöhemmille kierroksille. 3 Testauslähestymistavat 3.1 Testausmenetelmät Yksikkötestaus Kaikki järjestelmät modulit, poislukien käyttöliittymäkomponentit, yksikkötestataan. Yksikkötestaus toteutetaan käyttäen PHPUnit- alustaa. PHPUnit mahdollistaa testien suorittamisen automatisoinnin sekä antaa pohjan regressio- ja integraatiotestaukselle. Jokainen ohjelmoija on itse vastuussa toteuttamiensa modulien yksikkötestien luomisesta. Toteutettavalle toiminnallisuudelle luodaan ensin testi ja vasta tämän jälkeen vastaava toiminnallisuus (Test-driven developement). Tällä tavoin voidaan varmistua siitä, että yksikkötestit toteutetaan jokaiselle modulille. Vaihtoehtoinen tapa, jossa yksikkötestauksen tekee eri henkilö kuin toteuttaja, vaatisi ylimääräistä organisointia Integraatiotestaus Yksittäiset modulit integroidaan suuremmiksi kokonaisuuksiksi kun ne ovat valmiita ja niitä on yksikkötestattu riittävästi. Järjestelmä integroidaan klusteripohjaisesti (object cluster), jolloin lopputuloksena on testattuja, toiminnallisia kokonaisuuksia, joilla ei ole suuria keskinäisiä riippuvuuksia. Yksikkötestauksen yhteydessä luotuja automaattisia testejä hyödynnetään soveltuvin osin integraatiotestauksessa. 4

5 Ylimmän tason integroinnin ja integraatiotestaamisen suorittavat arkkitehtuurista vastaavat henkilöt, koska heillä on paras tietämys odotetusta toiminnallisuudesta. Ylimmän tason integroinnilla tarkoitetaan toimitettavan järjestelmän kokoamista ensimmäisellä implementaatiokierroksella, sekä testattujen klustereiden liittämistä järjestelmään myöhemmillä kierroksilla Systeemitestaus Jokaisen implementaatiokierroksen loppuvaiheessa suoritetaan systeemitestausta asiakkaalle toimitettavalle järjestelmän osalle. Systeemitestaus käsittää pääasiassa toiminnallista testausta ja tietoturvan testausta. Toiminnallinen testaus tehdään asiakkaan asettamien toiminnallisten vaatimusten perusteella, jotka on kirjattu vaatimusmäärittelyyn. Testaus tehdään käsin ennalta määrättyjen testitapausten mukaisesti. Testitapaukset pohjautuvat vaatimusmäärittelyn käyttötapauksiin Hyväksymistestaus Viimeistelykierroksella järjestelmälle suoritetaan hyväksymistestaus yhdessä asiakkaan kanssa. Hyväksymistestaus suoritetaan, kun systeemitestauksessa löydetyt virheet on korjattu ja testaus on niiltä osin suoritettu uudelleen Regressiotestaus Kun testattua järjestelmän osaa korjataan tai muutetaan, suoritetaan muutosten jälkeen regressiotestausta. Regressiotestaus käsittää vähintään kaikkien yksikkötestien automaattisen uudelleensuorituksen. Järjestelmälle voidaan suorittaa myös muita testejä yksikkötestien lisäksi laatuvastaavan harkinnan perusteella Katselmoinnit Tärkeimmät dokumentit katselmoidaan ennen palautusta. Katselmoinnissa on tarkoituksena löytää dokumentin puutteet asetettujen vaatimusten osalta ja ristiriidat muiden dokumenttien kanssa. Katselmoitavat dokumentit lähetetään ennen tilaisuutta katselmoijille, jotka lukevat ne läpi ja tekevät listan havaitsemistaan epäkohdista. Katselmoinneissa ei ole tarkoitus puuttua mielipiteillä enää varsinaiseen asiasisältöön, ellei kyseessä ole yksimielisesti selkeä virhe Käyttöliittymän heuristinen arviointi Toteutettu käyttöliittymä arvioidaan heuristisesti kummankin iteraatiovaiheen lopussa. Tarkemmat menetelmät on eritelty aiheeseen liittyvässä SEPA-päiväkirjassa. 3.2 Testaustyökalut Testauksessa käytetään seuraavia työkaluja: PHPUnit - Yksikkötestausalusta testien automatisointiin PHP-ohjelmointikielelle. PH- PUnit on vastine JUnitille, joka on niinsanottu de facto -standardi yksikkötestaukseen Javalla. HTTPUnit - Toiminnallisen testauksen automatisointiin. Vaikka toiminnallinen testaus tehdään pääasiassa manuaalisesti, voi HTTPUnittia käyttää sen tukena. 5

6 3.3 Testitapausten hallinta ja dokumentointi Kaikki testitapaukset dokumentoidaan priorisoituihin testijaksoihin. Priorisointi tehdään asiakkaan vaatimusten priorisoinnin perusteella. Toiminnalliset testitapaukset liitetään vaatimusmäärittelyn käyttötapauksiin, ei-toiminnalliset testitapaukset vaatimuksiin. Testitapaukset suunnitellaan siten, että ne olisivat valmiita hiukan ennen testattavaa toiminnallisuutta. Tällöin testitapaukset pohjautuvat täysin samoihin määrityksiin kuin itse toiminnallisuus. 3.4 Vikojen hallinta ja dokumentointi Kaikki integraatio-, systeemi-, hyväksymis- ja regressiotestaustauksessa havaitut viat kirjataan Bugzilla -järjestelmään. Kaikki yksikkötestauksessa havaitut viat joita ei korjata heti, kirjataan Bugzilla -järjestelmään. Yksikään versionhallintajärjestelmässä oleva revisio ei saa sisältää dokumentoimattomia ja havaittuja vikoja. Havaituista vioista kirjataan seuraavat tiedot: Vian yksilöivä tunniste Vian kuvaus Niiden toimintojen kulun kuvaus, joilla vika saadaan aiheuttettua uudelleen Vakavuusaste Ympäristön kuvaus Vian aiheuttama tulos ja varsinainen odotettu tulos Viat luokitellaan kolmeen vakavuusluokkaan, jotka on pyritty määrittelemään mahdollisimman yksiselitteisesti vian aiheuttaman seuraamuksen perusteella: Kriittinen vika - Vika, joka estää testattavan toiminnallisuuden käytön tai aiheuttaa kriittiseksi tai merkittäväksi luokiteltavia sivuvaikutuksia. Merkittävä vika - Vika, joka estää ajoittain testattavan toiminnallisuuden käytön, vaikettaa sitä tai aiheuttaa vähäisiä sivuvaikutuksia. Vähäinen vika - Vika ei estä toiminnallisuuden käyttöä eikä aiheuta sivuvaikutuksia. 3.5 Etenemisen seuranta ja mittarit Yksikkötestauksen etenemistä seurataan kun vastuullinen ohjelmoija luovuttaa toteuttamansa modulin integroimisvalmiina. Mikäli yksikkötestausta ei katsota tarpeeksi kattavaksi, moduli palautetaan toteuttajalleen testattavaksi. Yksikkötestausta seuratessa arvioidaan testien kattavuus priorisoinnin suhteen. Testien tulee kattaa syötteen tärkeimmät ekvivalenssiluokat ja raja-arvot siten, että jokaista positiivista testiä vastaa 3-5 negatiivista testiä. Integraatio- ja systeemitestauksessa löydetyistä vioista tuotetaan vikaraportteja. Näissä testausvaiheissa mittarina käytetään löydettyjen vikojen ja suoritettujen testien suhdetta. Vertailukohtana käytetään edellisten kierrosten aikana saatuja tuloksia. 3.6 Testidata ja aineistot Integraatio- ja järjestelmätestauksessa Hirviön tietokanta alustetaan määrätyllä testiaineistolla, jota täydennetään jokaisella iteraatiolla siten että se kattaa kierroksella toteutetut ja testattavat ominaisuudet. 6

7 3.7 Testien läpäisy- ja hylkäyskriteerit Testi on hylätty, jos se paljastaa vähintään yhden kriittisen vian. Testi on hylätty myös, mikäli se paljastaa vähintään yhden laillisella syötteellä aikaansaadun merkittävän vian. Muussa tapauksessa testi on läpäisty. 3.8 Testauksen keskeytys- ja uudelleenaloituskriteerit Testaus on keskeytettävä, mikäli testattavana on tietokantariippuvainen järjestelmän osa, ja testauksessa käytettävä tietokanta korruptoituu jonkin muun tekijän, kuin testin itsensä vuoksi. Testaus aloitetaan uudelleen, kun tietokanta on eheytetty. 3.9 Testauksen lopetuskriteerit Testausta ei voida lopettaa, jos testattavasta järjestelmästä paljastuu kriittisiä vikoja tai jos järjestelmästä paljastuu positiivisillä testeillä vähintään merkittäviä vikoja. Testaus voidaan lopettaa, jos testattavasta järjestelmästä ei löydetä vähintään merkittäviä vikoja yli kymmenellä testillä testattavaa ominaisuutta kohden. Ei-toivotussa tapauksessa testaus lopetetaan, kun sille asetetut resurssit ja aikarajat ylittyvät. 4 Resurssit 4.1 Vastuut ja henkilöstö Moduleiden yksikkötestauksesta ovat vastuussa niiden tekijät. Vastuut jokaisella iteraatiokierroksella on määritelty kyseisen iteraation iteraatiosuunnitelmassa. Matalan tason integroinnin ja integrointitestauksen tekevät integroitavista moduleista vastanneet henkilöt. Korkean tason integrointitestauksesta ovat vastuussa arkkitehtuurista vastaavat Liia Sarjakoski ja Anssi Kalliolahti. Systeemitestauksesta vastaavat Anssi Kalliolahti, Samuli Sorvakko ja Timo Toivanen. Laatuvastaavana toimii Anssi Kalliolahti, joka vastaa testauksen suunnittelusta, seurannasta ja raportoinnista projektipäällikölle. 4.2 Testausympäristö Kehitysympäristö toimii myös palvelinpään testiympäristönä. Implementaatiokierroksella 1 ei ole vielä tarvetta kiinnittää huomiota asiakaspään testiympäristöön. 5 Tehtävät ja aikataulu 5.1 Testaustehtävät Taulukon sarake vastuut tarkoittaa vastuuta systeemitestauksesta, jos kyse ei ole dokumentista. Yksikkö- ja integraatiotestausvastuu määräytyy iteraatiosuunnitelman mukaan edellä mainitulla tavalla. 7

8 5.1.1 Implementaatiokierros 1 # Tehtävä Vastuut 1 Päivitetty vaatimusmäärittely (katselmointi) Anssi Kalliolahti, Liia Sarjakoski, Jani Heikkinen 2 Arkkitehtuurikuvaus (katselmointi) Timo Toivanen, Jukka Larja 3 Testaussuunnitelma (katselmointi) Samuli Sorvakko, Jukka Larja 4 Tietokanta-moduli Jukka Larja, Jani Heikkinen 5 Sisään- ja uloskirjautuminen Anssi Kalliolahti 6 Yksinkertaisen muistiinpanon kirjaus Samuli Sorvakko 7 Työryhmän muistiinpanojen katselu Timo Toivanen 5.2 Aikataulu Testausaikataulu on aina suhteellinen, riippuen projektin yleisestä aikataulusta sekä mahdollisista liukumista. Yksikkö- ja osa integrointitesteistä on automatisoitu, jolloin niitä voidaan ajaa määrätyin väliajoin jatkuvan regressiotestauksen muodossa. Integraatio- ja systeemitestaukseen liittyvät testitapaukset pyritään luomaan samanaikaisesti ominaisuuden implementoinnin kanssa, jolloin ne ovat heti itse ominaisuuden valmistuttua valmiina. 5.3 Tuotokset Testaussuunnitelma - Tätä testaussuunnitelmaa päivitetään jokaisella kierroksella vastaamaan suunniteltuja laadunvarmistustoimenpiteitä. Testitapaukset - Systeemitestauksen tueksi tuotetaan joukko testitapauksia, joiden pohjalta testaus suoritetaan. Testitapaukset ovat käyttötapauksiin pohjautuvia, kevyitä ohjeistuksia testattavan toiminnallisuuden testaamiseen. Testiloki - Jokaisella implementaatiokierroksella systeemitestauksen aikana suoritettujen testitapausten tulokset kirjataan testilokiin. Testausraportti - Jokaisen implementaatiokierroksen päätteeksi kirjoitetaan testausraportti, joka tiivistää kierroksella tehdyn testauksen ja sen tulokset. Tiivistelmä vikaraporteista - Projektin lopuksi tuotetaan tiivistelmä kaikista projektin aikana dokumentoiduista vioista. 8