3.5 Hyväksymistestaus

Transkriptio

1 3.5 Hyväksymistestaus Hyväksymistestauksen perusteella voidaan päätellä onko tuote sopimusten mukainen Mikäli kehitys on ulkoistettu, saatetaan hyväksymistestaussuunnitelma ja siihen liittyvät testitapaukset liittää jopa osaksi organisaatioiden välistä sopimusta Perustuu siis asiakkaiden vaatimuksiin V-mallia noudatettaessa ensimmäinen vaihe testien suunnittelussa, viimeinen vaihe testien suorituksessa Hyväksymistestaussuunnitelma täytyy pitää ajan tasalla Mikäli uusia ominaisuuksia tilataan kesken kaiken (kuten tavallista), tulee nekin hyväksymistestata Mika Katara: Ohjelmistojen testaus, Hyväksymistestauksessa testataan kokonaista valmista tuotetta Kannattaa käyttää testaajina tuotteen loppukäyttäjiä Testiympäristön pitäisi olla mahdollisimman lähellä todellista loppukäyttäjän ympäristöä Ajallisesti yleensä melko lyhyt vaihe koska tarkoituksena on vain osoittaa, että vaatimukset on tyydytetty Virheiden löytyminen ei pitäisi olla enää ensisijaisena tavoitteena Suurenkin järjestelmän hyväksymistestin pitäisi kestää korkeintaan viikkoja Muuten kyseessä voi olla hyväksymistestiksi kutsuttu järjestelmätesti (mikä ei sinällään haittaa, kunhan se tiedostetaan) tällöin ensisijainen tavoite on virheiden löytyminen Mika Katara: Ohjelmistojen testaus,

2 Hyväksymistestin pitäisi olla lähinnä demonstraatio Mikäli virheitä löydetään, niiden korjaaminen voi tulla hyvin kalliiksi Alihankinta voi muuttaa tilannetta, jos tarkoituksena on varmistaa sopimusehtojen täyttyminen Asiakas voi haluta lykätä hyväksymistestauksen päättymisen ajankohtaa esimerkiksi silloin kun siitä katsotaan takuun alkavan Mikäli käyttäjät pääsevät tutustumaan tuotteeseen vasta kun sen pitäisi olla valmis, suurella todennäköisyydellä virheitä valitettavasti löydetään Idealistisesti ajatellen käyttäjien pitäisi osallistua jossain muodossa kaikkiin ohjelmistoprosessin vaiheisiin Iteratiivinen kehitys siten, että näytetään asiakkaalle väliversioita, saadaan palautetta ja opitaan käsittämään vaatimuksia paremmin Mika Katara: Ohjelmistojen testaus, Koska suurten muutosten tekeminen projektin lopussa voi johtaa kaaokseen, pitää niitä harkita tarkkaan Muutostarpeiden priorisoinnin jälkeen voi olla järkevintä jättää virheen korjaaminen vasta seuraaviin versioihin Mikäli muutoksiin päätetään ryhtyä, pitäisi niihin liittyvät riskit kartoittaa uudelleen esim. sen arvioimiseksi pitäisikö jokin ominaisuus jättää tästä versiosta kokonaan pois tai sen testausta vähentää Mika Katara: Ohjelmistojen testaus,

3 Kaikki erot testiympäristön ja loppukäyttäjän ympäristön välillä ovat asioita, joita ei tule testattua Käytetäänkö todellisia tietokantoja yms. testattavaan järjestelmään liittyviä muita järjestelmiä vai simuloidaanko niitä jotenkin? Onko testidata generoitua vai todellista? Onko käyttäjän laitteistossa muita ohjelmia? Onko laitteiston konfiguraatio realistinen? Erilaisia loppukäyttäjän ympäristöjä voi olla vaikka kuinka paljon Profiilien luonti vastaamaan yleisimpiä ympäristöjä voi kannattaa Mika Katara: Ohjelmistojen testaus, Ideaalitapauksessa hyväksymistestaussuunnitelman kirjoittajat ovat loppukäyttäjiä tai heidän edustajiaan Käyttäjät ymmärtävät Vaatimuksia Omaan liiketoimintaansa liittyviä riskejä Käyttäjät voivat Toimittaa realistista testidataa Toimittaa käyttötapauksia Määritellä hyväksymistestin lopetusehdon Suorittaa testejä Tarkastaa ja katselmoida testiraportteja muita projektissa syntyneitä dokumentteja Mika Katara: Ohjelmistojen testaus,

4 Jokaista vaatimusta kohden pitäisi olla vähintään yksi testitapaus Yksi testitapaus voi kattaa useamman (laillisen) vaatimuksen Vaatimuskattavuusmatriisin käyttö, jos vastaavaa tietoa ei tuoteta automaattisesti testienhallintatyökalusta Vaikka jokainen vaatimus olisikin testattu, ei kaikkea silti ole testattu Itse asiassa yhtään vaatimusta ei ole testattu täydellisesti Ohjelmistolla on paljon sellaisia tiloja, joita ei ole käyty testeissä läpi Hyväksymisvaiheessa toteutustekniikkaan ei kiinnitetä yhtään huomiota Testitapauksia kannattaa priorisoida analysoimalla niitä vastaavien vaatimusten riskejä Mika Katara: Ohjelmistojen testaus, Alfa- ja Beta-testit Käyttäjät tekevät testit Alfa-testit käyttäjän toimesta toimittajan tiloissa mahdollisimman realistisessa ympäristössä Kehitys- tai testausympäristö ei kelpaa Beta-testit käyttäjän toimesta käyttäjän tiloissa ja ympäristössä Sekä alfa- että beta-testauksen tapauksessa täytyy muistaa, että ad hoc -tyyppinen testaus (kokeileminen) ei korvaa järjestelmällistä testausta käyttäen suunniteltua testistrategiaa ja testitapauksia Keskeneräisen ohjelmiston jakelu valikoiduille käyttäjille ei siis yksinään riitä Kokeilukin voi joissain tapauksissa olla paikallaan, mutta vasta sitten kun järjestelmä on hyväksymistestattu järjestelmällisesti Mika Katara: Ohjelmistojen testaus,

5 Ekskursio: Riskianalyysi Riskianalyysiä tehdään Tiedostamatta: jos jätän tenttiin luvun viimeiseen iltaan, millä todennäköisyydellä reputan ja mitä seurauksia siitä on? Tiedostaen: mikäli organisaation avainhenkilöiden täytyy matkustaa samana päivänä samaan kohteeseen, kannattaako heidät laittaa samalle lennolle? Valitettavasti kaikista mahdollisista testeistä voidaan dokumentoida ja ajaa vain pieni osa Riskianalyysiä käyttämällä voidaan yrittää valita mahdollisimman hyödylliset testit Riskianalyysin tuloksilla voidaan myös vakuuttaa projektin johto siitä, että asiat pitää tehdä tietyllä tavalla Mika Katara: Ohjelmistojen testaus, Riskianalyysiprosessin kulku (mukailtu [Craig&Jaskiel 02]): Aivoriihen kokoaminen Listaa järjestelmän ominaisuudet ja attribuutit Arvioi häiriön todennäköisyys Arvioi häiriön vaikutus käyttäjiin Päätä mikä on alin testattava prioriteetti Järjestä ominaisuudet ja attribuutit Arvioi tuloksia ja muuta tarvittaessa Laske riskiprioriteetti Mieti kuinka riskejä voitaisiin pienentää Mika Katara: Ohjelmistojen testaus,

6 Riskianalyysi pitäisi tehdä mahdollisimman aikaisessa vaiheessa projektia Aivoriihen (brainstorming team) kokoaminen: mukana esim. käyttäjiä, kehittäjiä, testaajia sekä henkilöitä markkinoinnista, asiakaspalvelusta sekä teknisestä tuesta Tavoitteena mahdollisimman laaja tietämys tuotteesta ja toimialasta Mika Katara: Ohjelmistojen testaus, Järjestelmän ominaisuuksien ja attribuuttien listaaminen: lähteinä kaikki saavilla oleva dokumentaatio Aloitetaan korkealta abstraktiotasolta, keskitytään yksityiskohtiin myöhemmin Analyysi voi kohdistua osajärjestelmään kunhan tarvittavat rajapinnat otetaan huomioon Tyypillisiä attribuutteja: toiminnallisuus, luotettavuus, yhteensopivuus, käytettävyys, ylläpidettävyys, suorituskyky, skaalautuvuus, turvallisuus Mika Katara: Ohjelmistojen testaus,

7 Häiriön todennäköisyyden arviointi: käydään edellisen kohdan lista läpi ja jokaisen ominaisuuden ja attribuutin kohdalla arvioidaan häiriön todennäköisyys Suhteellinen eikä absoluuttinen arviointi Asteikko esim. 1-3 (low, medium, high) Tässä vaiheessa tärkeintä on saada jotain paperille, ei täydellinen yksimielisyys lopputuloksesta arvoja voi muuttaa vielä myöhemmin Esim. mikäli tiimi T toteuttaa ominaisuuden O ympäristössä Y, millä todennäköisyydellä ilmenee häiriö Mika Katara: Ohjelmistojen testaus, Häiriön vaikutuksen arviointi: käydään jälleen lista läpi ja arvioidaan häiriön vaikutusta käyttäjään Asteikko esim. sama kuin edellisessä vaiheessa Näkökulma käyttäjän, ei arvioida esim. sitä kuinka häiriö voisi vaikuttaa projektiin, työmääriin tms. Joskus käyttäjät haluaisivat korkeimman mahdollisen arvon kaikkiin kohtiin voidaan rajoittaa sitä, kuinka monta kappaletta kutakin arvoa käyttäjät voivat ehdottaa Mika Katara: Ohjelmistojen testaus,

8 Riskiprioriteetin laskeminen: lasketaan yhteen kahdessa edellisessä vaiheessa saadut arvot Tuloksena viisiportainen riskiprioriteetti asteikolla 2-6 Yhteenlaskun sijaan voidaan arvot myös kertoa keskenään mikäli arvoasteikossa on ollut mukana nolla, tämän vaikutus täytyy luonnollisesti ottaa huomioon laskuoperaatiota valittaessa Ongelmia: koska sekä vaikutuksen että todennäköisyyden arvot ovat täysin subjektiivisia, eivät aritmeettiset operaatiot ole periaatteessa sallittuja epälineaarisuus Riskiprioriteetin arvot ovat siis vain suuntaa antavia Mika Katara: Ohjelmistojen testaus, Tulosten arviointi ja muuttaminen tarvittaessa: aivoriihessä syntyneitä todennäköisyyksiä voidaan tässä vaiheessa arvioida uudelleen laajemman tiedon valossa Esim. mikäli tiedetään, että ominaisuuden toteuttaa kokematon kehitystiimi, voidaan häiriön todennäköisyyttä sen osalta nostaa Muutokset voivat perustua myös esim. jonkin mutkikkuusmittarin tuottamaan arvoon Mika Katara: Ohjelmistojen testaus,

9 Ominaisuuksien ja attribuuttien järjestäminen: järjestetään lista uudelleen riskiprioriteetin mukaiseen järjestykseen Järjestetty lista auttaa keskittämään resursseja sinne missä niitä tarvitaan Testitapausten välisiä riippuvuuksia ei vielä tässä vaiheessa kannata ottaa huomioon käytännössä ne voivat sanella sen, että matalamman prioriteetin ominaisuus on testattava ennen korkeamman prioriteetin ominaisuutta Mika Katara: Ohjelmistojen testaus, Alimman testattavan prioriteetin määrittäminen: pienemmän riskin omaavia ominaisuuksia/attribuutteja ei testata ollenkaan tai testataan kevyemmin Rajan vetoon vaikuttavat luonnollisesti käytettävissä olevat resurssit Projektin edetessä rajaa voidaan liikuttaa ylös- tai alaspäin Mika Katara: Ohjelmistojen testaus,

10 Todennäköisyyksien pienentämisen pohtiminen: lopuksi yritetään keksiä keinoja riskien pienentämiseksi pienentämällä häiriöiden todennäköisyyksiä Keskitytään tyypillisesti korkea prioriteetin ominaisuuksiin ja attribuutteihin Keinoja voivat olla vaikkapa tarkastus- ja katselmointitekniikoiden käyttö, prototyypin kehittäminen, tehokkaamman testaustekniikan käyttöönotto jne. Mika Katara: Ohjelmistojen testaus, Niin kuin muitakin dokumentteja, myös riskianalyysin tuloksia täytyy pitää yllä Esim. vaatimusten muuttuessa Kun ryhdytään tekemään järjestelmän uutta versiota, voidaan yleensä edellisen riskianalyysin tuloksia hyödyntää Muutettavien osien kohdalta riskit yleensä kasvavat Yleensä häiriöiden todennäköisyydet muuttuvat ennemmin kuin niiden vaikutukset Mika Katara: Ohjelmistojen testaus,

11 Harjoitus: riskianalyysi IDLE Ominaisuus Attribuutti Todennäköisyys Vaikutus Prioriteetti Todennäköisyyden alentaminen Kurssi-ilmoittautuminen Harj. ilmoittautuminen Tehtävien tekeminen Harj.työn palautus luotettavuus käytettävyys Mika Katara: Ohjelmistojen testaus, Toinen priorisointiasteikko liittyy ns. MoSCoW-menetelmään, joka määrittelee seuraavat neljä prioriteettia (alenevassa tärkeysjärjestyksessä): Must test Should test Could test Won t test Ks. Successful Test Management: An Integral Approach, Iris Pinkster & Bob van de Burgt & Dennis Janssen & Erik van Veenendaal, Springer, Mika Katara: Ohjelmistojen testaus,

12 Esimerkki MoSCoW-arvioinnista Ihmisiä kuolee Kaikki asiakkaat kärsivät Yksi asiakkaista kärsii Must test Must test Jos tämä vaatimus ei toteudu Asiakkaat menettävät rahaa Me menetämme rahaa Kaikki asiakkaat kärsivät Yksi asiakkaista kärsii Ei kiertotietä Kiertotie on olemassa Must test Should test Should test Could test Kukaan ei menetä rahaa Ei kiertotietä Kiertotie on olemassa Could test Won t test Mika Katara: Ohjelmistojen testaus, Edistymisen seuranta, eräs esimerkki toimitus testatut vaatimukset Could test Should test arvio toteutunut Must test aika Mika Katara: Ohjelmistojen testaus,

13 Joissain projekteissa voidaan tarvita vielä hienojakoisempaa priorisointia Testijoukot kootaan testitapauksista, jotka perivät testijoukon MoSCoW-prioriteetin testijoukko voi vastata esim. yhden vaatimuksen testejä Testijoukon sisällä, testitapaukset priorisoidaan vielä asteikolla High, Medium ja Low Nyt voidaan tehdä päätös, että esimerkiksi Should test prioriteetin omaavasta joukosta ajetaan vain High-prioriteetin omaavat testit Huom! Eri joukkoihin kuuluvien testien prioriteetit eivät välttämättä enää ole vertailukelpoisia keskenään onko Should test Low tärkeämpi testitapaus kuin Could test High? Mika Katara: Ohjelmistojen testaus, Testikohteen riskien ja vaatimusten yhteensovittaminen: Jos on olemassa riski, mutta ei sitä vastaavaa vaatimusta, pitää miettiä onko riski turha vai pitääkö sitä vastaava vaatimus lisätä Jos on olemassa vaatimus, mutta ei siihen liittyvää riskiä, voidaan riski joko lisätä tai sitten vaatimus poistaa turhana Riskianalyysi voi siis parantaa myös vaatimusmäärittelyn laatua Analyysiä voidaan käyttää myös taloudelliselta näkökantilta katsottuna Ei arvioidakaan suoraan häiriöiden vaikutusta käyttäjiin, vaan pikemminkin ohjelmiston tuottamaan rahamäärään Esim. mikäli jokin ominaisuus on äärimmäisen tärkeä jollekin hyvin maksavalle asiakkaalle, voidaan tämä ottaa huomioon häiriön vaikutusta arvioitaessa Mika Katara: Ohjelmistojen testaus,

14 3.6 Tarvitaanko kaikkia testausvaiheita? Testauksen järjestelmällisellä vaiheistamisella on selviä etuja suunnittelemattomaan lähestymistapaan verrattuna Varsinkin pienissä projekteissa kaikkien em. testausvaiheiden läpikäyminen voi kuitenkin aiheuttaa ylimääräistä työtä Testauksen vaiheistamista suunniteltaessa kannattaa ottaa huomioon ainakin Kehitettävän järjestelmän monimutkaisuus Projektin budjetti Testausorganisaatio Mika Katara: Ohjelmistojen testaus, Tärkeintä ei ole vaiheiden määrän maksimointi vaan oikeiden vaiheiden valinta kutakin projektia varten Huom! Samaa vaihetta voidaan kutsua eri nimillä Yksikkötestausta voi olla paitsi moduulitestaus myös komponenttitestaus, kehittäjätestaus, säietestaus jne. ei kannata antaa termien hämätä Mika Katara: Ohjelmistojen testaus,

15 Integrointitestauksen yhteydessä pohdittiin sen suhdetta yksikkötestaukseen: oma vaihe vai osa yksikkötestausta Entä voitaisiinko järjestelmätesti yhdistää integrointitestiin? Craig ja Jaskiel [Craig&Jaskiel 02] listaavat ominaisuuksia, jotka ovat yhteisiä heidän asiakasorganisaatioillensa, joissa näiden vaiheiden yhdistäminen on onnistunut: hyvä tuotteenhallinta suhteellisen paljon automatisoituja testejä kanssakäyminen kehittäjien ja testaajien välillä toimii hyvin Mika Katara: Ohjelmistojen testaus, Strategia järjestelmä- ja integrointitestauksen yhdistämiseen [Craig&Jaskiel 02]: Testausryhmä testaa jokaisen huomattavasti edellistä isomman buildin viimeisestä integrointitestin tasosta, missä kaikki yksiköt ovat mukana, tulee järjestelmätesti verrattuna siihen, että kehittäjät vastaisivat integrointitestauksesta, lähestymistapa valitettavasti siirtää kehittäjille kuuluvaa vastuuta oman koodinsa laadusta testaajille Mika Katara: Ohjelmistojen testaus,

16 Entä hyväksymistestin yhdistäminen järjestelmätestiin? Voi olla perusteltua tilanteissa, joissa loppukäyttäjät osallistuvat järjestelmätestaukseen Testejä pitäisi silloin ajaa myös loppukäyttäjän ympäristöä mahdollisimman paljon muistuttavassa ympäristössä Mika Katara: Ohjelmistojen testaus, Milloin siirtyä vaiheesta toiseen? Kaksi oleellista kysymystä testausta vaiheistettaessa Miten vaiheet liittyvät toisiinsa? selkeät rajat auttavat siirtymisessä vaiheesta seuraavaan Mistä tiedetään koska siirrytään vaiheesta seuraavaan? selkeät aloitus- ja lopetusehdot Eri testausvaiheiden ei tule olla päällekkäisiä, eikä niiden välillä saa olla suuria aukkoja Motivaatio päällekkäisyyteen usein elinkaaren nopeuttaminen Mika Katara: Ohjelmistojen testaus,

17 Päällekkäisyyden haittoja Aiemmin löydettyjä (ja korjattuja) virheitä voidaan löytää uudestaan yksikkö ja integrointivaiheissa löydetyt virheet ovat paljon halvempia korjata kuin myöhemmissä vaiheissa löydetyt kun testaus siirtyy kehittäjiltä erillisen testaustiimin harteille, virheiden hinta kasvaa Haaste virheidenhallinnalle Konfiguraationhallinta monimutkaistuu Mika Katara: Ohjelmistojen testaus, Hyvin määritellyt ja tunnollisesti noudatetut aloitus- ja lopetusehdot eri testausvaiheille luovat yhteiset pelisäännöt projektin etenemiselle Jotkin aloitus- ja lopetusehdoista riippuvat projektista, toiset voivat olla standardeja organisaation sisällä Edellisen vaiheen tekijät ovat kiinnostuneita seuraavasta koska heidän panoksensa vaikuttaa paitsi oman vaiheen lopetusehdon myös seuraavan vaiheen aloitusehdon saavuttamiseen Mika Katara: Ohjelmistojen testaus,

18 Esimerkki integrointitestin lopetusehdosta: Kaikki yksikkö- ja integrointitestit ja niiden tulokset on dokumentoitu Kaikki löydetyt vakavat virheet on korjattu ja regressiotestit ajettu Virheiden löytymistiheys on laskenut sovitun rajan alle (esim. viisi korkeintaan medium-tason virhettä viimeisen kolmen päivän aikana) Riittävä lausekattavuus on saavutettu (esim. 90%) Testit ovat kattaneet ohjelman spesifikaatiot riittävästi Koodin tarkastuksen tulokset on dokumentoitu ja ne ovat hyväksyttävissä Mika Katara: Ohjelmistojen testaus, Vaiheen aloitusehdon tulisi sisältää ainakin osa edellisen vaiheen lopetusehdoista Lisäksi siihen voidaan sisällyttää ehtoja koskien myös esim. testiympäristön luomista, testityökaluja ja jopa testaustyövoiman hankkimista Mikäli on vaarana, että aletaan testata versiota, jota ei käytännössä vielä voi testata, kannattaa aloitusehtoihin kirjata myös vaatimus savutestin läpäisemisestä Hyväksymistestauksen lopetusehto on erityisen tärkeä, koska se on samalla koko testauksen lopetusehto Mika Katara: Ohjelmistojen testaus,

19 Esim. hyväksymistestauksen lopetusehdosta (mukailtu [Craig&Jaskiel 02]): Medium tai sen vakavampia virheitä ei saa olla Missään ominaisuudessa ei saa olla kahta virhettä enempää eikä kaiken kaikkiaan yli 50 virhettä Vähintään yksi testitapaus jokaista vaatimusta kohden täytyy läpäistä Testitapaukset TT23, TT25 ja TT38-52 täytyy läpäistä Kahdeksan kymmenestä kokeneesta pankkivirkailijasta pystyy avaamaan tilin korkeintaan kymmenessä minuutissa käyttäen on-line ohjeita Järjestelmä pystyy avaamaan 1000 tiliä tunnissa Mika Katara: Ohjelmistojen testaus, Ruudusta toiseen siirtyminen kestää keskimäärin korkeintaan sekunnin kun järjestelmää käyttää 100 käyttäjää Käyttäjien täytyy hyväksyä allekirjoituksellaan testien tulokset Mika Katara: Ohjelmistojen testaus,

20 3.8 Dokumentoinnista Kuten ohjelmistotuotannossa yleensä, dokumentoinnilla on merkittävä osuus testauksessa Dokumentteja syntyy paljon Niiden kirjoittamiseen kuluu huomattavan paljon aikaa Dokumenttien ja varsinaisten testien synkronointi voi muodostua ongelmaksi Dokumentoinnin tarkoituksena on saada tieto suunnittelijoiden/testaajien korvien välistä muotoon, jota muutkin voivat käyttää Kun asiat kirjataan ylös, huomataan yleensä puutteita ja väärinkäsityksiä Dilemma: miten dokumentoida kaikki tarpeelliset asiat, mutta ei mitään turhaa Mika Katara: Ohjelmistojen testaus, Testauksen suunnittelun tavoitteena on tehdä testien ajaminen ja niistä raportointi mahdollisimman helpoiksi Projektisuunnitelma: mitä dokumentteja tuotetaan kuka tuottaa milloin Testauksen yleissuunnitelmasta (päätestaussuunnitelma) saattaa olla hyötyä ainakin isoissa projekteissa: Testien aikataulut Testausvaiheiden aloitus- ja lopetusehdot Kuka vastaa ja mistä (mm. testiympäristöjen pystyttäminen jne.) Mika Katara: Ohjelmistojen testaus,

21 Testauksen suunnittelu [Haikala&Märijärvi 06]: Functional specification Experiences, check lists Quality system code of practice Design specification Previous test documentation Test planning & design Test plan & design Test execution Test reports Mika Katara: Ohjelmistojen testaus, Koska hyväksymistestaussuunnitelmaa lukevat käyttäjät, pitää sen ymmärrettävyyteen kiinnittää erityistä huomiota Ideaalitapauksessa käyttäjät kirjoittavat sen itse, jos asiantuntemus riittää Tarvittavat lähteet: projektisuunnitelma, joka piirtää kokonaiskuvan projektin kulusta päätestaussuunnitelma vaatimukset, joiden perusteella testit suunnitellaan myös käyttöohje on hyödyllinen, mikä se vain on saatavilla Mika Katara: Ohjelmistojen testaus,

22 Järjestelmätestaussuunnitelma voidaan sisällyttää määrittelydokumenttiin Integrointitestaussuunnitelma voidaan sisällyttää suunnitteludokumenttiin Kunkin moduulin suunnittelun yhteyteen voidaan liittää sitä vastaavan testiympäristön ja testitapausten määrittely Mika Katara: Ohjelmistojen testaus, Kun testejä suunnitellaan yksityiskohtaisesti, saattaa päätestaussuunnitelmaan kohdistua muutostarpeita Päivittämisestä täytyy luonnollisesti huolehtia Ajastaan jälkeen jäänyt dokumentaatio on usein enemmän haitaksi kuin hyödyksi Mika Katara: Ohjelmistojen testaus,

23 Joskus dokumentoinnilla saattaa olla myös kirjoittamattomia tarkoitusperiä Projektin tukeminen? Prosessin tai laatujärjestelmän noudattaminen? Jos on, miksi niitä ei kirjata ylös? Hyvä dokumentointi auttaa keskittymään oikeisiin asioihin kun se mitä tai miten ollaan testaamassa muuttuu Testityökalut saattavat auttaa dokumentoinnissa Tietyntyyppisten dokumenttien (osittainen) generointi Mika Katara: Ohjelmistojen testaus, Kuten testauksen vaiheistaminenkin, dokumentointi pitää suunnitella projektin koon ja testattavan järjestelmän perusteella Jos kyseessä on pieni projekti, riittää yleensä yksi testaussuunnitelma, joka kattaa sekä integrointi- että järjestelmätestauksen Suunnitelma tehdään määrittelyvaiheessa ja sitä täydennetään järjestelmää suunniteltaessa Esimerkkirunko I [Haikala&Märijärvi 06]: 1. Johdanto. 2. Testauksen kohde ja tavoitteet. 3. Testausympäristö. 4. Testauksen organisointi ja raportointi. 5. Testausstrategia ja integrointisuunnitelma. 6. Testattavat toiminnot. 7. Toimintojen testitapaukset, hyväksymiskriteerit. 8. Ei-toiminnallisten ominaisuuksien testaus. 9. Erikoistilanteet. 10. Ominaisuudet, joita ei testata. Mika Katara: Ohjelmistojen testaus,

24 Esimerkkirunko II: Johdanto Tarkoitus ja kattavuus Tuote ja ympäristö Määritelmät, termit ja lyhenteet Viitteet Yleiskatsaus dokumenttiin Testimäärittely Testattavat vaatimukset Lähestymistavan tarkennus Testitapausten nimeäminen Hylkäys- ja hyväksymiskriteerit Testitapausten väliset riippuvuudet Testitapausten määrittely Määrittelystä/suunnittelusta löytyneet virheet Mika Katara: Ohjelmistojen testaus, Esimerkkirunkojen I ja II suurin ero on siinä, että II on yksittäisen vaiheen testaussuunnitelma ja olettaa erillisen päätestaussuunnitelman (Master Test Plan) olemassaolon: Yksikkötestaussuunnitelma Integrointitestaussuunnitelma Päätestaussuunnitelma Järjestelmätestaussuunnitelma Mika Katara: Ohjelmistojen testaus,

25 Testausraportti: Johdanto Ristiriidat ja poikkeamat Kattavuustarkastelu Tulokset Arviointi Toiminta Hyväksyminen Mika Katara: Ohjelmistojen testaus, IEEE Std (uusi versio 2008) IEEE (Institute of Electrical and Electronics Engineers) Standard for Software Test Documentation Määrittelee seuraavat dokumenttipohjat Toimintasuunnitelmien laatimiseen Test Plan: päätestaussuunnitelma, eri vaiheiden toimintasuunnitelmat Testauksen suunnitteluun Test Design Specification: eri vaiheiden testaussuunnitelmat, testitapausten riippuvuudet, kattavuustavoitteet yms. Test Case Specification: käytetään tarvittaessa määrittelemään testitapauksia ja testiautomaation skriptejä Mika Katara: Ohjelmistojen testaus,

26 Test Procedure Specification: kuvaa kuinka joukko testitapauksia suoritetaan Raportointiin Test Item Transmittal Report: käytetään tarvittaessa raportoimaan järjestelmän (tai sen osan) siirtymisestä testaukseen, esim. kehittäjiltä erilliselle testaustiimille Test Log: käytetään tarvittaessa dokumentoimaan testitapausten (ja niiden muodostamien joukkojen) suorituksia Test Incident Report: testauksessa havaittujen häiriöiden raportointi, häiriöt voi liittyä virheeseen missä tahansa, myös testitapauksen määrittelyssä Test Summary Report: raportoi testauksen päättymisestä joko yksittäisen vaiheen tai sen sisällä jonkin muun merkittävän tavoitteen saavuttamisen osalta Mika Katara: Ohjelmistojen testaus, Seuranta Kun testitapaukset suoritetaan, raportoidaan tuloksista testiraporteissa Asiakasreklamaatiot täytyy luonnollisesti dokumentoida huolellisesti Laatujärjestelmän kehittämiseksi virheet analysoidaan ja tilastoidaan Virheen löytymis-, syntymis- ja korjausajankohdat Testauksen kattavuusmitat Virheiden luokittelu (esim. mild, moderate, serious, catastrophic) liian monta tasoa hankaloittaa luokittelua Testipäiväkirjan pitämisestä saattaa myös olla hyötyä Mika Katara: Ohjelmistojen testaus,

27 4. Dynaamisen testauksen tekniikat Perinteisessä mielessä testaaminen on testitapausten ajamista. Tässä kohdassa esitellään dynaamiseen testaukseen liittyviä tekniikoita. Mika Katara: Ohjelmistojen testaus, Erilaisia tekniikoita on kehitetty valtava määrä Käytettävä tekniikka täytyy valita tapauskohtaisesti Yleisesti ottaen testauksessa on hyvin hankala löytää Best Practise -tyyppisiä toimintatapoja Sopivan tekniikan valintaan kussakin tilanteessa voidaan antaa kuitenkin joitain nyrkkisääntöjä Tekniikat voidaan myös luokitella usealla eri tavalla Mika Katara: Ohjelmistojen testaus,

28 Käytettiinpä mitä dynaamista tekniikkaa tahansa, seuraaviin kuuteen kysymykseen tarvitaan yleensä vastaukset: Hyödynnetäänkö testattavan ohjelman koodia vai ei? Kuka testaa? Mitä ohjelman osaa testataan? Minkä tyyppisiä ongelmia etsitään? Mitä pitää tehdä? Mistä tiedetään onnistuiko testiajo vai ei? Mika Katara: Ohjelmistojen testaus, Seuraava luokittelu jakaa tekniikat sen perusteella mihin em. kysymykseen ne pääsääntöisesti yrittävät vastata Luokittelu ja kuvaukset perustuu suurelta osin lähteeseen [Kaner et al. 02] Eri tekniikoita pitää sopivasti yhdistellä aina tarpeen mukaan Tekniikat muodostavat eräänlaisen työkalupakin Ruuvimeisselillä ja vasaralla pääsee jo pitkälle, mutta joskus tarvitaan sahaakin Mika Katara: Ohjelmistojen testaus,

29 4.1 Tekniikat Hyödynnetäänkö ohjelman koodia vai ei? Lasilaatikkotestauksessa testitapaukset valitaan järjestelmän toteutukseen, kuten lähdekoodiin, tutustumalla (glass/white/clear box testing) Lasilaatikkotestaus ei pysty havaitsemaan sellaisia käyttäytymisiä, jotka on spesifioitu, mutta joita ei ole toteutettu kalvon 20 kuvassa tämä tarkoittaisi sitä, että testitapauksia kuvaavien käyttäytymisen ympyrä on kokonaan ohjelman toteutettua käyttäytymistä kuvaavan ympyrän sisällä Mika Katara: Ohjelmistojen testaus, Mustalaatikkotestauksessa testattava ohjelma nähdään mustana laatikkona eli sen toteutuksesta ei välitetä (black box testing) Kun testattavan yksikön koko kasvaa, siirrytään lasilaatikkotestauksesta mustalaatikkotestaukseen yksikkötestaus usein lasilaatikkotestausta, järjestelmätestaus mustalaatikkotestausta toisaalta, mikäli halutaan saavuttaa tietty koodikattavuus, ajetaan ensin mustalaatikkotestit ja sen jälkeen kehitetään uusia testitapauksia lasilaatikkomenetelmällä ja ajetaan niitä, kunnes tavoite on saavutettu Mika Katara: Ohjelmistojen testaus,

30 Testitapaukset valitaan spesifikaation eikä toteutuksen perusteella Testit voidaan suunnitella vaikka toteutusta ei vielä olisikaan Testitapaukset säilyttävät käyttökelpoisuutensa myös toteutuksen muuttuessa, jos spesifikaatio säilyy samana Menetelmän haittoja testitapaukset saattavat olla keskenään redundantteja osia ohjelmasta jää helposti testaamatta Mika Katara: Ohjelmistojen testaus, Mustalaatikkotestaus ei pysty havaitsemaan sellaisia ohjelman käyttäytymisiä, jotka on toteutettu, mutta joita ei ole spesifioitu Kalvon 20 kuvassa tämä tarkoittaisi sitä, että testitapauksia kuvaavien käyttäytymisen ympyrä on kokonaan spesifioitua käyttäytymistä kuvaavan ympyrän sisällä Menetelmä toimii myös muulle kuin ajettavalle ohjelmalle, eli ideat yleistyvät Yleensä halvempaa kuin lasilaatikkotestaus, joka vaatii koodiin tutustumista Mika Katara: Ohjelmistojen testaus,

31 Tekniikat täydentävät toisiaan: siinä missä lasilaatikkotestit löytävät matalan tason virheitä, mustalaatikkotestit löytävät korkeamman tason virheitä Spesifikaatiot korkeammalla abstraktiotasolla kuin toteutus, jossa metsä hukkuu helposti puiden sekaan Mikäli testauksessa käytetään hyväksi tietoa ohjelman toteutusperiaatteista, mutta ei tehdä puhdasta lasi- tai mustalaatikkotestausta, voidaan tätä kutsua harmaalaatikkotestaukseksi Mika Katara: Ohjelmistojen testaus,