Ohjelmistotestauksen perusteet. versio 1.0

Transkriptio

1 Ohjelmistotestauksen perusteet versio 1.0

2 Sisällysluettelo Sisällysluettelo... 2 Johdanto... 4 Luku 1 Mitä on ohjelmistotestaus?... 5 Testauksen määritelmä... 5 Testauksen psykologia ja tavoitteet... 5 Virheiden eliminointi ja aikainen testaus... 5 Testaus osana laadunvarmistusta... 6 Virheet, viat ja häiriöt... 7 Virheiden tunnistaminen ja luokittelu... 7 Virheiden vakavuus ja vaikutukset... 8 Virheenjäljitys... 9 Luku 2 Testaus ohjelmiston elinkaaressa V-malli ja testaustasot Moduulitestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus Ylläpito- ja uudelleentestaus Luku 3 Testausprosessi ja sen hallinta Testaustyön roolit ja tehtävänjako Testauksen suunnittelu Testausstrategia Testaussuunnitelma Testauksen kohdentaminen ja priorisointi Testitapausten suunnittelu Testauksen toteuttaminen

3 Vaihekohtainen testaus Testitulosten tarkastelu ja raportointi Testauksen riittävyyden arviointi ja testauksen päättäminen Testauksen kattavuus Virheiden analysointi Testauksen tehokkuuden arvioiminen Testauksen päättämistehtävät Yhteenveto testauksen työvaiheista ja tuotoksista Luku 4 Testaustekniikat Staattiset testaustekniikat Katselmukset Tarkastukset Dynaaminen testaus Valkolaatikkotestauksen menetelmät Mustalaatikkotestauksen menetelmät Kokemukseen perustuvat menetelmät Luku 5 Testauksen työkalut Testausprosessin hallintaan liittyvät työkalut Staattisen testauksen työkalut Dynaamisen testauksen työkalut Yksikkötestauksen työkalut Toiminnallisen testauksen työkalut Suorituskykytestauksen työkalut Tietoturvatestauksen työkalut Testiaineistogeneraattorit Lähteet Liite 1. Testaustermien suomi-englanti sanasto

4 Johdanto Tämän oppaan tarkoituksena on tutustuttaa lukija ohjelmistotestauksen käsitteisiin, näkökulmiin ja tekniikoihin sekä havainnollistaa mitä ohjelmistotestaus käytännössä on. Oppaan keskeinen ajatus on tarjota lukijalle käytännön perustiedot ja työkalut, joilla testauksen suunnittelua, toteutusta ja analysointia pääsee itsenäisesti harjoittelemaan. Opas on jaettu viiteen lukuun. Ensimmäisessä luvussa määritellään testauksen käsitteitä sekä esitetään näkökulmia miksi testausta tarvitaan. Toinen luku kuvaa V-mallin avulla testausprosessin vaiheet osana ohjelmiston elinkaarta. Kolmannessa luvussa käsitellään testauksen perusprosessia ja sen hallintaa. Neljännessä luvussa esitellään staattisen ja dynaamisen testauksen lähestymistapoja, menetelmiä ja tekniikoita. Viidennessä luvussa käsitellään testauksen työkalutukea sekä luetellaan vapaan lähdekoodin ohjelmistoja, joita voidaan hyödyntää testauksen eri työvaiheissa. Oppaan lopussa olevat liitteet sisältävät tärkeimpien testaustermien suomi-englanti sanaston sekä hyödyllisiä dokumenttipohjia testauksen suunnittelua ja raportointia varten. 4

5 Luku 1 Mitä on ohjelmistotestaus? Testauksen määritelmä Glenford J. Myers esittää vuonna 1979 ilmestyneessä alkuperäisteoksessaan The Art of Software Testing käsitteen ohjelmistotestaus, johon yhä edelleen viitataan testaustyön keskeisimmän tehtävän ja tavoitteen määritelmänä: Testing is the process of executing a program with the intent of finding errors (Myers 1979, 5). Samaan tapaan muotoilee myös Haikala & Märijärvi (2002, 282), joiden mukaan ohjelmistotestaus on systemaattista, ohjelmaa suorittamalla tapahtuvaa virheiden etsintää ohjelmasta tai sen osasta. Testaaminen ei siis ole mitä tahansa kokeilua niin kuin arkikielessä usein testaamisella tarkoitetaan vaan tarkoituksena on toteuttaa systemaattinen ja suunnitelmallinen prosessi. Testauksella on ohjelmistokehityksessä erityinen tehtävä, jossa pyrkimyksenä on löytää ohjelmassa olevia vikoja ja puutteita. Määritelmän mukainen testaus perustuu ohjelmakoodin suorittamiseen, josta käytetään myös termiä dynaaminen testaus. Dynaamisen testauksen lisäksi virheiden ja ongelmakohtien etsintää tehdään myös staattisilla testausmenetelmillä, jotka perustuvat ohjelmakoodin analysointiin ja tarkastamiseen ilman, että ohjelmaa varsinaisesti käytetään. Testauksen psykologia ja tavoitteet Testaus nähdään usein toimenpiteenä, jonka tavoitteena on osoittaa, että ohjelma toimii oikein. Myers (1979, 5) tuo vahvasti esiin testauksen psykologisen näkökulman. Ihmisen toimintaan vaikuttaa olennaisesti se, kuinka tavoitteet asetetaan. Jos testauksen tavoitteena on vahvistaa, että ohjelma toteuttaa sille määritellyt tehtävät oikein, testaaja alkaa alitajuisesti toteuttaa testausta tavoitteensa mukaisesti. Tämä voi johtaa tilanteeseen, jossa testaaja välttää testitapauksia, jotka tuovat esiin virheitä. Seurauksena on, että testauksen lisäarvo jää saavuttamatta. Testauksen onnistumisen edellytyksenä on oikea asenne ja näkökulma testauksen tavoitteisiin. Kun tavoitteena on löytää ohjelmassa olevia virheitä, testit todennäköisemmin myös löytävät niitä. Kaner & al. (1999, 25) kiteyttää testauksen ydinajatuksen toteamalla, että onnistunut testi paljastaa ongelman, kun taas testi, joka ei tuo esiin virheitä on hukkaan heitettyä aikaa. Virheiden eliminointi ja aikainen testaus Ohjelmat sisältävät virheitä. Jo pitkään käytössä olleissa ohjelmissakin arvioidaan olevan noin yksi virhe tuhatta ohjelmariviä kohden (Haikala & Märijärvi 2002, 285). Tietoa tuotetaan, muunnetaan ja 5

6 siirretään kehitysprosessin vaiheiden läpi eri toimijoiden käyttöön, mikä on otollista maaperää virheiden syntymiselle. Suurin osa (jopa %) ohjelmavioista saa alkunsa jo ohjelmistokehityksen määrittely- ja suunnitteluvaiheessa (Kit 1995, 19). Mitä pitemmälle kehitystyö etenee sitä jyrkemmin virheiden etsinnästä ja erityisesti niiden korjauksesta aiheutuvat kustannukset kasvavat. Kaikkein kalleimmaksi tulevat virheet, jotka tulevat ilmi ohjelman julkaisun ja käyttöönoton jälkeen, jolloin kalliiden korjauskustannusten lisäksi voi aiheutua ikävää haittaa myös yrityksen imagolle. Ohjelman täydellinen testaaminen ei ole mahdollista, eikä ohjelman virheettömyyttä pystytä testauksella osoittamaan. Aivan yksinkertaisia tapauksia lukuun ottamatta ohjelman kaikkien mahdollisten ohjelmapolkujen ja syötekombinaatioiden määrä on niin suuri, että niiden läpikäyminen testaamalla on mahdoton tehtävä (Kaner & al. 1999, 17). Testauksen ensisijaisena pyrkimyksenä onkin löytää mahdollisimman paljon virheitä mahdollisimman varhaisessa vaiheessa, jotta niiden korjaamisesta aiheutuva lisätyö voidaan minimoida. Virheiden aikainen havaitseminen estää niiden siirtymisen ja ennaltaehkäisee uusien virheiden syntymistä. Testauksen hyöty saavutetaan, kun löytyneet virheet korjataan ja sen myötä ohjelman luotettavuus ja laatu paranee. Testaus osana laadunvarmistusta Ohjelma tai järjestelmä joutuu testattavaksi aina kun sitä käytetään. Ohjelmistotestausta tarvitaan, jotta tiedetään mitä käyttäjälle ollaan tarjoamassa ja kuinka hyvin ohjelman todellinen toiminta vastaa sitä mitä alun perin on lähdetty tekemään. Laatu on käsite, jolla kuvataan tuotteen ja tuotantoprosessin ominaisuuksia ja onnistumista suhteessa asetettuihin tavoitteisiin. Korkealaatuinen ohjelmistotuote täyttää sille asetetut tekniset vaatimukset ja vastaa käyttäjän odotuksia ja tarpeita. Laadukkaan tuotantoprosessin tuloksena lopputuote valmistuu asetetun aikataulun ja budjetin mukaisesti. Prosessin vaiheiden ja vaihetuotteiden seurannalla, arvioinnilla ja mittaamisella pyritään varmistamaan, että asetetut tavoitteet saavutetaan käytettävissä olevien resurssien puitteissa. Termejä verifiointi ja validointi (suom. todentaminen ja kelpoistaminen; engl. verfication & validation) käytetään laadunvarmistuksen yhteydessä kuvaamaan menettelytapoja tuotteen ja tuotantoprosessin laadun arvioinnissa (Haikala & Märijärvi, 2002, 49). Verifioinnilla tarkoitetaan toimenpiteitä, joilla pyritään todentamaan, että tuote on tehty suunnitelmien mukaan ja toteuttaa sille määritellyt toiminnot oikein ( are we building the product right ). Validoinnilla puolestaan pyritään varmistamaan, että toteutettu ohjelmisto täyttää sille määritellyt vaatimukset ( are we building the right product ). Ohjelmistotuotannon näkökulmasta testaus on keskeinen osa ohjelmistoprojektin laadunvarmistusta, jonka avulla ohjelmiston ja tuotantoprosessin laatu saadaan näkyväksi. Testaus lisää luottamusta, että toteutettu tuote vastaa asetettuja tavoitteita ja vaatimuksia. Hyvin toteutettu testaus 6

7 auttaa hallitsemaan ohjelmistonkehitykseen liittyviä riskejä. Testausprosessista saatua tietoa voidaan käyttää apuna päätöksenteossa sekä hyödyntää tulevissa projekteissa ja testausprosessin kehittämisessä. Laadunhallinnan kannalta on kuitenkin tärkeää huomioida, että ohjelmiston laatu on kehitystyön tulos ja laatua rakennetaan koko ohjelmistokehityksen ajan. Testaus ei paranna laatua eikä testauksella voida korjata huonosti suunnitellun tai huonosti tehdyn työn tulosta. Testaus todentaa ja vahvistaa olemassa olevan laadun. Mikäli ohjelmiston laatu on huono testauksen alussa, laatu on huono myös testauksen lopussa (Pressmann 2005, 356). Virheet, viat ja häiriöt Standardi IEEE (IEEE Standard Glossary of Software Engineering Terminology) esittää termeille virhe, vika ja häiriö seuraavanlaiset määritelmät: Mistake, error (virhe, erehdys) tarkoittaa virhettä, joka on seuraus ihmisen virheellisestä toiminnasta tai erehdyksestä. Inhimillinen virhe voi olla ohjelmointivirhe, virhe dokumentaatiossa tai dokumentaation tulkinnassa. Fault, bug, error (virhe, vika) on ohjelmavirhe, joka on seuraus inhimillisestä virheestä. Ohjelmavika voi johtaa ohjelman toimintahäiriöön. Failure (häiriö) on ohjelmavirheen seurauksesta aiheutuva toimintahäiriö, joka näkyy virheellisenä tuloksena ohjelman suorituksessa. Määritelmien mukaisesti ohjelmassa tai ohjelman dokumentaatiossa olevat virheet ovat seuraus ihmisen virheellisestä toiminnasta tai erehdyksestä. Virheellisen kohdan suorittaminen voi aiheuttaa ohjelmavian, jonka seurauksena ohjelma ei toimi niin kuin pitäisi. Kaikki virheet eivät välttämättä johda ohjelman virheelliseen toimintaan. Virheen vaikutukset eivät aina myöskään tule käyttäjälle näkyviin, sillä vika voi peittyä tai kumoutua jonkin toiminnon tai toisen virheen seurauksena (Haikala & Märijärvi 2002, 285). Toisaalta on myös tilanteita, joissa ohjelman toimintahäiriön syynä on jokin ulkoinen tekijä esimerkiksi häiriö tietoliikenneverkossa, laitteiston vioittuminen, sähkökatkos tai järjestelmään päässyt haittaohjelma. Ohjelmavirheiden etsinnän lisäksi testauksella selvitetään myös järjestelmän toimintakykyä ja reagointia normaalista poikkeavissa tilanteissa. Virheiden tunnistaminen ja luokittelu Testauksen yhteydessä ohjelmavirhe todetaan poikkeamana spesifikaatiosta (Haikala & Märijärvi 2002, 285). Jotta tiedetään mitä etsitään, tyypillisten ja yleisesti esiintyvien virheiden tunnistamiseksi on laadittu luokitteluja ja ns. tarkistuslistoja (checklists). Jo olemassa olevien luokittelujen lisäksi uusia virheiden tarkistuslistoja muodostetaan aina tarpeen mukaan kutakin ohjelmistoa ja sen testausta varten. Tarkistuslistaa voidaan hyödyntää sekä testien suunnittelussa 7

8 että testausta suoritettaessa esim. kooditarkastusten yhteydessä. Proseduuriin kuuluu, että tarkistuslistaa täydennetään iteratiivisesti testausprosessin aikana. Esimerkiksi Beizer (1990, ) on laatinut kattavan taksonomian, jossa virheet on jaettu niiden alkuperän mukaan kahdeksaan pääkategoriaan: 1. Vaatimusten määrittelyyn liittyvät virheet 2. Vaatimusten toteutukseen liittyvät virheet 3. Ohjelmakoodin rakenteelliset virheet 4. Tietorakenteiden ja tiedon määrittelyyn, toteutukseen ja käyttöön liittyvät virheet 5. Toteutukseen ja ohjelmointiin liittyvät virheet 6. Integraatioon liittyvät virheet 7. Järjestelmä- ja ohjelmistoarkkitehtuuriin liittyvät virheet 8. Testauksen määrittelyyn ja suorittamiseen liittyvät virheet Virheiden luokittelun lisäksi Beizerin taksonomiassa on esitelty kuhunkin luokkaan kuuluvia virheitä ja esitetty niistä havainnollisia esimerkkejä. Vastaavia virheiden luokitteluja ja tarkistuslistoja löytyy runsaasti internetistä esim. hakusanoilla code checklists, code review checklists ja inspection checklists ja niitä ovat laatineet myös mm. Myers (1979, 25-36) ja Kit (1995, ). Virheiden vakavuus ja vaikutukset Ohjelmavirheen vakavuus riippuu virheen esiintyvyydestä, korjauskustannuksista ja virheen aiheuttamista seuraamuksista (Beizer 1990, 27). Pienten ja vähäisten virheiden vaikutukset ovat paikallisia ja ne ovat myös helppoja korjata esim. kirjoitusvirhe, huono asemointi, tarpeeton tai harhaanjohtava tuloste jne. Vakavien virheiden seuraukset eivät rajoitu yksittäisiin ja paikallisiin tapauksiin. Ongelmat ovat usein kumuloituvia, jolloin sekä vaikutukset että kustannukset kertautuvat, leviävät ja kasvavat. Pahimmassa tapauksessa kriittisen järjestelmän ongelma voi aiheuttaa vakavan uhan ihmisten ja ympäristön turvallisuudelle. Alla olevassa taulukossa on Beizerin (1990, 28-29) luokittelu virheen vakavuusasteesta 1-10 ja esimerkkejä seuraamuksista, joita eri vakavuusasteen virheet voivat aiheuttaa. Aste Vakavuus Seuraus/oire 1 Vähäinen Kirjoitusvirhe tai huono asettelu tulosteessa Kosmeettinen haitta 2 Kohtalainen Harhaanjohtava tai tarpeeton tuloste Suorituskyvyn aleneminen 8

9 3 Ärsyttävä Hankalat komennot, vaikeasti ymmärrettävät tai turhat toiminnot ja tulosteet Esim. järjestelmä lähettää 0.00 Euron laskun 4 Häiritsevä Sallittua transaktiota ei suoriteta Esim. automaatti ei anna rahaa 5 Vakava Transaktio ei kirjaudu eikä siitä jää merkintää Esim. tilin laskenta menee sekaisin 6 Hyvin vakava Järjestelmä suorittaa väärän transaktion Esim. talletus muuntuu nostoksi 7 Erittäin vakava Ongelmat eivät rajoitu yksittäisiin ja poikkeaviin tapahtumiin vaan ovat toistuvia normaaliolosuhteissa esiintyviä häiriöitä 8 Sietämätön Vääristynyttä dataa pitkältä ajanjaksolta, jota on vaikea havaita ja palauttaa 9 Katastrofaalinen Järjestelmä katuu 10 Infektoiva Vika siirtyy ja tuhoaa muita järjestelmiä Aiheuttaa peruuttamatonta ja jopa henkeä uhkaavaa vahinkoa ympäristölle ja ihmisille Virheenjäljitys Testauksella havaittu vika paljastaa ongelman mutta ei useinkaan vian alkuperäistä syytä tai tarkkaa sijaintia. Testaajan tehtäviin kuuluu havaitun vian tai ongelman dokumentointi, jonka jälkeen vastuu ongelmakohdan paikantamisesta ja korjaamisesta siirtyy ohjelman kehittäjille. Virheenjäljitys (debugging) on kehitystyöhön liittyvä toimenpide, jonka tarkoituksena on jäljittää, analysoida ja poistaa testauksella havaitut virheet. Virheiden paikantamista helpottaa merkittävästi mitä aikaisemmin virhe havaitaan. Kun virhekohta löydetään, se korjataan ja ohjelma palautetaan takaisin testaajien testattavaksi. Mikäli virheenjäljityksellä ei suoraan löydetä virhekohtaa, voidaan sen avulla kuitenkin tehdä päätelmiä virheen todennäköisistä syistä ja mahdollisesta alkuperästä. Tiedon perustella testaajat voivat kohdentaa lisätestausta epäiltyihin virhekohtiin. (Pressman 2005, ). 9

10 Virheenjäljitystä tehdään ohjelmoinnin yhteydessä ohjelmoijan toimesta ja siihen tarkoitettu työkalu sisältyy usein kehitysympäristöön (voidaan myös käyttää erillistä ohjelmaa). Virheenjäljittäjän (debugger) perusominaisuuksiin kuuluu, että ohjelman kulkua ja muuttujia voidaan seurata vaiheittain esim. rivi tai funktiokutsu kerrallaan ja ohjelmaan voidaan tehdä hallitusti muutoksia. Esimerkiksi ohjelmoijan tyypillinen manuaalinen debuggaus -tapa, jossa ohjelman etenemistä seurataan ylimääräisillä tulostuksilla ohjelmakoodin seassa sisältää turhan riskin ylimääräisille virheille. Virheenjäljittäjä soveltuu erityisesti loogisten ohjelmavirheiden paikantamiseen. Useimpiin virheenjäljittäjiin sisältyy myös hyödyllisiä kooditarkastustoimintoja kuten syntaksivirheiden etsintä, automaattinen kooditäydennys ja koodimuotoilun asetustoiminto. Luku 2 Testaus ohjelmiston elinkaaressa Ohjelmiston elinkaari on aika, joka kuluu ohjelmiston kehittämisen aloittamisesta sen poistamiseen käytöstä (Haikala & Märijärvi 2002, 36). Ohjelmiston elinkaari ja siihen sisältyvän työn jakaminen vaiheisiin muodostaa ohjelmistokehityksen prosessimallin, jonka tunnetuin muoto ns. vesiputousmalli on esitetty kuvassa 1. Kuva 1. Vesiputousmalli (Haikala & Märijärvi 2002, 36). Vesiputousmallissa elinkaaren vaiheet esitetään peräkkäisinä askelmina mutta käytännössä ohjelmistokehitys ei koskaan etene suoraviivaisesti vaihe vaiheelta alusta loppuun vaan usein seuraava vaihe aloitetaan ennen kuin edellinen vaihe on saatu päätökseen ja kertaalleen suoritettuihin vaiheisiin joudutaan palaamaan uudelleen prosessin aikana. Vesiputousmalli antaa kuitenkin perusmallin kehitystyön vaiheistamiseen ja sen pohjalta on kehitetty useita prosessimallityyppejä (protoilumalli, evo-malli, spiraalimalli, RUP, ketterät menetelmät jne.), joita voidaan soveltaa käytäntöön kunkin ohjelmistoprojektin erityispiirteiden mukaan. 10

11 Riippumatta siitä, mitä ohjelmiston kehitysmallia käytetään, testaus on keskeinen osa ohjelmiston elinkaarta. Seuraavassa kappaleessa esitetään testauksen V-malli, joka on yksi tapa kuvata testausprosessi ja siihen sisältyvät vaiheet ohjelmiston elinkaaressa. V-malli ja testaustasot V-malli on testauksen prosessimalli, joka jakaa testaustyön osavaiheisiin eli testaustasoihin. Testaustyön vaiheistaminen mahdollistaa tehokkaamman ja tarkemman testauksen, sillä eri testaustasoilla testausta voidaan kohdentaa erityyppisten ja eri kehitysvaiheille ominaisten virheiden etsintään. Kuvassa 2 on esitetty nelitasoinen V-malli, jonka testaustasot ovat moduulitestaus, integrointitestaus, järjestelmätestaus ja hyväksymistestaus. Käytännössä testaustasojen määrä vaihtelee riippuen ohjelman elinkaarimallista ja ohjelmistoprojektin koosta ja luonteesta. Kuva 2. Testauksen V-malli. V-mallin mukaisesti testauksen suunnittelua tehdään vastaavalla tasolla ohjelmiston suunnittelun kanssa. Suunnittelu aloitetaan mahdollisimman varhaisessa vaiheessa ja suunnittelua täydennetään ohjelmistoprosessin edetessä. Testauksen suunnittelu ja testaustulosten todentaminen perustuvat ohjelmistolle asetettuihin tavoitteisiin ja vaatimuksiin, jotka on määritelty ohjelmiston määrittely- ja suunnitteludokumentaatiossa. Testauksen suorittaminen aloitetaan ohjelmointivaiheessa moduulitason testauksella. Moduulien suunnittelu, ohjelmointi, testaus ja integrointi määritellään usein ohjelman toteutusvaiheeksi, jonka aikaisesta testauksesta käytetään myös nimitystä alemman tason testaus. Alemman tason testausta tekevät tavallisesti ohjelman kehittäjät ja testauksen tavoitteena on ohjelmointi- ja suunnitteluvirheiden eliminointi. Ylemmän tason testauksella tarkoitetaan ohjelman toteutusvaiheen jälkeen tapahtuvaa erillistä testausvaihetta, jonka suorittavat testaukseen erikoistuneet ammattilaiset. Ylemmän tason testaukseen kuuluvat V-mallin järjestelmä- ja hyväksymistestaus. Järjestelmätestauksen tavoitteena on löytää ristiriidat ja virheet ohjelman todellisen toiminnan ja sille määriteltyjen 11

12 ohjelmistovaatimusten välillä. Hyväksymistestaus on testausprosessin viimeinen vaihe, jossa varmistetaan, että toteutettu järjestelmä vastaa tarkoitustaan eli niitä tavoitteita ja tarpeita, joita varten järjestelmää on alun perin lähdetty tekemään. Moduulitestaus Moduuli- eli yksikkötestauksessa (module testing, unit testing) tarkastelun kohteena on ohjelman pienin itsenäinen yksikkö eli moduuli/komponentti. Moduulin testaaja on yleensä moduulin tekijä eli ohjelmoija ja tyypillisesti moduuli testataan välittömästi ohjelmoinnin jälkeen kehitysympäristöön sisältyvillä yksikkötestauksen työkaluilla. Ohjelmarakenteen testaaminen moduuli kerrallaan parantaa testauksen hallittavuutta ja tehokkuutta. Ohjelman eri osia voidaan testata samanaikaisesti, usean eri henkilön toimesta ja toisistaan riippumatta. Lisäksi virheen paikallistaminen tiettyyn moduuliin mahdollistaa ongelmakohdan eristämisen ja nopeuttaa virheen korjausta. (Myers 1979, 77). Moduulin toteutusperiaatteesta johtuen moduulin toimintaa testataan kahdesta näkökulmasta: 1) moduulin ulkoista toimintaa analysoimalla, missä selvitetään toteuttaako moduuli spesifikaation mukaiset toiminnot ja 2) etsimällä virheitä ohjelmakoodin sisäisestä rakenteesta ja loogisesta toteutuksesta. Tyypillisiä testauksen kohteita ovat moduulin rajapintafunktiot, paikalliset tietorakenteet ja tiedon käyttö, loogiset ohjelmapolut, ohjausrakenteet, silmukat, virheidenkäsittely ja arvoalueiden rajakohdat (Pressman 2005, 363). Ohjelmakoodin rakenteen ja loogisen toiminnan analysointiin käytetään ns. valkolaatikkotestauksen menetelmiä (ks. sivu 35, Valkolaatikkotestauksen menetelmät). Tavoitteena on kehittää joukko testitapauksia, jotka testaavat ohjelmakoodin mahdollisimman kattavasti. Testitapausten suunnitteluun käytetään sekä ohjelman lähdekoodia että ohjelman toiminnan määrittelevää spesifikaatiota. Valkolaatikkotestauksella saavutettua kattavuutta täydennetään moduulin toiminnallisella testauksella, jossa tapauskohtaisesti sovelletaan erilaisia mustalaatikkotestauksen menetelmiä (ks. sivu 38, Mustalaatikkotestauksen menetelmät). Ohjelmamoduulien testaaminen voidaan aloittaa vaikka koko ohjelma ei olekaan valmis. Tällöin testauksen suorittamiseksi tehdään ns. testipetejä (test bed). Testipeti sisältää testiajureita (test driver), jotka simuloivat ohjelman ympäristöä (esim. testattavan moduulin funktioiden tai metodien kutsuminen) ja tynkiä (stub), jotka korvaavat puuttuvia ohjelmakomponentteja, joita testattava moduuli tarvitsee suorituksen aikana. (Haikala & Märijärvi 2002, 287). Integrointitestaus Moduulitestausta seuraava taso on integraatiotestaus (integration testing), jossa arkkitehtuurisuunnitelman mukainen ohjelmarakenne kootaan ja samalla etsitään virheitä liitettyjen komponenttien rajapinnoista. Testitapausten kehittäminen perustuu ohjelman arkkitehtuurin kuvaukseen ja mo- 12

13 duulien rajapintamäärittelyihin. Vaiheittaisessa integraatiossa uusi, yksikkötestattu komponentti lisätään aina jo aiemmin testattuun rakenteeseen. Vastakohtana vaiheittain etenevälle integraatiolle on ns. kertarysäys (big-bang), jossa testatut komponentit liitetään kerralla yhteen. Vaiheittaisessa menetelmässä uuden integraation testaaminen aiheuttaa aina myös kaikkien aiemmin integroitujen osien uudelleen testaamisen, jolloin testausta tehdään määrällisesti enemmän sekä monipuolisemmin kuin kertarysäysmenetelmässä (Myers 1979, 91). Luonnollisesti myös virheiden etsintää, jäljitystä ja korjausta on huomattavasti helpompi tehdä, kun integrointi toteutetaan komponentti kerrallaan. Kertarysäysmenetelmää voidaan hyödyntää esim. tilanteessa, jossa halutaan arvioida järjestelmän valmiutta integraatiotestaukseen tai tilanteessa, jossa järjestelmään tehty muutos on pieni ja paikallinen (Kasurinen 2013, 55). Vaiheittainen integraatio toteutetaan tavallisesti joko alhaalta ylöspäin tai ylhäältä alaspäin. Kokoava integrointi (bottom-up) aloitetaan komponenttihierarkiassa alimpana olevista, riippumattomista komponenteista. Riippumaton komponentti on päätekomponentti, josta ei kutsuta muita moduuleja. Komponentin integraatioon riittää ylemmän tason toimintaa simuloivan testiajurin kehittäminen. Integraatiojärjestyksestä johtuen kokoavassa integroinnissa ei tarvita testitynkiä. Komponenttien lisäysjärjestys voidaan muutoin valita vapaasti, kunhan alemman tason moduuli on testattu ennen sitä kutsuvaa ylemmän tason moduulia. Alhaalta ylöspäin etenevässä integraatiossa toimiva ohjelma on valmis vasta, kun viimeisinkin komponentti on lisätty ohjelmaan. Kuva 3. Kokoava integrointi (Bottom-up) 13

14 Päinvastainen vaiheittaisen integraation lähestymistapa on osittava integrointi (top-down), jossa integroimissuunta on ylhäältä alaspäin ja lähtöpisteenä on ylin tai keskeisin komponentti esim. pääohjelma. Testattavaa komponenttia varten toteutetaan tarvittavista alemman tason komponenteista testityngät. Testitynkien kehittäminen aloitetaan jo moduulivaiheessa ja usein moduulitestaus ja integrointitestaus etenevät rinnakkain. Testauksen edetessä testityngät korvautuvat valmiilla, testatuilla komponenteilla kunnes ohjelman integraatio on valmis. Ylhäältä alaspäin etenevässä integraatiossa on useita vaihtoehtoisia etenemispolkuja ja ohjelmasta voidaan jo aikaisessa vaiheessa rakentaa toimiva ns. luurankoversio. Menetelmän haasteena on toteuttaa yksinkertaisia testitynkiä, jotka simuloivat lopullisia toteutuksia oikein. Yhdestä testityngästä voidaan joutua tekemään useita eri versioita, jotta kaikki testitapaukset saadaan testatuksi. Työläs menetelmä houkuttelee myös jättämään osan testitapauksista odottamaan alempien komponenttien valmistumista, jolloin riskinä on niiden unohtuminen ja testauksen jääminen vaillinaiseksi. Testityngät ovat aina myös mahdollisia virheiden lähteitä, joten ohjelmakomponenttien lisäksi myös sijaiskomponentit tulee testata ennen käyttöönottoa. Kuva 4. Osittava integrointi (Top-down) Integraation toteutustapa valitaan aina tapauskohtaisesti. Hyvä lähestymistapa on integroida ohjelman kriittiset ja virhealttiit osat mahdollisimman aikaisessa vaiheessa. Tällaisia ovat esim. uudet algoritmit, monimutkaiset moduulit ja syöte- ja tulostustoimintoja sisältävät moduulit. Jos ohjelman kriittiset osat ovat enemmän painottuneet komponenttihierarkian alemmille tasoille, on järkevää aloittaa integroiminen alhaalta ylöspäin. Alhaalta ylöspäin edetessä testitapausten toteuttaminen 14

15 on usein myös yksinkertaisempaa ja helpompaa. Ylhäältä alaspäin integroitaessa etuna on, että ohjelman lopullista toimintaa voidaan demonstroida jo varhaisessa vaiheessa ja hyödyntää esim. käytettävyyden testaamisessa. (Myers 1979, ). Edellä kuvattu itsenäisten ohjelmakomponenttien integraatio kuuluu alemman tason testaukseen. Vaiheittaista integraatiota käytetään myös järjestelmätason integroinnissa esimerkiksi, kun itsenäisiä ohjelmia liitetään yhteen, alijärjestelmistä kootaan yhdessä toimiva ylemmän tason järjestelmä tai paikallisista järjestelmistä muodostetaan verkon yli kommunikoivia hajautettuja järjestelmiä. Top-down ja bottom-up eivät myöskään ole ainoita integraation toteutustapoja. Esimerkiksi voileipä- eli sandwich-integraatio on kokoavan ja jäsentävän tavan yhdistelmä, jossa integrointia lähdetään toteuttamaan yhtä aikaa molemmista päistä. Menetelmä tehostaa integraatiota mutta sen hallinta on huomattavasti haasteellisempaa. Järjestelmätestaus Järjestelmätestaus (system testing) suoritetaan testiympäristössä ohjelmistolle, jossa ei ole enää sijaiskomponentteja. Testauksessa järjestelmää tarkastellaan kokonaisuutena ja tapauskohtaisesti sovelletaan erilaisia korkean tason testausmenetelmiä. Objektiivisuuden säilyttämiseksi järjestelmätestauksen toteuttajina ovat kehitystiimin ulkopuoliset testaajat, jotka voivat olla kehittäjäyrityksen työntekijöitä tai ulkopuolisia, testaukseen erikoistuneita ammattilaisia. Järjestelmätestauksen tavoitteena on selvittää täyttääkö järjestelmä sille asetetut tavoitteet ja esiintyykö järjestelmän/ohjelman ja sen määrittelyn välillä ristiriitoja. Ohjelmalle asetettujen toiminnallisten tavoitteiden lisäksi järjestelmätestauksessa tarkastellaan ei-toiminnallisia vaatimuksia kuten suorituskykyä, käytettävyyttä, tietoturvaa ja luotettavuutta. Testaustyypistä riippuen järjestelmän laadullisia ominaisuuksia tarkastellaan ns. normaaliolosuhteissa ja normaalista poikkeavissa kuormitustilanteissa. Järjestelmätason testausta tehdään erityisesti ohjelmistotuotteille, jotka toteutetaan sopimusperusteisesti tai laajan asiakaskunnan käyttöön. Pienten ohjelmien kuten kokeellisten tai ohjelmoijan omaan käyttöön tarkoitettujen ohjelmien testauksessa riittää usein ohjelman toiminnallisuuden testaaminen (Myers 1979, 106). Toiminnallinen testaus Ohjelman toiminnallisen testauksen (functional testing, function testing) tarkoituksena on löytää ristiriitaisuudet ohjelman ulkoisen toiminnan ja toiminnallisen määrittelyn välillä. Toiminnallinen määrittely on spesifikaatio, jossa jokainen ohjelman toiminto on kuvattu yksityiskohtaisesti käyttäjän näkökulmasta. Myös toimintojen testaus suoritetaan järjestelmän ulkoista eli käyttäjälle näkyvää käyttäytymistä analysoimalla. Testitapausten suunnittelussa hyödynnetään pääasiallisesti mustalaatikkotestauksen menetelmiä. Esimerkiksi ekvivalenssiositus, raja-arvoanalyysi, syyseuraus-mallinnus ja virheenarvaus ovat tyypillisiä toiminnalliseen testaukseen sovellettuja tekniikoita (Myers 1979, 108). Toiminnallinen testaus voidaan aloittaa heti, kun toimintoja on valmiina 15

16 suoritettavaksi tai sitten, kun yksikkö- ja integraatiotestaus on saatu päätökseen. Toiminnallinen testaus sijoitetaankin usein omaksi vaiheeksi ennen varsinaista järjestelmätestausta (Myers ym. 2012, 117; Kit 1995, 98-99). Käytettävyystestaus Käytettävyydeltään hyvä ohjelma on tehty käyttäjän tarpeisiin, mikä tarkoittaa, että ohjelma sovitetaan käyttäjän toimintatapoihin eikä päinvastoin (Kit 1995, 96). Käytettävyystestauksessa (usability testing) pyritään löytämään järjestelmän toiminnot ja käyttötilanteet, jotka ovat hankalia tai vaikeaselkoisia käyttäjille. Käytettävyyden vaatimukset toteutetaan käyttöliittymässä. Käytännössä käytettävyystestaus painottuukin juuri käyttöliittymän toimivuuden ja tarkoituksenmukaisuuden analysointiin (Kasurinen 2013, 70). Käytettävyyden testausta voidaan suorittaa kaikissa ohjelmistokehityksen vaiheissa ja erilaisia menetelmiä sovelletaan ohjelmiston valmiusasteen mukaisesti. Tavallinen tapa on järjestää koetilanne, jossa käyttäjä kertoo ääneen ajattelemalla, mihin hänen toimintansa käyttötilanteessa perustuu. Tarkempaa analysointia varten koetilanne myös taltioidaan. Ongelmia paljastavasta käytettävyystauksesta on sitä enemmän hyötyä, mitä aikaisemmin sen tuloksia saadaan. Esimerkiksi ns. pikatestit käyttöliittymän näköiskuvilla ilman toiminnallisuutta mahdollistavat käytettävyystestauksen jo käyttöliittymän suunnitteluvaiheessa. Luotettavuustestaus Luotettavuustestaus (reliability testing) perustuu ohjelmassa esiintyvien vikojen ja häiriöiden mittaamiseen ja tilastolliseen analyysiin. Järjestelmän luotettavuustason arvioinnissa kiinnitetään huomiota mm. häiriöiden esiintymistiheyteen ja vakavuuteen. Lisäksi voidaan kerätä tietoa vikojen korjaamiseen käytetystä ajasta. Testausprosessin aikana kerättyjen tietojen perusteella voidaan todentaa milloin ohjelmiston luotettavuus (ohjelman häiriötön toiminta tietyssä ympäristössä tietyn ajanjakson aikana) vastaa vaatimusmäärittelyssä asetettuja tavoitteita. Luotettavuudelle määriteltyä tavoitetasoa voidaan käyttää myös testauksen lopetuskriteereinä esim. tuotantoon julkaisua varten. (Kit 1995, 159). Tietoturvatestaus Tietoturvatestauksella (security testing) selvitetään järjestelmään toteutettujen tietoturvatoimintojen (palomuuri, tiedon salaus ja käyttöoikeudet) kykyä torjua väärinkäytöksiä ja uhkia, jotka tulevat järjestelmän ulkopuolelta (virukset, haittaohjelmat tai asiattomat käyttäjät). Tietoturvatestauksella pyritään löytämään järjestelmässä olevia heikkoja kohtia ja haavoittuvuuksia, jotka aiheuttavat tietoturva-aukkoja järjestelmään. Testeillä voidaan simuloida hyökkäyksiä, jotka kohdistuvat havaittuihin tai mahdollisiin tietoturva-aukkoihin. Tietoturvaan liittyviä ongelmia voi syntyä missä ohjelmistonkehitysvaiheessa tahansa, joten myös tietoturvatestausta tulisi tehdä kaikilla testauksen tasoilla. 16

17 Tietoturvan ylläpito ja testaus ovat keskeisiä toimintoja myös ohjelmiston käyttöönoton jälkeen. (Pressman 2005, 377). Toipuvuustestaus Toipuvuustestaus (recovery testing) on järjestelmätestauksen muoto, jossa testataan järjestelmän kykyä toipua erilaisista häiriötilanteista. Toipuvuustestaus voi liittyä myös tietoturvatestaukseen, jossa järjestelmä kaatuu ulkopuolisen hyökkäyksen seurauksena. Toipuvuustestaukseen sisältyy häiriötilannetestausta, jossa arvioidaan järjestelmän toimintakykyä poikkeustilanteissa sekä toipumismenettelyjen testausta, jossa arvioidaan järjestelmän kykyä palautua häiriötilanteesta ns. normaalitilaan. (Pressman 2005, 377). Suorituskykytestaus Monilla sovelluksilla on erityisiä suorituskykyyn ja tehokkuuteen liittyviä vaatimuksia kuten vastausaika, välityskyky, saatavuus ja resurssien käyttöaste (muisti, CPU), joilla mitataan järjestelmän kykyä suoriutua sille määritellyistä tehtävistä. Suorituskykytestauksen (performance testing) tavoitteena on testata vastaako järjestelmän toiminta asetettuja suorituskykyvaatimuksia ja löytyykö järjestelmästä ns. pullonkauloja, jotka heikentävät järjestelmän toimintaa kokonaisuutena. Suorituskykytestausta voidaan tehdä kaikilla testaustasoilla (yksittäisille komponenteille, integraation yhteydessä ja järjestelmätasolla) riippuen toteutettavasta ohjelmasta/järjestelmästä ja sille asetetuista suorituskykyvaatimuksista. Suorituskykytestausta varten määritellään kuormitustaso ja laite- ja ohjelmistokonfiguraatio, joilla testausta suoritetaan sekä suorituskyvyn tavoitetaso, johon tuloksia verrataan. Suorituskykytestaukseen on olemassa erityisiä ohjelmallisia työkaluja, joilla voidaan simuloida käyttötilanteita ja mitata haluttuja ominaisuuksia dynaamisesti ohjelman suorituksen aikana (ks. Luku 5 Testauksen työkalut). Järjestelmän suorituskykyä voidaan arvioida myös käyttäjän subjektiivisen kokemuksen perusteella eli kuinka järjestelmä käyttäjän mielestä suoriutuu sille määrätyistä tehtävistä (Pressman 2005, 378) Kuormitustestaus ja stressitestaus Kuormitustestauksella tutkitaan järjestelmän käyttäytymistä erilaisilla kuormituksilla esim. samanaikaisten käyttäjien määrä (load testing) tai käsiteltävän tiedon määrä (volume testing). Kuormitustestauksella pyritään myös selvittämään maksimitaso kuormitukselle, jonka järjestelmä kestää kaatumatta. 17

18 Stressi- eli rasitustestauksella (stress testing) tutkitaan kuormitushuippuja, joissa järjestelmä joutuu äärirajoille ja selvitetään kuinka järjestelmä niihin reagoi. Rasitustestauksella voidaan myös selvittää yläraja rasitukselle, jonka ylittyessä järjestelmä ei enää kykene suoriutumaan tehtävistään vaatimusten mukaisesti esim. samanaikaisten käyttäjien maksimimäärä, yhtäaikaiset tietokantatransaktiot, palvelimelle tehtävien pyyntöjen tiheys jne. Kuormitus- ja stressitestauksessa käytetään tavallisesti apuna simulaattoreita, joilla voidaan luoda virtuaalisia käyttäjiä ja simuloida yhtäaikaisia tapahtumia. (Myers 1979, 113; Kasurinen 2013, 71-72) Muita tärkeitä järjestelmätestauksen muotoja ovat: Yhteensopivuustestaus (compatibility testing), jossa selvitetään ohjelman/järjestelmän yhteensopivuutta laiteympäristön, käyttöjärjestelmän, tietokannan ja muiden ohjelmistojen kanssa esim. selaimet. Asennettavuus- ja asennustestaus (installability/installation testing), joissa varmistetaan ohjelmiston asennettavuus. Käyttäjädokumentaation (user documentation testing) testaus, jolla varmistetaan sekä käyttöohjeiden että ohjelmiston käytettävyyden laatu. Näillä kaikilla pyritään varmistamaan, että järjestelmä on valmis siirrettäväksi lopulliseen käyttöympäristöön, jossa suoritetaan testauksen viimeinen vaihe eli virallinen hyväksymistestaus. (Myers 1979, ; Kit 1995, 128). Hyväksymistestaus Hyväksymistestauksella (acceptance testing) todennetaan kuinka hyvin lopputuote vastaa tarkoitustaan eli niitä tarpeita ja odotuksia, joita asiakas- ja käyttäjävaatimusten määrittelyssä asetettu. Jos kyseessä on sopimusasiakkuus, hyväksymistestauksella myös varmistetaan, että asiakkaalle luovutettava ohjelmisto täyttää ne tavoitteet, joita sopimukseen on kirjattu. Asiakasprojekteissa virallinen hyväksymistestaus tehdään tavallisesti asiakkaan toimesta. Testaus voidaan toteuttaa pitempänä ajanjaksona ja usean testin sarjana, jolloin virheiden kumuloituvat vaikutukset voidaan paremmin havaita (Pressman 2005, 375). Hyväksymistestauksen lopputuloksena vahvistetaan virallisesti, että tuote siirtyy asiakkaan omaisuudeksi ja ohjelmiston kehitystyö päättyy. Alfa- ja beta-testaus Laajalle asiakaskunnalle suunnattujen off-the-shelf -ohjelmistotuotteiden kohdalla käytetään alfa- ja beta-testauksena tunnettua hyväksymistestauksen muotoa, jossa valitaan rajattu joukko 18

19 asiakkaita ja/tai loppukäyttäjiä testaamaan tuotetta. Prosessissa löytyvät virheet ovat tyypillisesti sen kaltaisia, joita erityisesti loppukäyttäjät ovat hyviä havaitsemaan (Pressman 2005, 375). Alfa-testaus tehdään yleensä ohjelman toimittajan tiloissa, jolloin kehittäjillä on mahdollisuus seurata ja kontrolloida testauksen suoritusta. Beta-testauksessa valitut asiakaskunnan edustajat testaavat ohjelmaa omissa tiloissaan itsenäisesti ja raportoivat havaitsemistaan ongelmista ohjelman kehittäjille. Alfa- ja beta-testauksen tavoitteena on varmistaa, että valmis ohjelmaversio täyttää potentiaalisen asiakaskunnan odotukset. Pyrkimyksenä on kehittää kaupallisesti kannattava tuote, joten testaustulosten perusteella tuotteeseen voidaan tehdä isojakin muutoksia ennen virallista julkaisua. Ylläpito- ja uudelleentestaus Kun ohjelmaan tai järjestelmään tehdään mikä tahansa muutos, tulee uusi versio testata. Uudelleentestaus eli regressiotestaus on jatkuva prosessi, jonka tarkoituksena on varmistaa, että tehtyjen muutosten tai korjaustoimenpiteiden jälkeen aiemmin havaittuja virheitä ei enää esiinny ja että muutokset eivät ole aiheuttaneet uusia virheitä. (Pressman 2005, 369). Uudelleentestausta kohdennetaan muutoskohtien lisäksi valikoidusti myös muutosten ulkopuolisille alueille. Muutosten vaikutusten arviointia voidaan käyttää perusteena testitapausten valinnassa. Uudelleentestaus voi tulla erittäin kalliiksi, joten siinä pyritään hyödyntämään mahdollisimman paljon automatisointia. Esimerkkejä testaustyökalujen automatisoiduista toiminnoista ovat mm. testitapausten ja testidatan automaattinen generointi, testitapausten nauhoittaminen ja automaattinen toistaminen sekä testitulosten automaattinen kirjaaminen ja vertaaminen odotettuihin lopputuloksiin. (Haikala & Märijärvi 2002, ). Ylläpitotestauksella tarkoitetaan muutostestausta, jota tehdään ohjelman käyttöönoton jälkeen. Esimerkkejä ylläpitotestauksesta ovat mm. uuden päivitetyn ohjelmaversion testaaminen ennen julkaisua, korjattujen vikojen seurauksena tehtävä uudelleentestaus, muunnos- eli konversiotestaus (esim. järjestelmä siirretään uudelle alustalle) tai testaus tilanteessa, kun järjestelmää ollaan poistamassa käytöstä. Luku 3 Testausprosessi ja sen hallinta Testausprosessin vaiheet ovat testauksen suunnittelu, testauksen suorittaminen, tulosten tarkastelu ja testausprosessin päättäminen (Haikala & Märijärvi 2002, 281). Testausprosessin onnistunut läpivienti perustuu samoihin elementteihin kuin minkä tahansa hyvin hallitun projektityön. Niihin kuuluvat mm. hyvin organisoitu ja johdettu testaustiimi 19

20 ammattitaitoiset tekijät työn jakaminen helpommin hallittaviin osavaiheisiin työn suunnittelu ja tarvittavien resurssien määrittäminen työtä helpottavien käytäntöjen, menetelmien ja välineiden omaksuminen ja käyttöönotto projektin seuranta ja riskien hallinta Katselmoinnit, arvioinnit ja testaustoiminnan mittaaminen ovat konkreettisia käytännön toimia, joilla prosessin eteneminen tehdään näkyväksi ja varmistetaan testaustyön laatu. Testaustyön roolit ja tehtävänjako Testausta tehdään tiimityönä ja siinä tarvitaan erilaisia osaajia. Testaustiimin koko vaihtelee testattavan kohteen ja projektin koon mukaisesti mutta pienenkin projektin kohdalla työtehtävien ja vastuiden jakaminen mahdollistavat hallitun ja tehokkaan työskentelyn. Testaustiimi toimii myös tiiviissä yhteistyössä ohjelman kehittäjien kanssa. Testauksen organisointi, roolit ja vastuut määritellään testaussuunnitelmassa, jonka mukaisesti työtehtäviä jaetaan. Tyypillisesti testaustiimin vetäjänä toimii testauspäällikkö, jonka vastuulla on testauksenhallintaan liittyvät tehtävät kuten testaussuunnitelman laatiminen, tarvittavien resurssien määrittely ja hankkiminen, prosessin etenemisen seuranta ja ohjaus sekä testaustulosten arviointi ja loppuraportin laatiminen. Varsinaisen testaustyön tekevät testaajat, jotka suunnittelevat, suorittavat ja dokumentoivat testit. Testaajien tehtäviin kuuluu myös havaittujen poikkeamien analysoiminen ja raportointi. Lisäksi testaajat voivat toimia testausprosessissa tuotettujen dokumenttien tarkastajina ja katselmoijina. Testaustiimin muut roolit määräytyvät työtehtävien mukaan. Osa tehtävistä vaatii erityisasiantuntemusta, jolloin vastuuhenkilön tehtävänä voi olla pelkästään esim. testiympäristön rakentaminen, työkalujen asentaminen ja ylläpito, testauksen automatisointi, testitulosten analysointi jne. Testauksen organisoinnissa pyritään testauksen riippumattomuuteen ja testaustiimin itsenäisyyteen (Kit 1995, 174). Alemman tason testausta tekevät usein ohjelman kehittäjät. Isot ja vaativat projektit toteutetaan usealla testaustasolla, jolloin vastuut voidaan jakaa eri tahoille. Ylemmän tason testaus voidaan esimerkiksi ulkoistaa osittain tai kokonaan kehitysorganisaation ulkopuolisille testaukseen erikoistuneille ammattilaisille. Testauksen suunnittelu Testauksen suunnittelu aloitetaan mahdollisimman varhaisessa vaiheessa yhdessä ohjelmiston suunnittelun kanssa. Testauksen suunnittelun tavoitteena on liittää testaus osaksi hyvin suunniteltua ja onnistuneesti etenevää ohjelmistoprojektia. Resurssit ovat usein rajalliset, joten testauksessa joudutaan tekemään valintoja kuinka paljon ja kuinka kattavasti testejä suoritetaan. Hyvä suunnittelu 20