Testaus osana ohjelmistojen elinkaarta Luento 2 Antti-Pekka Tuovinen

Transkriptio

1 Testaus osana ohjelmistojen elinkaarta Luento 2 Antti-Pekka Tuovinen 19 March

2 Oppimistavoitteet Ohjelmistokehityksen V-malli Testauksen tasot (test level) Inkrementaalinen (ketterä) kehitys ja testaus Testityyppejä (test type) testauksen kohteena olevien ominaisuuksien ja tarkoituksen mukaan jaoteltuna 19 March

3 Ohjelmistokehityksen V-malli 19 March

4 Ohjelmistokehitysprosessit 19 March

5 Ohjelmistokehityksen V-malli Andreas Spillner, Tilo Linz, Hans Schaefer: Software testing foundations - a study guide for the certified tester exam : foundation level, ISTQB compliant, 4th Edition. Santa Barbara, CA : Rocky Nook, Inc., March

6 Ohjelmistokehityksen V-malli Nostaa testauksen muitten kehitysaktiviteettien rinnalle tärkeydessä Korostaa testauksen suunnitelmallisuutta V:n vasen haara edustaa ohjelmiston ja sen osien kehitysprosessia ja oikea haara integrointia ja testauksen suoritusta Malli tunnistaa ohjelmiston eri rakennetasot, jotka vaativat omanlaisensa testauksen Tavoitteet, tekniikat, osaaminen Testauksen suunnittelu ja valmistelu etenee rinnan vastaavan kehitystason työn aikana 19 March

7 V-mallin Veet Validointi soveltuuko ohjelma ajateltuun käyttöönsä? Verifiointi onko ohjelman osa toteutettu määrittelynsä mukaisesti? Validoinnin rooli korostuu V-mallin ylemmillä testaustasoilla 19 March

8 Testaustasot Test level 19 March

9 Testaustasot - Komponenttitestaus A.k.a Yksikkötestaus Ohjelman pienimpien toiminnallisten rakenneosien testausta Luokka, moduuli, funktio, skripti, 19 March

10 Komponenttitestauksen lähtökohdat Komponentit testataan yksitellen ja erillään muista komponenteista Löydetyt häiriöt johtuvat testattavassa komponentissa olevista vioista Testataan komponentin sisäistä toimintaa ja käyttäytymistä White-box testauksen rooli korostuu 19 March

11 Komponenttitestauksen ympäristö Testaus täytyy tehdä läheisessä yhteistyössä kehittäjien kanssa - usein kehittäjät tekevät yksikkötestauksen itse Tarvitaan testiajuri (test driver), joka Alustaa testitapausten suorituksen Kutsuu komponentin palveluja/toimintoja Vastaanottaa kutsujen tuottamat tulokset ja vertaa niitä odotettuihin arvoihin Kirjaa testien suorituksen ja tulokset (pass/fail) 19 March

12 Komponenttitestauksen ympäristö Yksikkötestauskehikot (test framework, test fixture) testiajurien toteuttamiseen xunit arkkitehtuuri JUnit Javalle ( Esimerkki JUnit:n käytöstä Eclipse kehitystyökalussa: c 19 March

13 Komponenttitestauksen yleiset tavoitteet Toiminnallisuuden verifiointi Varmistetaan oikea toiminta valituilla testitapauksilla eli syöte/tulos kombinaatioilla Vikasietoisuuden (robustness) testaus Testataan toimintaa virheellisillä (ja määrittelemättömillä) syötteillä Testataan toimintaa muissa poikkeustilanteissa Engl. negative tests 19 March

14 Komponenttitestauksen erityiset tavoitteet muut laatupiirteet Nämä ovat esimerkkejä komponenttikohtaisista testeistä (vaihtelevat komponenteittain) Tehokkuus Laskentaresurssien käyttö, suoritusnopeus Vain kriittisille komponenteille (sulautetut ohjelmistot, tiukat aikavaatimukset) Ylläpidettävyys Käytetään staattista analyysiä (työkaluja, katselmointia), ei ohjelman suorittamista (dyn. testausta) Koodin rakenne, modulaarisuus, kommentointi, koodauskonventioiden noudattaminen, ymmärrettävyys jne March

15 Komponenttitestauksen strategia Testitapausten suunnittelu on yleensä komponentin ohjelmoijan tehtävät Hänellä on tarvittava tieto toteutuksen yksityiskohdista White-box suunnittelumenetelmien pääasiallinen käyttökohde Tavoitteena usein saavuttaa riittävä kooditason kattavuus testitapauksilla (tähän palataan myöhemmin) Käytännössä testien suunnittelussa käytetään usein black-box menetelmiä (koska white-box menetelmiä voi olla vaikea käyttää oikein?) 19 March

16 Komponenttitestauksen strategia Testilähtöinen kehitys Test Driven Development (TDD) Suosittu iteratiivisessa ja ketterässä kehityksessä Koodattavan moduulin/luokan yksikkötestit kirjoitetaan ensin Aluksi testi epäonnistuu, koska implementaatiota ei vielä ole Koodausta jatketaan, ja kun kaikki testit lopulta menevät läpi, implementaatio on valmis Testit automatisoidaan ja ne ajetaan koodin muuttuessa 19 March

17 Testaustasot - Integrointitestaus Integrointi = komponenttien/yksiköiden koostaminen suuremmiksi rakenneyksiköiksi (alijärjestelmiksi) Integroitavat komponentit on jo testattu Tavoitteena on löytää vikoja yhdistettyjen komponenttien Rajapinnoista (interface) Vuorovaikutuksesta (interaction) 19 March

18 Testaustasot - Integrointitestaus Eri tiimien toteuttamien komponenttien vuorovaikutus/yhteistoiminta on altis puutteellisen määrittelyn, väärinymmärrysten ja heikon kommunikaation aiheuttamille vioille Eri tahtiin etenevä kehitystyö asettaa haasteensa komponenttien yhteistoiminnan toteutttamiselle Erityisen hankalia ovat tapaukset, joissa vieraat komponentit käyttävät sisäisiksi (ei-julkiksi) tarkoitettuja rajapintoja (tai muita elementtejä), jotka voivat muuttua odottamatta 19 March

19 Integrointitestauksen lähtökohdat Testitapausten pohjana käytetään arkkitehtuurisuunnittelua Arkkitehtuuri / järjestelmäarkkitehtuuri Käyttötapaukset Työnkulkujen kuvaukset (workflow) Valmisohjelmistojen/komponenttien (COTS) vuorovaikutus itse kehitettyjen komponenttien kanssa kuuluu integraatiotestauksen piiriin 19 March

20 Integrointitestauksen ympäristö Pyritään käyttämään hyväksi komponenttitestauksen testiajureita Komponentit tarjoavat palvelunsa rajapintojen kautta, joita komponenttitestauksenkin ajurit käyttävät Integroitujen komponenttien yhteistoiminnan seurantaa varten tarvitaan monitoreita (monitor) Komponenttien välisen dataliikenteen ym. lukeminen ja kirjaaminen lokiin 19 March

21 Integrointitestauksen tavoitteet Integroitavien komponenttien yhteistoiminnan vikojen ja ristiriitojen löytäminen Käännösaikaiset (staattiset) rajapintamäärittelyjen ristiriidat löytyvät usein koostamisen (build) aikana Dynaamiset ohjelmointikielet vaativat testausta staattisesti tyypitettyjä enemmän Suoritusaikaiset (protokolla-) viat löytyvät vain testaamalla 19 March

22 Integrointitestauksen tavoitteet Tyypillisiä kommunikaatioon liittyviä vikoja Syntaktisesti vääränmuotoisen datan lähettäminen tai datan lähettämättä jättäminen aiheuttaa poikkeuksen vastaanottavassa komponentissa Datan välitys toimii, mutta komponentit tulkitsevat datan merkityksen eri tavoin Tiedonsiirrossa on ajoitusongelmia Väärään aikaan, liian myöhään, liian tiheään 19 March

23 Integrointitestauksen tavoitteet K: Voisiko komponenttitestauksen jättää pois, ja ajaa kaikki testit vasta integroinnin jälkeen? V: Ei ole järkevää Häiriön aiheuttavan vian paikallistaminen hankalaa, kun on monta osallistuvaa komponenttia Yksittäisten komponenttien toimintaa on vaikea tai mahdotonta ohjata ja valvoa Integrointitestausympäristössä voi olla vaikeaa saada aikaan tilannetta, joka laukaisee tietyn poikkeustilanteen käsittelyn komponentissa 19 March

24 Integrointistrategioista Komponentit valmistuvat usein eri tahtiin, jolloin voi olla vaikea etukäteen tietää, milloin integraatiotestausta päästään tekemään Testauspäällikön (test manager) on tehtävä integrointitestausta varten suunnitelma, joka ottaa huomioon ohjelmiston testausstrategian, arkkitehtuurin ja projektisuunnitelman Parhaassa tapauksessa testaustarpeet otetaan jo huomioon projektisuunnitelmassa ja komponenttien implementointijärjestyksessä 19 March

25 Yleisiä integrointistrategioita Top-down Bottom-up Ad hoc Backbone / skeleton ja tietysti viimeiseen asti vältettävä, eiinkrementaalinen Big Bang Lähinnä seurausta integrointistrategian puuttumisesta! 19 March

26 Testaustasot Järjestelmätestaus Tuo mukaan asiakkaan ja käyttäjän näkökulman teknisten vaatimusten rinnalle Ohjelmiston tarjoamia palveluja koetellaan todellisessa käytössä Monien toimintojen suorittaminen ja järjestelmän piirteiden havainnointi vaativat kaikkien komponenttien yhteistoimintaa Niitä voidaan testata vain järjestelmätasolla 19 March

27 Järjestelmätestauksen lähtökohdat Järjestelmä- ja ohjelmistovaatimukset, määrittelyt, käyttöoppaat, asennusohjeet, ylläpito-ohjeet jne. Testit suoritetaan mahdollisimman samanlaisessa laitteisto- ja ohjelmistoympäristössä kuin lopullinen käyttöympäristö Ohjelmiston eri konfiguraatiot ja suorituskyky eri tilanteissa on myös testattava 19 March

28 Järjestelmätestauksen lähtökohdat Datan laatu on entistä tärkeämpää nykyisissä ohjelmistoissa Järjestelmän käyttämän datan eheys, täydellisyys ja ajantasaisuus on varmistettava! 19 March

29 Järjestelmätestauksen lähtökohdat Järjestelmätestaus on syytä tehdä erillisessä testausympäristössä ei asiakkaan tuotantoympäristössä Vältetään testattavan ohjelmiston vioista tuotantoympäristöön aiheutuvat vahingot Testausolosuhteita (test condition) voi olla vaikeaa hallita tuotantoympäristössä Testien toistettavuus on parempi 19 March

30 Järjestelmätestauksen tavoitteet Vaatimusten väärästä, epätäydellisestä tai epäyhtenäisestä implementoinnista johtuvien vikojen löytäminen Puuttuvien tai unohdettujen vaatimusten huomaaminen ja tunnistaminen 19 March

31 Järjestelmätestauksen ongelmia Jos vaatimuksia ei ole kirjattu ylös, järjestelmätestien suunnittelijoiden vaikeana tehtävänä on haalia tarvittava informaatio hajallaan olevista lähteistä Tässä tilanteessa paljastuu yleensä myös erilaisia tulkintoja samoista vaatimuksista, jolloin testaajien täytyy ottaa aloite yhteisen näkemyksen muodostamiseksi (testitapausten tuottamiseksi) Näissä olosuhteissa voi olla parasta turvautua tutkivaan testaukseen (exploratory testing) Käsitellään myöhemmin kurssilla 19 March

32 Testaustasot - Hyväksyntätestaus Edellä kuvatut testit tekee ohjelmiston toimittaja Ennen ohjelmiston ottamista käyttöön asiakkaankin on osallistuttava validointiin Asiakkaan/käyttäjän näkökulma ja evaluointi Erityisen tärkeää räätälöidyille ohjelmistoille Vakiintuneen valmisohjelmiston (COTS) hankinnan yhteydessä tehtävät hyväksyntätestaus voi olla kevyempi 19 March

33 Hyväksyntätestauksen lähtökohdat Mikä tahansa järjestelmää käyttäjän/asiakkaan näkökulmasta kuvaava dokumentaatio Käyttötapaukset, liiketoimintaprosessit, lait ja säännökset, tietohallinnon ja ylläpidon säännöt ja prosessit 19 March

34 Hyväksyntätestauksen lähtökohdat Hyväksyntätestejä voidaan tehdä osana muittenkin tasojen testausta Valmisohjelmistojen käyttöä voidaan testata jo integroinnin aikana Käyttöliittymään liittyvien komponenttien käytettävyyttä voidaan testata komponenttitestauksen yhteydessä Prototyyppejä voidaan käyttää uuden toiminnallisuuden testaamiseen jo ennen järjestelmätestausta Asiakkaan ja käyttäjän näkökulman saaminen mukaan projektin alkuvaiheessa on tavoiteltava asia Ketterien menetelmien yksi kulmakivi 19 March

35 Hyväksyntätestauksen muodot 1. Sopimukseen kirjattujen hyväksymisehtojen täyttymisen testaus 2. Loppukäyttäjän hyväksyntätestaus 3. Tuotannon/operoinnin hyväksyntätestaus 4. Kenttätestaus 19 March

36 Hyväksymisehtojen testaus Asiakas varmistaa, että ohjelmistossa ei ole (merkittäviä) puutteita ja että ohjelmisto muuten on tilaussopimuksen mukainen Toimittajan ja asiakkaan välisessä sopimuksessa on usein kirjattu erikseen hyväksymisehdot (acceptance criteria) Toimittajan pitäisi olla testannut ehtojen täyttyminen jo omissa järjestelmätesteissään Yleensä riittää hyväksynnän kannalta riittävien testien toistaminen yhdessä asiakkaan kanssa 19 March

37 Hyväksymisehtojen testaus On tärkeää, että asiakas on itse määritellyt hyväksymistestauksen testitapaukset tai ainakin ne huolellisesti katselmoinut Toisin kuin järjestelmätestaus, hyväksyntätestaus tehdään nyt asiakkaan (tuotanto-)ympäristössä Myös ohjelmiston jakelu ja asennus testataan asiakkaan ympäristössä 19 March

38 Loppukäyttäjän hyväksyntätestaus Asiakas ja loppukäyttäjät voivat olla eri henkilöitä Eri käyttäjäryhmillä on erilaisia tarpeita ja odotuksia Ohjelmistoa päivittäin työssään käyttävät Satunnaiset käyttäjät Ylläpidon ja tuotannon työntekijät, jotka vastaavat ohjelmiston saatavuudesta Johto, jolla on omia seuranta- ja raportointitarpeitaan Asiakkaan tehtävänä on usein valita testitapaukset kullekin käyttäjäryhmälle 19 March

39 Loppukäyttäjän hyväksyntätestaus Tässä vaiheessa havaittujen merkittävien ongelmien ja vikojen korjaaminen voi olla hyvin kallista Siksi on syytä esimerkiksi prototyyppien ja käytettävyystestien kautta varmistua jo projektin aikaisessa vaiheessa, että kehitettävä ohjelmisto tulee täyttämään käyttäjäryhmien tarpeet Yleisimpien käyttäjän tehtävien pitää onnistua helposti ja intuitiivisesti; harvemmin tarvittavien toimintojen käyttämiseen voidaan edellyttää käyttöoppaiden lukemista 19 March

40 Tuotannon/operoinnin hyväksyntätestaus Validoidaan ohjelmiston ominaisuudet ylläpidon (system administration) näkökulmasta Varmistukset Toipuminen vakavista häiriöistä (disaster recovery) Käyttäjien hallinta Turvaominaisuudet Jne March

41 Kenttätestaus Ohjelmistoa voidaan käyttää hyvin monenlaisissa ympäristöissä Kenttätesteillä (field test) tavoitteena on tunnistaa eri käyttöympäristöjen mukanaan tuomat vaikutukset, joita on vaikea ennakoida Tärkeää erityisesti COTS ohjelmille Valituille käyttäjille toimitetaan esiversioita ohjelmistosta, jotka antavat siitä palautetta toimittajalle Alpha-, Beta-testaus 19 March

42 Inkrementaalinen ohjelmistokehitys 19 March

43 Inkrementaalinen ohjelmistokehitys Inkrementaalisen kehityksen idea on tuottaa ohjelmisto sarjana pienempiä peräkkäisiä kehitysaskeleita sen sijaan, että ohjelmisto rakennetaan kerralla valmiiksi Jokainen kehitysaskel eli inkrementti lisää uutta toiminnallisuutta järjestelmään kasvattaen ohjelmistoa siivu siivulta Asiakkaalta mahdollista saada nopeasti palautetta, jonka perusteella voidaan tehdä muutoksia ja korjauksia ketterästi Ohjelmistolla on varhaisesta vaiheesta lähtien jonkinlainen perusrunko tai luuranko (skeleton), johon inkrementtien tuotokset integroidaan 19 March

44 Inkrementaalinen ohjelmistokehitys by Man vyi wikimedia.org 19 March

45 Inkrementaalinen ohjelmistokehitys Inkrementaalinen kehitysprosessi tekee mahdolliseksi asiakkaan osallistumisen jo varhaisessa vaiheessa toimintojen testaukseen Hyväksyntätestausta ja käytettävyystestausta voidaan tehdä koko kehitysprojektin ajan Kunkin iteraation (sprintin) alussa sovitaan toteutettavat piirteet (käyttäjätarinat) ja hyväksyntätestit, joilla toteutuksen toimivuus verifioidaan Asiakkaan osallistuminen testien suunnitteluun on tärkeää validointinäkökulman kannalta 19 March

46 Inkrementaalinen ohjelmistokehitys Muukin testaus on mukautettava jatkuvaan muutokseen Yksikkötestien läpimeno edellytys koodin viennille versionhallintaan Jatkuva integrointitestaus (frequent integration, continuous integration) Jatkuva regressiotestaus Testitapausten uudelleenkäytettävyys inkrementistä toiseen tärkeää (vaatii myös testien ylläpitoa) 19 March

47 Inkrementtien testaus 1. julkaisu 2. julkaisu 3. julkaisu 19 March

48 Ketterä testaaja ISTQB:n oppisisältö ketterän testaajan koetta varten: March

49 Ketterä testaaja Test automation pyramid March

50 Agile Testing Quadrants Crispin, L., Gregory, J.: Agile Testing - A Practical Guide for Testers and Agile Teams. Addison-Wesley, Figure March

51 Testityyppejä Test types 19 March

52 Testityyppejä On olemassa perustestityyppejä, joita voidaan käyttää useilla eri testaustasoilla Testin kohteena oleva ohjelmiston ominaisuus on testityypin määrittävä tekijä ei kehitysprojektin vaihe tai rakennetaso 19 March

53 Toiminnallinen testaus (functional testing) Toiminnallinen testaus verifioi ohjelmiston tuottamat tulokset ja käyttäytymisen ohjelmiston syötteillä (input-output behavior) Ohjelmistoa tarkastellaan mustana laatikkona (black box) eli tarkastellaan vain sen ulkoisesti havaittavaa käyttäytymistä, ei sen sisäistä tilaa Testien lähtökohtana ovat ohjelmiston toiminnalliset vaatimukset, jotka määritelevät mitä ohjelmisto tekee Tämä testaustyyppi sopii parhaiten järjestelmäja hyväksyntätestaukseen 19 March

54 Kirjattuihin vaatimuksiin perustuva t:nen testaus Jos toimintoja koskevat vaatimukset on kirjattu ylös, testitapaukset suunnitellaan niiden perusteella Jokaista vaatimusta kohden tehdään vähintään yksi testitapaus Usein vaatimukseen sisältyy (eksplisiittisesti tai implisiittisesti) useita mahdollisia tapoja tehdä vaadittu asia (ja poikkeustilanteita), joten testitapauksia tarvitaan yleensä useita 19 March

55 Kirjattuihin vaatimuksiin perustuva t:nen testaus Toiminnallisista vaatimuksista johdetaan usein käyttötapauksia (use case), jotka toimivat käyttöliittymä- ja myös ohjelmistosuunnittelun lähtökohtina Käyttötapaus kuvaa täydellisen vuorovaikutusjakson (skenaarion) ohjelmiston ja ulkoisen aktorin välillä siten, että jokin aktorin tavoite (syy ohjelmiston käytölle) tulee täytetyksi skenaarion aikana Käyttötapaukset ovat hyvä pohja testitapausten suunnittelulle 19 March

56 Liiketoimintaprosesseihin perustuva t:nen testaus Yksittäisiä käyttötapauksia laajempia kuvauksia ovat liiketoimintaprosessien (business process) ja -tapahtumien kuvaukset Liiketoimintatapahtuma kokoaa yhteen useita käyttötapauksia loogiseksi toimintojen ketjuksi, joka täyttää jonkin asiakkaan liiketoiminnan tavoitteen Tapahtuman testaus vaatii oman testiskenaarionsa 19 March

57 Liiketoimintaprosesseihin perustuva t:nen testaus Esim auton myynti liiketoimintatapahtuma koostuu käyttötapauksista 1. autotarjonnan selaus, 2. auton ja lisävarusteiden valinta, 3. [ rahoitustarjouksen pyyntö ], 4. [ vakuutustarjouksen pyyntö ], 5. hankintasopimuksen teko ja tallennus 6. auton ja lisävarusteiden tilauksen toimitus maahantuojalle 19 March

58 Laatuominaisuuksien testaus (non-functional testing) Laatuominaisuuksilla tarkoitetaan järjestelmän toimintaa tai sitä kokonaisuutena määrittäviä laatupiirteitä Laatumalli määrittelee joukon laatupiirteitä (characteristics, quality attributes) joiden suhteen laatua mitataan Esimerkiksi ISO/IEC laatumalli: Viisi laatupiirrettä käytön aikaisen laadun määrittelyyn Kahdeksan laatupiirrettä tuotelaadun määrittelyyn 15 laatupiirrettä datan laatua varten (ISO 25012) 19 March

59 Konkreettisia testauskohteita Käytös kuormituksen (load test) alla Suorituskyky tärkeissä käyttötapauksissa ja kuorman alla Suurten datamäärien käsittely (volume test) Ylikuormitustilanteet (stress test) Turvauhkien käsittely ja torjunta (security) Vakaus ja luotettavuus jatkuvassa käytössä (stability) Käytös virhetilanteissa (robustness) Yhteensopivuus, datamuunnokset (compatibility) Eri laitteisto- ja ohjelmistokonfiguraatiot Käytettävyys Dokumentointi 19 March

60 Laatuominaisuuksien testauksen haasteita Laatua koskevat vaatimukset ovat usein niin epämääräisesti muotoiltu, että konkreettisia testitapauksia ei voi määritellä Ohjelmiston pitää olla helppokäyttöinen Järjestelmän pitää olla nopea Myös laatuvaatimusten pitää olla ilmaistu testattavassa muodossa! 19 March

61 Laatuominaisuuksien testitapaukset?? Valitaan toiminnallisista testeistä skenaario, joka edustaa poikkileikkausta koko järjestelmän toiminnasta (esim. käyttöliittymästä tietokantapalvelimeen asti) Testattavan ei-toiminnallisen ominaisuuden tulee olla havainnoitavissa ja mitattavissa skenaarion suorituksen aikana Jos mittauksen tulos on sallituissa rajoissa tavoitearvoon verrattuna, testin tulos on pass ja muuten fail 19 March

62 Ohjelmiston rakenteen testaus Testitapausten suunnittelussa käytetään hyväksi tietoa ohjelmiston arkkitehtuurista ja sisäisistä tiloista (esim. mallien avulla) Tarkoitus on suunnitella ja ajaa riittävästi testitapauksia kaikkien rakenteiden testaamiseksi 19 March

63 Ohjelmiston muutosten testaus ja regressiotestaus Uudelleentestaus (retesting) muutosten jälkeen Toistetaan aikaisemmat testit sen osoittamiseksi, että korjatut viat ovat todella hävinneet Regressiotestaus muutosten jälkeen Tarkoituksena on osoittaa, että muutokset eivät ole aiheuttaneet uusia vikoja (tai vanhojen vikojen uusiutumista) ohjelmistoon regressio: palautuminen, taantuminen, takautuminen. Kielitoimiston sanakirja 19 March

64 Ohjelmiston muutosten testaus ja regressiotestaus Regressiotestaukseen valitut testitapaukset suoritetaan usein, joten ne on dokumentoitava hyvin Testit kannattaa mahdollisuuksien mukaan automatisoida 19 March

65 Regressiotestauksen laajuus Tärkeää on päättää regressiotestauksen laajuus Suoritetaan uudestaan kaikki testit, jotka löysivät jonkin nyt korjatuista vioista Testataan kokonaan uudelleen kaikki ne ohjelman osta joita on nyt muutettu Testataan kaikki vastikään integroidut ohjelmiston osat Testataan uudelleen koko ohjelmisto 19 March

66 Regressiotestauksen laajuus Ohjelmistomuutoksilla voi olla arvaamattomia sivuvaikutuksia myös niissä ohjelman osissa, joihin ei ole koskettu Osien välillä voi olla suuri määrä suoria ja epäsuoria riippuvuuksia niitä on helppo saada aikaan mutta työlästä poistaa Syynä usein huonosti suunniteltu tai muuten sopimaton arkkitehtuuri ja piittaamattomuus riippuvuuksia koskevista säännöistä Periaatteessa vain koko ohjelmiston täydellinen uudelleentestaus on riittävän laaja regression havaitsemiseen 19 March

67 Regressiotestauksen laajuus Käytännössä koko ohjelmiston uudelleentestaus on kuitenkin liian kallista ja hidasta On siis valittava huomattavasti suppeampi joukko testitapauksia, joitten suoritus tuottaa riittävän varmuuden regression poissaolosta On yritettävä päätellä, mihin ohjelmiston osiin sivuvaikutuksia voisi tulla On muutenkin pyrittävä rajoittamaan ajettavien testitapausten määrä minimiin 19 March

68 Regressiotestauksen laajuus Regressiotestitapausten valintakriteereitä Vain testisuunnitelman korkeimman prioriteetin testit ajetaan Toiminnallisten testien tietyt variantit voidaan jättää pois Rajoitetaan testaus vain tiettyihin tuotekonfiguraatioihin (vain yksi kieliversio ja yksi käyttöjärjestelmä) Testataan vain tietyt alijärjestelmät tai vain tietyt testitasot 19 March