Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

Transkriptio

1 Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versio Päiväys Tekijä Kuvaus Risto Kunnas Ensimmäinen versio Risto Kunnas Korjauksia Mika Suvanto Lisätty johdanto Mikko Ruokojoki Korjauksia Mikko Ruokojoki Päivitetty dokumenttia I1-vaiheen tilanteen perusteella Päivitetty FD-vaiheen kohdalta. Dokumentin päivitys I Mikko Ruokojoki vaiheen osalta on vielä tekemättä.

2 T Laadunvarmistuksen suunnitelma Sivu 2/8 Sisällysluettelo 1 Johdanto Projektin laadunvalvontakäytännöt Testaus Testaustasot Testaustekniikat Testauksen raportointi Testitapaukset Katselmoinnit Ohjelmointikäytännöt Asiakkaan mahdollisuudet osallistua laadunvalvontaan Iterointien laadunvalvonta Iteraatiotason aiheet Iteraatio I1:ssa testattavat ominaisuudet Iteraatio I2:ssa testattavat ominaisuudet Iteraatio I2:ssa testauksen ulkopuolelle jäävät osat Hyväksymis / hylkäämis kriteerit I2 vaiheessa Testauksen lopettaminen I2 vaiheessa Resurssit I2-vaiheessa Iteraatiossa FD testattavat ominaisuudet Vertaistestaus FD-vaiheessa Hyväksymis / hylkäyskriteerit FD-vaiheessa Testauksen aikataulu Viitteet...8

3 T Laadunvarmistuksen suunnitelma Sivu 3/8 1 Johdanto Tämän dokumentin tarkoitus on toimia laadunvalvontasuunnitelmalle ExtraTerrestriaLsprojektiryhmälle Teknillisen korkeakoulun ja Aureolis Oy:n projektissa, jonka tarkoituksena on ETL- työkalun kehittäminen Aureolis Oy:n käyttöön. Projekti on tarkemmin kuvattu projektisuunnitelmassa [1], jota tämä dokumentti täydentää. Tässä kuvattuja laadunvalvonnan ja -varmistuksen käytäntöjä on tarkoitus noudattaa projektin ajan, ja mahdollisesti tarpeelliseksi havaitut muutokset käytäntöihin päivitetään tähän dokumenttiin projektin aikana. 2 Projektin laadunvalvontakäytännöt 2.1 Testaus Testaustasot Kaavio 1 Testauksen V-malli Projektissa pyritään käymään läpi kaikki ns. V-mallin mukaiset tasot. Projektissa varaudutaan kuitenkin alusta lähtien siihen, että annetussa ajassa ei välttämättä ehditä toteuttaa kaikkia vaatimuksia, jolloin ylempiä tasoja ei ehditä kokonaisuudessaan testata Testaustekniikat Todennäköisimmät ja samalla kriittisimmät virheet löytyvät järjestelmän toiminnallisuudesta. Pääpaino testauksessa on vaatimusmääritelmän kriittisiksi merkityissä ominaisuuksia. Funktionaalinen testaus pyritään suorittamaan automaattisesti. Automatisoitua testausta hyödynnetään yksikkötestauksen lisäksi järjestelmätestaustasolla. Kuvauskielen osalta tehdään kevyt käytettävyystestaus. Mikäli projektin puitteissa ehditään toteuttaa käyttöliittymä, suoritetaan ensimmäisten käyttöliittymäluonnosten jälkeen käytettävyystestaus prototyypin avulla.

4 T Laadunvarmistuksen suunnitelma Sivu 4/8 Koodin laatua pyritään valvomaan staattisilla menetelmillä, lähinnä katselmoinnilla. Koodia arvioidaan lisäksi CCCC-työkalulla, ja pyritään sen avulla löytämään tarkempaa katselmointia vaativat kohdat. Muita testaustekniikoita ei projektissa käytetä, ellei projektin kuluessa niille ilmesty erityistä tarvetta Testauksen raportointi Testien suorittaminen kirjataan lokiin. Testilokilla varmennetaan asiakkaalle se, että testausta on suoritettu. Esimerkki testilokista: Päivämäärä Suorittaja TC_ID Tulos Virheiden tunnisteet Risto Kunnas P2 Hylätty V1,V Risto Kunnas P2 Hyväksytty - Taulukko 1 Esimerkki testilokista Löydetyt virheet raportoidaan JIRA-tietokantaan.Virheiden raportoinnissa käytetään luokittelua Blocker, Critical, Major, Minor ja Trivial. Luokittelu Blocker Critical Major Minor Kuvaus Virhe estää testauksen tai kehityksen jatkamisen Aiheuttaa ohjelman kaatumisen tai tiedon katoamista Vakava puute toiminnallisuudessa Puute toiminnallisuudessa, joka on helposti korjattavissa Trivial Kosmeettiset ongelmat, kirjoitusvirheet Taulukko 2 Kuvaus virheiden vakavuusluokittelusta Virhetietokannasta virheet poimitaan toimenpiteitä varten uudelleen käsiteltäväksi. Mikäli virhe päätetään jättää korjaamatta esimerkiksi ajan puutteen, virheen vähäisyyden tai tietotaidon puutteen vuoksi, tehdään tästä merkintä virhetietokantaan. Jos virhe taas korjataan, tehdään tästä merkintä virhetietokantaan. Virhe voidaan avata uudelleen, mikäli testauksessa huomataan, että virhe ei korjaantunut.

5 T Laadunvarmistuksen suunnitelma Sivu 5/8 Kaavio 2 Virheen käsittely Testauksesta saadaan joitain metriikoita, joiden avulla voidaan seurata projektin etenemistä. Avoinna olevien virheiden osuus raportoiduista virheistä kertoo ongelmista virheiden korjaamisessa. Jos avoinna olevia virheitä on runsaasti, joudutaan niiden korjaamiseen varaamaan lisää aikaa. Jos suurin osa raportoiduista virheistä on saatu korjattua, ja raportoitujen virheiden määrä on suuri, voidaan laadunvalvontaa pitää onnistuneena Testitapaukset Testauksessa pyritään käyttämään automaattista testausta, mikäli se on mahdollista. Toimenpidemoduulien testausta varten luodaan erilaisia syötteitä sekä niitä vastaavia tuloksia. Erityisesti testataan myös ns. negatiiviset testitapaukset. Testauksessa käytetään ns. regressiotestausta, eli jo kertaalleen hyväksytysti tapahtuneet testiajot ajetaan virheen korjaamisen jälkeen uudestaan. Integraatiotestauksesta eteenpäin suoritetaan testaus pääosin kuvauskieli-skriptien avulla. Vertailutulos saadaan monimutkaisissa tapauksissa ulos vastaavista järjestelmistä. Myös kuvauskieli skriptien avulla suoritetaan ns. regressio-testausta. Muita toimintoja varten luodaan sanallisesti kuvatut testitapaukset Excel-taulukko muotoon. Sanallisissa kuvauksissa tulee kiinnittää erityistä huomiota siihen, että testi pystytään ajamaan samanlaisena eri suorituskerroilla, eikä kuvaus jätä tulkinnanvaraa testin suorittajalle. 2.2 Katselmoinnit Tärkeimmät dokumentit käydään läpi formaalisti katselmointimenetelmällä. Tärkeimmät dokumentit ovat iteraatiosuunnitelmat sekä arkkitehtuurin ja rajapintojen määrittely. Lisäksi arkkitehtuurisuunnitelman jälkeen voidaan arvioida, mikäli jokin moduuli tarvitsee eifunktionaalista testausta. Katselmointiin osallistuu 3-4 henkilöä, joista tasan yksi kuuluu katselmoitavan dokumentin vastuuhenkilöihin. Mikäli katselmointitilaisuus perustellusta syystä järjestetään isompana, voivat kaikki dokumentin vastuuhenkilöt osallistua tilaisuuteen. Katselmointitilaisuuden kesto pyritään pitämään alle kahdessa tunnissa. Mikäli dokumentti on laaja, on syytä katselmoida dokumentti eri

6 T Laadunvarmistuksen suunnitelma Sivu 6/8 osissa. Katselmoitava dokumentti on jokaisella katselmointiin osallistuvalla henkilöllä luettavissa vähintään kaksi tuntia ennen katselmointitilaisuutta. Katselmointiin osallistuvat henkilöt, mukaan lukien dokumentin vastuuhenkilö, tekevät itselleen vapaamuotoisen listan huomautuksista ennen katselmointitilaisuuden alkua. Myös huomautusten vakavuusasteeseen sekä korjauksen prioriteettiin otetaan kantaa tässä vaiheessa. Mikäli katselmoija ei täysin ymmärrä jotain kohtaa, on sekin merkittävä huomautukseksi. Vakavuusasteet ja korjausprioriteetit ovat määritelty testaussuunnitelmassa. Katselmointitilaisuudessa ovat läsnä puheenjohtaja, sihteeri sekä varsinaiset katselmoijat. Katselmoitavan dokumentin vastuuhenkilöt eivät saa johtaa puhetta. Katselmoitavan dokumentin vastuuhenkilö toimii pääsääntöisesti sihteerinä, mutta mikäli katselmointi järjestetään isompana (yli 5 henkilöä), voi sihteerinä toimia myös joku muu. Katselmointeihin osallistuu mahdollisuuksien mukaan myös asiakkaan edustaja. Dokumentti käydään läpi kappale kerrallaan, ja puheenjohtaja esittelee lyhyesti käsiteltävän kappaleen sisällön. Mikäli dokumentti noudattaa jotain standardia tai pohjaa, esittelee puheenjohtaja myös lyhyesti standardin tai pohjan vaatimukset käsiteltävälle luvulle. Tämän jälkeen kukin osallistuja, myös puheenjohtaja sekä sihteeri, huomauttaa kappaleessa olevista virheistä puheenjohtajan annettua puheenvuoron. Osa huomautuksista tulee esiin vasta katselmointitilaisuudessa, osa on jo ennalta valmisteltuja. Sihteeri merkitsee kirjoitusvirheet ja epäselvät lauserakenteet alleviivauksilla paperiseen dokumenttiin, muut huomautukset, ehdotukset ja kritiikki sihteeri kirjaa virhetietokantaan kuten minkä tahansa muunkin virheen. Virheiden korjaamisesta ei käydä keskustelua, mutta puheenjohtaja voi harkintansa mukaan sallia lyhyiden ratkaisuehdotusten esittämisen. Tämä ei kuitenkaan saa viedä liikaa aikaa varsinaiselta tarkoitukselta, eli virheiden löytämiseltä. Katselmointitilaisuuden kulussa on erityisesti kiinnitettävä huomiota siihen, että dokumentin vastuuhenkilö ei ota huomautuksia henkilökohtaisesti eikä selittele tai puolustele tekemiään ratkaisuja. Dokumentin vastuuhenkilöt käsittelevät katselmoinnissa esiin tulleet huomautukset katselmointitilaisuuden jälkeen ennalta määrätyn aikataulun puitteissa. Osa katselmointitilaisuudessa tulleista huomautuksista on puhtaita väärinkäsityksiä, ja niille ei tarvitse tehdä mitään. On kuitenkin huomattava, että mikäli katselmoija ymmärtää jonkin asian väärin, on asia huonosti esitetty. Tämä pätee myös erityisesti ohjelmakoodin katselmoinnissa. Katselmoinnissa kerättävät laatumetriikat koostuvat osallistujien ennen tilaisuutta tekemistä huomautuksista (pois lukien kirjoitusvirheet ja epäselvät lauserakenteet) sekä virhetietokantaan viedyistä huomautuksista. Katselmointitilaisuus on onnistunut, mikäli virhetietokantaan viedään enemmän huomautuksia kuin yksittäisellä katselmoijalla on ennen katselmointitilaisuutta ollut. Jos yksi katselmoija on löytänyt kaikki virheet dokumentista ennen katselmointitilaisuutta, ei katselmointitilaisuudesta ja muiden työpanoksesta ole ollut hyötyä. Toinen mittari on dokumentin vastuuhenkilön ennen katselmointitilaisuutta tekemien huomautusten määrän (mikä on todennäköisesti aika alhainen) suhde virhetietokantaan vietyjen huomautusten määrään. Katselmoitavan dokumentin laatu paranee, mitä enemmän virheitä siitä löydetään (ja korjataan). 2.3 Ohjelmointikäytännöt Käytämme Sun Microsystems:n virallisia koodikäytäntöjä ( Suurin osa kehitystyöstä tehdään Eclipse IDE:llä, johon on määritelty Sunin koodikäytännöt.

7 T Laadunvarmistuksen suunnitelma Sivu 7/8 Hyödynnämme sen automaattisia koodin generointi- ja muotoiluominaisuuksia. 2.4 Asiakkaan mahdollisuudet osallistua laadunvalvontaan Asiakkaalla on pääsy projektiryhmän virhetietokantaan sekä CVS:ään. Asiakas voi siten seurata laadunvalvonnan toteutumista sekä tehdä omalta osaltaan laadunvalvontaa, esimerkiksi tarkkailemalla CVS:stä löytyvää ohjelmakoodia ja olla ryhmään yhteydessä, mikäli ohjelmakoodin laatu jatkokehitystä ajatellen ei ole riittävä. Asiakas voi huomauttaa löytämistään laatuongelmista joko suoraan projektipäällikölle tai tekemällä virheilmoituksen virhetietokantaan. 3 Iterointien laadunvalvonta Jokaisen iteraation alussa määritellään iteraation tavoitteet. Laadunvalvonnan tarkoituksena on tarjota käytännöt tavoitteiden toteutumisen arvioimiseksi. Kunkin iteraation tavoitteet määritellään selkeästi ja yksiselitteisesti ennen toteutusta. Laadun mittarina käytetään korjattujen virheiden suhdetta löydettyihin virheisiin. 3.1 Iteraatiotason aiheet Iteraatiokohtaiset suunnitelmat tarkentuvat projektin edetessä Iteraatio I1:ssa testattavat ominaisuudet Iteraatiossa ei päästy varsinaiseen ohjelmakoodin testaukseen. Dokumenttien testauksesta on tarkemmin tietoa testiraportissa [2]. Testitapausten suunnitteluun ja testidatan kehittämiseen varataan iteraation alusta 20 henkilötyötuntia Iteraatio I2:ssa testattavat ominaisuudet TS_ID VM_ID Kuvaus Prioriteetti Muuta TS1 ET1, ET2, ET4 Kuvauskielen käytettävyystestaus Korkea Testihenkilöitä tarvitaan TS2 T1 Toimenpiteen Join funktionaalinen testaus Kriittinen TS3 T2 Toimenpiteen Summaus funktionaalinen Kriittinen testaus TS4 T7 Toimenpiteen Copy funktionaalinen Kriittinen testaus TS5 T13 Toimenpiteen Rajaus funktionaalinen Kriittinen testaus TS6 P1, P2, P3, ETL-Moottorin perustoteutuksen Korkea P4, E1, E2, funktionaalinen testaus. Toimenpiteiden E6 suoritus ja tulosten välittäminen toimenpiteestä toiseen TS7 ETL-Moottorin perustoteutuksen Korkea funktionaalinen testaus. Taulurakenteiden selvittäminen ennen ajon alkua. TS8 ET6, ET7, ET9 Koodin laadun katselmointi Korkea Asiakkaan osallistuminen Taulukko 3 Testisarjat iteraation I2:en testattaville ominaisuuksille Testitapaukset jakautuvat testisarjoihin. Yksi testisarja vastaa yhden toteutettavan ominaisuuden testauksesta.

8 T Laadunvarmistuksen suunnitelma Sivu 8/ Iteraatio I2:ssa testauksen ulkopuolelle jäävät osat Testauksen ulkopuolelle jäävät myöhemmissä iteraatioissa toteutettava toiminnallisuus. Lisäksi testauksen ulkopuolelle jäävät kolmansien osapuolien ohjelmistot ja itse tietokantojen testaus. I2 vaiheessa ei testata järjestelmän vakautta (vaatimusmäärittelyn kohta ET 11) Hyväksymis / hylkäämis kriteerit I2 vaiheessa Testattava ominaisuus on hyväksytysti testattu, kun kaikki ominaisuuden testitapaukset pystytään ajamaan läpi niin, että ominaisuuteen ei jää yhtään Major, Critical tai Blocker tason virhettä. Hyväksymiskriteeriä voidaan tiukentaa myöhemmissä iteraatioissa, mikä vaikuttaa myös I1-vaiheen kertaalleen jo hyväksyttyihin ominaisuuksiin Testauksen lopettaminen I2 vaiheessa Testaus voidaan lopettaa, kun sille varattu aika on käytetty, eikä yhtään Blocker, Critical tai Major tasoista virhettä ole avoinna. Mikäli pienemmän prioriteetin avoinna olevia virheitä kuitenkin korjataan testauksen lopettamisen jälkeen, tulee testaus aloittaa uudestaan Resurssit I2-vaiheessa Varsinaiseen testaukseen ei varata henkilöstöresursseja erikseen, vaan testiajot tehdään toteutuksen yhteydessä ohjelmoijien toimesta Iteraatiossa FD testattavat ominaisuudet FD-vaiheen testauksen aikataulu määritellään FD iteraatiosuunnitelmassa Vertaistestaus FD-vaiheessa Vertaistestaus toteutetaan FD-vaiheessa. Tarkempi suunnittelu tehdään iteraatiosuunnitelmaan ja yhdessä testauksen toteuttavat ryhmän kesken Hyväksymis / hylkäyskriteerit FD-vaiheessa TODO Testauksen aikataulu Testauksen aikataulua FD-vaiheelle ei ole vielä määritelty ja sitä tarkennetaan FD-vaiheen iteraatiosuunnitelmassa. Testausta suoritetaan yhtä aikaa toteutuksen kanssa. Testitapaukset pyritään suunnittelemaan ennen toiminnallisuuden toteuttamista. 4 Viitteet [1] ETL-työkalun projektisuunnitelma [2] ETL-työkalun testiraportti