TAMPEREEN AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma Ohjelmistotekniikan suuntautumisvaihtoehto Tutkintotyö Jaakko Saarinen TESTAUS OSANA OHJELMISTOPROJEKTIA Työn valvoja Tampere 2008 Lehtori Erkki Hietalahti, Tampereen ammattikorkeakoulu
TAMPEREEN AMMATTIKORKEAKOULU TIIVISTELMÄ Tekijä: Työn nimi: Jaakko Saarinen Testaus osana ohjelmistoprojektia Päivämäärä: 14.12.2008 Sivumäärä: 36 Hakusanat: Ohjelmistotestaus, prosessi, testaus Koulutusohjelma: Tietotekniikka Suuntautumisvaihtoehto: Ohjelmistotekniikka Työn valvoja: Lehtori Erkki Hietalahti Ohjelmistotestaus on yksi ohjelmistoprojektin tärkeimpiä vaiheita. Nykyään ohjelmiston laatuun kiinnitetään yhä enemmän huomiota ja tämän vuoksi testaus on kasvattanut osuuttaan jatkuvasti osana ohjelmistoprojektia. Tässä tutkintotyössä tarkastellaan ohjelmistotestauksen roolia ohjelmistoprojektissa. Työssä esitellään ensin ohjelmistotestausta yleisellä tasolla sisältäen muun muassa eri ohjelmistotestauksen menetelmiä ja testausprosessin. Toisessa teoriaosuudessa tarkastellaan ohjelmistoprojektin erilaisia prosessimalleja. Tämän kappaleen tarkoituksena on tuoda esille testauksen tärkeys ja osaltaan kasvattaa ohjelmistotestauksen vähäistä arvostusta. Työn viimeisessä osiossa tarkastellaan edelleen työn laatijan oman kokemuksen kautta testauksen ulkoistamisen vaikutuksia ohjelmistoprojektille. Tämä tutkintotyö ei suoranaisesti esitä ratkaisua mihinkään tunnettuun ongelmaan, vaan lisää ymmärrystä ohjelmistotestauksen suhteesta itse ohjelmistoprojektiin.
TAMPERE UNIVERSITY OF APPLIED SCIENCES ABSTRACT Author: Name of the thesis: Jaakko Saarinen Testing as a part of Softwareproject Date: 14.12.2008 Number of pages: 36 Keywords: Software testing, process Degree programme: Information and communications technology Specialisation: Software technology Supervisor: Lecturer Erkki Hietalahti Software testing is one of the most important phases of software project. Nowadays is more and more attention paid to the quality of software and that's the reason why proportion of testing has significantly increased in this project. This thesis is examining role of software testing in the whole software development project. Theory part of this study is firstly introducing software testing generally including well-known testing methods and process of testing. The second part of theory is introducing different software lifecycle models. Purpose of this part is to prove importance of testing and increase appreciation of software testing. The last part of this study is still examining how outsourcing of testing process will affect for software development project. This knowledge is based on writer s own experiences. This thesis isn't directly giving solution for any common problem but increasing understanding of software testing as a part of software project.
ALKUSANAT Tämä tutkintotyö on tehty Tampereen Ammattikorkeakoulun ohjelmistotekniikan insinöörityönä. Työn aiheen päätin loppukesästä 2008 ja työn kirjoittaminen tapahtui syksyn ja alkutalven 2008 aikana. Tahdon kiittää Erkki Hietalahtea työhön liittyvistä neuvoista. Tampereella 14.12.2008 Jaakko Saarinen
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 5 (36) SISÄLLYSLUETTELO TIIVISTELMÄ ABSTRACT ALKUSANAT SISÄLLYSLUETTELO...5 1 JOHDANTO...6 2 OHJELMISTOTESTAUKSEN TAUSTAA...7 2.1 Virheen määritelmä...7 2.2 Testausprosessi...8 2.2.1 Testauksen aikataulutus...9 2.2.2 Virheen korjausprosessi...10 2.2.3 Roolit testauksessa...11 2.2.4 Testauksen dokumentaatio ja raportointi...12 2.2.5 Testauksen päättäminen...14 2.3 Tunnetuimmat testausmenetelmät...15 2.3.1 Lasilaatikkotestaus...16 2.3.2 Mustalaatikkotestaus...17 3 OHJELMISTOPROJEKTI YLEISESTI...19 3.1 Ohjelmistoprojektin elinkaari...19 3.2 Ohjelmistoprojektin vaihejakomallit...21 3.2.1 Big-Bang-malli...22 3.2.2 Vesiputousmalli...22 3.2.3 Spiraalimalli...23 3.2.4 Code-and-Fix-malli...25 3.2.5 V-malli...26 4. TESTAUKSEN ROOLI ERI OHJELMISTOPROJEKTEISSA...30 4.1 Vaihejakomallin vaikutus testausprosessiin...30 4.2 Testauksen ulkoistamisen vaikutus koko ohjelmistoprojektiin...32 5 YHTEENVETO...35 LÄHDELUETTELO...36
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 6 (36) 1 JOHDANTO Testaus on jatkuvasti kasvattanut merkitystään ohjelmistoprojekteissa ja on nykypäivänä kiistatta yksi projektin tärkein ja kustannuksiltaan merkittävin vaihe. Olen itse työskennellyt ohjelmistotestaajana Manpower Business Solutions Oy:n Testing Servicessä lähes kaksi vuotta. Tänä aikana olen tutustunut testauksen eri menetelmiin ja tekniikoihin. Testausyrityksenä emme useinkaan ole mukana ohjelmistoprojektin muissa työvaiheissa. Tästä syystä testaus on ainoastaan erillinen ulkoistettu osa ohjelmistoprojektia. Tutkintotyössäni haluan selvittää, tulisiko testauksen kulkea mukana koko ohjelmistoprojektin elinkaaren ja mikä on sen tehtävä tässä prosessissa? Vastausta tähän kysymykseen etsitään olemassa olevan teorian pohjalta, eli kyseessä on teoreettinen tutkintotyö. Ensimmäisessä teoriakappaleessa tarkastellaan yleisellä tasolla ohjelmistotestauksen taustaa ja menetelmiä. Kappaleessa esitellään ohjelmistotestaukseen usein yhdistettäviä käsitteitä sekä tunnetuimia ohjelmistotestausmenetelmiä. Toisessa teoriakappaleessa tarkastellaan koko ohjelmistoprojektin elinkaarta, jonka yhtenä osana on edellisessä kappaleessa esitelty ohjelmistotestaus. Tämän kappaleen tarkoituksena on käydä läpi erilaisia olemassa olevia prosessimalleja ohjelmistoprojektin toteutukselle. Kolmannessa teoriakappaleessa tarkastellaan kerätyn teorian pohjalta testauksen tehtävää koko ohjelmistoprojektissa. Kappaleen tarkoituksena on selvittää onko olemassa yhtä ohjelmistoprojektin elinkaarimallia, jossa testauksella on selvä paikka ja rooli tässä prosessissa? Edelleen kappaleessa käydään läpi kirjoittajan oman kokemuksen pohjalta ohjelmistoprojektin tärkeimmän osan, eli testauksen ulkoistamisen vaikutusta koko ohjelmistoprojektin toteutukseen.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 7 (36) 2 OHJELMISTOTESTAUKSEN TAUSTAA Ohjelmistojen laatuun kiinnitetään tänä päivänä entistä enemmän huomiota. Asiakkaat ja käyttäjät ovat laatutietoisempia kuin ennen ja näin vaativat ohjelmiltaan entistä enemmän. Testauksen osuus koko projektin resursseista arvioidaankin tyypillisesti olevan yli puolet. Testaukseen kuluvien resurssien arviointi on hyvin hankalaa ja huonosti suoritettu testausprosessi aiheuttaa helposti ohjelmistoprojektin suurimmat kustannukset. Tässä kappaleessa esitellään yleisesti ohjelmistotestausta ja annetaan muun muassa vastaus kysymykseen Mikä on testausprosessin päätarkoitus?. 2.1 Virheen määritelmä Testauksen tarkoituksena on löytää mahdollisimman suuri osa ohjelman virheistä sen mahdollisimman varhaisessa kehitysvaiheessa. Englanninkielisiä termejä virheelle on useita, kuten fault, bug, error ja defect. Näistä termeistä käytetään aina kuhunkin ohjelmistoprojektin osa-alueeseen parhaiten sopivaa vaihtoehtoa. Yleisesti virheenä voidaan pitää koodissa esiintyvää poikkeamaa sovelluksen toiminnallisesta tai teknisestä määrittelystä. Erimielisyyksien välttämiseksi tulisi näiden dokumenttien olla mahdollisimman tarkkoja. Koska määrittelyssä kuvataan kehitettävä tuote yksityiskohtaisesti toimintavaatimuksineen, sen epätarkkuus aiheuttaa suurimman osan löydetyistä virheistä. Se mitä pidetään virheenä kulloisessakin ohjelmistossa, voidaan todeta jo tuotteen määrittelyssä. Seuraava lista kuvaa viisi eri vaihtoehtoa, joista yhden tai useamman toteutuessa esiintyy ohjelmistossa virhe. 1. Ohjelmisto jättää tekemättä jotain, mitä sen määrittelyn mukaan tulisi tehdä. 2. Ohjelmisto tekee jotain, minkä määrittely kieltää.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 8 (36) 3. Ohjelmisto tekee jotain mitä ei mainita määrittelyssä. 4. Ohjelmisto jättää tekemättä jotain, mitä ei määrittelyssä virheellisesti mainita. 5. Ohjelmisto on hankala ymmärtää, vaikeakäyttöinen, hidas tai toimii loppukäyttäjän näkökulmasta selkeästi väärin. Virheen vakavuus riippuu sen yleisyydestä sekä korjaus-, asennus- ja seurauskustannuksista. Se, onko virhe merkityksellinen testattavan ohjelmiston kannalta, riippuu myös sovelluksesta, josta se löydetään. Sovellukset voidaan jakaa äärimmäistä luotettavuutta vaativiin (kuten sairaala- ja pankkisovellukset) sekä vähemmän kriittisiin (kuten kalenterisovelluksiin). /1/ 2.2 Testausprosessi Testausprosessin tulisi kulkea mukana kaikissa ohjelmistoprojektin kehitysvaiheissa, jolloin virheiden löytäminen aikaistuisi ja näin vältyttäisiin mahdolliselta päällekkäiseltä työltä. Suunniteltaessa testausprosessia täytyy ottaa huomioon monia tekijöitä, kuten työntekijöiden osaamisalueet, aikataulut, testausmenetelmät ja mahdollisesti testausprosessia tukevat työkalut. Totta kai on tärkeää huomioida myös asiakas ja loppukäyttäjät. On kuitenkin mahdotonta ottaa huomioon kaikkea tulevaa, sillä aikataulut usein venyvät ja virheiden määrää ei pystytä ennustamaan etukäteen. Testausprosessi alkaa yleisesti prosessin määrittelystä ja suunnittelusta. Itse testaus suoritetaan näiden suunnittelujen, tuotetun koodin ja testiaineiston pohjalta. Testikierroksella havaitut virheet raportoidaan ja ohjataan kehittäjille korjattavaksi. Kehittäjät tekevät korjaukset koodiin, jonka jälkeen suoritetaan uusintatestaus, jossa tehdyt korjaukset joko hyväksytään tai hylätään. Tätä toistetaan kunnes testikierros hyväksytään.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 9 (36) Kun samoja testejä toistetaan useita kertoja, tulevat virheet helposti immuuneiksi näille testeille. Tämän vuoksi saatetaan joutua tekemään muutoksia testitapauksiin. Näin uusilla testitapauksilla on mahdollista löytää vielä olemassa olevia virheitä. Seuraavassa listassa on esitelty kuusi keskeistä periaatetta ohjelmistotestauksessa. /1, 2/ 1. Testauksen onnistuminen on riippuvainen testausprosessin laadusta. 2. Testauksen aloittaminen elinkaaren varhaisessa vaiheessa ehkäisee virheiden siirtymisen. 3. Tehokas testaus vaatii ajanmukaiset testityökalut. 4. On nimettävä henkilö vastaamaan testausprosessin kehityksestä. 5. Testaus on ala, joka vaatii koulutettuja, osaavia ihmisiä. 6. Ryhmässä on ylläpidettävä myönteistä luovan tuhoamisen (creative destruction) ajattelua. 2.2.1 Testauksen aikataulutus Testauksen ja verifioinnin aloittaminen mahdollisimman aikaisessa vaiheessa säästää huomattavasti vaivaa ja rahaa. Kun virhe saadaan poistettua mahdollisimman varhaisessa prosessin vaiheessa, säästytään pitkältä jäljitysprosesseilta ja säästetään niin resursseja kuin rahaakin. Tuotteen toiminnallisuuden ja laadun varmistamiseksi tulisi kullekin testauksen tasolle tehdä testaussuunnitelma jo alkuvaiheessa, kun saman tason määrittely tiedetään. Oletettavaa tietenkin on, että tuotteen määrittely tehdään lopulliseksi jo projektin alkuvaiheessa. Muokattaessa määrittelyä myöhemmin koituu lisätyötä kehittäjien ja dokumentoijien lisäksi myös testaajille. Testauksen aikataulun suunnittelu on tärkeää. Aikataulutus on toteutettavissa muun muassa yksinkertaisilla tehtävälistoilla tai vaihtoehtoisesti yksityiskohtaisemmilla Gant-kaavioilla. Hyvän aikataulun avulla tiedetään, mitä on tehty, mitä on vielä tekemättä ja paljonko aikaa tekemättömiin testauksiin on jäljellä. /1/
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 10 (36) 2.2.2 Virheen korjausprosessi Yksinkertaisimmillaan virheen elinkaari noudattaa seuraavanalaista kaavaa: virhe löydetään ja raportoidaan kehittäjille, kehittäjä korjaa virheen ja raportoi siitä testaajalle, testaaja testaa uudelleen ja hyväksyy korjauksen. Osalla virheistä on kuitenkin selvästi mutkikkaampi elinkaari (kuva 1). Aluksi, kun uusi virhe on havaittu, se avataan (engl. open). Kun virhe on avattu, siirretään se katselmoinnin (engl. review) jälkeen korjattavaksi kehittäjille tai mahdollisesti virhe asetetaan odottamaan myöhempää korjausta (engl. deferred). Virhe voidaan katselmoinnin jälkeen myös hylätä kokonaan. Lopulta, kun kehittäjät ovat saaneet virheen korjattua, testataan toiminta uudelleen ja joko hyväksytään virhe ja suljetaan se, tai hylätään ja avataan se uudelleen. New Bug Open Review Reopened Resolved Deferred Test Closed Kuva 1 Virheen elinkaari Syitä joidenkin virheiden korjaamatta jättämiseen on useita. Osa virheistä jätetään korjaamatta ajan puutteen vuoksi, koska ohjelma on saatava valmiiksi tiettyyn päivämäärään mennessä. Joskus kyseessä ei ole todellinen virhe, vaan ominaisuus. Tämä johtuu useimmiten väärinymmärryksestä tai muuttuneesta määrittelystä. Joidenkin virheiden korjaamisen pidetään riskitekijänä, koska niiden korjaaminen aiheuttaisi lisää virheitä, joiden korvaaminen olisi huomattavasti työläämpää. Lisäksi joidenkin virheiden korjaaminen ei ole vaivan arvoista. Tällaiset virheet esiintyvät
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 11 (36) vain harvoin ja niiden välttämiseksi ohjelmassa on vaihtoehtoinen tapa suorittaa asia. Näin liiketoiminnan kannalta on kannattavampaa jättää virhe korjaamatta. /1, 4/ 2.2.3 Roolit testauksessa Kun testausta suunnitellaan, tulee päättää myös testauksen rooleista. On harhaanjohtavaa ajatella, että kehittäjät ovat parhaita testaajia, koska he tuntevat koodinsa parhaiten. Kehittäjät kuitenkin pyrkivät testaajina todistamaan vain oman koodinsa toimivaksi ja tulevat helposti sokeiksi omassa koodissaan esiintyville virheille. Suurissa ja tärkeissä projekteissa testaus ulkoistetaan erilliselle testausorganisaatiolle. Tällaisia testauspalveluja tarjoavia yrityksiä on tänä päivänä markkinoilla useita. Sovelluskehittäjän rooliin kuuluu yksikkötestauksen suorittaminen ja useimmiten myös integraatio-osuuden testaaminen, jolloin tulee varmistetuksi osien välisten yhteyksien toimiminen. Tämän jälkeen varsinainen testausryhmä aloittaa testauksen. Testausryhmä on jo aiemmin luonut tarvittavat testaussuunnitelmat, joiden pohjalta testaus aloitetaan. Kehittäjät ovat testauksen aikana virheiden korjaajina. Testiryhmä koostuu neljästä päätehtävänimikettä: testiteknikko tai nykyään paremminkin seniori ohjelmistotestaaja, huolehtii testauksessa tarvittavien ohjelmien asennuksesta ja konfiguroinnista sekä suorittaa mahdollisesti joitakin pienempiä ja yksinkertaisempia testejä. Yleisin ja tunnetuin tehtävänimike on ohjelmistotestaaja, joka uransa alkuvaiheessa työskentelee senioritestaajan kanssa, kuitenkin kirjoittaen itse testitapauksensa. Kokeneemmat ohjelmistotestaajat ottavat osaa myös testaussuunnitelmien tekoon. Seuraavana roolina testauksen urakehityksessä on testiryhmän johtaja, joka vastaa pienissä projekteissa koko testauksesta ja suuremmissa projekteissa suurimmasta osasta testausta. Johtaja vastaa myös testaussuunnitelman teosta ja valvoo muiden testaajien työskentelyä. Testausryhmää johtaa testimanageri. Hänen tehtäviinsä kuuluvat tiedon välitys projektin johdolle, aikataulus-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 12 (36) ta sopiminen, tavoitteiden suunnittelu, ensisijaisten tehtävien valinta ja testausresurssien hyödyntäminen projektin aikana. /1/ 2.2.4 Testauksen dokumentaatio ja raportointi Testaukseen liittyy hyvin merkittävänä osana erilainen dokumentointi ja raportointi projektin eri vaiheissa. Testausdokumentaation tarvitsevat testaajien lisäksi projektin johto ja muut työntekijät. Kunnollinen dokumentaatio on äärimmäisen tärkeässä tehtävässä projektin onnistuneessa läpiviennissä, uusien työntekijöiden perehdyttämisessä ja sovelluksen uusien versioiden kehityksessä. Tämän takia dokumentaatiot tulee kirjoittaa alusta pitäen vastaamaan kattavasti kysymyksiin; mitä testaan, miksi testataan ja miten testataan. Kattava ja kunnollinen dokumentointi vie paljon aikaa projektilta, mutta se tekee testauksesta hallittua, joustavaa ja nopeampaa. Testauksessa tarvittavia dokumentteja on useita riippuen projektin koosta. Dokumentit voidaan jakaa kolmeen pääkategoriaan: suunnittelu, spesifiointi ja raportointi. Seuraavaksi esitellään lyhyesti seuraavat dokumentit: testaussuunnitelma, testitapaukset ja virheraportointi. Nämä kolme dokumenttia edustavat dokumenttien pääkategorioita. Testaussuunnitelma on ensimmäinen testausvaiheen dokumentti. Se ohjaa testauksen aikaista toimintaa. Testaussuunnitelma toteutetaan useimmiten valmiiseen pohjaan, mutta toteutukseen tulisi varata kuitenkin riittävästi aikaa, sillä suunnitelma on ehdottomasti testauksen tärkeimpiä raportteja. Testaussuunnitelmasta tulisi ensimmäisenä selvitä suunnitelman tarkoitus, testattavan sovelluksen tiedot ja yksityiskohtaisesti eritellyt vaatimukset. Suunnitelmassa tulisi määrätä myös testauksen aikataulu. Aikataulusta tulee selvitä testikierrosten aloitus- ja lopetuskriteerit.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 13 (36) Kaikki testauksessa tarvittavat resurssit, ihmisistä työkaluihin ja ohjelmistoihin, tulee dokumentoida. Pienenkin projektin testaussuunnitelmassa on hyvä kertoa, kuka projektissa on vastuussa mistäkin. Sovelluksen osa-alueet tulee jakaa testaajien kesken sekä määritellä ensi- ja toissijaiset tehtävät. Yhteisymmärryksen saavuttamiseksi olisi kaikki käytetyt termit määriteltävä. Testaussuunnitelmassa kerrotaan testaukseen liittyvästä strategiasta, käytetyistä menetelmistä ja mahdollisista testaustyökaluista. Lisäksi tulee päättää ja kirjata, testataanko kaikki itse vai annetaanko ainakin osa testauksesta ulkopuolisen testausyrityksen hoidettavaksi. Olennainen osa testausprosessia ovat dokumentaatioon kirjoitetut testitapaukset. Testitapausten tärkeyteen on neljä pääsyytä: useat testaajat, toistettavuus, jäljitettävyys ja todistaminen. Projektissa saattaa olla useita testaajia laatimassa testitapauksia pitkällä aikavälillä. Tämän vuoksi muidenkin testaajien ja projektiin liittyvien henkilöiden on tiedettävä ja pystyttävä käyttämään testitapauksia. Toistettavuudella tarkoitetaan samojen testitapausten suorittamista uudelleen. Tätä tarvitaan korjattujen virheiden uudelleen testaukseen, jolloin testauksen alussa on saatava täsmälleen samat arvot kuin aiemmilla testauskerroilla. Jäljitettävyydellä tarkoitetaan, että testitapaukset toimivat dokumentteina kerrottaessa suoritettujen ja suorittamatta jätettyjen testitapausten määrästä sekä hyväksytyistä ja hylätyistä testeistä. Viimeinen tärkeä syy, todistaminen, tarkoittaa mahdollisuutta todistaa tiettyjen osien testaaminen ja siten niiden toiminta. Testitapausten tulisi olla mahdollisimman yksiselitteisiä ja niiden tulisi kuvata yksityiskohtaisesti testauksen suoritus askeleittain. Aluksi tulee kuvata lähtötilanne, josta selviävät mahdolliset alkuvalmistelut. Ohjelmalle annettavat syötteet on mainittava tarkasti, ja mikäli syötteitä on joissain kohdissa useampia, tulee vaihtoehdot listata selkeästi. Myös oletettujen tulosten tulee selvitä testitapausdokumenteista. Testaus tulisi siis pystyä suorittamaan pelkillä testitapausten kuvaamilla tiedoilla. Kaikki testauksessa havaitut virheet tulee dokumentoida. Virheraportin tulee olla tarkka, ettei kehittäjille tule väärinkäsityksiä asiasta, jolloin virhe voi jäädä huomi-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 14 (36) oimatta. Mitä aikaisemmassa vaiheessa projektia virhe raportoidaan, sitä suuremmalla todennäköisyydellä se tulee korjatuksi. Jotta varmistutaan vakavien virheiden korjaamisesta, tulee virheraporttien elinkaarta seurata. Virheraportissa tulee virhe kuvata tarkasti, mutta kuitenkin vain tarvittavat arvot ja askeleet tulee kuvata virheen uudelleen tuottamiseksi. Muuttujien alkuarvot, suoritetut toiminnot ja arvot virheen esiintyessä ovat välttämättömiä kohtia raportissa. Mikäli mahdollista, tulee syitä virheen syntymiselle etsiä ja raportoida. Raporttiin tulee kirjata myös virheen vakavuus ja prioriteetti, jotka auttavat kehittäjiä päättämään virheiden korjauksen kiireellisyydestä. /1, 5/ 2.2.5 Testauksen päättäminen Jo testausta suunniteltaessa tulee määrittää kriteerit, joiden täytyttyä testaus voidaan lopettaa ja todeta sovellus kelvolliseksi. Yksi hiukan harhaluuloinen tapa todeta testaus suoritetuksi on se, että virheitä ei enää löydy. Tämä ei kuitenkaan todellisuudessa ole mahdollista, sillä suurin osa nykyisistä ohjelmista on sen verran laajoja, että niistä on mahdotonta löytää kaikki virheet. Testauksen lopettaminen tulisi ajoittaa niin, että tuotteessa ei ole enää liikaa virheitä ja toisaalta liiketoiminnan kannalta on aika luovuttaa tuote asiakkaalle. Tätä voidaan kuvata kaaviolla (kuva 2), jossa testauksen kustannuksia ja löytämättömien virheiden määrää verrataan liian vähäiseen ja liiallisen testaukseen. Hyvä lopetuskohta on mahdollista pyrkiä määrittämään tietyillä säännöillä ja niin, että sen kriteereillä olisi testauksen tasoa nostava vaikutus. Nykypäivänä testaus teetetään yhä useammin ulkopuolisilla, jotta testaus olisi tavallista laadukkaampaa. Jokaiselle testauksen vaiheelle tulisi erikseen määritellä lopetuskriteerit. Näin siirtyminen seuraavaan vaiheeseen testauksessa tapahtuisi vain silloin, kun edellisen vaiheen testauskriteerit on täytetty. Usein kuitenkin projekteissa päädytään testauk-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 15 (36) sen lopettamiseen aiemmin valitun päivämäärän mukaan, mikä siirtää ongelmia tulevaisuuteen. /1, 3/ Löytämättömien virheiden määrä Testauksen kustannukset Optimaalinen testausmäärä Määrä Liian vähäinen testaus Liiallinen testaus Testauksen määrä Kuva 2 Optimaalinen testausmäärä 2.3 Tunnetuimmat testausmenetelmät Testausmenetelmillä tarkoitetaan tapaa suorittaa testit. Testitapausten valinta määräytyy valitun testausmenetelmän mukaan. Yleisesti testitapausten valintaan on käytettävissä kaksi päästrategiaa: musta- ja lasilaatikkotestaus. Mustalaatikkotestaus (engl. black-box testing) toteutetaan ohjelman määrittelyjen avulla ja siinä pyritään syötteiden ja vasteiden avulla toteamaan toiminnan oikeellisuus. Lasilaatikkotestauksessa (engl. white-box testing, glass-box testing) pyritään löytämään virheellisiä kohtia ja toiminnallisuuksia ohjelman koodin avulla. Mustalaatikko- ja lasilaatikkotestauksen yhdistelmää kutsutaan harmaalaatikkotestaukseksi, jossa hyödynnetään molempien menetelmien parhaimpia ominaisuuksia. Testauksen taso yleisesti määrää testitapausten valintamenetelmän niin, että lasilaatikkomenetelmää käytetään yksikkötestauksessa ja siirryttäessä suurempiin kokonaisuuksiin muuttuu laatikon väri tummemmaksi. Lasilaatikkomenetelmillä kes-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 16 (36) kitytään siis yksityiskohtiin ja siksi sen käyttö on mahdotonta integroidussa systeemissä. Testausmenetelmät jaetaan musta- ja lasilaatikkotestauksen lisäksi staattisiin ja dynaamisiin menetelmiin. Dynaamisessa testauksessa (engl. dynamic testing) sovelluksesta pyritään löytämään virheitä ajamalla sitä. Staattisessa testauksessa (engl. static testing) ohjelmaa ei sen sijaan ajeta, vaan testaaminen toteutetaan tarkkailemalla suunnitelmaa, arkkitehtuuria ja koodia virheiden löytämiseksi. /1, 6/ 2.3.1 Lasilaatikkotestaus Lasilaatikkotestaus edellyttää koodiin käsiksi pääsyä ja mahdollisuutta nähdä ja analysoida sitä. Tähän viittaa myös testausmenetelmän nimi, eli testaaja näkee laatikon sisään ja voi näin tarkastella koodia. Staattisessa lasilaatikkotestauksessa tarkastellaan huolellisesti ja suunnitelmallisesti ohjelman rakennetta, arkkitehtuuria tai koodia virheiden löytämiseksi kuitenkaan ajamatta sitä. Staattinen testaus on hyvin aikaa vievää ja kallista, minkä takia sitä ei suoriteta kovinkaan useissa projekteissa. Iso etu staattisessa testauksessa on kehittäjien ja ohjelmoijien yhteistyö. Tämä antaa molemmille osapuolille mahdollisuuden nähdä ja ymmärtää toisen osapuolen työtä ja taitoja, ja näin he oppivat ja osaavat arvostaa toisiaan entistä paremmin. Staattista lasilaatikkotestausta pidetään yleisesti aikaa vievänä, kalliina ja tuloksettomana. Virheiden löytäminen on kuitenkin huomattavasti hankalampaa ja kalliimpaa kehityksen loppuvaiheessa. Ongelma onkin siinä, että yleisesti kehittäjän työnä pidetään pelkkää koodin kirjoitusta ja kaikki aika, jonka hän käyttää muuhun, hidastaa projektia. Dynaamisessa lasilaatikkotestauksessa testitapaukset rakennetaan ohjelman sisäisen rakenteen avulla. Testitapausten suorittamisen jälkeen tuloksia verrataan odotettuihin tuloksiin ja tehdään analyyseja sen pohjalta. Dynaamisen lasilaatikkotes-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 17 (36) tauksen menetelmät jaetaan yleisesti kolmeen ryhmään: kontrollin kulku, silmukkatestaus ja tietovirtatestaus. Näille eri menetelmillä voidaan varmistaa sovelluksen kattavuus kullakin osa-alueella. Dynaaminen testaus on huomattavasti systemaattisempaa kuin staattinen testaus. Dynaaminen lasilaatikkotestaus soveltuu useimpiin ohjelmiin. Koska menetelmät voidaan ottaa käyttöön jo varhaisessa vaiheessa, on niihin kuluva aika lyhyempi. Menetelmien avulla saadaan käytyä läpi kaikki niin sanotut tavallisimmat virhetilanteet. Suurimpana haittapuolena voidaan pitää lähdekoodin välttämättömyyttä. Koska testaus suoritetaan aikaisessa vaiheessa, ei lähdekoodia ole aina välttämättä saatavilla. /1, 3, 6/ 2.3.2 Mustalaatikkotestaus Päinvastoin kuin lasilaatikkotestauksessa, mustalaatikkotestauksessa testataan sisäisen toiminnan sijaan ohjelman syöte-vaste-käyttäytymistä. Mustalaatikkotestauksessa ei siis välitetä ohjelman sisäisestä rakenteesta tai sisällöstä, vaan ainoastaan ohjelmaan annettuja syötteitä ja niiden tuottamia vasteita tutkitaan. Testattava kohde voi siis olla testaajalle täysin tuntematon, niin sanottu musta laatikko. Sovelluksen käyttäytymistä tietyillä syötteillä verrataan määrittelyihin sekä arkkitehtuuriin ja ohjelmakoodin toimintapa jätetään huomioimatta (kuva 3). Staattinen mustalaatikkotestaus suoritetaan ainoastaan kirjoitetulle määrittelyaineistolle. Tällä tavoin estetään virheiden siirtyminen dokumentaatiosta kirjoitettuun koodiin. Staattinen mustalaatikkotestaus voidaan suorittaa jo projektin alkuvaiheessa, koska riittää, että tuotteen määrittelydokumentti on valmiina. Tällöin virheiden korjauskustannuksissa säästetään, kun virheet eivät ehdi koodiin.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 18 (36) Kun ohjelmaa testataan tuntematta sen koodin yksityiskohtia, puhutaan dynaamisesta mustalaatikkotestauksesta. Koska ohjelmaa ajetaan loppukäyttäjän tapaan, puhutaan dynaamisesta testauksesta ja koska ohjelman toimintatapaa ei tunneta tarkalleen, kyseessä on mustalaatikkotestaus. Testauksessa ohjelmalle annetaan syötteitä ja tarkastellaan niiden tuottamia vasteita. Dynaamista mustalaatikkotestausta kutsutaan myös käyttäytymistestaukseksi, koska siinä testataan kuinka ohjelma todellisuudessa käyttäytyy, kun sitä käytetään. /1, 6/ Mustalaatikko Syöte Vaste Testattavan tuotteen määrittelyt Odotettu vaste Tulosten vertailu Kuva 3 Mustalaatikkotestauksessa ei tunneta testattavan kohteen sisältöä.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 19 (36) 3 OHJELMISTOPROJEKTI YLEISESTI Pääluvussa kaksi esiteltiin eri näkökulmista ohjelmistotestausta, joka on osa koko ohjelmistoprojektia. Tämän kappaleen tarkoituksena on esitellä lyhyesti ohjelmistoprojektin elinkaarta sekä etsiä vastausta kysymykseen: Voiko testauksen rooli ja työvaihe vaihdella eri ohjelmistoprojekteissa ja mitkä tekijät tähän mahdollisesti vaikuttavat? 3.1 Ohjelmistoprojektin elinkaari Ohjelmistoprojektit noudattavat yleisesti jonkun tietyn prosessimallin mukaista kaavaa. Prosessimalli vaihtelee pitkälti ohjelmistotuotteen mukaan. Yleisimmissä prosessimalleissa ohjelmistoprojektin vaiheita ovat esitutkimus, määrittely, suunnittelu, toteutus, testaus sekä käyttöönotto ja ylläpito (kuva 4). 1.Esitutkimus 2.Määrittely 6.Käyttöönotto ja ylläpito Ohjelmistoprojektin elinkaari 3.Suunnittelu 5.Testaus 4.Toteutus Kuva 4 Ohjelmistoprojektin yleinen elinkaari
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 20 (36) Esitutkimus on yleisesti ohjelmiston elinkaaren ensimmäinen vaihe. Esitutkimusvaiheessa selvitetään asiakkaan ja käyttäjien vaatimukset kehitettävän tuotteen suhteen. Tässä vaiheessa määritellään yleiset järjestelmätason vaatimukset päätavoitteista. Tätä määrittelyä kutsutaan asiakasvaatimukseksi, koska siinä huomioidaan asiakkaan ja käyttäjien tarpeet ilman varsinaista toteutusta. Jotta asiakkaan todelliset tarpeet ja toiveet saadaan kirjattua ylös, tulee asiakkaan tarpeet selvittää tapaamisten yhteydessä esim. haastatteluilla. Määrittelyvaiheessa asiakasvaatimuksia analysoidaan ja niistä johdetaan ohjelmistovaatimukset eli haetaan vastaus kysymykseen mitä ohjelma tekee?. Määrittelyn tuloksen syntynyttä dokumenttia kutsutaan toiminnalliseksi määrittelyksi. Siinä kuvataan ohjelmiston toiminnot, tiedon kulku ja sisältö sekä toteutukselle asetettavat ei-toiminnalliset vaatimukset ja rajoitukset. Vaatimusmäärittely on elinkaaren tärkein vaihe, sillä huonoa määrittelyä ei voida pelastaa enää suunnittelulla tai koodauksella, eikä tuote miellytä asiakasta ja käyttäjiä tai se ei vastaa heidän tarpeitaan. Kolmas eli suunnitteluvaihe vastaa kysymykseen miten ohjelma toteutetaan?. Tämä vaihe jaetaan neljään osaan: tiedon rakenteeseen, ohjelmiston arkkitehtuuriin, käyttöliittymän esittämiseen ja toiminnallisiin yksityiskohtiin eli moduulien suunnitteluun. Määrittelyvaiheen tiedoista muodostetaan ohjelmiston suunnittelu ja dokumenttina saadaan tekninen määrittely. Ennen siirtymistä toteutusvaiheeseen on suunnitteluvaiheessa toteutettujen dokumenttien laatu hyvä varmistaa. Sovelluksen laadun varmistamiseksi on suunnitteluvaiheessa huolehdittava selkeydestä, ymmärrettävyydestä, tehokkuudesta, luotettavuudesta, ylläpidettävyydestä ja siirrettävyydestä. Toteutusvaiheessa ohjelman osat toteutetaan suunnitteludokumenttien mukaisesti. Dokumentteja tulee noudattaa ja tarvittaessa niihin voidaan tehdä muutoksia. Tuotteen määrittelyyn ja suunnitteluun tulee tutustua tarkasti kehitystyön aikana, jotta
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 21 (36) vältytään suurelta määrältä virheitä. Tähän vaiheeseen kuuluu myös virheenjäljitys, joka ei siis ole osa testausvaihetta. Kun ohjelmasta on olemassa ensimmäinen toimiva ja annetut vaatimukset täyttävä versio, voidaan sitä alkaa testata. Testauksessa on tarkoitus tarkastaa ohjelman kaikki osa-alueet sekä havainnoida ja korjata virhetilanteet. Elinkaaren viimeiseen vaiheeseen kuuluvat käyttöönotto ja ylläpito, joka on yleensä vaiheista pisin. Kun ohjelmisto on siirretty asiakkaalle, tehdään siihen monesti muutoksia uusien virheiden ilmentyessä. Asiakkaan halutessa muutoksia tai uusiutuneen ympäristön vuoksi, tarvitaan aina uutta toimintatapaa. Ohjelmistotuotteissa ei varsinaista ylläpitovaihetta esiinny kovin usein verrattuna muiden alueiden tuotteisiin, koska useimmat tuotteet on tehty juuri tiettyä asiakasta varten ja muutokset tehdään sovelluksen seuraavassa versiossa. Tämän perinteisen jaon mukaan testaus on siis ohjelmistotuotantoprosessin viimeinen vaihe ennen käyttöönottoa ja ylläpitoa. Seuraavassa luvussa tullaan pohtimaan muita vaihtoehtoisia paikkoja testauksella ohjelmistoprojektissa esiteltävien vaihtoehtoisten vaihejakomallien avulla. /1, 9/ 3.2 Ohjelmistoprojektin vaihejakomallit Edellisessä kappaleessa esitettiin hyvin pelkistetty elinkaarimalli, mutta on olemassa myös joukko muita tunnettuja ohjelmistoprojektin kehitysmalleja. Näitä eri ohjelmistoprojektin elinkaarimalleja kutsutaan alan kirjallisuudessa vaihejakomalleiksi. Kuten edellisessä kappaleessa todettiin, jaetaan ohjelmiston koko elinkaari, tai ainakin sen toteutusprosessi, eri vaiheisiin. Vaihejakomalleilla määrätään kuinka tämä eri prosessivaiheisiin jako toteutetaan. Tässä luvussa esitellään ensin neljä yleisintä vaihejakomallia ja viimeisenä edelleen yhden vaihejakomallin pohjalta testauksen näkökulmasta kehitetty uusi malli.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 22 (36) 3.2.1 Big-Bang-malli Big-Bang-malli on yksinkertaisin vaihejakomalli, joka noudattaa niin sanotun maailman alkuräjähdyksen kaltaista kaavaa. Mallin mukaan ohjelmisto syntyy, kun kootaan yhteen ihmiset, rahaa ja aika ja odotetaan räjähdystä. Kaikki teho käytetään ohjelman kehitykseen ja koodin kirjoittamiseen. Tässä mallissa ei suunnitella, aikatauluteta, dokumentoida eikä tiedetä ohjelman tarkkaa lopputulosta ennen sen valmistumista. Mallissa ei myöskään palata aiempiin vaiheisiin, joten testaus on ainoastaan virheiden raportointia asiakkaalle. Tätä mallia ei pidetä kovin hyvänä, koska yleensä lopputulosta ei voida taata. Big-Bang-mallissa testausta ei huomioida juuri lainkaan. Mikäli testaus on otettu mukaan malliin, se suoritetaan hyvin pienimuotoisena juuri ennen tuotteen julkaisua. Useimmiten testaus on kuitenkin mukana vain näennäisesti, jotta saataisiin kaikki vakuutettua testauksen jonkinlaisesta toteutuksesta. /1/ 3.2.2 Vesiputousmalli Vesiputousmalli on vaihejakomalleista tunnetuin. Se on yksinkertainen, järkevä ja oikeanlaisessa projektissa erittäin toimiva. Mallissa liikutaan portaittain vaiheesta toiseen projektin alkuideasta aina sen elinkaaren loppuun (kuva 5). Kun siirrytään seuraavaan vaiheeseen, tarkastetaan ensin edellisen vaiheen lopussa, ollaanko valmiita siirtymään vai tarvitseeko samaa vaihetta vielä jatkaa. Mallia käytetään usein myös lineaarisesti, jolloin paluuta edellisiin vaiheisiin ei käytetä. Vesiputousmallissa ohjelman suunnittelulle on varattu paljon käytössä olevasta ajasta. Itse ohjelman toteutukselle sen sijaan on varattu vain yksi askel kuudesta. Nämä askeleet ovat irrallisia, eikä päällekkäisyyksiä niiden tehtävissä ole. Tämä on jokseenkin rajoittavaa, mutta malli toimii hyvin projekteissa, joissa vaatimukset ymmärretään hyvin ja niitä noudatetaan kunnolla.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 23 (36) Idea Määrittely Suunnittelu Toteutus Testaus Kuva 5 Vesiputousmalli. Ylläpito Testauksen näkökulmasta malli tarjoaa yhden suuren edun muihin malleihin verrattuna. Koska kaikki on tarkasti ja perusteellisesti suunniteltu ennen testauksen aloitusta, on testiryhmän helppo määrittää tarkka testaussuunnitelma. Lisäksi testiryhmä pystyy arvioimaan hyvin tulevan testausaikataulun, koska sen jäsenet tietävät tarkalleen, mitä heidän tulee testata. Koska testaus tapahtuu ainoastaan lopussa, ovat virheiden korjauskustannukset huomattavasti suuremmat kuin määrittely- tai suunnitteluvaiheessa. Tätä seikkaa pidetään merkittävimpänä vesiputousmallin haittapuolena. Tämä vaihejakomalli on kuitenkin käytetyin ja yleisesti projektin vetäjien osalta helposti hallittavin malli. Vaihejakomallista on luotu useita variaatioita ja sen pohjalta on kehitetty myös kokonaan uusia malleja. /1, 8 / 3.2.3 Spiraalimalli Yksi käytetyimmistä vaihejakomalleista on spiraalimalli (kuva 6), joka on erityisen tehokas malli kehitysprosessissa. Mallin perusajatuksena on, että prosessia tarkennetaan asteittain. Aluksi luodaan alkeellinen prototyyppi toteutettavasta ohjelmasta tai sen tärkeästä osasta. Sitä testataan ja mahdollisesti esitellään asiakkaalle. Testa-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 24 (36) uksesta ja asiakkaalta saadusta palautteesta aloitetaan seuraava suunnittelun, kehityksen ja testauksen kierros. Kuva 6 Spiraalimalli Spiraalimalli on kehitetty lainaamalla hyväksi todettuja ominaisuuksia muilta malleilta. Kun tähän lisätään ongelmakohtien aikaisen havaitsemisen alhaisemmat kustannukset, saadaan kohtalaisen hyvä vaihejakomalli. Testaajat ovat mukana kaikissa projektin vaiheissa, ja näin he näkevät vaatimukset ja halutut tuotokset. Testaus tapahtuu siis vaihejakomallin kaikissa vaiheissa. Tällöin projektin viivästyessä testaus ei ole ensimmäinen osa-alue josta aikataulua kiristetään. Ainoastaan viimeinen testien tarkastelu ja oikeellisuuden tarkistus jäävät projektin kiireiseen loppuun. Spiraalimallin heikkoutena on mahdollinen aikataulun venyminen ja kustannusten kasvaminen, koska tulevia projektin vaiheita ei tiedetä tarkasti. Edelleen mallin toimivuutta voi olla hankala selittää sitä tuntemattomalle ja se saattaa aiheuttaa
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 25 (36) epäselvyyttä projektiryhmään kuuluvien henkilöiden välillä. Projektimallia paremmin tuntemattomat voivat helposti luulla, että jo ensimmäisessä testausvaiheessa ollaan tuotteen osalta lähellä valmista lopputuotetta. /1, 7/ 3.2.4 Code-and-Fix-malli Code-and-Fix-malliin päädytään usein, jos mitään muuta mallia ei pystytä käyttämään. Mallissa toistetaan koodausta, testausta ja virheiden korjausta kunnes niin sanotusti annetaan periksi ja julkaistaan tuote (kuva 7). Valmis tuote Vapaamuotoinen määrittely Koodaus, (testaus), korjaus, toistoja kunnes? Kuva 7 Code-and-Fix-malli Code-and-Fix-mallia käytettäessä aloitetaan tyypillisesti karheasta ideasta, eli siitä mitä projektilta halutaan. Seuraavaksi tehdään yksinkertainen suunnitelma ja aloitetaan pitkä koodauksen, testauksen ja virheiden korjauksen toisto. Kun tullaan siihen lopputulokseen, että toistoa on tehty tarpeeksi, on tuote valmis. Malli sopii hyvin etenkin pienten projektien, kuten demojen ja prototyyppien, toteuttamiseen, koska suunnitteluun ja dokumentointiin ei käytetä kovin paljon resursseja, saadaan tulokset esiteltyä välittömästi. Mallia on tosin käytetty myös monissa suurissa ja tunnetuissakin ohjelmistoprojekteissa. Ohjelman, joka on toteutettu Code-and-Fix-mallia käyttäen, tunnistaa usein sen sisältämästä suuresta määrästä pieniä virheitä ja sen viimeistelemättömyydestä.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 26 (36) Kuten Big-Bang-mallissa, myös Code-and-Fix-mallissa on testaus jätetty kokonaan pois, mutta todellisuudessa testauksella on suuri merkitys koodauksen ja korjauksen välissä. Testaajien on yhdessä ohjelmoijien kanssa oltava jatkuvasti tietoinen kehityksen vaiheesta. Testaajat saavat jatkuvasti uusia versioita ohjelmasta testattavaksi. Kun tietty versio on testattu, raportoidaan virheistä ja saadaan taas uusi versio testattavaksi. Code-and-Fix-malli on hyvä johdatus ohjelmistokehitykseen testaajille ja auttaa heitä hyväksymään uusia tavanomaisia metodeita. /1/ 3.2.5 V-malli Testauksen näkökulmasta katsottuna, on niin kutsuttu V-malli (kuva 8) yksi käytetyimmistä prosessimalleista. V-malli on edelleen kehitetty vesiputousmallista ottaen huomioon testauksen osuus kaikissa ohjelmistoprojektin vaiheissa. Ohjelmistoprojekti etenee V-mallin mukaisesti asteittain tarkentuen seuraavassa järjestyksessä: vaatimusten määrittely ja analysointi, arkkitehtuurin suunnittelu, yksityiskohtainen eli moduulisuunnittelu ja itse toteutus. V-mallissa itse testaus etenee ohjelmistoprojektia vastaavasti seuraavasti: yksikkötestaus, integraatiotestaus, systeemitestaus ja hyväksymistestaus. V-mallissa käydään läpi niin sanottu validisoinnin ja verifioinnin prosessi. Tällä prosessilla pyritään selvittämään ja takaamaan ohjelman laatu. Validisoinnilla tarkoitetaan asiakkaan alkuperäisten toivomusten ja asiakkaan kanssa sovittujen toimintojen toimivuuden täyttämistä. Tämä arviointi tehdään vaatimusmäärittelyn avulla. Verifiointi sen sijaan selvittää ohjelman toiminnan oikeellisuuden, verraten tuotetta sen spesifikaatioon.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 27 (36) Vaatimukset Systeemitestaus Hyväksymistestaus Määrittely Testauksen suunnittelu Integraatiotestaus Arkkitehtuurin suunnittelu ja tulosten vertailu Testaus alkaa yksikkötasolta, jossa keskitytään yksittäisten ohjelman osien, moduulien, toimintaan. Useimmiten ohjelmoijat testaavat itse oman ohjelmakoodinsa yksikkö- ja integraatiotasolla. Systeemitestauksen suorittaa erillinen testiryhmä, jonka tehtäviin kuuluu kaikki systeemitestauksen tehtävät sekä koko sovelluksen integraatiotestaus. Hyväksymistestauksen suorittavat loppukäyttäjien edustajat. Nykyisin yhä useammin testauksen suorittaa kokonaisuudessaan erillinen testausryhmä, jolloin sekä testaus että raportointi suoritetaan hyvin järjestelmällisesti. Ideaalissa tilanteessa yksiköissä esiintyvät virheet löydettäisiin kehityksen alkuvaiheissa ja rajapintavirheet integroinnin aikana. Tällöin systeemi- ja hyväksymistestauksessa voidaan keskittyä ainoastaan korkean tason toiminnallisuuksiin. Käytännössä näin ei kuitenkaan ole, vaan yksikkötason virheitä paljastuu vielä systeemitestausvaiheessakin. Tämän vuoksi testaus suoritetaankin V-mallin mukaan itera- Yksityiskohtainen suunnittelu Yksikkötestaus Koodaus Kuva 8 Testauksen V-malli Kuten kuvasta 3 nähdään, eri testausvaiheet on liitetty yhteen suunnitteluvaiheiden kanssa. Käytännössä eri testausvaiheiden suunnittelu voidaan aloittaa, kun sitä vastaava vaatimus- ja suunnitteluvaihe on valmis. Testauksessa saatuja tuloksia voidaan verrata sitä vastaavan suunnitteluvaiheen vaatimusdokumentteihin.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 28 (36) tiivisesti, jolloin löydettäessä uusia virheitä palataan takaisin aiempien tasojen testaukseen. Yksikkötestaus on järjestelmän pienempien osien eli moduulien testausta. Moduulilla tarkoitetaan ohjelmasta erotettavissa olevaa loogista kokonaisuutta, kooltaan tyypillisesti alle 1000 ohjelmariviä. Testauksen tuloksia verrataan yksikkösuunnittelun- ja arkkitehtuurisuunnittelun dokumentteihin. Yksikkötestauksen suorittaa tavallisesti sovelluksen kehittäjä. Testimoduulien ollessa vain pieniä ohjelman osia, eikä suuria kokonaisuuksia ei moduulitestaus sovellu ainoaksi testausmenetelmäksi. Integrointitestaus tapahtuu eri ohjelman osien, moduulien rajapinnoissa. Pienempiä osia kootaan yhteen ja niitä testataan kunnes koko systeemi on saatu kasaan. Tärkein kohde on moduulien välisten rajapintojen toimivuus. Integrointitestausmenetelmät voidaan jakaa kahteen pääryhmään: lisäävään (incremental) ja ei-lisäävään (non-incremental). Lisäävässä menetelmässä järjestelmän osat testataan siten, että seuraavaan osaan siirrytään vasta, kun aiemmat osat on testattu yhteen toimiviksi. Ei-lisäävässä menetelmässä kaikki osat kootaan kerralla yhteen testattavaksi järjestelmäksi. Tämä on kuitenkin heikompi tapa, koska virheiden jäljittäminen on huomattavasti hankalampaa. Integrointitestauksessa varmistetaan ohjelman moduulien toimivuus keskenään ja pyritään löytämään ja korjaamaan mahdollisimman paljon yhteen sopimattomia moduuleita. Systeemitestauksessa tarkastellaan kehitettyä järjestelmää kokonaisuudessaan sen käyttötarkoitusta vastaavassa ympäristössä. Ohjelmaa tarkastellaan järjestelmätestausvaiheessa loppukäyttäjän näkökulmasta ja pyritään osoittamaan poikkeamia tuotteen sekä sen vaatimusten ja dokumentaation välillä testauksessa. Testauksen suorittajan tulisi olla mahdollisimman riippumaton järjestelmän kehityksestä. Jär-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 29 (36) jestelmätestauksessa testataan myös järjestelmän ei-toiminnalliset ominaisuudet: kuormitustestit, luotettavuustestit, asennustestit, käytettävyystestit jne. Hyväksymistestauksella pyritään osoittamaan, että järjestelmä pystyy suoriutumaan asiakkaan sille asettamista vaatimuksista. Hyväksymistestaus suoritetaan ajallisesti viimeisenä testausvaiheena osana järjestelmätestausta tai omana vaiheenaan sen jälkeen. Testaus suoritetaan yhdessä asiakkaan kanssa käyttäen tuotteen alustavaa versiota. Ennekuin tuote todetaan valmiiksi, se käy läpi vielä kaksi vaihetta. Ensimmäinen vaihe on alfa-testaus, joka suoritetaan kehittäjäyrityksen tiloissa tulevien käyttäjien toimesta kehittäjien johdolla. Toinen vaihe on beta-testaus, joka taas suoritetaan asiakkaan tiloissa ja siihen osallistuu myös ihmisiä kehittäjäyrityksen ulkopuolelta. /1, 6, 7, 9/
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 30 (36) 4. TESTAUKSEN ROOLI ERI OHJELMISTOPROJEKTEISSA Kuten aikaisemmin on todettu, testaus on olennainen osa ohjelmistoprojektia ja sen päätavoitteena on löytää ohjelmiston virheet mahdollisimman aikaisessa vaiheessa ja pitää huolta niiden korjaamisesta. Ohjelmistoprojekti voidaan toteuttaa edellisessä kappaleessa esiteltyjen eri vaihdejakomallien mukaisesti. Tässä kappaleessa vertaillaan edellisessä kappaleessa esitetyn teorian pohjalta, miten testauksen rooli vaihtelee eri ohjelmistoprojekteissa ja kuinka valittu vaihejakomalli vaikuttaa testauksen rooliin. Kappaleessa käsitellään myös testauksen ulkoistamisen vaikutusta itse ohjelmistoprojektiin, tämä tieto perustuu työn laatijan omiin kokemuksiini ohjelmistotestaajana. 4.1 Vaihejakomallin vaikutus testausprosessiin Kappaleessa 3.2 esiteltiin ohjelmistoprosessin vaihejakomallit. Kaikissa vaihejakomalleissa testaus toteutetaan omalla tavallaan ja näin voidaankin todeta vaihejakomallin osaltaan määräävän testauksen roolin ohjelmistoprojektissa. Se missä vaiheessa testaus on mukana ohjelmistoprojektissa ja mikä sen osuus koko ohjelmistoprojektista, vaihtelee merkittävästi eri mallien välillä. Taulukkoon yksi on koottu yhteenveto testauksen merkityksestä kussakin vaihejakomallissa. Pienten projektien kohdalla usein hyödynnetään Big Bang- tai Code-and-fix-mallia. Näissä malleissa ei testaukselle ole varsinaisesti varattu omaa osuutta, vaan se toteutetaan projektin lomassa hyvin pienimuotoisesti. Spiraalimallissa testaus toteutetaan sykleittäin eri ohjelmistoprojektin vaiheissa, kun sen sijaan vesiputousmallissa ohjelmistotestaus tulee projektin viimeisenä vaiheena. Nämä kaksi mallia sopivat kaikenlaisille ja kokoisille projekteille. Vesiputousmallin haittapuolena voidaan mainita se, että puhtaasti lineaarinen prosessi ei yleensä käytännöntasolla onnistu. Koska virheet testataan vasta projektin viimeisessä vaiheessa, mahdolliset korjaukset ohjelmaan voivat aiheuttaa merkittäviä kustannuksia. Mikäli virheiden olemassaoloon olisi puututtu jo aikaisemmassa vaiheessa, olisi vältytty mahdolliselta tur-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 31 (36) halta palaamiselta takaisin, jopa projektin määrittelyvaiheeseen. Spiraalimallin haittapuolena on pidetty sen hallinnan vaikeutta, joka lisäksi saattaa johtaa aikataulun ja kustannusten mahdolliseen karkaamiseen. Testauksen näkökulmasta kehitetyn vaihejakomallin, eli V-mallin, käyttö on tunnetusti paras vaihtoehto tehokkaan ja organisoidun testauksen suorittamiseen ohjelmistoprojektissa. Ohjelmistoprojekteissa, joissa V-mallia käytetään, on otettu alusta alkaen huomioon testaus ja pyritään selkeästi laadukkaaseen lopputulokseen. V- mallissa testaus on mukana kaikissa ohjelmistoprojektin vaiheissa aina suunnittelusta lähtien. Taulukko 1 Testauksen rooli eri vaihejakomalleissa VAIHEJAKOMALLI Big-Bang -malli TESTAUKSEN ROOLI MALLISSA Ei varsinaista testausta. Testaus ainoastaan virheiden raportointia asiakkaille. MALLIN KÄYTTÖ Malli sopii pienten projektien läpivientiin. Vesiputosmalli Spiraalimalli Testaukselle on varattu oma askeleensa ennen ylläpitoa, eli toiseksi viimeinen askel. Testaus helppo suunnitella, koska mallissa käytetään paljon aikaa ohjelmiston suunnitteluun. Testaus mukana mallin kaikissa vaiheissa. Kaikenlaiset projektit. Erityisesti projekteihin, joissa vaatimukset ovat hyvin selvillä. Kaikenlaiset projektit. Erittäin hyvä ja tehokas malli. Code-and-fix -malli V-Malli (Edelleen testausta silmälläpitäen vesiputousmallista kehitetty malli) Ei varsinaista testausta, mutta todellisuudessa testaus suoritetaan jokaisen koodaus-sarjan jälkeen ennen korjaustvaihetta. Testaus kulkee mukana kaikissa projektin kehitysvaiheissa. Malli sopii pienten projektien läpivientiin Soveltuu käytettäväksi sellaisissa projekteissa, joissa sovelluskehitys toteutettu vesiputousmallin tapaan.
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 32 (36) Mikä tahansa edellä esitellyistä vaihejakomalleista valitaankin, on ohjelmisto joka tapauksessa testattava jossain ohjelmistoprojektin vaiheessa. Kussakin mallissa testauksella on erilainen rooli, mutta yleisen tuntemuksen mukaan mitä aikaisemmassa vaiheessa testaus on mukana projektissa, sitä tehokkaampi ja laadukkaampi saadaan kehitettävästä ohjelmistosta. Kuitenkaan yhtä ja oikeaa ohjelmistoprojektin elinkaarimallia ei ole olemassa, vaan kulloiseenkin projektiin tulisi valita parhaiten kyseistä projektia tukeva vaihtoehto. Sen sijaan testauksen merkitys itse ohjelmistoprojektissa on kiistaton. Seuraavassa kappaleessa pohditaan edelleen miten testauksen ulkoistaminen vaikuttaa ohjelmistoprojektin läpiviennin tehokkuuteen. 4.2 Testauksen ulkoistamisen vaikutus koko ohjelmistoprojektiin Testauksen ulkoistaminen on nykypäivänä hyvin yleistä. Ainoastaan testaukseen keskittyneitä yrityksiä on markkinoilla suuri määrä. Ulkoistamisella varmistetaan testauksen laatu ja tehokkuus sekä pyritään säästämään kustannuksissa. Ulkoistetun testauksen suhde ohjelmistoprojektiin eroaa osaltaan sisäisesti toteutetusta testauksesta. Kun ohjelmistoprojektin testaus ulkoistetaan, syntyy projektiin useimmiten kolmas osapuoli, asiakkaan ja kehittäjän lisäksi. On tietenkin mahdollista, että yritys kehittää ohjelmistoja omiin tarpeisiinsa, jolloin ulkoistettu testaus tuottaa toisen osapuolen ohjelmistoprojektiin. Tämä luonnollisesti muuttaa ohjelmistoprojektin kulkua. Työskentelen itse pääasiassa matkapuhelinohjelmistojen testauspalveluja tuottavassa yrityksessä ja olen päivittäin tekemisissä niin omaan, kuin kolmannen osapuolen tarpeisiin ohjelmistoja kehittävien yritysten kanssa. Ulkoistettu testaus voidaan suorittaa monella tavalla. Testaus voi kulkea ohjelmistoprojektissa koko sen elinkaaren ajan mukana tai vain osa ohjelmiston toiminnoista testataan ulkopuolisella testausyrityksellä. Ulkoistettaessa testaus niin sanotusti kokonaan, ei testaus aiheuta itse ohjelmistoprojektiin suuria muutoksia, koska tes-
TAMPEREEN AMMATTIKORKEAKOULU TUTKINTOTYÖ 33 (36) tausryhmä on mukana kaikissa testausvaiheissa. Jos testaus taas tuotetaan vain osittain alihankkijalla, se voi vaikuttaa ohjelmistoprojektin kulkuun. Täysin ulkoistetussa testauksessa testaajat siis ovat osa kehitysryhmää. He toteuttavat testaussuunnitelmat ja testitapaukset, tuntevat kehitettävän ohjelmiston tarkat määrittelyt, ovat mukana projektin tapaamisissa, ovat jatkuvasti yhteydessä kehittäjiin ja raportoivat suoraan kehittäjille. Tällöin ohjelmistoprojekti etenee täysin samalla kaavalla kuin, jos testaus olisi toteutettu sisäisesti. Projekteissa, joissa testaus teetetään kokonaisuudessaan ulkopuolisilla, ei ohjelmiston tuottavalla yrityksellä ole yleensä lainkaan varsinaista testaushenkilöstöä. Työn ensimmäisessä teoriaosuudessa puhuttiin testauksen raportoinnista ja dokumentoinnista. Kun testaus ulkoistetaan vain osittain, on testaussuunnitelmat ja testitapaukset usein toteutettu kehittävän yrityksen testaustiimin toimesta ja testausprosessista toteutetaan ainoastaan itse testaus. Tällöin testaajat tietävät testattavasta sovelluksesta ainoastaan sen, mitä testispekseissä kerrotaan, eivätkä ole suoraan yhteydessä kehittäjiin. Tämä vaikuttaa etenkin testauksen raportointiin, koska se toteutetaan käytännössä kahteen kertaan. Ensiksi ulkoisen testausyrityksen testaajat raportoivat kehittäjäyrityksen testausvastaaville, jotka raportoivat sitten itse kehittäjille. Tämä voi aiheuttaa väärinymmärryksiä ja näin pitkittää ohjelmistoprojektin aikataulua virheellisten korjausten takia. Omassa työssäni olen useaan kertaan törmännyt tilanteeseen, jossa jonkin virheen takia on jouduttu raportoimaan useasta virheestä. Loppujen lopuksi on selvinnyt pitkän ajan kuluttua, että kyseessä onkin ollut vain testattavan tuotteen ominaisuus ja näin ollen testit ovat tulleet uudelleen ajoon virheellisten tulosten vuoksi. Tältä työltä olisi siis vältytty, mikäli yhteys kehittäjiin olisi ollut alun perin suora. Kuten aikaisemmin todettiin, testausprosessiin oleellisesti liittyy testauksen aikataulutus. Osittain ulkoistetun testauksen aikataulutus on usein haasteellista. Itse olen joutunut tilanteeseen, jossa testaus joudutaan suorittamaan kiireellä ja mahdollisesti pienemmällä henkilöstöllä, koska tieto testaussessiosta tulee viime hetkillä ja aikataulu on tiukka. Tällöin testauksen laatu voi kärsiä ja aiheuttaa näin ongelmia