Ohjelmistotestauksen suunnittelu - Case: A-lehdet Oy:n laskujen tulostusohjelma

Transkriptio

1 Ohjelmistotestauksen suunnittelu - Case: A-lehdet Oy:n laskujen tulostusohjelma Eija Rauhala Tietojenkäsittelyn koulutusohjelma 2010

2 Tiivistelmä Koulutusohjelma Tekijät Eija Rauhala Opinnäytetyön nimi Ohjelmistotestauksen suunnittelu Case: A-lehdet Oy:n laskujen tulostusohjelma Ryhmä tai aloitusvuosi 2007 Sivu- ja liitesivumäärä Ohjaaja tai ohjaajat Raine Kauppinen Opinnäytetyön tavoitteena on selvittää ohjelmistotestauksen osuutta ohjelmistoprojektissa. Ohjelmistotestaukseen tutustumisen kautta päätavoitteena on luoda testauksen suunnittelumallit, joita voimme A-lehdet Oy:ssä tulevissa ohjelmistoprojekteissa hyödyntää. Teoriaan ja aikaisempiin tutkimuksiin tutustumalla on tutkittu ohjelmiston ja testauksen laatua, testauksen sijoittumista ohjelmistoprojektiin, testaustasoja, testausmenetelmiä ja testaukseen liittyviä dokumentteja. Opinnäytetyössä on tutkittu menetelmiä siihen liittyen, miten testauksen avulla saavutetaan laadukas ohjelmisto tehokkaasti ja mahdollisimman pienin kustannuksin. Näihin menetelmiin kuuluvat esimerkiksi testitapausten valinta, testauksen riittävyyden arviointi, testauksen tehokkuuden arviointi ja testauksen dokumentointi. Kaikkia, kuten staattisen mallin mukaisia testausmenetelmiä ei aina mielletä testaukseen kuuluviksi, mutta testauksen alussa käytettynä ne pienentävät projektin kustannuksia ja ovat hyvä virheiden etsimiskeino. Testitapausten suunnittelu tulee aloittaa ohjelmistotuotantoprosessissa jo määrittelyvaiheessa. Aikaisessa vaiheessa löydetyt virheet vähentävät virheenkorjauksista aiheutuvia kustannuksia. Testauksen suunnittelun ja testauksen tulee edetä ohjelmistoprojektin kanssa rinnakkain. Testaussuunnittelu eri testaustasoilla, joita ovat moduuli-, integrointi-, järjestelmä- ja hyväksymistestaus, on tämän opinnäytetyön päätavoite. Testaussuunnitelmia on toteutettu kaksi: moduulitestaussuunnitelma ja testaussuunnitelma, missä on yhdistettynä integraatio-, järjestelmä- ja hyväksymistestaus. Testaussuunnitelmat on tehty laskujen tulostuksen muutosprojektia varten. Varsinainen testaus ja sen tuloksiin liittyvät dokumentit eivät kuulu tähän opinnäytetyöhön. Asiasanat Testaussuunnitelma, ohjelmistotestaus, testaustasot, testausmenetelmät, testitapaukset

3 Abstract Degree programme Authors Eija Rauhala The title of thesis Software Test Design - Case: A-lehdet Oy s invoice printing program Group or year of entry 2007 Number of pages and appendices Supervisors Raine Kauppinen The objective of this thesis is to examine a software testing role in a software project. The main objective is to create a test design models, which we can utilized in future software projects in A-lehdet Oy. The methods used in this study were reading theory and previous studies. The focus has been in software quality and testing quality, where the testing takes place in a software project, test levels, test methods and the documents of testing. In this thesis has been studied methods, how the testing will achieve a high quality software efficiently and at minimum cost. These matters include, for example the selection of test cases, testing the adequacy of the evaluation, testing the effectiveness of the evaluation and testing documents. The study showed that static test methods are not always regarded as part of the testing, but using at the beginning of testing, they reduce the cost of the project and are a good way to find errors. According to the study test case design should be started already in a specification phase in software production process. Errors which are found at early stage reduce the error correction costs. Test design and testing should proceed at the same time with the software project. Test plan in different test levels, which are module, integration, system and acceptance, is the main objective of this thesis. Test plans have been made two: the module test plan and test plan, which is a combination of integration, system and acceptance testing. Test plans have been made for invoice printing project. Actual testing and the documents of the tests results do not include in this thesis. Key words Test plan, software testing, testing levels, test methods, test cases

4 Sisällys 1 Johdanto Rajaukset Keskeiset käsitteet Ohjelmistotestaus Ohjelmistotestauksen määritelmä Ohjelmiston laatu Testauksen laatu Laadunvarmistus Ohjelmistoprojektit ja testaus Testauksen sijoittuminen ohjelmistoprojektiin Testaustasot Testausmenetelmät Staattiset menetelmät Dynaamiset menetelmät Testauksen riittävyyden arviointi Virheet, viat ja häiriöt Testauksen tilanneraportti Testauksen tehokkuuden arviointi Testaussuunnitelma Testaussuunnitelman tarkoitus Testaussuunnitelmat vaiheiden mukaisesti Testauksen suunnittelun dokumentit Testaussuunnitelma Testisuunnitelma Testitapausten määrittely Testausmenettely Testauksen tulosten dokumentit Testiloki Testauksen tapahtumaraportti / Virheraportti Testauksen yhteenvetoraportti... 44

5 9 Ohjelmistotestauksen nykytilan arviointi Laskujen tulostuksen testaussuunnitelmien toteutus Testaussuunnitelma Moduulitestaussuunnitelma Yleiset havainnot Pohdinta Tavoitteena testaussuunnitelma Muut tavoitteet Yhteenveto Lähteet Liite1. Laskutuksen tulostuksen testaussuunnitelma Liite2. Laskutuksen tulostuksen moduulitestaussuunnitelma Liite3. Loppuraportti... 97

6 1 Johdanto Opinnäytetyö antaa yleiskuvan siitä, mitä ohjelmistotestauksessa tapahtuu. Ohjelmistotestauksen eri vaiheet suunnittelusta testitapausten tekemiseen ja testauksen raportointiin käydään läpi. Opinnäytetyön tarkoituksena on tutustua ohjelmistotestaukseen ja luoda testauksessa käytettävä suunnittelumalli, jota yrityksessämme voidaan hyödyntää. Ohjelmistotestaus pitää sisällään useita eri asioita ja opinnäytetyöni tavoitteena on selvittää ohjelmistotestauksen käsitettä, ohjelmiston ja testauksen laatua, ohjelmistotestauksen sijoittumista ohjelmistoprojektiin, ohjelmistotestausprosessin vaiheet, ohjelmistotestauksen testausmenetelmiä, testaussuunnitelman tarkoitus, ohjelmistotestauksen onnistumiseen vaikuttavat tekijät sekä ohjelmistotestauksen suunnittelu- ja raportointimalleja. Päätavoitteeni on luoda testauksen suunnittelumalli, jota voimme hyödyntää A-lehdet Oy:ssä tulevissa ohjelmistoprojekteissa. Tätä mallia on tarkoitus lähteä luomaan esimerkin kautta, joka liittyy laskutuksen tulostuksen uusimiseen. Tarkoituksenani on tehdä laskutuksen tulostuksessa tarvittavat testaussuunnitelmat: yleistestaussuunnitelma ja moduulitestaussuunnitelma. Henkilökohtaisella tasolla tavoitteenani on tutustua testauksen teoriaan, koota siitä hyvä yleiskäsitys ja hyödyntää näitä tietoja työssäni tulevaisuudessa. Opinnäytetyössä tutustutaan ensimmäiseksi ohjelmistotestauksen käsitteeseen. Sekä ohjelmistolta että testaukselta vaaditaan hyvää laatua. Testauksen tavoitteena on tuottaa laadukas ohjelmisto, jossa ei ole virheitä. Laatuun tutustumisen yhteydessä paneudutaan syvällisemmin staattisista testausmenetelmistä tarkastuksiin. Tarkastuksilla voidaan vaikuttaa jo varhaisessa vaiheessa testauksen laatuun. Perinteisessä ohjelmistoprojektissa testaus sijoittuu prosessin loppupäähän. Opinnäytetyössä lähdetään tutkimaan mihin testauksen tulisi ohjelmistoprojektissa sijoittua, jotta testauksesta ja itse ohjelmistoprojektista tulisi mahdollisimman kustannustehokas. 1

7 Testaussuunnitelma on hyvä lähtökohta lähteä suorittamaan testausta. Suunnitelman avulla saadaan selville ohjelmistoprojektin kriittiset kohdat. Opinnäytetyössä tutustutaan testaussuunnitelman tarkoitukseen, sen sisältöön ja tuotoksiin. Testaustasoihin tutustutaan yleisen V- mallin kautta. Testausmenetelmistä käydään läpi yleisimmät testausmenetelmät ja testitapausten valintakriteerit. Lisäksi tutustutaan testauksen tehokkuuden arviointimenetelmiin. Opinnäytetyössä tutustutaan perusteellisesti testauksen suunnittelu- ja raportointimalleihin tarkoituksena hyödyntää näitä malleja tulevissa ohjelmistoprojekteissa yrityksessämme. Testauksen suunnitteluun ja raportointiin liittyviä dokumentteja on määritelty eri tarkkuustasoille alkaen yleisestä testaussuunnitelmasta päätyen yksittäisten testitapausten suunnitteluun ja testitapausten tulosten raportointiin. Käyn nämä dokumentit läpi. Tarkoituksena on, että näistä mallipohjista voisi jatkossa luoda eri ohjelmistoprojekteihin sopivat testaussuunnitelmat ja raportit. Lopuksi esittelen testaussuunnitelman ja moduulitestaussuunnitelman, joka liittyy laskujen tulostusohjelmaan ja on tehty näiden opintojen pohjalta. Menetelminä käytän teoriaan tutustumista kirjallisuuden, aikaisempien tutkimusten ja internetistä löytyvän materiaalin pohjalta. Teorian pohjalta kirjoitan testaussuunnitelman ja moduulitestaussuunnitelman mukaillen IEEE standardin mallipohjaa. 1.1 Rajaukset Itse testauksen toteuttaminen ei kuulu tämän opinnäytetyön kokeelliseen osaan. Testaukseen liittyvät testiraportit, testauksen tapahtumaraportti ja testauksen yhteenvetoraportti, jäävät näin ollen myös kokeellisesta osasta pois. 1.2 Keskeiset käsitteet Dynaaminen analyysi Ohjelmiston testaaminen ohjelmakoodia suorittamalla Harmaalaatikkotestaus Musta- ja valkolaatikkotestauksen välimuoto, jossa käytetään hyväksi tietoa ohjelman toteutusperiaatteista Hyväksymistestaus Loppukäyttäjän suorittama testaus, jossa arvioidaan tuotteen kykyä vastata asiakasvaatimuksiin IEEE standardi Standardi ohjelmistojen testausdokumenteille 2

8 Integrointitestaus Järjestelmätestaus Katselmus Kelpoistaminen Lasilaatikkotestaus Läpikäynti Moduulitestaus Mustalaatikkotestaus Regressiotestaus Staattinen analyysi STEP metodologia Testaussuunnitelma Tarkastus Vesiputousmalli Testaus, jonka tarkoituksena on testata moduulien välisten rajapintojen toimintaa Testaus, jonka tarkoituksena on testata koko järjestelmän toimintaa Menetelmä, jolla todetaan jonkin ohjelmistotuotantoprosessin vaiheen päättyminen Menetelmä, jolla tutkitaan tuotteen sopivuus käyttötarkoitukseensa Testausmenetelmä, jossa nähdään testattavan kokonaisuuden sisäinen toiminta ja rakenne eli koodi. Tunnetaan myös nimellä valkolaatikkotestaus Menetelmä, jolla varmistetaan, että tuote vastaa vaatimuksia ja määritelmiä kooditasolla. Englanninkielinen nimi walkthrough Testausvaihe, jossa kohteena on vain yksittäinen moduuli Testausmenetelmä, joka perustuu testattavan kokonaisuuden ulkoiseen toimintaan (syötteisiin ja tulosteisiin) Testausmenetelmä, jolla todennetaan ohjelmistoon tehdyn korjauksen toimivuus ja varmennetaan, että uusia vikoja ei ole syntynyt muuttumattomiin ohjelmiston osiin korjauksen myötä Ohjelmiston testaaminen ilman ohjelmakoodin suorittamista The Systematic Test and Evaluation Process Metodologia, joka näkee testauksen prosessina alkaen heti määrittelyvaiheen yhteydessä Suunnitelma, jonka pohjalta ohjelmistotestaus voidaan viedä organisoidusti läpi Menetelmä, jolla varmistetaan, että tuote vastaa vaatimuksia ja määritelmiä Perinteinen ohjelmistotuotantoprosessia kuvaava elinkaarimalli 3

9 2 Ohjelmistotestaus Ohjelmistotestausta suoritetaan, jotta varmistuttaisiin ohjelmistojen toimivuudesta ja että ohjelmisto täyttää sille asetetut vaatimukset eikä siinä ole virheitä. Testauksessa varmistutaan, että ohjelmisto täyttää asiakkaiden ja käyttäjien tarpeet, että ne ovat nopeita ja käyttäjäystävällisiä. Ohjelmistolta ja testaukselta vaaditaan siis hyvää laatua. Graigin ja Jaskielin (2002, 6) mukaan monissa yrityksissä testausta suoritetaan vasta ohjelmistoprojektin loppuvaiheessa, kun koodi on jo kirjoitettu. Kustannukset puolestaan kasvavat mitä myöhemmin virheet löydetään ja korjataan. Ohjelmistotestauksen tulisi kuulua olennaisena osana ohjelmistotuotantoprosessia vaatimusmäärittelystä alkaen, jotta kustannukset eivät tulisi kohtuuttomiksi. Testauksen työvaiheisiin kuuluvat testauksen suunnittelu, testiympäristön luominen, testin suorittaminen, testitulosten tarkastelu ja raportointi. Haikalan ja Märijärven (2006, 283) mukaan näihin työvaiheisiin ja niihin liittyviin virheiden etsimiseen ja korjaukseen kuluu tyypillisesti yli puolet ohjelmistoprojektin resursseista. Testauksen kohteena ovat yleensä ohjelmiston erilaiset toiminnot kuten tietojen lisäys, poisto tai päivitys. Testauksen kohteena voi olla myös suorituskyky, jolloin testauksessa kiinnitetään huomiota suuriin tapahtumamääriin. Myös turvallisuutta voidaan testata jolloin tarkastetaan, että oikeat käyttäjät pääsevät käsiksi oikeisiin tietoihin. Konfiguraatiotestauksia suoritetaan ohjelmistoille, jotka on suunniteltu toimimaan erilaisissa laite- ja käyttöjärjestelmäympäristöissä. (Rajamäki 2000, 4.) Yksinkertaistettuna esimerkkinä testauksesta voimme ajatella ohjelmalle annettavaa syötettä X, josta ohjelma tuottaa tulosteen Y. Testaustulos riippuu syötteen lisäksi järjestelmän sisäisestä tilasta. Sisäinen tila tarkoittaa mm. ohjelman muuttujien ja rekisterien arvoja sekä levylle talletettuja tietoja. Testin onnistuminen edellyttää, että tulos Y on oikea ja että sisäinen tila on muuttunut oikein. Testausta varten on oltava käsitys ohjelman syötteistä ja oikeasta lopputuloksesta. Tätä varten tarvitaan spesifikaatio, jonka perusteella testitapaukset voidaan suunnitella ja voidaan päätellä oikeat lopputulokset. (Haikala & Märijärvi 2006, 285.) 4

10 2.1 Ohjelmistotestauksen määritelmä Ohjelmistotestauksen perinteinen määritelmä on virheiden suunnitelmallinen etsiminen. Testaukseen valitaan usein ilman sen kummempia suunnitelmia syöttöaineisto ja tavoitteena on ennemminkin osoittaa ohjelman toimivuus kuin virheiden löytyminen. Nykyään testaus määritellään ohjelmiston laadun mittaamisen ja parantamisen näkökulmasta. (Haikala & Märijärvi 2006, 284.) Graigin ja Jaskielin (2002, 4-6) mukaan Testing is a concurrent lifecycle process of engineering, using and maintaining testware in order to measure and improve the quality of the software being tested. Eli korostetaan sekä testauksen tuottamien mittareiden tärkeyttä että ohjelmiston laadun parantamista. Tämä tunnetaan ehkäisevän testauksen (preventive testing) käsitteenä, jolloin ohjelmiston vaatimusmäärittelyn pohjalta kirjoitetaan testitapauksia. Koodaajan on huomattavasti helpompi aloittaa työskentely, kun hänellä on vaatimusmäärittelyn lisäksi valmiita testitapauksia. Ehkäisevässä testauksessa käytetään menetelmänä esimerkiksi tarkastuksia (inspections), joista kerrotaan enemmän luvussa 2.4 Laadunvarmistus. Koska testauksella pyritään hyvään laatuun, seuraavaksi hieman, mitä laadulla tarkoitetaan. 2.2 Ohjelmiston laatu Ohjelmiston laadulle asetetut vaatimukset voivat vaihdella suurestikin käyttötarkoituksen mukaan. Esimerkiksi suunniteltaessa sairaalaan teho-osaston valvontalaitteistoa, ovat laatuvaatimukset huomattavasti korkeammat kuin suunniteltaessa ohjelmistoja, jotka eivät vaaranna ihmishenkiä. (Enqvist ym. 2001, 3) mukaan hyvälaatuisen ohjelmiston tulisi vastata tarkoitustaan ja määritystään, olla helppokäyttöinen ja riittävän yksinkertainen, olla helposti ylläpidettävä ja päivitettävä, olla turvallinen sekä olla mahdollisimman suorituskykyinen. Ohjelmistotestauksella pyritään varmistamaan ohjelmiston laatu. Tavoitteena on tuottaa kustannustehokkaasti toivottu lopputulos, valmis ohjelmisto. Kustannustehokkuuteen ohjelmistojen laadussa päästään silloin, kun testauksen suunnittelu aloitetaan mahdollisimman varhaisessa vaiheessa yhtä aikaa itse ohjelmistoprojektin kanssa. 5

11 2.3 Testauksen laatu Testauksen laatua voidaan mitata sillä, miten kattavasti testaus on suoritettu. Täydellisestä kattavuudesta puhutaan silloin, kun ohjelmiston kaikki mahdolliset reitit on tutkittu kaikilla mahdollisilla syötteillä. Tämä on käytännössä mahdotonta toteuttaa. Testausprosessi on sidottu käytettävissä oleviin resursseihin kuten raha, aika ja henkilöstöresurssit. Kattavuudesta on kerrottu luvussa 4.2 lasilaatikkotestauksen yhteydessä ja luvussa 5.3 Testauksen tehokkuuden arvioinnin yhteydessä. (Enqvist ym. 2001, 3.) 2.4 Laadunvarmistus Laadunvarmistuksen yhteydessä puhutaan katselmuksesta (tekninen katselmus, technical review) sekä todentamisesta ja kelpoistamisesta (verification and validation). Katselmuksessa todetaan jonkin vaiheen päättyminen. Siinä varmistetaan, että asetetut kriteerit on täytetty ja vaaditut asiat suoritettu. Katselmuksia pidetään esimerkiksi määrittely- tai suunnitteluvaiheen päättyessä. Laadunvarmistamisen lisäksi toimenpiteillä saavutetaan projektin etenemisen näkyvyys. Myös tietämys kohteena olevasta ohjelmistosta lisääntyy, on sitten kyseessä uusi ohjelmisto tai ohjelmistoon tehtävät muutokset. Todentaminen ja kelpoistaminen puolestaan ovat ohjelmiston laadun tarkastelua. Todentamisessa (objektiivinen laatu) esimerkiksi järjestelmätestauksen yhteydessä verrataan tuotetta sen toiminnalliseen määrittelyyn. Todentamismenettelyjä ovat tarkastusmenettely (inspection) ja läpikäynti (walkthrough). Tarkastuksissa dokumentteja verrataan vaatimusmäärittelyihin ja läpikäynnissä tarkastus tehdään yleensä koodille. Kelpoistamisessa tarkastellaan tuotteen sopivuutta sen käyttötarkoitukseen (subjektiivinen laatu). Katselmusten ja tarkastusten erona voidaan pitää sitä, että katselmuksessa havaittu virhe on merkki huonosti tehdystä työstä, kun taas tarkastuksessa havaittu virhe on merkki hyvin tehdystä työstä. Virheiden korjaukset maksavat huomattavasti enemmän, jos ne havaitaan katselmuksessa. Virheiden kustannusvaikutuksista projektiin on enemmän tarkastusten yhteydessä tässä luvussa. Kuviosta 1 selviää tarkemmin miten katselmukset ja tarkastukset projektiin ajoittuvat. (Haikala & Märijärvi 2006, ) 6

12 esitutkimus & määrittely suunnittelu ohjelmointi ja tarkastus katselmus, toimittajan katselmus, asiakas mukana integrointi järjestelmätestaus aika Kuvio 1. Projektin katselmukset ja tarkastukset (Haikala & Märijärvi 2006, 52) Tarkastukset Tässä käytetään termiä tarkastus, mutta samaa menetelmää voi käyttää myös katselmukseen ja läpikäyntiin. Tarkastusten oppi-isä on Fagan, joka kehitti menetelmän IBM:llä jo 1970-luvulla. Tarkastusten avulla pyritään auttamaan ohjelmistoprojektin elinkaaren (määrittely-suunnittelutoteutus-testaus-käyttöönotto) etenemistä niin, että virheet löydettäisiin mahdollisimman varhaisessa vaiheessa ja eteneminen olisi näkyvää. Tarkastukset kannattaisi tehdä ainakin määrittelydokumentille, projektisuunnitelmalle, suunnitteludokumenteille ja testiraporteille. Tarkastuksen vaiheita ovat tarkastuksen suunnittelu, tarkastustilaisuus, virheiden korjaaminen ja jälkiseuranta. Koska tarkastusten suunnittelua olisi hyvä tehdä jo projektisuunnittelun yhteydessä, tämä täytyisi huomioida projektisuunnitelmaa tehtäessä varaamalla aikaa tarkastuksiin. (Haikala & Märijärvi 2006, ) 7

13 Tarkastettava materiaali jaetaan osallistujille ajoissa, jotta he ehtivät tutustua tarkastettavaan aiheeseen ja löytää mahdolliset virheet tai ongelmakohdat. Itse tarkastustilaisuudessa dokumentti käydään läpi ja kaikki löydetyt virheet kirjataan ylös. Sovitaan myös siitä, kuka korjaa löydetyt virheet ja miten jälkiseuranta toteutetaan. (Enqvist ym. 2001, 8.) Tarkastukset ovat mm. testausta tehokkaampi virheiden etsintäkeino. Haikalan ja Märijärven (2006, 275) mukaan määrittelyvirheen korjaaminen suunnitteluvaiheessa on neljä kertaa kalliimpaa kuin heti määrittelyn yhteydessä. Moduulisuunnitteluvaiheessa kerroin on 7 jne. Suunnitteluvirheet vaikuttavat samalla tavalla. Kuvio 2 havainnollistaa virhekustannusten kertoimia suhteessa siihen, milloin virheet havaitaan. Tarkastuksilla voidaan löytää 80 % kaikista virheistä. Tarkastuksiin kuluu yleensä 5-15 % projektin kokonaistyöajasta. Muita hyviä puolia tarkastuksissa on, että tarkastuksiin tuotetaan mahdollisimman valmista materiaalia. Kukaan ei halua päästää käsistään keskeneräistä työtä muiden tarkastettavaksi. Toinen erittäin tärkeä tekijä on tiedonkulku, tarkastukset toimivat erinomaisena tiedotus- ja koulutustilaisuutena. Kuvio 2. Virhekustannusten kertoimia (Haikala & Märijärvi 2006, 275, teoksessa Jalote 1999) Kuvio 3 puolestaan havainnollistaa virheiden aiheuttaman lisätyön osuutta eri vaiheissa ilman tarkastuksia tai tarkastusten kanssa. Vasemmanpuoleinen pylväs kertoo, miten paljon virheiden korjaamiseen kuluu resursseja, jos tarkastuksia ei käytetä. Tällöin virheiden korjaus tapahtuu 8

14 testausvaiheessa, joka aiheuttaa enemmän lisätyötä kuin jos olisi käytetty tarkastuksia. Oikeanpuoleisesta pylväästä näkyy, että kustannukset voivat alkuvaiheessa kasvaa tarkastusten seurauksena, mutta testausvaiheessa kustannukset ovat huomattavasti pienemmät. (Haikala & Märijärvi 2006, 276.) Ilman tarkastuksia Tarkastusten kanssa Määrittely Määrittely Suunnittelu Suunnittelu Ohjelmointi, moduulitestaus Integrointi, testaus Ohjelmointi, moduulitestaus Integrointi, testaus varsinainen työ virheiden aiheuttama lisätyö Kuvio 3. Virheiden aiheuttaman lisätyön osuus ei vaiheissa (Haikala & Märijärvi 2006, 276) 9

15 3 Ohjelmistoprojektit ja testaus Ohjelmistoprojektista erotellaan yleisesti seuraavat vaiheet: määrittely, suunnittelu, toteutus ja testaus sekä näitä vaiheita seuraavat käyttöönotto ja lopuksi ohjelmiston ylläpito. Yleisimmin kuvattu vaihejakomalli on vesiputousmalli, jonka perinteinen versio on kuvattuna kuviossa 4. Mallista löytyy eri versioita, mutta yleensä niistä löytyvät määrittely-, suunnittelu- ja toteutusvaiheet. Määrittelyvaihetta edeltää usein tarvekartoitus. Perinteisen vesiputousmallin hyvinä puolina voidaan pitää sitä, että kaikki voimavarat keskittyvät aina yhteen vaiheeseen kerrallaan ja seuraavaan vaiheeseen mentäessä edellisen vaiheen tuotokset ovat käytettävissä. Vaatimukset Määrittely Suunnittelu Toteutus Testaus Käyttöönotto ja ylläpito Kuvio 4. Perinteinen vesiputousmalli ohjelmistotuotantoprosessin vaiheista Kuten kuviosta 4 käy ilmi, ongelmakohtana voidaan pitää varsinaisen testauksen sijoittumista vaihejakomallissa prosessin loppuun ennen käyttöönottoa. Vasta tässä vaiheessa aloitettuna testaus tuottaa huomattavasti enemmän kustannuksia projektiin, kuin että testauksen suunnittelu aloitetaan heti projektin alussa määrittelyvaiheen alkaessa. Toinen ongelma testaajien kannalta on, että yleensä testausvaiheessa ohjelmistoprojektilla on jo kiire ja testattava aineisto tulee usein myöhässä. Testausajan jäädessä liian lyhyeksi, ohjelmiston laatu kärsii. (Craig & Jaskiel 2002, 7 8.) 10

16 3.1 Testauksen sijoittuminen ohjelmistoprojektiin Kuten aikaisemmin on jo tullut ilmi, tulisi testaus aloittaa mahdollisimman varhaisessa vaiheessa, mieluiten heti määrittelyvaiheessa. Graig ja Jaskiel (2002, 10 21) puhuvat kirjassaan STEP metodologiasta (The Systematic Test and Evaluation Process). Se perustuu IEEE standardiin , joka on standardi ohjelmistojen testausdokumenteille (Standard for Software Test Documentation). Se on ensimmäisen kerran esitelty Metodologia perustuu ajatukselle, joka näkee testauksen prosessina, joka menee rinnakkain ohjelmistokehityksen tai ohjelmiston ylläpidon kanssa. Metodologia jakautuu samoihin työvaiheisiin, joista Haikala ja Märijärvikin (2006, 283) ovat teoksessaan kertoneet eli testauksen suunnittelu (yleinen testaussuunnitelma ja yksityiskohtainen testaussuunnitelma), testiympäristön luominen, testin suorittaminen ja testitulosten tarkastelu. STEP metodologian suurimmat erot perinteiseen testaukseen ovat testauksen aloittaminen ajoissa heti määrittelyvaiheen yhteydessä ja tätä kautta riskien parempi hallinta. Myös dokumentointi on parempaa ja tekee testauksen näkyväksi. Riippuen projektin suuruudesta, onko kysymyksessä uusi ohjelmisto vai ohjelmiston ylläpito, eri vaiheisiin käytettävät panokset voivat vaihdella suurestikin. Oheisessa kuviossa 5, Jäntti (2003, 21) on kuvannut projektin eri vaiheet, sekä miten testaus sijoittuu suhteessa projektin etenemiseen. Oheisen mallin mukaan edeten voidaan puhua ennalta ehkäisevästä testauksesta. Testauksessa voidaan erotella neljä eri testaustasoa: yksikkö-, integrointi-, järjestelmä- ja hyväksymistestaus. Eri testaustasoista kerrotaan enemmän luvussa

17 Projektin vaihe Vaatimukset Määrittely Suunnittelu Toteutus Testaus Käyttöönotto Tulosdokumentti Projektisuunnitelma, Vaatimusmäärittely Systeemin määrittely, Testaussuunnitelma ja testitapausten kuvaus Tekninen ja toiminnallinen kuvaus, Alustava käyttöohje Ohjelmakoodi, Ohjelmistokuvaus Testauslistat, Testausraportti Käyttöohje, Loppuraportti Testausvaihe Testauksen alustava suunnittelu Määrittelyn tarkastus ja testi- tapausten tarkentaminen Suunnittelun tarkastus ja testitapausten tarkentaminen Testitapaukset valmiina Moduulitestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus Kuvio 5. Testauksen suunnittelu ohjelmistotuotannon eri vaiheissa (Jäntti 2003, 21) 3.2 Testaustasot Yleisin käytetty testausmalli on V-malli. Kuviossa 6 on kyseinen malli esiteltynä. Mallin mukaisesti testauksen suunnittelu tehdään testaustasoa vastaavalla suunnittelutasolla. Hyväksymistestaus suunnitellaan vaatimusmäärittelyvaiheessa, järjestelmätestaus suunnitellaan määrittelyvaiheessa, integrointitestaus arkkitehtuurisuunnitteluvaiheessa ja moduulitestaus moduulisuunnitteluvaiheessa. Testaukseen kuuluvat vaiheet ovat suunnittelu, suoritus ja dokumentointi. (Haikala & Märijärvi 2006, 288.) Joissakin V-malleissa ei hyväksymistestaustasoa esitetä. Otan kuitenkin tähän malliin mukaan kaikki neljä tasoa, koska esityksen tarkoituksena on kattaa testaus kokonaisuudessaan. 12

18 Projektin taso Testaustaso Vaatimusmäärittely Määrittely Arkkitehtuurisuunnittelu Testauksen suunnittelu ja tulosten verifiointi Integrointitestaus Hyväksymistestaus Järjestelmätestaus Moduulisuunnittelu Moduulitestaus Ohjelmointi Kuvio 6. Testauksen V-malli (Jäntti 2003, 13) Itse testaus tapahtuu käänteisessä järjestyksessä eli vaikka hyväksymistestaus on ensimmäinen joka suunnitellaan, se testataan viimeisenä. Suunnittelu alkaa hyväksymistestauksesta, koska projektisuunnittelussa vaatimusmäärittely tehdään ensimmäisenä. Kun siirrytään testauksen suunnittelussa seuraavalle tasolle, suunnittelun perusteena ovat edellisen ja kyseisen tason suunnittelun määritykset, niin että moduulitestausta suunniteltaessa käytössä ovat moduulisuunnittelun, arkkitehtuurisuunnittelun, määrittelyn ja vaatimusmäärittelyn määritelmät. Kaikissa testaussuunnitelmissa määritellään kriteerit, milloin testaus voidaan aloittaa ja milloin siirrytään seuraavaan vaiheeseen. Testaustasot esitellään ylhäältä alaspäin, koska testien suunnittelukin aloitetaan sieltä eli hyväksymistestauksesta. (Craig & Jaskiel 2002, 101.) Hyväksymistestaus Hyväksymistestaus perustuu vaatimusmäärityksiin ja testauksen on tarkoitus näyttää toteen, että nuo vaatimukset on huomioitu. Testaussuunnitelman yksi päätarkoitus on määritellä millä kriteereillä ohjelmisto katsotaan hyväksytyksi. Testaussuunnitelman ja testitapausten on tarkoitus näyttää asiakkaalle tai hyväksyjälle, miltä ohjelmisto tai järjestelmä näyttää, kun se on val- 13

19 mis. Testausta voidaan siis pitää myös demo-tilaisuutena. Hyväksymistestaus on asiakkaan vastuulla. Yleensä hyväksymistestauksessa on läsnä it-henkilöstöä, asiakkaan edustajia tai organisaation sisäisissä projekteissa ohjelmiston käyttäjiä. Testaussuunnitelmaa tehtäessä on syytä kiinnittää huomiota, ettei sanasto ole liian teknistä. Hyväksymistestaussuunnitelmaa tehtäessä tarvitaan projektisuunnitelma, yleistestaussuunnitelma ja vaatimusmäärittelydokumentti. Testitapauksia suunniteltaessa vaatimukset otetaan huomioon niin, että yhtä vaatimusta testataan yhdessä tai useammassa testitapauksessa ja näin vaatimukset ovat jäljitettävissä. Hyväksymistestausta suoritettaessa tulisi testiympäristön vastata todellisuutta mahdollisimman hyvin. (Craig & Jaskiel 2002, ) Järjestelmätestaus Järjestelmätestauksessa koko järjestelmä (ohjelmisto, laitteisto, tietokanta) on tarkastelun kohteena. Järjestelmätestauksen suunnittelussa käytetään hyväksi määrittelydokumenttia, jossa on ohjelmiston toiminnallinen määrittely sekä asiakas- ja suunnitteludokumentteja, jos nämä kaikki ovat olemassa. Järjestelmätestauksen suunnittelu voidaan siis aloittaa heti kun määrittely-, asiakas- ja suunnitteludokumentaatio on valmis. Jos hyväksymistestaustasoa ei ole erikseen määritelty, se liitetään järjestelmätestaukseen. Järjestelmätestauksessa testataan myös järjestelmän ei-toiminnalliset ominaisuudet mm. kuormitustestit, luotettavuustestit ja asennustestit. Järjestelmätestaus pohjautuu integrointitestauksen tuloksiin. (Haikala & Märijärvi 2006, 288.) Jos järjestelmätestaus aloitetaan ennen kuin integrointitestaus on lopetettu, voi järjestelmätestauksessa tulla ilmi virheitä, jotka olisi huomattu jo integrointitestausvaiheessa. Tällaisten virheiden korjaamiseen menee enemmän aikaa ja rahaa. Virheiden korjauksen jälkeen järjestelmätestausta joudutaan suorittamaan uudelleen eli tekemään ns. regressiotestausta. Järjestelmätestauksesta saadaan paras mahdollinen testaustulos, kun integrointitestauksen hyväksymiskriteerit ja järjestelmätestauksen aloituskriteerit on määritelty. Aloituskriteereinä voi olla edellisen tason hyväksymiskriteereitä sekä esimerkiksi testausympäristön perustaminen ja testidatan kerääminen. (Craig & Jaskiel 2002, ) Järjestelmätestauksessa koko järjestelmä testataan yhtenä kokonaisuutena, koska yksittäiset osat on jo testattu aikaisemmin. Testaus on luonteeltaan mustalaatikkotestausta. Testausmenetelmistä kerrotaan luvussa 4. Tässä vaiheessa voi tulla ilmi, että laitteisto- ja komponenttikokoonpano eivät toimikaan oletetusti yhdessä, suorituskyky on liian alhainen, virhetilanteiden 14

20 toipuminen on heikkoa tai ohjelmiston turvallisuudessa voi olla puutteita. Jäntti (2003, teoksessa Paakki 2000, 15) esittää järjestelmätestauksesta seuraavia muotoja: volyymitestaus (volume testing) määrittelee, pystyykö järjestelmätestaus käsittelemään riittävää määrää tietoa tai pyyntöjä kuormitustestaus (load/stress testing) tunnistaa kuormitushuiput, joissa järjestelmä voi epäonnistua käsittelemään tietoa annetuilla aikarajoilla turvallisuustestaus (security testing) osoittaa, että järjestelmä täyttää sille asetetut turvallisuusvaatimukset suorituskykytestaus (performance testing) määrittelee, täyttääkö järjestelmä sille asetetut suorituskykyvaatimukset resurssien käytön testaus (resource usage testing) tarkistaa, käyttääkö järjestelmä liikaa resursseja kuten muistia tai levytilaa tms. konfiguraatiotestaus (configuration testing) näyttää, toimiiko järjestelmä oikein, kun ohjelmisto, laitteisto, tietokannat ja ulkoiset laitteet on liitetty yhteen asennettavuustestaus (installability testing) testaa, johtaako asennusprosessi epäonnistuneeseen asennukseen toipumistestaus (recovery testing) osoittaa, miten järjestelmä täyttää sille asetetut vaatimukset uudelleenkäynnistämiseen johtavan virheen tai muun virheen jälkeen luotettavuus/saatavuustestaus (reliability/availability testing) määrittelee, täyttääkö järjestelmä sille asetetut luotettavuus- ja saatavuusvaatimukset. Esim. kuinka usein järjestelmä on käytettävissä. Integrointitestaus Integrointitestauksessa yhdistellään yhteen moduuleita tai moduuliryhmiä (osajärjestelmiä). Testauksessa keskitytään moduulien välisten rajapintojen toimivuuteen ja tiedonvaihdon oikeellisuuteen. On huomioitava, että muuttujia on voitu määritellä globaalisti tiedostojen tai tietokantojen avulla. Integrointitestausta suunniteltaessa käytetään hyväksi arkkitehtuurisuunnittelun (teknisen määrittelyn) dokumentteja, määrittely- ja suunnitteludokumentteja sekä käyttöohjeita. Arkkitehtuurisuunnittelussa määritellään karkean tason ohjelmistomoduulit ja niiden väliset yhteydet. Testauksen suunnittelu voidaan aloittaa, kun nämä ovat valmiina. Integrointitestaus käyttää hyväkseen moduulitestauksen tuloksia. Haikalan ja Märijärven (2006, 290) mukaan integrointitestaus voi edetä rinnan moduulitestauksen kanssa. 15

21 Vaikka yksittäiset moduulit onkin jo testattu moduulitestauksessa, integrointitestauksessa löydetään mahdolliset ongelmakohdat, joissa nämä moduulit eivät yhdessä toimi oikein. Virheellisessä tilanteessa esimerkiksi tietoa voi hävitä moduulien rajapinnoilla tai moduulit eivät ole yhteensopivia. Virheitä voi myös syntyä, jos suunnitteluvaiheessa ei ole huomioitu, voiko kutsuttu moduuli saada virheellistä tietoa vai ei tai mitä arvoja virhetilanteissa saadaan. Testausmenetelmänä voidaan käyttää Big Bang-menetelmää, jossa testaus tehdään liittämällä kaikki moduulit kerralla yhteen. Muita testausmenetelmiä on testata järjestelmää inkrementaalisesti liittämällä moduulit yhteen kokoavasti bottom-up periaatteella alemman tason moduuleista ylöspäin. Jäsentävässä top-down periaatteessa etenemissuunta on päinvastainen. Inkrementaalisen testauksen hyötynä on virheiden helpompi paikallistaminen alimoduuleista. Testausmenetelmistä on kerrottu enemmän kappaleissa 4. (Jäntti 2003, 14.) Integrointitestaus olisi hyvä aloittaa kriittisimmistä kohdista, joissa tn. tulee vastaan eniten ongelmia, jotta ne saadaan selvitetyksi. Testauksen laajuus vaihtelee kohteen mukaan. Testattavana voi olla yksittäinen ohjelma tai laaja järjestelmä, joka koostuu monista osajärjestelmistä, ohjelmista ja niiden moduuleista. Integrointitestauksen hierarkiaa on kuvattu kuviossa 7. Testiä suunniteltaessa tulisi määritellä mitkä moduulit tai kohteet testataan ryhmänä, mitkä ovat kriittisiä piirteitä, kuinka paljon testausta suoritetaan, milloin testaus aloitetaan ja mitkä ovat testauksen lopettamiskriteerit. (Craig & Jaskiel 2002, ) Järjestelmä Osajärjestelmä A Osajärjestelmä B Ohjelma A Ohjelma B Ohjelma C Mod. 1 Mod. 2 Mod. 3 Mod. 4 Mod. 5 Kuvio 7. Integrointitestauksen hierarkiaa 16

22 Moduulitestaus Moduulitestauksessa testattavana on yksi moduuli, joka koostuu yleensä n ohjelmarivistä. Testauksen suunnittelussa käytetään hyväksi moduulisuunnittelun ja edellisten tasojen määritelmiä. Suunnitteluvaiheessa laaditaan testitapausten luettelo ja suunnitellaan testaamistapa. Moduulin toimintaa verrataan moduulisuunnittelun ja arkkitehtuurisuunnittelussa lähinnä teknisen määrittelyn tuloksiin. Testauksen lähtökohtana on, että ohjelmointi on tehty. Testauksen suorittaa yleensä moduulin toteuttaja. Moduulin toteuttamiseen voidaan joutua laatimaan testiajureita (test drivers) ja tynkämoduuleita (test stubs). Testiajurit mahdollistavat moduulien toteuttamien palveluiden kutsumisen ja tulosten tarkastelun. Tynkämoduulit esittävät aliohjelmaa, jota testattava moduuli kutsuu. (Haikala & Märijärvi 2006, 289.) Ohjelmarivin pieni määrä helpottaa moduulitestauksessa virheiden löytymistä ja tässä vaiheessa virheiden korjauskustannukset ovat vielä pieniä. Moduulitestaus on luonteeltaan lasilaatikkotestausta, ts. moduulien rakenne tunnetaan yksityiskohtaisesti. Kun moduulit on testattu, voidaan testauksen ylemmillä tasoilla luottaa yksittäisten moduulien toimivuuteen. Moduulitestauksessa tehokkaita virheiden tai huonosti toteutettujen ratkaisujen etsintäkeinoja ovat tarkastukset ja läpikäynnit. Eräs tehokas keino on myös parityöskentely, jossa henkilö A kirjoittaa testitapaukset määritysten pohjalta valmiiksi henkilölle B ennen koodin kirjoitusta ja päinvastoin. Testitapausten määrittäminen ennen koodauksen aloittamista helpottaa itse koodaustyötä. Parityöskentelyn toisena hyvänä puolena voidaan pitää tietotaidon jakamista useammalle henkilölle. (Craig & Jaskiel 2002, ) Partasen (2009, 21) mukaan ohjelmistoprojektin luonteesta riippuen moduuleita voidaan ottaa integrointitestaukseen varhaisessa vaiheessa, jolloin moduuli sisältää vain perustoimintoja. Näin pystytään lisäämään projektin joustavuutta, mutta tämä edellyttää hyvää kommunikointia ohjelmistokehittäjien ja testaajien välillä. 17

23 4 Testausmenetelmät Testausmenetelmän valinta riippuu testattavan ohjelmiston luonteesta, testaustasosta ja testaajien testaustaidoista. Menetelmät jaetaan staattisiin ja dynaamisiin testausmenetelmiin. Seuraavissa luvuissa kerrotaan enemmän näistä testausmenetelmistä ja testitapausten valinnasta. 4.1 Staattiset menetelmät Ohjelmiston staattinen analyysi tarkoittaa ohjelmiston arkkitehtuuri- ja moduulisuunnitelmien tai itse ohjelmakoodin tarkastelua ja analysointia ilman ohjelmakoodin suorittamista. Analysointi voidaan suorittaa joko käsin tai automaattisesti koodin analysointiohjelmalla. Staattinen analyysi voi paljastaa muuttujiin tai parametreihin liittyvät virhekäytöt, indeksien ja osoittimien virheellisen käytön tai funktiokutsuihin liittyvät ongelmat, kuten kutsumattomat funktiot. (Partanen 2009, 29.) Staattisiin menetelmiin kuuluvat tarkastukset, katselmoinnit ja läpikäynnit, joista on puhuttu luvussa 2.4 Laadunvarmistus. Staattista analyysiä voidaan suorittaa eri testaustasoilla, mutta näiden painottuminen testauksen alkupäähän pienentää kustannuksia. 4.2 Dynaamiset menetelmät Dynaaminen analyysi testausmenetelmänä on ohjelmiston varsinaista testaamista ohjelmakoodia suorittamalla niin, että pyritään löytämään virheitä. Tällöin keskitytään ohjelman ja koodin käyttäytymiseen ohjelman suorituksen aikana. Mustalaatikkotestaus Mustalaatikkotestaus (Black-Box testing) perustuu testattavana olevan kohteen (ohjelma tai funktio) syötteisiin ja tulosteisiin. Mustalaatikkotestauksessa ei välitetä testattavana olevan kohteen rakenteesta tai sisällöstä (koodista), vaan tutkittavana ovat kohteen tulosteet erilaisilla syötearvoilla. Testaajalle kohde on ikään kuin musta laatikko. Kuten kuviosta 8 nähdään, testauksen oikeellisuutta tarkastellaan vertaamalla saatuja tuloksia oikeisiin tai haluttuihin tulosteisiin. Ohjelman ja sen ympäristön pitää jäädä suorituksen jälkeen oikeaan tilaan. Testitapaukset johdetaan aina kohteen määrittelyn perusteella. (Enqvist ym. 2001, 8.) 18

24 Testitapahtumat eli syötteet Testattava kohde Saadut tulosteet Tulosten vertailu Testattavan kohteen määrittely Odotetut tulosteet Kuvio 8. Mustalaatikkotestaus (Enqvist ym. 2001, 8) Testitapausten suunnittelu voidaan aloittaa, kun vaatimusmäärittely ja määrittelydokumentti on tehty, siis ennen kuin ohjelmakoodia on olemassa. Testitapausten suunnittelu jo tässä vaiheessa auttaa parantamaan moduulisuunnittelua ja ohjelmakoodin kirjoittamista. Testitapausten valintaan mustalaatikkotestauksessa on olemassa mm. seuraavia tekniikoita: Ekvivalenssiositus (Equivalence partitioning) Tässä tekniikassa on pyrkimyksenä jakaa testattava aineisto ekvivalenssiluokkiin siten, että testauksesta tulee mahdollisimman kattava ja testitapausten määrä pysyisi kuitenkin pienenä. Kaikilla mahdollisilla syötteillä on lähes mahdotonta testata ohjelmistoa tai se ei ole ainakaan järkevää. Ideana on jakaa testitapaukset siten, että yhteen ekvivalenssiluokkaan tulevat syötteet, joita ohjelmisto käsittelee samalla lailla ja tuottaa samanlaisia tulosteita. Mikä tahansa arvo luokassa edustaa koko luokkaa. Lisäksi valitaan vielä ekvivalenssiluokka, johon tulevat kelvottomat tai laittomat arvot. Kun jako on tehty, testitapaukset voidaan valita kattavasti eri ekvivalenssiluokista. Kuviossa 9 on havainnollistettu testitapausten jakoa. Esimerkkinä ottoautomaatti, josta voi nostaa 20 seteleitä :n väliltä. Testitapaukset voidaan jakaa kolmeen eri ekvivalenssiluokkaan, joista jokaisesta otetaan yksi testitapaus testattavaksi. Kattavaan testaukseen riittää tässä tapauksessa kolme testitapausta. (Craig & Jaskiel 2002, ) 19

25 kelvottomat arvot kelvolliset arvot kelvottomat arvot alle yli 20 Kuvio 9. Esimerkki ekvivalenssiluokkiin jaosta (Craig & Jaskiel 2002, ) Raja-arvoanalyysi (Boundary value analysis) Tässä tekniikassa testattavat tapahtumat valitaan nimensä mukaisesti rajoilla olevista äärimmäisistä arvoista. Jos käytetään ekvivalenssiluokitusta, tulevat raja-arvotkin usein käytännössä testattua. Raja-arvot ovat erittäin tärkeitä testauksen kohteita, koska niissä tapahtuu herkästi virheitä. Craigin ja Jaskielin (2002, 166) mukaan raja-arvojen lisäksi testataan arvo, joka on välittömästi ylimmän raja-arvon yläpuolella ja alimman raja-arvon alapuolella. Esimerkin mukaan, joka esiteltiin kuviossa 9, testattavia arvoja olisivat: 0, joka on alimman raja-arvon alapuolella (kelvoton) 20 alin raja-arvo (kelvollinen) 200 ylin raja-arvo (kelvollinen) 220, joka on ylimmän raja-arvon yläpuolella (kelvoton). Jos syötejoukko on järjestetty, testataan ensimmäinen ja viimeinen syöte. Virheen arvaus (Error guessing) Enqvist (2001, 9) esittelee virheen arvauksen yhtenä paljon käytettynä testausmuotona. Menetelmä perustuu testaajan ammattitaitoon, kokemukseen, sovellusalueen tuntemukseen ja aikaisempiin testiraportteihin. Virheen arvaus-menetelmässä listataan kaikki mahdolliset mieleen tulevat testitapaukset, joilla testaus saadaan epäonnistumaan ja suoritetaan testaus näillä tapauksilla. Tyypillisesti 0 tai tyhjä ovat arvoja, jotka aiheuttavat ongelmia ohjelmistoissa. Tämä on hyvä lisä muille menetelmille, mutta ei itsessään täysin kattava. 20

26 Sattumanvarainen testaus (Random testing) Tässä tekniikassa testiaineisto valitaan umpimähkään, yleensä jonkin työkalun avulla ja testaus suoritetaan tällä syötejoukolla. Tämä tekniikka ei ole suositeltava, koska sattumanvaraisesti valittu testiaineisto voi kuulua ainoastaan yhteen edellä mainittuun ekvivalenssiluokkaan. Testiaineistosta ei näin ollen saada luotettavasti kattavaa. (Craig & Jaskiel 2002, ) Käyttöliittymän testaus Jäntti (2003, 19) ottaa esille käyttöliittymän testauksen yhtenä mustalaatikkotestausmenetelmänä. Käyttöliittymää testattaessa ohjelmiston sisäinen toteutus on piilossa. Tätä testausmenetelmää käytetään järjestelmä- ja hyväksymistestaustasoilla. Käyttöliittymävirheitä voivat olla mm. näyttövirheet (tieto on väärässä paikassa) tai virheellinen suoritusjärjestys (tallennus jää kesken). Lasilaatikkotestaus Lasilaatikkotestauksessa (White-Box testing, Glass-Box testing) testaaja näkee ohjelmiston rakenteen eli koodin. Testitapahtumat voidaan suunnitella koodin perusteella. Kuviossa 10 on havainnollistettu lasilaatikkotestauksen toimintapataa. Testaus tapahtuu nimenomaan ohjelmiston toiminnallisuuden perusteella eikä testaaja välitä ohjelmistolle asetetuista vaatimuksista. Lasilaatikkotestausta suoritetaan moduulitestaustasolla, koska testauksessa keskitytään yksityiskohtiin. (Enqvist ym. 2001, 10.) Saadut Testitapahtumat eli syötteet Testattava (tunnettu) kohde tulosteet Odotetut Tulosten vertailu tulosteet Kuvio 10. Lasilaatikkotestaus (Enqvist ym. 2001, 10) 21

27 Lasilaatikkotestauksessa testaus etenee loogisia polkuja pitkin. Tämän takia testitapausten valinnassa tavoitteena on, että kaikki kohteen (ohjelman tai funktion) haarat ja ohjelmapolut tulisivat käytyä läpi. Testidatan valinnalla pyritään mahdollisimman kattavaan testaukseen. Kattavuusmitoilla yritetään varmistua, että ohjelman kaikki osat tulisi kattavasti suoritettua. Testauksen kattavuutta voidaan mitata eri tavoilla ja nämä eri tavat määräävät myös testidatan valintaa. Korkein kattavuus saavutetaan moduulitestaustasolla. Edettäessä V-mallissa ylöspäin kattavuus yleensä laskee. Seuraavaksi esiteltyinä koodikattavuuteen liittyviä tekniikoita, joiden kriteerien mukaan testitapaukset voidaan valita: (Haikala & Märijärvi 2006, ) Lausekattavuus (Statement coverage) Lausekattavuudella tarkoitetaan, että ohjelman jokainen lause suoritetaan vähintään kerran. Todellisuudessa päästään harvoin tilanteeseen, jossa saavutetaan 100 % lausekattavuus. Haikalan ja Märijärven (2006, 295) mukaan pienenkin koodimoduulin todellinen kattavuus ylittää harvoin 90 %. Polkujen kattavuus (Path coverage) Tekniikan mukaan kaikki ohjelman polkujen vaihtoehdot tulisi pystyä suorittamaan valituilla testitapauksilla. Polulla tarkoitetaan ohjelman kohtaa, jossa on kaksi tai useampia vaihtoehtoisesti suoritettavia lauseita (if-else, switch-case jne.). Täydellinen polkujen kattavuus on mahdollista saavuttaa vain yhden yksinkertaisen funktion sisällä. Ehtokattavuus (Condition coverage) Ehtokattavuudessa edellytetään, että päätöksen kaikkien osaehtojen on saatava molemmat arvonsa (tosi/epätosi). Päätöskattavuus (Decision coverage) Tekniikassa edellytetään, että ehtorakenteen päätös saa vähintään kerran molemmat arvonsa (tosi/epätosi). 22

28 Harmaalaatikkotestaus Harmaalaatikkotestaus (Gray box testing) on musta- ja lasilaatikkotestauksen välimuoto. Tekniikassa käytetään hyväksi tietoa ohjelman toteutusperiaatteista. Testataan yleensä raja-alueita kuten ali- ja ylivuotoja, nollalla jakamista, pyöristyksiä ja esim. kuukauden alku- ja loppupäiviä. Siirryttäessä V-mallissa alimmalta tasolta ylöspäin testauksen luonne muuttuu lasilaatikkotestauksesta enemmän mustalaatikkotestaukseksi. (Haikala & Märijärvi 2006, 291.) Top-dowm-testaus Top-down-tekniikassa testaus aloitetaan ohjelman korkeimman tason moduuleista ja tämän jälkeen edetään alemman tason moduulien ja komponenttien testaukseen. Koska testaus aloitetaan ylemmältä tasolta, täytyy alemman tason moduuleita simuloida. Tähän tarvitaan tyhmiä moduuleita tai moduulin pätkiä (module stubs), jotka ovat yksinkertaisia eivätkä sisällä monimutkaista toiminnallisuutta. Kun testaus etenee alemmalle tasolle, stub-moduulit korvataan oikeilla moduuleilla. Etuina tässä menetelmässä ovat varhaisessa vaiheessa saatava alustava ohjelma sekä kahden mahdollisesti erillisen testitason yhdistyminen esim. integrointi- ja järjestelmätestitasojen. (Enqvist ym. 2001, ) Bottom-up-testaus Bottom-up-tekniikassa testaus aloitetaan alimman tason moduuleista, jotka eivät kutsu tai käytä muita moduuleita. Testaus etenee alhaalta ylöspäin, kunnes koko ohjelma on testattu. Tekniikka vaatii testiajureiden (test drivers) luomisen, jotta alimman tason moduuleita voidaan suorittaa ja testata. Tämän menetelmän etuna on testiaineiston helppo valinta. Jos moduulien alimmilla tasoilla on kriittisiä tai virhealttiita kohtia, kannattaa käyttää bottom-up-tekniikkaa. Haittapuoleksi voidaan katsoa, että mitään ohjelmaa ei ole valmiina ennen kuin viimeinenkin ylimmän tason moduuli on testattu. Testausta ei myöskään voida aloittaa ennen kuin alimmankin tason moduulit on suunniteltu ja määritelty. (Enqvist ym. 2001, 12.) 23

29 5 Testauksen riittävyyden arviointi Milloin testaus sitten pitäisi lopettaa? Etukäteen on vaikea arvioida kuinka kauan testejä tulisi suorittaa. Testaussuunnitelmassa tulisi olla hyväksymiskriteerit, milloin testaus on hyväksytty ja voidaan siirtyä seuraavaan vaiheeseen. Kriteerinä voi olla esimerkiksi löydettyjen virheiden määrä suhteessa korjattuihin virheisiin. Kun virhekäyrä tasaantuu, voidaan testaus lopettaa. Apuna voidaan myös käyttää kattavuusmittoja, joista on kerrottu luvussa 4.2 lasilaatikkotestausmenetelmien yhteydessä. (Haikala & Märijärvi 2006, 293.) Mitä nämä virheet ovat, mitä testauksessa etsitään? 5.1 Virheet, viat ja häiriöt Testauksessa keskitytään virheiden etsimiseen ja niiden eliminoimiseen. Testauksen yhteydessä virheet voidaan jaotella eri ryhmiin Haikalan ja Märijärven (2006, ) mukaan seuraavasti: virhe (error) on ihmisen (ohjelmistokehittäjän) tekemä poikkeama spesifikaatiosta. Tästä seuraa, että ilman spesifikaatiota testaus on mahdotonta, koska lopputulosta ei voida todentaa vika (fault) voi aiheutua järjestelmään, kun tällainen virheellinen kohta on ajettu. Vika voi korjautua itsestään toisen toiminnon seurauksena, mutta se voi myös aiheuttaa järjestelmään häiriön häiriö (failure) näkyy järjestelmän ulkoisessa toiminnassa. Esimerkiksi ottoautomaatilta nostettaessa tilin saldo laskettaisiin väärin. Termien käyttö ei ole vakiintunut. Yksi yleinen tulkinta on, että virhe (error) on ihmisen aiheuttama teko, jonka seurauksena syntyy vika (fault). Yleinen arvio virheiden määrästä on, että ohjelmoinnin jälkeen löytyy yksi virhe muutamaa kymmentä ohjelmariviä kohden. Pitempään käytössä olleista ohjelmista arvioidaan löytyvän yksi virhe tuhatta ohjelmariviä kohden. Virheiden korjaus kannattaa keskittää sinne, mistä niitä eniten löytyy. Jäntti (2003, 26) on esittänyt Pro Gradu tutkielmassaan, että virheitä esiintyy eniten ohjelmien suorituslogiikassa kuten 24

30 ehtolausekkeissa, toisto- ja silmukkarakenteissa. Rajapintavirheiden määrä on myös lisääntynyt komponenttipohjaisten sovellusten myötä. 5.2 Testauksen tilanneraportti Yleistestaussuunnitelmassa kerrotaan, miten testauksen tilannetta seurataan. Testauksen tilanneraportissa kerrotaan, mitä testauksia on tehty: testausten määrä, löydettyjen virheiden sijainti ja luokitusaste (kuinka vakavasta virheestä on kyse) sekä testauksen kattavuus. Raportti voi olla taulukkomuodossa, josta tilannetta on helppo seurata. Tilanneraportin avulla voidaan yhteistyökumppaneille jakaa tietoa testauksen tilanteesta. Tällainen raportti kertoo testattavien testitapausten määrästä. Mittarina voidaan käyttää myös aikapohjaista mittausta, jossa kerrotaan testaukseen mennyt aika. Toiminnallisessa tilanteen määrittelyssä huomioidaan kuinka paljon testitapaukset kattavat toiminnallisuutta. Jotkin testitapaukset kattavat liiketoiminnalle tärkeitä piirteitä enemmän kuin toiset. (Craig & Jaskiel 2002, ) 5.3 Testauksen tehokkuuden arviointi Kuinka tehokasta testaus on ollut? Näitä eri tekijöitä on yrityksissä Craigin ja Jaskielin (2002, ) mukaan jaettu yleisesti kolmeen eri kategoriaan kuvion 11 mukaan. Monet näistä mittareista mittaavat testauksen tehokkuuden lisäksi myös itse tuotteen laatua. Testauksen tehokkuuden arviointi Asiakastyytyväisyysmittarit selvitykset help desk soitot viittaukset yms. Virheet testauksessa löydetyt asiakkaan löytämät ikä, vakavuus, tiheys Kattavuus koodi suunnittelu vaatimus Kuvio 11. Testauksen tehokkuuden arviointi (Craigin & Jaskielin 2002, 269) 25

31 Asiakastyytyväisyys-mittarit Yleisesti käytettyjä asiakastyytyväisyys mittareita ovat soitot ohjelmistotukeen ja asiakastyytyväisyyskyselyt. Tyytyväisyyskyselyistä ei välttämättä saa objektiivista kuvaa todellisesta tilanteesta. Ongelmia voi tulla kysymysten asettelussa ja vastausten tulkinnassa. Vastauksista ei pystytä erottelemaan, mikä on ollut tehokkuutta testauksessa ja mikä on ollut itse ohjelmistoprojektin osuus. Asiakastyytyväisyyskyselyt antavat hyvän yleisen mielipiteen kokonaistilanteesta. Asiakastyytyväisyydellä mitataan kuitenkin ohjelmistoa vasta jälkeenpäin, kun se on jo tuotannossa. Ne antavat arvokasta tietoa yritykselle ja testaajille, mutta eivät pelkästään ratkaise ongelmaa, miten testauksen tehokkuutta mitataan. Virheet ja niiden mittaaminen Testauksessa löydetyt virheet kannattaa jaotella niiden vakavuuden mukaan, jotta saataisiin todenmukaisempi kuva testauksesta. Luonnollisesti, jos ohjelmistossa on paljon virheitä, löytyy myös testauksessa paljon virheitä. Eli tämä mittaa myös itse tuotteen laatua. Yleisempi mittari on löydetyt virheet tuotannossa tai asiakkaan toimesta. Näissäkin mitataan tehokkuutta, kun ohjelmisto on jo tuotannossa. Näistä mittareista onkin hyötyä yritykselle, kun katsotaan testausten tehokkuuden kehitystä pitkällä aikavälillä, ei niinkään kyseisen projektin kohdalla. Tähän ryhmään kuuluu myös virheen ikä, jossa virhe on sitä vanhempi, mitä myöhemmin se löydetään. Kuten aikaisemmin on jo todettu, virheen löytäminen ja korjaaminen tulee sitä kalliimmaksi, mitä myöhemmin se löydetään. Virheiden tiheys lasketaan: löydetyt virheet ohjelmakoodin rivimäärä Yleensä, jos jossain testattavassa ohjelmakohdassa virhetiheys on ollut suuri, virheitä löytyy jatkossakin. Virhetiheyden laskeminen auttaa testaajia jatkossakin keskittymään paremmin osaalueisiin, joissa virhetiheys on ollut suuri. 26