10. Tarkastukset. Tarkastusten rakenne

Transkriptio

1 10. Tarkastukset Tarkastus (inspection) on tehokas analyysitekniikka, jota voidaan käyttää minkä tahansa projektin tuotoksen läpikäyntiin. Tarkastus on systemaattinen ja yksityiskohtainen katselmointi (review), jonka avulla etsitään tuotoksesta puutteita ja virheitä ja arvioidaan tuotoksen laatua. Tarkastukset täydentävät testausta, sillä niiden avulla löydetään sellaisia virheitä, joiden löytyminen testaamalla on joko mahdotonta tai onnistuu projektissa vasta myöhemmässä vaiheessa. Mitä aikaisemmin virhe löydetään, sitä halvemmaksi sen korjaaminen tulee. Näin tarkastukset säästävät parhaimmillaan laadunvarmistuksen kustannuksia. Ohjelmistojen testaus / Taina 157 Tarkastusten rakenne Eri yrityksissä tarkastuksilla tarkoitetaan eri tekniikoita. Tarkastustekniikat voidaan erottaa kolmen tekijän perusteella: osallistujien roolit, tarkastusprosessi ja käytetty lukutekniikka. Eli ketkä toimivat tarkastajina, miten he toimivat tarkastajina ja miten he tutkivat tarkastettavaa tuotosta. Ohjelmistojen testaus / Taina 158 (c) Juha Taina,

2 Tarkastustiimi Klassisessa tarkastustiimissä (1970-luvulta) on 4-6 tarkastajaa. Viime aikoina näin isot tarkastustiimit on kyseenalaistettu kirjallisuudessa. Jopa kahden hengen tiimillä saadaan hyviä tarkastuksia. Nykyisin lähtökohta on, että tarkastettava tuotos vaikuttaa tarkastusprosessiin. Mitä laajempi ja vaikeampi tuotos on kyseessä, sitä useampi henkilö osallistuu tarkastukseen. Yli kuuden hengen tarkastusryhmiä ei suositella, sillä tätä suuremmat ryhmät joko jakaantuvat osaryhmiksi tai passivoivat osallistujia. Ohjelmistojen testaus / Taina 159 Tuotoksen tekijän rooli Klassiseen tarkastukseen osallistuu tarkastajien lisäksi tuotoksen tekijä. Tekijän rooli on passiivinen. Hän vastaa kysymyksiin, mutta ei yritä selittää tekemisiään. Moderneissa tarkastuksissa tuotoksen tekijä on usein samassa asemassa muiden tarkastajien kanssa. Molemmissa lähestymistavoissa on etunsa. Mitä yksinkertaisempaa tuotetta tarkastetaan, sitä vähemmän tarvitaan erityistä tuotoksen tekijän roolia. Ohjelmistojen testaus / Taina 160 (c) Juha Taina,

3 Tarkastusprosessi Tarkastukseen kuuluu systemaattinen toistettava prosessi, jonka avulla tarkastuksesta saadaan parhaat puolet irti. Tarkastusprosessiin kuuluu ainakin kolme päävaihetta: 1. valmistelu (preparation), 2. tarkistus (review) ja 3. seuranta (follow-up). Ohjelmistojen testaus / Taina 161 Tarkastusprosessin vaiheet Valmisteluvaiheessa varmistetaan, että tarkastettava tuotos on valmis, valitaan tarkastajat, jaetaan tarkastajille tehtävät, jaetaan tarvittavat materiaalit, päätetään tarkastustoimista ja valitaan tarkastustilaisuuden ajankohta. Tarkistusvaiheessa tutustutaan tarkastettavaan tuotokseen ensin yksin ja tarkastustilaisuudessa ryhmässä. Tarkastustilaisuudessa seurataan ennalta jaettua esityslistaa, jonka mukaan tarkastus etenee hallittuna prosessina. Seurantavaiheessa tuotoksen tekijöille kerrotaan tarkastuksen tuloksesta ja päätetään mahdollisesta seuraavasta tarkastuksesta. Ohjelmistojen testaus / Taina 162 (c) Juha Taina,

4 Vielä tarkastusprosessista Tarkastukset ovat raskasta työtä. Tarkastustilaisuus ei saisi kestää enempää kuin kaksi tuntia kerrallaan. Kahden tunnin jälkeen tarkastajien tuottavuus putoaa selvästi. Kenenkään ei pitäisi osallistua useampaan kuin kahteen tarkastustilaisuuteen saman päivän aikana. (Klassiset) tarkastukset vaativat paljon henkilöresursseja. Usein tarkastuksiin pyydetään henkilöitä, jotka eivät ole suoraan tekemisissä tuotoksen kanssa. Ohjelmistojen testaus / Taina 163 Vieläkin tarkastusprosessista Tarkastukset ovat kalliita. Klassiseen tarkastukseen tarvitaan parhaimmillaankin noin henkilötyötuntia, mistä tuloksena saadaan noin 20 sivua tarkastettua dokumentaatiota. Eli: tarkastukset ovat hyödyllisiä, mutta niiden käytössä kannattaa käyttää tervettä järkeä. Kaikissa työvaiheissa kannattaa käyttää tarkastuksia, mutta kaikkea ei voida tarkastaa niin huolellisesti kuin haluttaisiin. Ohjelmistojen testaus / Taina 164 (c) Juha Taina,

5 Tarkistuslistat Tarkistuslista (checklist) sisältää joukon kysymyksiä, joihin on koottu aiempien projektien kokemus tämän tyyppisissä tarkastuksissa löydettävistä virheistä. Tarkistuslista sisältää joukon kysymyksiä, joihin on mahdollista vastata valinnoilla kyllä/ei. Jos kysymykseen vastataan kyllä, kyseistä ongelmaa ei esiinny tuotoksessa. Jos kysymykseen vastataan ei, kyseinen ongelma esiintyy tuotoksessa. Ohjelmistojen testaus / Taina 165 Tarkistuslistan ominaisuuksia Tarkistuslistaan ei sisällytetä sellaisia kysymyksiä, jotka on mahdollista tarkistaa automaattisesti A&T:n tekniikoilla. Esimerkiksi koodintarkistimella löydettävät virheet etsitään sillä tarkastusten sijaan. Kielioppivirheitä ei yleensä kirjata tarkistuslistaan. Ne tarkistetaan tarkastusten ulkopuolella. Tarkistuslistat pyritään pitämään tiiviinä. Mitä enemmän kysymyksiä, sitä huonommin kukin kysymys käydään läpi tarkistuksessa. Ohjelmistojen testaus / Taina 166 (c) Juha Taina,

6 Pariohjelmointi Ketterissä prosesseissa käytetty pariohjelmointi (pair programming) on tarkastusten variantti. Pariohjelmoinnissa kaksi ohjelmoijaa työskentelee vierekkäin samalla tietokoneella. Kun toinen kirjoittaa uutta koodia, toinen tarkastaa tehtyä työtä. Pariohjelmoinnin parit vaihtavat aika ajoin roolia. Tällöin äsken koodia kirjoittanut siirtyy koodin tarkistajaksi ja päinvastoin. Ohjelmistojen testaus / Taina 167 Pariohjelmoinnin tehokkuus Koska pariohjelmointiin tarvitaan kaksi ohjelmoijaa, intuitiivisesti vaikuttaisi siltä, että pariohjelmoinnin tehokkuus on puolet tavallisen ohjelmoinnin tehokkuudesta. Näyttää kuitenkin siltä, että pariohjelmoinnilla saavutetaan odotettua parempi tehokkuus. Kaksi ohjelmoijaa yhdessä saa aikaan enemmän kuin kumpikaan saisi yksin (mutta vähemmän kuin kummankin panos laskettuna yhteen). Pariohjelmoinnilla tuotoksen laatu on yksin tehtyä tuotosta parempaa. Pariohjelmointiin käytetty aika on parhaimmillaan suoraan poissa muihin tarkastuksiin vaadittavasta ajasta. Ohjelmistojen testaus / Taina 168 (c) Juha Taina,

7 11. Testausprosessi (P&Y:20-22) Laadun varmennus siis verifiointi ja validointi - on prosessi, johon pätevät samat säännöt kuin laajempiin ohjelmistoprosesseihin. Prosessin täytyy olla suunniteltu, systemaattinen ja seurattu. Laadunvarmennusprosessin, tai lyhyemmin laatuprosessin (quality process) täytyy erityisesti olla yhteensopiva kehitystyössä käytettävän prosessimallin kanssa. Esimerkiksi ketterät prosessit perustuvat lyhyisiin sykleihin, kevyeen projektinhallintaan ja minimaaliseen dokumentaatioon. Tällaiseen prosessiin on vaikea liittää yksityiskohtaista formaalia tarkastuskäytäntöä. Ohjelmistojen testaus / Taina 169 Laatuprosessi ja ohjelmistoprosessi Hyvä laatuprosessi on rakenteeltaan yhtenevä koko käytettävän ohjelmistoprosessin kanssa. Vesiputousmallin tapaisissa prosesseissa käytetään V-mallia (kalvo 10) tai sen varianttia. XP:ssa yksikkötestit yhdistetään jokaisella syklillä osajärjestelmien ja järjestelmän testaukseen. Spiraalimallin tapaisissa syklisissä prosessissa on sekä laajempaa monen syklin yli ulottuvaa testausta että tiivistä syklikohtaista testausta. Olivatpa prosessin yksityiskohdat mitä tahansa, laadun varmistuksessa tulee huolehtia, että virheet havaitaan ja korjataan mahdollisimman pian. Mitä myöhemmin virhe havaitaan, sitä kalliimmaksi sen korjaaminen tulee. Tuotantokäyttöön päässeen virheen kustannukset voivat olla heti löytymiseen verrattuna tuhatkertaiset. Ohjelmistojen testaus / Taina 170 (c) Juha Taina,

8 XP:n laatuprosessi Laatuprosessin kannalta asiakkaan läsnäolo XP-projektissa on oleellista. Asiakas osallistuu vaatimusmäärittelyyn tekemällä käyttäjätarinoita, jotka toimivat sekä suunnittelun että testauksen pohjana. Asiakas on vastuussa jokaisen syklin lopussa tehtävästä hyväksymistestauksesta. Koska XP:n syklit ovat lyhyitä, asiakas on läsnä koko projektin ajan. Tiivistäen voi sanoa, että mitä paremmin asiakas on läsnä XPprojektissa, sitä luultavammin projekti onnistuu. Tämä on osoittautunut ongelmaksi, sillä yleensä asiakkaalla ei ole aikaa olla mukana projektissa. Jos asiakas ei ole kunnolla läsnä, prosessi käytännössä degeneroituu jonkinlaiseksi vesiputousmallin ja iteratiivisen mallin yhdistelmäksi. Ohjelmistojen testaus / Taina 171 XP:n laatuprosessi 2 XP:n testitapaukset perustuvat käyttäjätarinoihin. Ne korvaavat osin vaatimusmäärittelydokumentin. Toisin sanoen XP:n testitapaukset ovat osa tehtävän ohjelmiston määrittelyä. Puhtaimmillaan käyttäjätarinat ja testitapaukset korvaavat vaatimusmäärittelydokumentin. Automatisoitavissa olevat yksikkötestit lasketaan ohjelmakoodiksi. Itse testattava koodi kirjoitetaan vasta sen jälkeen, kun kaikki sitä verifioivat testitapaukset on kirjoitettu. Tätä sanotaan testilähtöiseksi kehitystyöksi (test-driven development, TDD). Kaikkia testejä ei kirjoiteta ennen koodia. Esimerkiksi käytettävyystestit ja osin järjestelmätestit kirjoitetaan vasta sen jälkeen, kun testattava ohjelma on valmis. Ohjelmistojen testaus / Taina 172 (c) Juha Taina,

9 XP:n laatuprosessi 3 XP:n kehitystyö tehdään pariohjelmointina. Toinen ohjelmoi ja toinen tarkkailee kirjoitettavan koodin laatua. Aiemmin tehtyä testipakettia täydennetään tämän syklin uusilla yksikkötesteillä ja kaikki testit suoritetaan syklin päätteeksi. Epäonnistunut hyväksymistesti tarkoittaa, että yksikkötesteissä on puutteita. Pariohjelmoinnin avulla ohjelman kirjoitus ja koodin tarkastus (katselmointi) yhdistyvät yhtenäiseksi kokonaisuudeksi. Ohjelmistojen testaus / Taina 173 XP:n laatuprosessi 4 Seuraavassa on XP:n laatuprosessi kaaviokuvana. XP:n laatu perustuu automatisoituihin yksikkötesteihin. Syklin päättymisen vaatimuksena on, että kaikki hyväksymistestit ovat menneet läpi. Kuvalla (c) Pezzè & Young, 2007 Ohjelmistojen testaus / Taina 174 (c) Juha Taina,

10 Laatustrategia Hyvän laatuprosessin ehdoton vaatimus on onnistunut yrityksen sisäinen laatustrategia (quality strategy). Se määrittelee, miten laatu varmennetaan yrityksessä. Strategia määrittelee ainakin: mitä projektien laatusuunnitelmat sisältävät, mitkä ovat yrityksen sisäiset laatustandardit, miten projektien laadun varmennukseen kuuluu ja miten käytettyjä prosesseja valvotaan ja parannetaan. Ohjelmistojen testaus / Taina 175 Vielä laatustrategiasta Lisäksi strategia voi määritellä: mitä kaikille tuotteille yhteisiä laatuvaatimuksia on, miten projektien etenemistä mitataan, mitä tekniikota ja niitä tukevia työkaluja käytetään, mitä dokumentteja tuotetaan ja mitä työnkuvia (roolit ja vastuut) projekteihin kuuluu. Strategia voi olla kuvattuna yrityksen laatukäsikirjana (quality manual). Sitä seurataan ja parannetaan säännöllisillä laatuauditoinneilla (quality audit). Ohjelmistojen testaus / Taina 176 (c) Juha Taina,

11 Integrointitestaus Perinteinen testauksen V-malli (kalvot 9-10) jakaa testauksen neljään työvaiheeseen: yksikkötestaukseen (module testing, unit testing), missä testataan pienimpiä jakamattomia yksiköitä (yleensä olioita tai proseduureja), integrointitestaukseen (integration testing), missä testataan yksiköiden välinen yhteensopivuus, järjestelmätestaukseen (system testing), missä testataan koko järjestelmä ja hyväksymistestaukseen (acceptance testing), missä järjestelmä validoidaan. Työvaiheista integrointitestaus on vähiten arvostettu, mutta se on yhtä tärkeä kuin muut työvaiheet. Ohjelmistojen testaus / Taina 177 Integrointitestauksen perusteet Tehokas integrointitestaus perustuu hyvin tehtyyn yksikkötestaukseen ja katselmointeihin. Yksikötestaus varmistaa, että integroitavat yksiköt toteuttavat kaikki niille asetetut vaatimukset. Katselmoineilla löydetään yksikköjen rajapintojen välisiä korkean tason puutteita ja virheitä. Integrointivaiheessa integroitavat yksiköt on testattu niin hyvin, että yksiköiden sisäisiä ongelmia ei ole. Kaikki ongelmat johtuvat yksiköiden keskinäisestä yhteensopimattomuudesta. Yhteensopimattomuus voi johtua vajaasti määritellystä tai toteutetusta rajapinnasta, virheellisestä resurssien käytöstä tai puuttuvista tai väärin toteutetuista ominaisuuksista.tyypillisiä integrointivirheitä Ohjelmistojen testaus / Taina 178 (c) Juha Taina,

12 Tyypillisiä integrointivirheitä Yhteensopimattomuudesta seuraa integrointivirheitä. Seuraavassa on listattu muutama tyypillinen vaihtoehto: Epäyhtenäinen parametrien tulkinta Jokaisen yksikön tulkinta voi olla järkevä, mutta tulkinnat eivät ole yhteensopivia. Arvoalue- ja kapasiteettivirheet Parametrin arvoalueesta tai kapasiteetista tehdään vääriä oletuksia. Parametrien tai resurssien sivuvaikutukset Sivuvaikutukset voivat aiheuttaa implisiittisen testaamattoman rajapinnan kahden yksikön välille, joilla ei muuten olisi mitään yhteistä. Puuttuva tai väärin tulkittu toiminnallisuus Oletetusta eroava toiminta voi johtaa odottamattomaan lopputulokseen. Ei-toiminnalliset ongelmat Vaikka yksiköt täyttävät ei-toiminnalliset vaatimukset, integrointi ei välttämättä täytä niitä. Esimerkiksi vasteaika on ei-toiminnallinen vaatimus, joka voi kärsiä syvästä rajapintahierarkiasta. Ajonaikaiset yhteensopimattomuudet Väärä dynaaminen sidonta voi johtaa yhteensopimattomaan rajapintaan. Ohjelmistojen testaus / Taina 179 Integrointitestausstrategiat Integrointitestauksessa yksiköitä kootaan lisäävästi pienistä kokonaisuuksista suuremmiksi, kunnes koko ohjelmisto on koottu yhteen. Tavoitteena on, että yhdessä integrointitestauksen vaiheessa testataan vain yhtä rajapintaa. Toisin sanoen kerralla integroidaan vain kaksi yksikköä. Hyvä integrointitestaus tapahtuu yhtä aikaa kehitystyön kanssa. Integrointia tehdään heti, kun on integroitavaa. Tietenkin integroitavat yksiköt on ensin testattu kunnolla. Hyvä yksikkötestaus on integrointitestauksen ehdoton vaatimus. Ohjelmistojen testaus / Taina 180 (c) Juha Taina,

13 Perinteiset integrointitestauksen menetelmät Perinteiset integrointitestauksen menetelmät ovat top-down ja bottom-up. Menetelmissä testattavat yksiköt järjestetään käytön/sisältyvyyden mukaan. Matalimmalla tasolla ovat yksiköt, jotka eivät tarvitse muilta palveluita. Korkeimmalla tasolla ovat yksiköt, jotka eivät tarjoa muille palveluita. Top-down-testauksessa integrointitestaus aloitetaan korkeimmalta tasolta. Bottom-up-testauksessa integrointitestaus aloitetaan alimmalta tasolta. Yleensä ei tehdä puhdasta top-downia tai bottom-upia, vaan integrointitestausta tehdään samaan aikaan ylhäältä alas ja alhaalta ylös. Tämä on voileipätestausta (sandwich testing). Ohjelmistojen testaus / Taina 181 Modernit integrointitestauksen menetelmät Perinteiset menetelmät riittävät pienten järjestelmien integrointiin, mutta isompiin järjestelmiin tarvitaan järeämpiä keinoja. Säietestauksessa (thread integration testing) yksiköt integroidaan järjestelmän ominaisuuksien mukaan. Jokainen säie kuvaa jonkun järjestelmän ominaisuuden vaatimat yksiköt. Integrointitestaus tehdään säikeittäin ylhäältä alas tai alhaalta ylös. Kriittisen yksikön testauksessa (critical module integration testing) resurssit keskitetään niihin yksiköihin, jotka ovat projektin onnistumisen kannalta suurin riski. Yksiköt lajitellaan riskin mukaan. Integrointi aloitetaan riskialtteimmista yksiköistä. Myös ulkoiset riskit, projektin riskit ja liiketoiminnan riskit voidaan huomioida. Ohjelmistojen testaus / Taina 182 (c) Juha Taina,

14 Järjestelmä-, hyväksymis- ja regressiotestaus Järjestelmätestaus (system testing) on tavallaan integrointitestauksen viimeinen vaihe. Siinä testataan koko järjestelmää, mutta paino on sisäisten rajapintojen sijaan järjestelmätason ominaisuuksissa. Hyväksymistestaus (acceptance testing) on validointia. Siinä testataan, miten hyvin valmis järjestelmä täyttää asiakkaan tarpeet. Regressiotestaus (regression testing) auttaa löytämään muutoksen tai uuden ominaisuuden aiheuttamia virheitä jo aiemmin testatussa koodissa. Ohjelmistojen testaus / Taina 183 Järjestelmätestaus Järjestelmätestaus perustuu ohjelman rajapintojen spesifikaatioon. Se on riippumatonta suunnittelun ja toteutuksen yksityiskohdista. Järjestelmätestaus on testauksen kulminaatiopiste. Tässä vaiheessa koko järjestelmä (tai sen ohjelmistot) on koossa ja testattu sisäisesti. Sisäinen toiminnallisuus on testattu yksikkötestauksessa. Sisäiset rajapinnat on testattu integrointitestauksessa. Vain ulkoiset rajapinnat, eli yhteistyö muiden järjestelmien ja loppukäyttäjien kanssa, ovat testaamatta. Järjestelmätestauksen tuloksena saadaan tuote, joka täyttää sekä sisäiset että ulkoiset speksit: siis SRS:n. Ohjelmistojen testaus / Taina 184 (c) Juha Taina,

15 Järjestelmätestauksen suoritus Järjestelmätestauksesta voi olla vastuussa erillinen testaustiimi, mutta varsinkin ketterissä prosesseissa järjestelmätestauksen tekee usein kehitystiimi. Erillinen testaustiimi on paras keino varmistaa, että suunnittelu- ja toteutusratkaisut eivät vaikuta järjestelmätestaukseen. Jos järjestelmätestauksesta vastaa kehitystiimi, paras keino varmistaa järjestelmätestauksen objektiivisuus on suunnitella järjestelmätestit ennen yksikkötestejä. Tämä onnistuu myös ketterissä prosesseissa suunnittelemalla sykliin liittyvät järjestelmätestit syklin alussa. Ohjelmistojen testaus / Taina 185 Ei-toiminnallisten vaatimusten järjestelmätestaus Järjestelmätestaukseen liittyy ei-toiminnallisten vaatimusten testaus. Ei-toiminnalliset vaatimukset liittyvät laatuattribuutteihin. Yleensä testataan ainakin suorituskyky rasitustestauksella (stress testing). Rasitustestauksessa järjestelmän kuormitusta lisätään tasaisesti, kunnes se ei enää selviä kuormasta. Näin selvitetään, täyttääkö järjestelmä sille asetetut suorituskykyvaatimukset. Jotkut ei-toiminnalliset vaatimukset ovat vaikeita tai jopa mahdottomia testata. Esimerkiksi tietoturvan testaaminen on äärimmäisen vaikeaa. Toki voidaan verifioida, että kaikki tunnetut turvaaukot on tukittu, mutta tuntemattomien turva-aukkojen tukkiminen ja sisäisten väärinkäytösten estäminen on vaikeampaa. Ohjelmistojen testaus / Taina 186 (c) Juha Taina,

16 Yksikkö- integrointi- ja järjestelmätestauksen erot Yksikkötestaus Integrointitestaus Järjestelmätestaus Testitapaukset johdetaan Yksiköiden (luokkien) määrittelyistä Arkkitehtuurista ja suunnittelun yksityiskohdista Vaatimusmäärittelydokumentista Näkyvyystaso Kaikki yksityiskohdat Rajapinnat, osa koodia Vain ulkoiset rajapinnat Testausympäristö Monimutkainen. Tarvitaan ajurit, tyngät ja oraakkelit Riippuu arkkitehtuurista ja integrointitekniikasta. Tarvitaan ajurit ja oraakkelit, tynkiä ei välttämättä Tarvitaan oraakkelit ja joskus käyttöympäristön simulaatio (jos järjestelmällä on paljon ympäirstöön sidottuja vaatimuksia) Testaus keskittyy Yksiköihin (luokkiin) Yksiköiden yhteistyöhön Järjestelmän toiminnallisuuteen Ohjelmistojen testaus / Taina 187 Hyväksymistestaus Hyväksymistestauksessa päätetään, onko kehitettävä järjestelmä sellaisessa kunnossa, että sen voi julkaista. Hyväksymistestit voidaan tehdä formaalisti: hyväksymistesteillä validoidaan, että määritellyt ulkoiset ja sisäiset laatuattribuutit toteutuvat tuotteessa. tai ne voidaan tehdä epäformaalisti: loppukäyttäjät tekevät hyväksymistestit alfatestauksella (alpha testing) ja beetatestauksella (beta testing). Ohjelmistojen testaus / Taina 188 (c) Juha Taina,

17 Alfa- ja beetatestaus Alfa- ja beetatestauksessa lopullisista käyttäjistä valitaan sopiva otos, jotka testaavat järjestelmää. Alfatestauksessa käyttäjät käyttävät järjestelmää laboratorio-olosuhteissa. Käyttäjien toimintaa seurataan tarkasti. beetatestauksessa käyttäjät käyttävät järjestelmää todellisessa ympäristössä ilman seurantaa. Alfa- ja beetatestaus pitäisi tehdä lopulliselle tuotteelle. Usein tästä oiotaan, ja ensimmäiset alfaja beetatestit tehdään keskeneräiselle tuotteelle tai prototyypille. Tarkkaan ottaen tämä ei ole hyväksymistestausta, sillä prototyyppi tai keskeneräinen tuote ei tule tuotantokäyttöön. Ohjelmistojen testaus / Taina 189 Regressiotestaus Aina kun koodia muutetaan tai integroidaan uusia yksiköitä on riski, että aiemmin kirjoitettu koodi ei ole yhteensopivaa uuden koodin kanssa. Regressiotestauksella verifioidaan, että muutokset eivät ole rikkoneet jo testattua koodia. Yksinkertaisin regressiotestauksen tekniikka on suorittaa kaikki aiemmin tehdyt testit uudestaan. Aina tämä ei ole järkevää: Testejä voi olla niin paljon, että kaikkien testien suorittaminen ei onnistu järkevässä ajassa. Muutokset voivat olla sellaisia, että vanhat testitapaukset eivät ole enää yhteensopivia muokatun järjestelmän kanssa. Testit voivat olla muutoksen jälkeen tarpeettomia. Näiden kohtien johdosta tarvitaan testitapausten ylläpitoa (test case maintenance). Siinä huolehditaan, että regressiotestauksen testipaketti on ajan tasalla. Ohjelmistojen testaus / Taina 190 (c) Juha Taina,

18 12. Yhteenveto Kuten kaikki ohjelmistotyö, myös testaus ja analyysi jaetaan kahtia: prosessiin ja menetelmiin. Testausprosessi vaihtelee käytetyn ohjelmistoprosessin mukaan. Käytännössä kaikissa prosesseissa ovat mukana ainakin yksikkötestaus ja järjestelmätestaus. Lisäksi ylläpitovaiheessa mukana on aina regressiotestaus. Testausprosessi vaihtelee yrityksittäin Pienissä yrityksissä ohjelmoijat testaavat omat tuotoksensa. Isommissa yrityksissä on yleensä erillinen testaustiimi, joka vastaa ainakin järjestelmätestauksesta. Ohjelmistojen testaus / Taina 191 Yhteenveto 2 Menetelmistä käytössä ovat käytännössä aina toiminnallinen testaus ja rakenteinen testaus. Toiminnallisen testauksen menetelmistä ylivoimaisesti yleisimmät ovat kombinaatiotestauksen variantit. Varsinkin luokittelutestausta käytetään paljon. Rakenteisen testauksen menetelmistä käytetyimmät ovat haaraumakattavuus ja jokin ehtokattavuus. Testausta voi ja kannattaa tehostaa sopivalla mallinnuksella, kuten äärellisillä automaateilla ja totuustauluilla. Ohjelmistojen testaus / Taina 192 (c) Juha Taina,