Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

Transkriptio

1 Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versi Päiväys Tekijä Kuvaus o 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 Mikko Ruokojoki Risto Kunnas Päivitetty Päivitetty FD-vaiheen kohdalta. Dokumentin päivitys I2- vaiheen osalta on vielä tekemättä Risto Kunnas Läpikäynti viimeistä palautusta varten

2 T Laadunvarmistuksen suunnitelma Sivu 2/9 Sisällysluettelo 1Johdanto...3 2Projektin laadunvalvontakäytännöt Testaus Testaustasot Testaustekniikat Testauksen automatisointi 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 Resurssit I2-vaiheessa Iteraatiossa FD testattavat ominaisuudet Testauksen automatisointi Vertaistestaus FD-vaiheessa Hyväksymis / hylkäyskriteerit FD-vaiheessa Testauksen lopettaminen FD vaiheessa Testauksen aikataulu...8 4Viitteet... 9

3 T Laadunvarmistuksen suunnitelma Sivu 3/9 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. Koska projektin edetessä on käynyt ilmi, että alkuperäinen näkemys siitä, että yksikkötestauksessa yksikkönä on yksittäinen toimenpide, ei ole kovin relevantti, on testauksessa siirrytty suoraan systeemitestaustasolle. Systeemitestaus pyritään suorittamaan automaattisesti tätä varten kehitetyllä työkalulla. Testaustyökalu toimitetaan myös asiakkaalle ETL-työkalun tulevan kehitystyön avuksi 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.

4 T Laadunvarmistuksen suunnitelma Sivu 4/9 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. 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 automatisointi Testauksessa käytetään apuvälineenä tätä varten kehitettyä työkalua 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/9 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. 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. 2.2 Katselmoinnit Tärkeimmät dokumentit käydään läpi formaalisti katselmointimenetelmällä. Tärkeimmät dokumentit ovat tekninen spesifikaatio, kehitysohje sekä arkkitehtuurin ja rajapintojen määrittely. Lisäksi arkkitehtuurisuunnitelman jälkeen voidaan arvioida, mikäli jokin moduuli tarvitsee eifunktionaalista testausta. Katselmoinnin tarvetta arvioidaan myös staattisin menetelmin. 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 osissa.

6 T Laadunvarmistuksen suunnitelma Sivu 6/9 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. Hyödynnämme sen automaattisia koodin generointi- ja muotoiluominaisuuksia.

7 T Laadunvarmistuksen suunnitelma Sivu 7/9 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, E6 funktionaalinen testaus. Toimenpiteiden 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 Resurssit I2-vaiheessa Varsinaiseen testaukseen ei varata henkilöstöresursseja erikseen, vaan testiajot tehdään toteutuksen yhteydessä ohjelmoijien toimesta Iteraatiossa FD testattavat ominaisuudet Iteraatiossa testataan toteutut ja viimeistellyt toimenpidekomponentit. Jo testattuja ominaisuuksia testataan uudestaan, mikäli niille tehdään muutoksia Testauksen automatisointi Edellisissä iteraatioissa testausta on tehty sitä varten kehitetyllä työkalulla. FD vaiheessa työkalusta pyritään saamaan aikaan parannettu versio, joka mahdollistaisi testiajon tuloksen vertaamista oletettuun tulokseen. Testaustyökalu on olennainen osa ETL-työkalua, sillä osa sen käyttöä on uusien toimenpidekomponenttien ohjelmoiminen ja niiden testaus Vertaistestaus FD-vaiheessa Vertaistestauksella täydennetään normaalia testausta. Vertaisryhmän testaaja määrittelee erilaisia prosessiajoja, jotka liitetään osaksi testitapauksia. Testausta ei vertaistestauksessa kuitenkaan rajoiteta mihinkään tiettyyn osa-alueseen jotta saadaan selville puuttee projektiryhmän omassa testauksessa. Vertaistestauksessa pyritään myös saamaan selville puutteet kehitys ja käyttöohjeessa sekä muussa dokumentaatiossa. Vertaisryhmän testaajalle annetaan avuksi vain dokumentaatio sekä pieni opastus. Tarkempaa opastusta annetaan vain jos testaus ei etene Hyväksymis / hylkäyskriteerit FD-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ä. Jos aikaa jää, pyritään myös alemman tason virheet korjaamaan Testauksen lopettaminen FD 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 Testauksen aikataulu Testausta jatketaan koko FD-iteraation ajan. Vertaustestaus suoritetaan välisenä aikana.

9 T Laadunvarmistuksen suunnitelma Sivu 9/9 4 Viitteet [1] ETL-työkalun projektisuunnitelma [2] ETL-työkalun testiraportti