GLOW projekti ja sen hyväksymistestaus

GLOW projekti ja sen hyväksymistestaus Rönnquist, Olavi 2009 Leppävaara

Laurea ammattikorkeakoulu Laurea Leppävaara GLOW projekti ja sen hyväksymistestaus Olavi Rönnquist Tietojenkäsittelyn koulutusohjelma Opinnäytetyö Toukokuu, 2009

Laurea ammattikorkeakoulu Laurea Leppävaara Tietojenkäsittelyn koulutusohjelma Yritysten tietoverkot Tiivistelmä Olavi Rönnquist GLOW projekti ja hyväksymistestaus Vuosi 2008 Sivumäärä 53 Ohjelmistojen testaus on tärkeä osa ohjelmistokehitystä. Vaikka ohjelmistojen täydellinen testaus on mahdotonta, niin hyvin suunnitellulla ja toteutetulla testauksella saavutetaan asiakasta tyydyttävä ja laadukas tuote. Siltikään ohjelmistoprojekteissa testaukselle ei usein varata tarpeeksi aikaa eikä resursseja, jolloin testaus jää liian yleiselle tasolle ja loppukäyttäjän vaivaksi jää virheiden löytäminen. Lumenella aloitettiin syksyllä 2007 GLOW projekti, jonka tarkoituksena oli löytää ja ottaa käyttöön Lumenen tarpeita vastaava ja yrityksen toimintaa tehostava dokumenttien ja projektien hallintajärjestelmä. Lumenella ei ollut aikaisemmin käytössä vastaavanlaista järjestelmää. Opinnäytetyön tavoitteena oli luoda ja suorittaa hyväksymistestaus Lumenen uudelle tietojärjestelmälle opinnäytetyön tekijän toimesta ja varmistaa, että ohjelmistoyrityksen luoma järjestelmä varmasti vastaa ohjelman määrittelydokumentteja ja Lumenen tarpeita. Opinnäytetyön teoriaosuus perustuu testausta käsittelevään kirjallisuuteen. Sen tarkoituksena on luoda kattava ja tiivis kuvaus ohjelmistojen koko testausprosessista lähtien liikkeelle uuden ohjelmiston määrittelydokumenteista ja suunnitelmasta päättyen asiakkaan suorittamaan hyväksymistestaukseen. Lumenen suorittama ensimmäinen hyväksymistestaus ei mennyt aivan suunnitelmien mukaisesti, koska testeihin saatu ohjelma oli keskeneräinen, eikä sitä pystytty testaamaan kuten oli aiottu. Toiseen hyväksymistestaukseen saatiin jo paljon valmiimpi järjestelmä ja luodut testit pystyttiin suorittamaan. GLOW projekti pystyttiin päättämään onnistuneesti, kun ohjelmistoyritys korjasi siinä havaitut virheet. Projektin aikataulussa ei kuitenkaan onnistuttu pysymään. Asiasanat testaus, ohjelmistotestaus, testauksen suunnittelu, hyväksymistestaus, GLOW

Laurea University of Applied Sciences Laurea Leppävaara Information Technology Programme Information Systems and Data Communications Abstract Olavi Rönnquist GLOW project and acceptance testing Year 2008 Pages 53 Software testing plays a major role in the development of quality software. Although absolute testing of software is impossible, it is still achievable to produce quality software and, thus, gain customer satisfaction through a well planned and executed testing process.however, software companies still do not reserve enough time or resources for testing, and leave the testing of software at a too common level. As a result, users are left with the inconvenience of finding errors in the software they use. In the autumn 2007 the Finnish cosmetics company Lumene started a project named GLOW. The goal of GLOW was to find and deploy a document and project management system that would meet the needs of the company and, at the same time, benefit Lumene s business operation. Before, Lumene had no similar system to GLOW in use.the objective of this thesis is to describe the project GLOW in which an acceptance testing for the new programme was planned and implemented by an appointed project group including the writer. The main goal of this testing procedure was to ensure that the new management system meets the needs of Lumene as well as conforms to the specification documents of the new programme itself. The programme system tested and taken into use was created by a large Finnish software company X. The theoretical overview of this thesis is based on publications on software testing. The purpose of the overview is to give a comprehensive and concrete description of the complete process of software testing. Initially, this description concentrates on software planning and draws to its close with acceptance testing. The first executed acceptance testing of GLOW did not come out in a satisfactory way. This was due to the fact that the management programme that Lumene received was very incomplete at first and the original test planned could, therefore, not be executed. For the second acceptance testing Lumene received a much more defined management system and the tests where executed as planned. In summary, the GLOW project was successfully completed during the second testing round, after the software company X fixed the errors found in the first programme that, at first, turned out to be imperfect. The objectives of the project were obtained and, thus, the research questions of this thesis (in relation to the benefits and ways of testing) became answered. However, the schedule of the GLOW project was delayed in accordance with the original plans made by Lumene and the writer. The new document and project management system GLOW will be taken into use by Lumene in May 2008 partly owing to the eventually successful acceptance testing procedure that this thesis describes in detail. Key words: testing, software testing, acceptance testing, test design, GLOW

Sisällys 1 JOHDANTO...6 2 OPINNÄYTETYÖN TAVOITTEET JA RAJAUKSET...7 3 YRITYKSEN JA PROJEKTIN TAUSTAA...8 4 TIETOJÄRJESTELMIEN KEHITTÄMINEN JA TESTAUS...8 4.1 Testaus...9 4.2 Testauksen määritelmä ja merkitys...10 4.3 Täydellisen testauksen mahdottomuus...11 4.4 Virheet, viat ja häiriöt...12 4.5 Ohjelman määritelmän tekeminen...12 4.6 Testauksen tasot...13 4.6.1 Moduulitestaus...14 4.6.2 Integrointitestaus...15 4.6.3 Järjestelmätestaus...15 4.6.4 Regressiotestaus...17 4.6.5 Hyväksymistestaus...18 4.7 Testauksen laatu ja riittävyys...19 4.8 Testauksen työkalut...21 4.9 Testausstrategiat ja testitapausten valinta...23 4.10 Riskianalyysi...26 4.11 Laatu ja laatujärjestelmä...27 4.12 Laadunvarmistus ja varmistukseen käytettävät tekniikat...28 4.13 Dokumentointi ja standardit...29 5 GLOW PROJEKTI...31 5.1 Projekti ja testiryhmä...31 5.2 Projektin aikataulu...32 5.3 Sharepoint 2008...32 5.4 GLOW järjestelmä...33 5.5 Testitapausten suunnittelu...34 5.6 Testiympäristö, tila ja laitteet...37 5.7 Sharepoint koulutus...38 6 GLOW HYVÄKSYMISTESTAUS...39 6.1 Ensimmäinen hyväksymistestaus...39 6.2 Muut suoritetut testit...39 6.3 Ensimmäisen hyväksymistestauksen tulokset ja raportointi...40

6.4 GLOW projektin ensimmäisen hyväksymistestauksen tuloksien läpikäyntikokous...41 6.5 GLOW järjestelmän uusintatestaus...41 6.6 Uusintatestauksen tulokset ja raportointi...42 6.7 GLOW projektin toisen hyväksymistestauksen testitulosten läpikäyntipalaveri...43 6.8 GLOW järjestelmän toinen koulutustilaisuus...43 6.9 GLOW projektin nykytilanne...44 7 JOHTOPÄÄTÖKSET, KEHITYSEHDOTUS JA ARVIOINTI...45 7.1 GLOW projekti ja opinnäytetyö...45 7.2 Kehitysehdotus...46 7.3 Arviointi...46 LÄHTEET...48 LIITTEET...49

6 1 Johdanto Testaus on virheiden etsimistä, ja se on erittäin merkittävässä asemassa ohjelmistojen toimivuuden ja laadun kannalta ohjelmistojen kehitys ja toteutusprojekteissa. Testaukseen suhtaudutaan kuitenkin usein liian vähättelevästi, ja sitä suoritetaan riittämättömällä tavalla, vaikka sillä on suora yhteys ohjelmiston toimivuuteen ja asiakkaan tyytyväisyyteen. Syy testauksen puutteellisuuteen on usein ohjelmistoprojektin liian tiukka aikataulu ja henkilöstöresurssien vähyys. Ohjelmistojen ja tietojärjestelmien tehokas ja järjestelmällinen testaus ja sen suunnittelu onkin vaativa prosessi, joka sitoo yrityksen henkilöresursseja ja on aikaa vievää. Testauksen tulisi aina olla määrätietoista ja ennalta suunniteltua, jotta testauksesta saataisiin ohjelmiston laadun kannalta irti maksimaalinen hyöty. Ohjelmiston kattavaan testaukseen tuleekin panostaa heti ohjelmiston elinkaaren alkuvaiheessa. Samoin ohjelmistoprojektin määrittelydokumentit tulee luoda erittäin huolellisesti ja selkeästi, jotta ne varmasti pitävät sisällään asiakkaan ohjelmistolta tarvitsemat ominaisuudet ja täten vastaavat sitä tarvetta, mihin ohjelmistoa on alun perin lähdetty kehittämään. Yksi merkittävä syy testauksen määrätietoiseen suorittamiseen ja määrittelydokumentin huolelliseen laatimiseen jo ohjelmistoprojektin alkuvaiheessa on se tosiasia, että jos ohjelmiston virheet löydetään ja korjataan ohjelmistoprojektin alkuvaiheen sijasta vasta projektin loppuvaiheessa, niiden korjaaminen tulee 50 200 kertaa kalliimmaksi. Testausprosessia selkiyttämään ja helpottamaan ohjelmistoyrityksillä tulisi olla selkeät toimintamallit ja ohjeet, jotka standardoisivat koko prosessia ja samalla pienentäisivät projektin vaatimia henkilöresursseja ja kustannuksia sekä tehostaisivat prosessin läpivientiä. Koska jokainen ohjelmistoprojekti on erilainen, toimintamallien ja ohjeiden tulisi olla luotu niin, että niitä on mahdollisimman helppo soveltaa erilaisiin projekteihin. Vaikka ohjeistukset ja mallit olisivat kuinka hyvin luotuja, täytyy jokaiseen ohjelmistoprojektiin silti luoda omat testitapauksensa, joilla testataan määrättyjä ominaisuuksia. Tällaisen laatujärjestelmän ja sen sisältämien ohjeistuksien ja mallien olemassaolo antaa myös asiakkaalle luotettavamman kuvan siitä, että ohjelmistoyritys hoitaa testauksensa huolellisesti. Tietenkin pelkkä laatujärjestelmän olemassaolo ei riitä, vaan sitä tulee myös käyttää.

7 Kun on kyse ohjelmistoprojektista, jossa osapuolina ovat ohjelmistoyritys ja asiakasyritys, jonka henkilöstön käyttöön jokin tietojärjestelmä luodaan, niin projektiin liittyy oleellisena osana ohjelmiston hyväksymistestaus. Tämä asiakasyrityksen suunnittelema ja suoritettava hyväksymistestaus päättää onnistuneesti läpivietynä koko ohjelmistoprojektin. Vaikka ohjelmistoprojekti olisikin päätetty onnistuneesti, on projektien sopimuksiin yleensä kirjattu, että ohjelmistoyritys antaa tuotteelleen takuun, joka kattaa projektin päätyttyä tietyn ajan sisällä löydetyt virheet ja niiden korjauksen veloituksetta. 2 Opinnäytetyön tavoitteet ja rajaukset Tässä opinnäytetyössä käydään läpi GLOW projektia ja prosessia, jossa asiakasyritys Lumene on tilannut dokumentin ja projektinhallintaan tarkoitetun tietojärjestelmän ohjelmistoyritykseltä. Opinnäytetyössä perehdytään testauksen teoriaan ja Lumenen suorittamaan ohjelmiston hyväksymistestaukseen sekä tutkitaan optimaalisia tapoja suorittaa hyväksymistestaus. Opinnäytetyön teoriaosuuden tarkoituksena on luoda kattava ja tiivis kuvaus ohjelmistojen koko testausprosessista, lähtien liikkeelle uuden ohjelmiston määrittelydokumenteista ja suunnitelmasta ja päättyen Lumenen suunnittelemaan ja suorittamaan tietojärjestelmän hyväksymistestaukseen, järjestelmän hyväksymiseen ja käyttöönottoon valmiina ohjelmana. Testauksen teoriaosuus perustuu testauksen V mallin eri tasoihin, joita ovat moduulitestaus, integraatiotestaus, järjestelmätestaus ja hyväksymistestaus. Teoriaosuudessa käydään myös kattavasti läpi testauksen eri tasoilla käytettäviä testaustekniikoita ja strategioita. Opinnäytetyön loppupuolella käydään läpi itse GLOW projektin etenemistä, Lumenelle suunnittelemiani ja luomiani testitapauksia hyväksymistestauksen suorittamiseksi, itse testien suorittamista, saatujen tulosten arviointia, projektin hyväksymistä ja projektin nykytilaa.

8 3 Yrityksen ja projektin taustaa Lumene on suomalainen kosmetiikka alan yritys, joka on perustettu vuonna 1948. Lumene Groupilla on ulkomailla tytäryhtiöitä Virossa, Latviassa, Norjassa, Venäjällä ja Yhdysvalloissa. Lumenen pääkonttori ja tuotteiden valmistuspiste sijaitsee Kauklahdessa Espoossa. Lumenen palveluksessa työskentelee noin 1000 työntekijää, joista 730 työskentelee Suomessa. Lumene Groupiin kuluu kolme divisioonaa, joita ovat Lumene, Cutrin ja Farmos. Cutrin on keskittynyt hiusalan tuotteiden valmistukseen ja myyntiin. Farmos on puolestaan keskittynyt teollisuuskäyttöön tarkoitettujen puhdistusaineiden valmistukseen ja myyntiin. Cutrinin ja Farmoksen toimitilat sijaitsevat myös Espoon Kauklahdessa Lumenen toimitilojen yhteydessä. Farmoksella on lisäksi toimitilat Turussa. Lumenen GLOW projekti käynnistyi tarpeesta saada paremmin hallittua ja tehostettua Lumenen tuoteprojekteja, tuotteiden uudelleen rekisteröintiä, dokumenttipohjia, toimintakäsikirjaa ja näihin liittyviä dokumentteja, jotka sijaitsevat hajanaisesti Lumenen verkkolevyillä. Samalla haluttiin ottaa käyttöön tehokkaampia ja yhtenäisempiä työnkulkuja ja käytänteitä, jotka jo itsessään tehostavat Lumenen liiketoimintaa. Lumenella päädyttiin siihen, että näiden edellä mainittujen asioiden toteuttamiseksi Lumene Groupille hankitaan yhtenäinen dokumentin ja projektinhallintatietojärjestelmä. Tietojärjestelmä tulisi alkuvaiheessa vain Lumenen henkilökunnan käyttöön, mutta se tultaisiin lanseeraamaan tulevaisuudessa myös Cutrinille. 4 Tietojärjestelmien kehittäminen ja testaus Tietojärjestelmien kehittäminen on sitä suorittavalle yritykselle osa sen oman toiminnan kehittämistä. Toiminnan kehittämisen tarkoituksena on saada aikaan toimintatavan muutos, joka tehostaa yrityksen toimintaa. Toiminnan kehittämiselle voidaan antaa muun muassa seuraavanlaisia tavoitteita: Se auttaa yritystä saavuttamaan tavoitteensa entistä paremmin. Se mahdollistaa entistä vaativampien tavoitteiden asettamisen. Se tehostaa jo olemassa olevia toimintatapoja. Se tekee mahdolliseksi jonkin uuden toiminnon.

9 Toiminnan kehittäminen kohdistuu yrityksissä sen henkilöstöön, järjestelmiin ja toimintoihin. Henkilöstön kohdalla kehittäminen tarkoittaa tyypillisesti henkilöstön koulutusta tai työtehtävien ja olosuhteiden uudelleenjärjestelyä. Järjestelmien kehittäminen on puolestaan seurausta yleisen teknisen osaamisen kehityksestä ja sen tarjoamista uusista mahdollisuuksista. Myös yksittäisiä toimintoja voidaan kehittää tarkastelemalla niiden suoritustapoja ja luomalla uusia käytänteitä. Tietojenkäsittelyn ja tietojärjestelmien kehittäminen vaikuttaa yleensä kaikkiin kolmeen edellä mainittuun osa alueeseen. Vaikka nykyisin tietojärjestelmien kehityshankkeissa pääpaino onkin teknologian kehittämisessä, silti niillä on vaikutusta myös tietojenkäsittelykäytänteisiin ja tietojenkäsittelyä suorittaviin henkilöihin. Kehitystyön lähtökohtana voi olla tietotekniikan hyödyntäminen yrityksen prosesseissa, mutta kuitenkin kyseessä on tietojenkäsittelytoimenpiteiden kehittäminen. Tällaisen projektin tuloksena usein tietojenkäsittelyyn liittyviä tehtäviä poistuu käytöstä ja uusia tulee tilalle. Esimerkiksi mainittakoon, että kun yritykseen otetaan käyttöön uusi tietojärjestelmä, täytyy sitä käyttävät henkilöt kouluttaa ja uusia käytänteitä aletaan soveltaa. Keskeinen osa tietojenkäsittelyn kehittämistä on jo olemassa olevien ja uusien tietojär jestelmien kehittämisellä. Atk sanakirja määritteleekin tietojärjestelmien kehittämisen olevan uusien tietojärjestelmien laatimista tai nykyisten oleellista muuttamista. Parempi määritelmä olisi, että tietojärjestelmien kehittäminen on liiketoiminnan tehos tamista kehittämällä uusia tietojärjestelmiä tai olemassa olevien tietojärjestelmien muokkaamista vastaamaan paremmin liiketoiminnan tarpeita. (Pohjonen 2002,14 15.) 4.1 Testaus Testaus on virheiden etsimistä ja siihen liittyvät seuraavat työvaiheet: testauksen suunnittelu (testaussuunnitelma ja testitapaukset) testiympäristön luonti testin suorittaminen tulosten tarkastelu virheiden korjaus

10 uusintatestaus. Edellä listattuihin työvaiheisiin ja niihin läheisesti liittyvään virheiden jäljitykseen, korjaamiseen (debugging) ja niistä syntyvään toistoon kuluu yleisesti yli puolet ohjelmistoprojektin resursseista. Tästä syystä testauksen suunnitteluun ja itse testaukseen kannattaa kiinnittää erityistä huomiota. Testauksen yhteydessä virhe on poikkeama ohjelman spesifikaatiossa (määritelmässä) eli suunnitellussa tavasta millä ohjelman tulisi toimia. Testauksen määritelmästä seuraa, että testaus ilman spesifikaatiota on mahdotonta, koska lopputuloksen oikeellisuutta ei voi todeta. Seuraavissa luvuissa käyn läpi testauksen teoriaa ja menetelmiä. 4.2 Testauksen määritelmä ja merkitys Normaalissa puhekielessä testaus tarkoittaa lähes mitä tahansa kokeilua. Ohjelmistojen testauksessa testaus määritellään suunnitelmalliseksi virheiden etsimiseksi ohjelmaa tai sen osaa suorittamalla. Tässä määritelmässä keskeisiä sanoja ovat suunnittelu ja etsiminen. Virheiden etsimisen ja korjaamisen lisäksi testauksen tarkoituksena on varmistaa ja parantaa järjestelmän laatua. Myös tarkistuksia ja ohjelmakoodin staattista analysointia kutsutaan joskus testauksek si. Tässä opinnäytetyössä termi testaus rajataan kuitenkin tarkoittamaan ohjelmaa suo rittamalla tapahtuvaa testausta. Valitettavan usein testaus tapahtuu vain kokeilemalla ohjelmaa umpimähkäisesti jollain syöttöaineistolla, ja varsinkin jos testaaja on ohjelman tekijä, niin tavoitteeksi muodostuu helposti ennemmin ohjelman toimivuuden osoittaminen kuin sen virheiden etsiminen. Useissa aiheeseen liittyvissä kirjoissa painotetaankin, että ohjelman tekijä ei ole paras mahdollinen testaaja. Testauksen määrä (työtunnit ja testitapausten määrä) ei välttämättä ole sama kuin testauksen tehokkuus, sillä muutaman tunnin testaus huolellisesti suunnitellulla testitapausjoukolla voi hyvin johtaa parempaan tulokseen kuin päiväkausien umpimähkäinen kokeilu. Hyvä testaaminen lähteekin huolellisesta testauksen suunnittelusta ja testauksen suorittamisesta heti ohjelmiston kehityksen alkuvaiheista lähtien. Koska mitä var

11 haisemmassa vaiheessa ohjelmiston virheet löydetään, niin sitä pienemmiksi jäävät niiden korjauskustannukset ja korjauksista aiheutuva työmäärä. Koska pientäkään ohjelmaa ei voida testata täydellisesti, niin ei koskaan voida olla täysin varmoja ohjelman virheettömyydestä. Tästä johtuen voidaankin todeta, että testauksen avulla on mahdollista osoittaa, että ohjelmassa on virheitä, mutta ohjelman täyttä virheettömyyttä sillä sen sijaan ei ole mahdollista osoittaa. Käytännössä ohjelman testauksessa pystytään kattamaan vain häviävän pieni murto osa kaikista mahdollisista tilanteista. Tämä ei kuitenkaan tarkoita sitä, että testaukseen panostaminen olisi hyödytöntä, vaan sitä, että ohjelman toimivuuteen ei kannata luottaa liikaa hyvistä testituloksista huolimatta. (Haikala & Malijärvi 2006, 281 285; Software business competence 2006.) 4.3 Täydellisen testauksen mahdottomuus Syy, miksi ohjelman täydellinen testaus on mahdotonta, johtuu seuraavista asioista Testattavien syötteiden määrä on suuri Tulosten määrä on suuri Ohjelmiston läpikulkevien polkujen määrä on suuri Ohjelman sisäisen tilan muutokset Kun nämä mahdollisuudet kerrotaan yhteen, saadaan tulokseksi liian paljon eri mahdollisuuksia tai erilaisia testitapauksia ohjelmiston täydelliselle testaukselle. Otetaan esimerkiksi summausohjelma. Sen syöteavaruus muodostuu kaikista mahdollisista kelvottomista syötteistä sekä kaikista sallitulla vaihteluvälillä olevista kokonaisluvuista ja niiden kombinaatioista. Ohjelman tulosavaruus koostuu virheilmoituksista ja summista. Tällaisen ohjelman kattava testaus edellyttäisi ohjelman suorittamista ainakin kaikilla kelvollisilla syötteillä. Tässä tapauksessa kelvollisia syötekombinaatioita on noin 2 potenssiin 32 kappaletta eli noin 4 miljardia. Lisäksi ohjelman sisäinen tila tuo lisää haastetta testaukseen. Esimerkiksi suoritettaessa sama testi kahteen kertaan tietokantajärjestelmässä saatetaan saada kaksi eri tulosta. Tämä voi johtua esimerkiksi siitä, että ohjelman käyttämä tietokanta on muuttunut. Käytännössä ohjelmien sisäisten tilojen määrä on rajaton. (Haikala & Malijärvi

12 2006, 290 295; Software business competence 2006.) 4.4 Virheet, viat ja häiriöt Testauksen yhteydessä virhe (error, mistake, bug, fault, defect) on poikkeama ohjelmalle asetetusta spesifikaatiosta eli määritelmästä. Yhden yleisen tulkinnan mukaan error on ihmisen toiminto (esimerkiksi ajatusvirhe), jonka tuloksena syntyy defect. Tämän tulkinnan mukaan fault on ohjelmakoodissa oleva defect, jonka tuloksena sitten failure aiheutuu. Yleensä ottaen ohjelmissa arvioidaan olevan ohjelmoinnin jälkeen yksi virhe muutamaa kymmentä koodiriviä kohden. Jopa pitkään käytössä olleissa ohjelmissa arvioidaan yleensä olevan noin yksi virhe tuhatta koodiriviä kohden. On myös arvioitu, että noin viisi prosenttia ohjelmavirheistä on sellaisia, ettei niitä koskaan edes havaita. Syy tälle on ohjelmien täydellisen testauksen mahdottomuus, ja vaikka virheellinen kohta suoritettaisiinkin testauksen yhteydessä, se ei välttämättä johda virhetoimintoon. Virheellisen kohdan suoritus voi aiheuttaa järjestelmään vian (fault). Vika voi korjaantua itsestään järjestelmän toisen toiminnon seurauksena tai sen vaikutus voi kumoutua toisen virheen seurauksena. Pahimmassa tapauksessa vika voi aiheuttaa häiriön (failure), joka näkyy järjestelmän ulkoisessa toiminnassa.(haikala & Malijärvi 2006, 285 286) 4.5 Ohjelman määritelmän tekeminen Ohjelman määritelmä voi olla ohjelman kehittäjän itsensä laatima, jos kyseessä on esimerkiksi uusi markkinoille tuleva ohjelma. Määritelmä voi myös olla ohjelman kehittäjän ja asiakkaan yhdessä tekemä, jos kyseessä on vaikkapa ohjelmointiyrityksen laatima ohjelma toisen yrityksen tiettyihin tarpeisiin. Määritelmästä seuraa, että testaus ilman spesifikaatiota on mahdotonta, koska lopputuloksen oikeellisuutta ei voida muuten todentaa. Määritelmädokumentin tärkeys nousee esiin varsinkin mahdollisissa kiistatilanteissa. Tavallisimmin testauksessa käytettäviä määritelmiä ovat toiminnallinen ja tekninen määrittely. Näiden dokumenttien tulkinnoissa voi esiintyä erimielisyyksiä. Esimerkiksi asiakkaan mielestä selvä virhe voi olla toimittajan mielestä ohjelman ominaisuus. Vir

13 heen vakavuus voi vaihdella järjestelmän käytön kokonaan estävästä virheestä pie neen asiakasta ärsyttävään yksityiskohtaan. Ohjelmistoprojektin sujuvuuden ja kiistatilanteiden välttämisen kannalta on erittäin tärkeää, että määritelmät tehdään mahdollisimman huolellisesti. Käytännössä kuitenkin suurin ongelma on se, että paraskin spesifikaatio on aina puutteellinen ja tulkinnanvarainen, jolloin ristiriitatilannetta ei välttämättä pystytä ratkaisemaan ohjelman spesifikaatiota tulkitsemalla. Pahimmassa tapauksessa asia joudutaan ratkaisemaan lakiteitse. Suunnitelmiin ja sopimuksiin asiakkaan ja toimittajan välillä onkin aina syytä kirjata, miten tulkinnat näiltä osin tehdään. (Haikala & Malijärvi 2006, 285 286.) Itse olin mukana ohjelmaprojektissa, jonka määritelmää ei ollut tehty riittävän tarkasti, ja joka oli osittain melko tulkinnanvarainen. Tästä syystä jouduimmekin vääntämään kättä toimittajan kanssa ohjelmistoprojektin määritelmässä olleista asioista, tarkemmin ottaen siitä, olivatko tietyt haluamamme ominaisuudet määritelmän mukaisia. Samoin kävi myös muutamissa hyväksymistesteissämme. Meidän mieltämistämme virheistä ohjelmassa kommentoitiin toimittajan puolelta, että kyseessä on ohjelman ominaisuus, ei virhe. 4.6 Testauksen tasot Yleisesti testaus ja sen suunnittelu etenee niin sanotun V mallin mukaisesti, testausta soa vastaavalla suunnittelutasolla kuten alla olevassa kuviossa 1 on osoitettu: Kuvio 1. Testauksen V malli.

14 Erilaisia testaustasoja ovat moduulitestaus (module testing, yksikkötestaus), integrointitestaus (intergration testing) ja järjestelmätestaus (system testing). Ilkka Haikala kirjoittaa kirjassaan Ohjelmistotuotanto, että järjestelmätestausta voi seurata erillinen kenttätestaus (field testing) ja/tai hyväksymistestaus. Mielestäni kuitenkin, jos kyseessä on toimittaja ja asiakas projekti, niin kenttätestaus ja/tai hyväksymistestaus on välttämätön. Projektissa, jossa itse olin mukana, olisimme ilman hyväksymistestausta saaneet täysin keskeneräisen ja Lumenen tarpeita vastaamattoman tietojärjestelmän, jolle ei olisi juurikaan ollut käyttöä. 4.6.1 Moduulitestaus Moduulitestauksessa testattavana on yksittäinen moduuli. Moduulilla tarkoitetaan ohjelmasta erotettavissa olevaa loogista kokonaisuutta, joka yleensä koostuu noin 100 1000 koodirivistä. Tyypillinen moduuli sisältää tietomäärittelyjä ja joukon kyseistä tietoa käsitteleviä funktioita. Moduulin toimintaa verrataan moduulisuunnittelun ja arkkitehtuurisuunnittelun tuloksiin, tavallisimmin tekniseen määrittelydokumenttiin. Testauksen suorittaa yleensä moduulin toteuttaja. Testit ovat usein mustalaatikkotestejä. Jos prosessit ovat vaikeita, myös lasilaatikkotestausta voidaan käyttää. Testauksen suorittamiseksi voidaan joutua toteuttamaan testipetejä (test bed), joilla moduulin toimivuutta voidaan kokeilla. Testipetiin kuuluu yleensä ohjelman tulevaa ympäristöä simuloivia osia, tavallisesti testiajureita (test drivers) ja tynkämoduuleita (test stubs). Testiajurit mahdollistavat moduulin toteuttamien palveluiden kutsumisen ja tulosten tarkastelun. Tynkämoduulit puolestaan korvaavat testattavan moduulin tarvitsemat muut moduulit, jos niitä ei ole vielä olemassa. Testeissä keskitytään sisäiseen logiikkaan ja tietorakenteisiin. Jos moduuli suorittaa vain yhden funktion, testitapausten määrä vähenee ja virheet ovat helpommin löydettävissä. Moduulitestauksen yhteydessä pyritään myös löytämään ristiriitoja testattavien moduulien määrittelyjen ja toiminnan välillä. Moduulitestaus ei sovellu ainoaksi testausmenetelmäksi, koska testimoduulit ovat ainoastaan pieniä ohjelman osia eivätkä laajoja kokonaisuuksia. (Haikala & Malijärvi 2006, 287)

15 4.6.2 Integrointitestaus Integrointitestauksessa yhdistellään yhteen moduuleita tai moduuliryhmiä (osajärjestelmiä). Integraatiotestaus alkaa siitä, että moduulitestauksessa erikseen testattuja moduuleita ryhdytään testaamaan toistensa kanssa. Integrointitestaus loppuu siihen kun koko ohjelman kaikki moduulit ovat valmiita, ja niiden yhteistoiminta on kokonaisuudessaan testattu. Integrointitestauksen painopiste onkin moduulien välisten rajapintojen toimivuuden tutkimisessa: tavoitteena on löytää virheitä ohjelman rajapinnoista ja niiden keskinäisestä yhteistoiminnasta. Virheitä saattaa löytyä, vaikka yksittäiset moduulit olisivatkin osoittautuneet toimiviksi. Testien tuloksia verrataan usein ohjelman määrittelydokumenttiin ja tämä vertailu etenee usein rinnakkain moduulitestauksen kanssa. Ohjelman määrittelydokumenttia ja testien tuloksia onkin usein tarpeetonta tarkastella erillään moduulitestauksesta. Testauksen kattavuuden kannalta moduulitestauksessa on tosin helpompi saavuttaa kunnollinen testikattavuus, koska testattavan kokonaisuuden kasvaessa on vaikea käydä kaikkea koodia läpi. Integrointitestaus voidaan toteuttaa useammalla lähestymistavalla. Yleisin tapa on kokoava (bottom up), jossa testaus etenee alimman tason moduuleista ylöspäin. Tämän tavan vahvuus on siinä, että kun virhe ilmaantuu, niin ainakin teoriassa vian pitäisi löytyä viimeksi testauskokonaisuuteen lisätystä moduulista. Jäsentävässä eli osittavassa (top down) tavassa testauksen etenemissuunta on päinvastainen. On olemassa lisäksi vielä kaksi tapaa (sandwich ja big bang), joista en kuitenkaan lukemassani suomalaisessa kirjallisuudessa löytänyt mainintoja. Sandwich mallissa yhdistellään bottom up ja top down testausta kunnes koko ohjelma on käyty läpi. Big bang mallissa kaikki moduulit integroidaan kerralla yhteen ennen testauksen aloittamista. (Haikala & Malijärvi 2006, 287 288; Tamres 2002, 221.) 4.6.3 Järjestelmätestaus Järjestelmätestauksessa (system testing) tarkastelun kohteena on koko järjestelmä ja sen tuloksia verrataan määrittely ja asiakasdokumentaatioon. Järjestelmätestauksen kohteena ovat toiminnalliset ja ei toiminnalliset ominaisuudet. Kun käytössä on täysin kokonainen ja ainakin suurimmilta osin toimiva kokonaisuus, päästään testaamaan ominaisuuksia, joita ei aikaisemmin ollut mahdollista tai järkevää testata. Testauksen

16 tarkoituksena on siis löytää vikoja, joita ei voida moduuli eikä integrointitestauksessa löytää. Järjestelmätestaus koostuu useista erityyppisistä testausosioista. Eri osien tarkoitukse na on virheiden löytämisen lisäksi varmistaa, että järjestelmä vastaa asiakkaan sille asettamia vaatimuksia. Näitä osia ovat muun muassa: Toiminnallisuustestauksen (functional testing) tarkoituksena on varmistaa, että kaikki järjestelmän toiminnot toimivat määrittelyjen mukaisesti. Yhteensopivuustestauksen (compatibility testing) tarkoituksena on selvittää, kuinka hyvin järjestelmä toimii määrätynlaisessa ympäristössä, kuten vaikkapa tietynlaisessa verkkoympäristössä tai käyttöjärjestelmässä. Konfigurointitestauksen (configuration testing) tarkoituksena on varmistaa, että ohjelma toimii eri ohjelmien, tietokoneiden ja niiden eri komponenttien kanssa, joita sen tulee tukea. Asennustestauksen (installation testing) tarkoituksena on testata, että ohjelman asennus, päivittäminen ja poistaminen toimivat määrittelyjen mukaisesti. Kuormitustestauksessa (load testing) järjestelmää käytetään niin kuin sen käyttäjä sitä käyttäisi ja varmistetaan, että sen käyttö on sulavaa. Suorituskykyä voidaan testata myös siten, että järjestelmää kuormitetaan erilaisilla lasteilla. Tällöin tarkoituksena on selvittää, minkälaisesta kuormituksesta järjestelmä selviää pysyen samalla käyttökelpoisena. Suorituskyvyn testauksessa (performance testing) mitataan, kuinka kauan eri työtehtävät kestävät järjestelmän normaalikuormituksen ja huippukuormituksen alaisena. Tietoturvatestauksessa (security testing) tavoitteena on varmistaa, että järjestelmään rakennettu suojamekanismi suojaa laittomilta tunkeutumisilta, kopioinnilta ja muokkaamiselta. Palautumistestauksessa (recovery testing) varmistetaan, että järjestelmä pystytään palauttamaan toimivaan tilaan sen kaatumisen, sisäisen ongelman tai palvelimen fyysisen vian jälkeen. Huollettavuustestauksessa (serviceability testing) varmistetaan, että järjestelmänsisäiset ylläpitoinformaatiot, kuten käyttäjistä jäävät jäljet ja diagnostiikkaviestit, toimivat. Käytettävyystestauksella (usability testing) halutaan arvioida järjestelmän hyödyllisyys, sopivuus ja helppokäyttöisyys. Tavoitteena on samalla tunnistaa oh

17 jelman ongelmakohdat käyttäjän kannalta. Käytettävyystestaus on pääasiassa käyttöliittymän testausta. Siinä halutaan varmistaa, että järjestelmä on mahdollisimman käyttäjäystävällinen. Tämä tarkoittaa sitä, että käyttäjä pystyy selviämään mahdollisimman hyvin tehtävistä, joiden suorittamiseksi järjestelmää ollaan rakentamassa. Käytettävyystestausta voidaan yleensä suorittaa jo aikaisemmassa vaiheessa esimerkiksi järjestelmän ohjelmoijan toimesta. Yleensä käytettävyystestiä varten valitaan pieni joukko tulevia käyttäjiä ja heitä seurataan valvotussa testiympäristössä. Käytettävyystestauksen lisäksi tai sen sijaan voidaan käyttää hyväksi myös ohjelmiston arviointiin erikoistuneita ammattilaisia. Edellä listatuilla testeillä ja niiden tuloksilla ohjelman toimittaja arvioi, toimiiko järjestelmä määritysten mukaisesti. Tällöin punnitaan, onko järjestelmä valmis julkaistavaksi tai toimitettavaksi asiakkaan hyväksymistestausta varten. Kun suoritetaan järjestelmätestejä, tulee testiympäristön olla mahdollisimman lähellä ohjelman tuotantoympäristöä: muuten ei pystytä arvioimaan lopullista tuotetta. Järjestelmätestaukseen voi lisäksi liittyä erillinen kenttätestaus (alfa testing, jonka asiakas suorittaa toimittajan tiloissa) ja hyväksymistestaus (beta testing, jonka asiakas suorittaa itsenäisesti omissa tiloissaan). Valinta kenttätestauksen ja hyväksymistestauksen välillä riippuu tietenkin siitä, tehdäänkö järjestelmä yritykselle itselleen firman omasta toimesta vai myydäänkö järjestelmä ulkopuoliselle asiakkaalle. Nämä testit suoritetaan varsinaisen järjestelmätestauksen jälkeen. (Haikala & Malijärvi 2006, 288; Tamres 2002, 222 223.) 4.6.4 Regressiotestaus Regressiotestaus on järjestelmän uudelleentestausta virheiden löytymisen jälkeen. Voidaan sanoa, että mikään järjestelmä ei ole ensimmäisellä kerralla niin täydellinen, ettei regressiotestausta tarvitsisi tehdä. Regressiotestauksessa järjestelmätestaus tulisi suorittaa mieluiten kokonaan uusiksi, koska usein virheiden korjaus ja/tai uuden ominaisuuden lisäys aiheuttaa uuden virheen järjestelmän aikaisemmin normaalisti toimineessa osassa. Regressiotestauksen päämääränä onkin osoittaa, että aikaisemmin toimineet ominaisuudet toimivat myös järjestelmän uudessa versiossa. Uuden ominaisuuden lisääminen aiheuttaa usein sen, että aikaisempia järjestelmätestejä joudutaan päivittämään uuden ominaisuuden takia. Tämä siksi, että suorittamalla joukko vanhoja testejä ei voida todeta, että järjestelmä olisi virheetön, jos siihen lisättyjä uusia ominaisuuksia ei ole testattu.

18 Regressiotestausta tehdään kaikilla testauksen V mallin tasoilla. Testaustasojen erona on se, että mitä korkeammalla V mallin tasolla ollaan, sitä kalliimmaksi virheiden korjaus tulee. Ideaalissa tilanteessa regressiotestaus tehdään aina kun järjestelmään tulee muutos. Tämä tosin ei aina ole mahdollista, varsinkin jos testausta ei saada automatisoitua, sillä testauksen kustannukset voivat nousta erittäin kalliiksi. (Haikala & Malijärvi 2006, 288; Tamres 2002, 223.) 4.6.5 Hyväksymistestaus Hyväksymistestaus suoritetaan yleensä asiakkaan toimesta asiakkaan tiloissa todellisessa tuotantoympäristössä. Sen tarkoituksena on varmistaa, että luotu järjestelmä on oikeasti sellainen, mitä asiakas on halunnut, ja että järjestelmä tukee asiakkaan haluamia toimintoja. Hyväksymistestausta kutsutaan myös beta testaukseksi. Sitä saattaa edeltää alfa testaus toimittajan tiloissa, mikä simuloi tulevaa tuotantoympäristöä. Kirjallisuudessa on ristiriitaisia väitteitä alfa testauksen pakollisuudesta. Ainakaan Lumenen projektissa tällaista testiä ei ollut. Hyväksymistestauksen testaajina on yleensä valittu joukko järjestelmän todellisia käyttäjiä. Hyväksymistestausta varten suunnitellaan ja luodaan testitapauksia, joiden tarkoituksena on simuloida todellisia järjestelmän käytön tilanteita, joita varten uusi järjestelmä on alun perin haluttu. Testeistä luodaan mahdollisesti melko tarkatkin paperiversiot, joita testaajat sitten käyvät läpi kohta kohdalta ja merkitsevät ylös mahdolliset virheet, puutteet, huomautukset ja kehitysehdotukset. Testit pohjautuvat yleensä projektin määrittelydokumentteihin. Testien tulosten pohjalta luodaan testiraportti, joka käydään läpi toimittajan ja asiakakkaan edustajien kesken palaverissa. Tässä palaverissa ovat läsnä ainakin asiakkaan ja toimittajan projektipäälliköt. Erillisessä projektin päätöspalaverissa on lisäksi mukana projektin ohjausryhmä ja siinä päätetään jatketaanko vai päätetäänkö projekti. Onnistunut hyväksymistestaus on kriteerinä projektin lopettamiselle eli laskun maksamiselle. Hyväksymistestausta saattaa edeltää ohjelmaan liittyvä henkilöstökoulutus, varsinkin jos ohjelma ei ole käyttäjille ennestään tuttu. Jos testaus ei mene odotusten mukaisesti ja korjattavaa on enemmänkin, suoritetaan hyväksymistestaus uudelleen

19 kun järjestelmän toimittaja on saanut korjattua havaitut puutteet. Näitä toimintoja toiste taan kunnes järjestelmä on asiakkaan määritelmien mukainen. Pahimmassa tapauksessa voidaan joutua kääntymään lain puoleen, jos asiakkaan ja toimittajan yhteisymmärrys halutusta järjestelmästä ei kohtaa tai jos järjestelmä on kirjattu määrittelydokumentteihin liian ympäripyöreästi. Esimerkiksi ohjelman toimittaja saattaa pitää jotain korjaustyötä muutospyyntönä ja asiakas taas ajatella sen olevan määrittelyn mukainen ominaisuus. Mahdollisen riitatilanteen varalta voidaan sopia kolmas ulkopuolinen taho, joka yrittää ratkaista asian puolueettomasti ennen asian oikeuteen viemistä. Riitatilanteiden estämiseksi projektin määrittelyvaiheen määrittelydokumentit tulisi tehdä erittäin huolellisesti ja mahdollisimman seikkaperäisesti. Hyväksymistestaus voidaan myös suorittaa kolmannen osapuolen toimesta, joka on erikoistunut testaukseen. Kolmannen osapuolen käytön etuna on se, että tieto kolmannen osapuolen käytöstä pakottaa entisestään järjestelmän toimittajaa suorittamaan omat testinsä huolellisesti, jolloin yleensä jo ensimmäinen versio järjestelmästä on virheettömämpi. Samalla asiakasyrityksen omia resursseja voidaan hyödyntää muihin tehtäviin. Ohjelmistoprojekteille sovitaan yleensä tietyn ajanjakson pituinen takuuaika alkaen siitä kun projektin asiakas on hyväksynyt toimittajan tekemän järjestelmän. Yleensä takuuaika tarkoittaa sitä, että takuuajan aikana havaitut virheet korjataan järjestelmän toimittajan puolesta ilmaiseksi. Esimerkiksi Lumenen Sharepoint ohjelmalle ohjelmistoyritys X antoi puolen vuoden takuun. Yleensä ohjelmistoyritys X antaa vuoden takuun, mutta nyt kyseessä oli heidän projektipäällikkönsä mukaan ensimmäinen kerta kun ohjelmiston toimittaja räätälöi Sharepointin projektin ja dokumentinhallintaan. Rivien välistä pystyi lukemaan, että juuri tämä asia oli syy takuun lyhyydelle. Tämä asia kasvatti GLOW projektin epäonnistumisen riskiä. (Tamres 2002, 223 224; Cybercom Plenware 2008.) 4.7 Testauksen laatu ja riittävyys Johtuen siitä, että ohjelmiston täydellinen testaaminen on lähes mahdotonta, niin myös tarvittavan testauksen määrää on vaikea arvioida. Varsinkin järjestelmätestauksessa testausta voidaan jatkaa kunnes aika ja/tai rahat loppuvat. Tuotekehitystyössä testauk

20 sen lopettaminen on usein kompromissi tuotteessa olevien vikojen aiheuttamien kus tannusten ja markkinoilta myöhästymisen aiheuttaman tuoton menetyksen välillä. Testauksen ongelmana on se, että jos kaikkea yritetään testata, niin kustannukset nousevat dramaattisesti ja ei löydettyjen virheiden määrä laskee pisteeseen, josta ei ole enää kustannustehokasta jatkaa. Jos testaus jätetään liian lyhyeksi tai testitapaukset ovat huonoja, niin kustannukset ovat alhaiset, mutta virheitä jää paljon huomaamatta. Tavoitteena on päästä optimaaliseen testausmäärään, jolloin ei testata liikaa eikä liian vähän. Testauksen lopettamiselle tulisikin aina asettaa hyväksymiskriteerit, jotka määritellään testaussuunnitelmassa. Muuten on vaikea sanoa, milloin testaus voidaan lopettaa ja siirtää järjestelmä eteenpäin. Järjestelmätestauksessa kriteeri voi liittyä esimerkiksi kumulatiiviseen löydettyjen virheiden määrään; kun virhekäyrä tasaantuu, testaus voidaan lopettaa. Tarvittavaa testauksen määrää voidaan koettaa arvioida mutkikkuusmitoilla ja testauksen riittävyyttä puolestaan niin kutsutuilla kattavuusmitoilla. Mutkikkuusmitoilla pyritään päättelemään ohjelmamoduulin monimutkaisuutta koodin rakennetta analysoimalla. Mutkikkuusmitan avulla voidaan yrittää paikantaa ohjelmistossa paljon testausta vaativat moduulit. Tunnetuimmat mutkikkuusmitat ovat Halsteadin mitta ja McCaben mitta. Kirjallisuudessa näihin mittoihin suhtaudutaan kuitenkin melko varautuneesti. Kattavuusmitoilla voidaan yrittää varmistaa, että testiaineisto aiheuttaa testattavan ohjelman kaikkien osien kattavan suorittamisen. Kattavuusmittaa voidaan myös käyttää todisteena siitä, että testausta on suoritettu riittävästi. Kattavuusmittoja ovat lausekattavuus, päätöskattavuus, ehtokattavuus, moniehtokattavuus ja polkukattavuus. Lausekattavuudella tarkoitetaan suoritettuja lauseita jaettuna ohjelman sisältämillä lauseilla. Vaikka 100 % lausekattavuus saattaa kuulostaa itsestään selvältä vaatimukselta, niin käytännössä siihen on mahdotonta päästä. Käytäntö onkin osoittanut, että jos ohjelmoijaa pyydetään testaamaan pienikin koodimoduuli lausekattavasti, niin todellinen kattavuus harvoin ylittää 90 %.

21 Päätöskattavuudella tarkoitetaan suoritettuja haaroja jaettuna mahdollisten haarojen määrällä, eli jokainen ehto saa testattaessa molemmat arvonsa (tosi/epätosi). Ehtokattavuudella tarkoitetaan, että päätöksen kaikkien ehtojen on saatava kaikki arvonsa. Moniehtokattavuudessa testaus suoritetaan kaikkien ehtojen kaikilla kombinaatioilla. Polkukattavuudessa ohjelmaa tarkastellaan suunnattuna verkkona, jonka solmuina ovat ohjelman haarautumiskohdat. Polkukattavuudessa pyritään kattamaan mahdollisimman monia erilaisia suorituspolkuja ohjelman läpi. On olemassa myös testikattavuusanalysaattoreita. Nämä ovat työkaluja, jotka mittaavat testin kattavuutta jollain ylläkuvatulla kattavuusmitalla. Samalla työkalulla voi usein mi tata ohjelmarivien suorituskertojen lukumääriä ja prosessorin ajankäyttöä. Testauksen kattavuuden saaminen korkeaksi on helpointa moduulitestauksessa, vaikkakin siinäkään ei yleensä päästä täyteen sataan prosenttiin asti. Sääntönä voidaan pitää, että mitä korkeammalle testauksen V mallissa edetään, sitä pienemmäksi kattavuuden prosentuaalinen määrä laskee. Esimerkiksi asiakkaalle toimitettua versiota testatessa (ns. julkaisutestaus) testikattavuus harvoin ylittää 50 prosentin rajan. (Haikala & Malijärvi 2006, 290 295; Patton 2006, 38 40; Black 2005, 298 300.) 4.8 Testauksen työkalut Kuten edellä mainittiin, testaukseen on olemassa ohjelmallisia työkaluja, joiden tarkoi tuksena on automatisoida testejä. Varsinkin regressiotestauksen tulisi olla mahdolli simman automatisoitua. Testien automatisoinnin hyötyjä pitkällä tähtäimellä ovat: testisarjojen suorittamiseen kuluvan ajan pienentyminen testien suorittamisessa testaajien käytön tarpeen pienentyminen satojen eri käyttäjien simuloinnin mahdollistaminen ihmistestaajien inhimillisten virheiden, kuten näppäilyvirheiden, karsiutuminen

22 Testityökalujen kaksi päätoimea ovat testien suorittamien ja niistä saatujen tulosten arviointi. Näitä työkaluja ovat esimerkiksi testipetigeneraattorit, testitapausgeneraattorit, vertailijat ja testikattavuustyökalut. Testipetigeneraattori (test bed generator) luo testattavalle ohjelmamoduulille testipedin, jolle luodaan testikuvauskielellä ajettava testi. Kielellä voidaan määrätä halutut testitu lokset, jolloin testitulosten tarkastelu on automatisoitavissa. Järjestelmätestauksessa taas käytetään ns. capture and playback työkaluja, jotka voi vat tallentaa testaajan näppäinlyönnit, hiiren liikkeet ja järjestelmän antamat syötteet. Ohjelma tallentaa nämä syötteet scriptiin, joka voidaan ajaa myöhemmin uudelleen. Testitapausgeneraattoreiden käyttö ei ole kovin yleistä ja se on yleensä lähes mahdotonta, koska se edellyttää testattavan ohjelman formaalia spesifiointia. Joissain erikoistapauksissa sen käyttö on kuitenkin mahdollista. Esimerkiksi, jos monimutkainen käyttöliittymä on spesifioitu tilakaaviona, testiaineisto voidaan generoida tilakaavion avulla ja myös testitulosten tarkastelu voidaan automatisoida. Vertailijaohjelmilla (comparators) etsitään eroja ohjelman antamien tulosten välillä ja erojen perusteella päätellään, ovatko testit menneet läpi onnistuneesti. Testaaja pystyy usein lisäksi määrittelemään tietyn osan testituloksista, jonka hän haluaa jättää huomioimatta. Esimerkiksi päivämäärän ja ajan huomiotta jättäminen on järkevää, koska tällöin testin lopputulos on silti positiivinen, jos testi on muilta osiltaan suoritettu onnistuneesti (paitsi silloin jos kellon aika olisi muuttunut). Testikattavuusanalysaattorityökalut käyttävät hyväkseen jotain olemassa olevasta kattavuusmitoista. Toimintaperiaatteiltaan ne ovat yleensä esiprosessoreita, jotka instrumentoivat moduulin koodin siten, että ne mittaavat testin kattavuuden sitä suoritettaessa. Samoilla työkaluilla pystytään yleensä myös mittaamaan ohjelmarivien suorituskertojen lukumääriä ja prosessoriajan käyttöä. Ohjelmakoodin instrumentoinnin haittapuolena on se, että se kasvattaa ohjelmakoodin kokoa ja hidastaa suoritusta. Tämän takia se rajoittaa testikattavuusanalysaattoreiden käyttöä järjestelmätestauksessa ja reaaliaikajärjestelmien yhteydessä.

23 Testityökalujen käyttö ei myöskään ole ilmaista ja vaatii työtä niistä saatavan hyödyn saavuttamiseksi. Pelkkä ohjelmien hankkiminen ei automatisoi testausprosessia onnistuneesti, vaan ne vaativat hyvän testaussuunnitelman. Hyödyllisen automaattisen testausympäristön luominen vie aikaa ja siitä saatavan hyödyn saaminen edellyttää useiden automatisoitujen testien suorittamista. Tämä sen takia, että automatisoitujen testien luominen vaatii testaustyökalujen hyvää tuntemusta ja niiden ohjelmointia sekä niitä käyttävien testaajien kouluttamista. Lisäksi uusia testejä joudutaan aina luomaan. Tulee myös ottaa huomioon, että testityökalut ovat ohjelmia, eli nekään eivät ole sataprosenttisesti virheettömiä. Testaustyökalut eivät ole myöskään ongelmattomia, sillä niiden käyttö saattaa vaikuttaa ohjelman toimintaan. Esimerkiksi sulautetuissa järjestelmissä on tavallista, että kehityslaitteistossa toimiva ohjelma ei jostain syystä toimi kohdelaitteessa tai että testaustyökalun ohjelmaan liittämisen jälkeen ohjelmassa esiintynyttä ongelmaa ei saada enää esiintymään. Täytyy myös muistaa, että vaikka jokin automatisoitu testiohjelma ei löytäisikään ohjelmasta virhettä, niin se ei takaa, että ohjelma olisi virheetön. (Tamres 2002, 225 226;Haikala & Malijärvi 2006, 294 296.) 4.9 Testausstrategiat ja testitapausten valinta Kaksi yleisintä testitapausten luomiseen käytettävää testaustekniikkaa tai lähestymistapaa ovat mustalaatikkotestaus (black box, functional testing) ja lasilaatikkotestaus (glass/white box testing). Tässä opinnäytetyössä käydään läpi myös harmaalaatikkotestauksen (grey box testing), tutkivan testauksen, positiivisen testauksen ja negatiivisen testauksen lähestymistapa. Nämä kaikki neljä lähestymistapaa ovat testausstrategioita eivätkä teknisiä tai analyyttisiä menetelmiä. Mustalaatikkotestien testitapaukset johdetaan asiakkaan kanssa tehdystä ohjelmistoprojektin määrittelydokumentaatiosta kiinnittämättä huomiota ohjelman sisäiseen tekniseen toteutukseen. Mustalaatikkotestauksessa tarkastellaan ohjelmalle annettuja syötteitä ja niistä palautuvien tulosten oikeellisuutta. Mustalaatikkotestauksessa tulee ottaa huomioon, että vaikka sen avulla voidaan löytää virheitä ja virheellisiä komponentteja, se ei välttämättä kerro virheiden syitä. Tätä varten virheiden syyt voidaan joutua selvittämään lasilaatikkotestauksella.

24 Mustalaatikkotestauksessa testitapausten valinta perustuu syöteavaruuden jakamiseen ekvivalenssiluokkiin (equivalence partitioning). Oletuksena on, että jos järjestelmä toimii yhdellä ekvivalenssiluokan edustajalla, niin se toimii kaikilla saman ekvivalenssiluokan edustajilla. Otetaan esimerkiksi ohjelma, joka pyytää syöttämään kokonaisluvun yhdestä kymmeneen. Tämän ohjelman ekvivalenssi luokat voisivat olla seuraavanlaiset: 1. Epäkelvot syötteet (ei kokonaisluvut ja kaikki muut näppäimistön ei numeraaliset merkit ja niiden yhdistelmät) 2. Liian pienet tai suuret kokonaisluvut 3. Kelvolliset syötteet Tyypillisten ekvivalenssiluokkien edustajien lisäksi on hyvä ottaa testitapauksiksi luokkien rajoilla olevia mahdollisimman suuria, pieniä, pitkiä ja lyhyitä edustajia. Esimerkkitapauksessa näitä olisivat luvut 0, 1, 10 ja 11. Tällaista testitapausten valintaa kutsutaan raja arvoanalyysiksi. Lasilaatikkotestauksessa testitapausten valintaa käytetään hyväksi tietoa ohjelman sisäisestä teknisestä toteutuksesta. Sillä pyritäänkin testaamaan ohjelmiston sisäisten komponenttien virheettömyyttä. Harmaalaatikkotestauksessa taas käytetään hyväksi tietoa ohjelman toteutusperiaatteista. Esimerkiksi harmaalaatikkotestauksessa käytetäisiin hyväksi tietoa siitä, että ohjelma lukee lukuja merkki kerrallaan ja muuttaa ne tässä yhteydessä 32 bittisiksi kokonaisluvuiksi, kun taas lasilaatikkotestauksen testitapaukset perustuvat ohjelmakoodiin tutustumiseen. Sekä mustalaatikko ja lasilaatikkotestauksessa testitapaukset tulee suunnitella siten, että ne sisältävät sekä oikeita että virheellisiä syöttöarvoja. Mitä korkeammalle testauksen V mallissa edetään, sitä enemmän testaus siirtyy lasilaatikkotestauksesta mustalaatikkotestaukseksi. (Tamres 2002, 220; Haikala & Malijärvi 2006, 289; Pohjonen 2002, 36; Kit 2005, 79 80.) Positiivisen testauksen tarkoituksena on osoittaa, että ohjelma vastaa sille asetettuja vaatimuksia. Positiivisen testauksen testitapauksilla pyritään todistamaan, että ohjelma tekee sen, mitä sen on tarkoitus tehdä, eli ohjelma toimii odotusten mukaisesti. Näitä testejä suoritetaan sallituilla syötteillä. Negatiivisen testauksen tarkoituksena on, päinvastoin, todistaa, että ohjelma toimii niin kuin sen ei ole tarkoitus toimia. Negatiivisten

25 testien testitapaukset ovat yleensä monimutkaisempia kuin positiivisten testien. (Sten berg 2007; Tapola 2004.) Testejä luotaessa tai testausammattilaisen testatessa ohjelmaa voidaan käyttää hyväksi myös virheen arvausta (error guessing), joka ei kuitenkaan ole varsinainen testaustekniikka, vaan lähinnä asiakohtainen toiminta tai lähestymistapa. Perusideana on luoda lista mahdollisista virheistä ja virhetilanteista sekä luoda testitapaukset hyväksikäyttäen tätä listaa. Kokenut testaaja pystyy arvaamaan yleisesti tunnettuja kohtia, joissa virheitä voi esiintyä ja suurella todennäköisyydellä virheitä löytyy samoista paikoista kuin ennenkin. Esimerkiksi negatiiviset numerot ovat yksi tunnetuista virhetilanteiden luojista. (Kit 2005, 87.) Tutkiva testaus (exploratory testing) on samanaikaista oppimista, testien suunnittelua ja testien suorittamista. Toisin sanoen tutkiva testaus on mitä tahansa testausta silloin kun testaaja aktiivisesti kontrolloi testien suunnittelua samalla kun testejä suoritetaan ja käyttää hyväkseen niistä saatua tietoa suunnitellakseen uusia ja parempia testejä. Tutkivassa testauksessa voidaan käyttää hyväksi esimerkiksi määrittelydokumentteja tai standardeja, joita ohjelman tulee täyttää. Tutkivassa testauksessa testaaja ei kysy mitä testejä tulee suorittaa, vaan mikä on paras testi, minkä hän voi suorittaa juuri nyt. Tutkivan testauksen hyöty on siinä, että niitä voidaan optimoida koko testausprosessin ajan, kun taas käytettäessä valmiiksi kirjoitettuja testejä itse testit eivät muutu ja niistä tulee tehottomampia ajan myötä. Tutkiva testaus ei missään tapauksessa vastusta suunniteltuja kirjallisia testejä ja suunnitellut kirjalliset testit ovatkin joissain tapauksissa tehokkaampia. Esimerkiksi, jos testeistä saatavan palautteen eteenpäin meneminen on hidasta, se menettää tehonsa. Paras tapa olisi käyttää valmiiksi kirjattuja testejä ja tutkivaa testausta yhdessä ja oikeassa suhteessa. Kaikki ohjelmistotestaajat suorittavat tutkivaa testausta ainakin jollain tasolla, vaikka he eivät loisikaan testejä. Se on vahva lähestymistapa, joka on silti laajasti väärinkäsitetty ja epäkunnioitettu: monetkaan eivät käytä tätä lähestymistapaa, eikä aihetta edes käsitellä alan kirjallisuudessa muutamaa poikkeusta lukuunottamatta.