Testitapaukset ja testien suorittaminen Maaret Pyhjrvi ja Erkki

Testitapaukset ja testien suorittaminen Maaret Pyhäjärvi ja Erkki Pöyhönen Julkaisuversio 1. 0 2005 -01 -23 tekijä mainittava http: //creativecommons. org/licenses/by/1. 0/fi/ Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Tiedoksi lukijalle • Tämä materiaali on edelleen työn alla – Varsinainen julkaisu tapahtuu testauskirjan julkaisun yhteydessä tai jälkeen • Materiaalin hyödyntäminen on vapaata – Erityisesti haluamme tukea yleishyödyllisen ohjelmistotestauksen opetuksen jäsentymistä tarjoamalla materiaalimme vapaasti muokattavaksi pohjamateriaaliksi • Uskomme että kirjallinen materiaali on noin 20 % vastaavasta koulutuksesta puhuttuna – Lisää materiaalia löytyy pään sisältä • Kysyttävää? – Ota yhteyttä maaret. pyhajarvi@iki. fi ja erkki. poyhonen@nokia. com Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

5 – Testitapaukset ja testien suorittaminen Tehokas ohjelmistotestaus Testaustekniikat Testaus ohjelmistokehityksen osana Testauksen suunnittelu ja hallinta Virheraportointi ja virheasian ajaminen Testausvälineet ja testauksen automatisointi Katselmoinnit testaustoimintana Testausprosessin muuttaminen Testitapaukset ja testien suorittaminen Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Oppimistavoitteet • Tiedät mikä on testitapaus ja mistä osista se koostuu • Ymmärrät hyvän testitapauksen suhteen onnistuneeseen testaukseen • Ymmärrät testitapauksen suhteen testattavan järjestelmän versioon ja kokoonpanoon, ajoympäristöön sekä testauksen ajankohtaan suhteessa ohjelmiston rakentamiseen • Tunnet testien suorittamiseen liittyvät käytännöt Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

5 – Testitapaukset ja testien suorittaminen Käsiteltävät asiat Testitapaukset testauksen ohjaajana Testitapausten suunnittelu ja dokumentointi Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

5 – Testitapaukset ja testien suorittaminen Käsiteltävät asiat Testitapaukset testauksen ohjaajana Testitapausten suunnittelu ja dokumentointi Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testauksen suunnittelu Testauksen missio ja korkean tason tavoitteet • • • Testausstrategia • • Yleistestaussuunnitelma • Järjestelmä / tuote / palvelukohtainen Useita projekteja saman järjestelmän elinkaaressa Projektikohtainen Projektin lähestymistapa, strategian räätälöinti • Tarkentavat suunnitelmat ryhmittäin • Testattavien asioiden yksityiskohdat Testaussuunnitelma Testitapaukset Organisaation odotukset testaustoiminnalle Laatupainotukset sovellusalueella Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Harjoitus: Testitapauskatselmointi • Mikä on testitapauksen käyttäjäryhmä? Luonnehdi. • Millaisia virheitä testitapauksella voi löytää? • Mitä oletuksia testitapauksen laatija on tehnyt? • Mistä testitapauksen käytön kustannus muodostuu? • Kuinka tärkeä tämä yksittäinen testi olisi? Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapaus katselmoitavaksi 1. 2. 3. 4. 5. 6. 7. 8. 9. Avaa asiakkaan ”Tiina Testaaja” tiedot, tunniste #1234 Varmista että asiakkaalla on tilaus odottamassa, tunniste #4567, joka on valmis toimitukseen Varmista että luottovahvistuspyyntö on tehty tälle asiakkaalle Varmista että luottovahvistuspyyntö on hylätty koodilla #4321 Varmista että asiakas ei ole maksanut tilausta kokonaisuutena etukäteen Varmista että asiakkaalla ei ole aiempia jo maksettuja rahoja sisällä joka riittäisi kattamaan tämän tilauksen Yritä vapauttaa tämä tilaus toimitukseen Varmista että järjestelmä ei vapauta tilausta ja toimita tilauksen mukaisia tavaroita, vaan antaa varoituksen: ”Luottoa asiakkaalle Tiina Testaaja, tunniste #1234 ei ole vahvistettu. Ei voida toimittaa tilausta #4567. Luottovahvistuspyyntö hylätty koodilla #4321. ” Varmista että tilaus odottaa edelleen eikä ole lähtenyt varoituksesta huolimatta. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Mikä on testitapaus? • Testitapaus käyttää yhtä tiettyä tilannetta tai ehtoa testattavassa järjestelmässä. • Testitapaus kuvaa mitä testata ja miten, ja ohjaa testaajaa (tai testausvälinettä) joka suorittaa testauksen. • Tämä ohjaus sisältää ohjeita testin alustamiseen ja suorittamiseen, sekä siihen mitä käyttäytymisiä tarkkailla ja kuinka arvioida lopputulos. Valitettavasti todellisuudessa ei näin suoraviivaista – monia tarpeellisia ilmenemismuotoja. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Esimerkkejä testitapauksista TKK: n testauskurssilta 2001 Testitapaus 1: Tarkista dialogi-ikkunan “Tabs” otsikko. 1. Käynnistä Word. Pad juuri luomastasi “TempTest. This”-hakemistosta. 2. Valitse “Format”-menusta kohta “Tabs”. Odota dialogi-ikkunan otsikon olevan: “Tabs”. Testitapaus 2: Tarkista “Find Next”-painikkeen käytettävissä oleminen “Find”-dialogissa. 1. Käynnistä Word. Pad. 2. Kirjoita jotain Word. Pad: lla. 3. Valitse “Edit”-menusta kohta “Find”. 4. Kirjoita jotain “Find what”-kenttään. Odota “Find Next”-painikkeen olevan harmaannettu siihen asti kunnes olet kirjoittanut jotain etsintä-kenttään. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Aiheellista palautetta • ”Kiva kuulla että teette nämä järkevästi eikä niin kuin TKK: n testauskurssilla opetettiin” – ulkopuolinen toimija eräässä vetämässäni testausprojektissa vuonna 2003 • Mikä on näiden toimintatapojen (uusi ja vanha) oleellinen ero? – Tulkinta ”testitapauksen” tasosta erilaisissa tilanteissa – Dokumentoinnin erilainen painottuminen Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Erilaisia määritelmiä testitapaukselle • Toimintatapa keskeisenä asiana – ”Syötteiden, suoritusehtojen ja odotettujen tulosten joukko, joka on luotu tiettyä tavoitetta varten, kuten suorittamaan tiettyä ohjelman polkua tai varmistamaan vastaavuus tiettyyn vaatimukseen” (IEEE Std 610 -1990) – ”Dokumentaatio, joka määrittelee syötteet, odotetut tulokset ka koukon suoritusehtoja testauksen kohteelle” (IEEE Std 829 -1983) – ”Testitapaukset ovat valittuja syötteitä, joita kokeillaan, ja toimintatapoja, joita seurataan, kun ohjelmistoa testataan” (Patton 2001) – ”Testitapaus määrittelee testauksen kohteen testiä edeltävän tilan ja ympäristön, testisyötteet tai ehdot, ja odotetun tuloksen. ” (Binder 1999) • Testi-idea keskeisenä asiana – ”Testi-idea on lyhyt ilmaisu jostakin, joka pitäisi testata. Esimerkiksi, jos testaat neliöjuurifunktiota, yksi idea olisi testata negatiivisilla luvulla tarkistaaksesi virheenkäsittely” (Marick) – Testitapaus on kysymys, joka kysytään ohjelmalta ja siten testitapausten tulee olla kykeneviä paljastamaan tietoa (Cem Kaner, 2003) Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapauksella haetaan tietoa • Dokumentointitarve tasapainoteltavana: – Itsestään selvyyksien välttäminen – Riittävä tuki muistin rajoitteille (7± 2 asiaa) – Dokumentoinnin kustannus vs. hyöty • Lisähaasteena: – Testi-ideasta lähtevän testitapauksen laajuus muuttuu ohjelmiston luotettavuuden parantuessa • Samaa ideaa voi käyttää syvemmälle – Testitapausten määrän mittaamisella ei ole suurta merkitystä • Koko muuttuu ajan myötä, alkujaankin eri kokoisia – Testitapauksen tavoite ei aina ole paljastaa virheitä, vaan myös tietoa riskeistä • Sisältäen kuitenkin myös virheet Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Odotetut tulokset testauksessa Näyttää mielestäni ihan hyvältä. . . Oikeanlainen toiminta pitää kyetä tunnistamaan - joskus se vaatii analysointia etukäteen. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Vaaditaanko testitapaukseen odotettu tulos? • Miksi ei vain katsota mitä ohjelmisto tekee ja arvioida sitä samalla? – Alitajuinen halu saada testi menemään läpi – Väärä tulos voidaan tulkita oikeaksi • Huomioi – muistin rajoitteet – vinoumat – heuristiikat oikealle toiminnalle – moniulotteinen oraakkeli • Usein suositellaan että odotetut tulokset pitäisi ennustaa osana testien suunnittelua ennen testien ajamista – Ei näin suoraviivaista: kannattaa miettiä onko itsellä/muilla kyky tunnistaa oikea tulos – Testitapaus voi olla parempi testitapaus vaikka siitä puuttuisi odotettu tulos! • Kirjaa asiat, jotka eivät ole itsestään selvyyksiä Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testattava kohde ja testioraakkeli Lähde: Mukaillen Doug Hoffman Syöte Testattava järjestelmä Tulos Odotettu tulos Aineisto ennen Aineisto jälkeen Ohjelman tila ennen Ohjelman tila jälkeen Ympäristösyötteet Ympäristötulos Testioraakkeli Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Yhdenmukaisuuden heuristiikat Lähde: James Bach 1. Vastaa historiaa (history) Nykyinen toiminta vastaa aiempaa toimintaa. 2. Vastaa ulkoista kuvaa (image) Toiminta vastaa ulkoista kuvaa, jonka organisaatio haluaa itsestään antaa 3. Vastaa verrattavia järjestelmiä (comparable products) Toiminta vastaavanlaisia toimintoja vastaavissa tuotteissa. 4. Vastaa väitteitä (claims) Toiminta vastaa sitä mitä ihmiset sanovat sen olevan. 5. Vastaa käyttäjän arvoja (user values) Toiminta vastaa sitä mitä oletamme käyttäjien haluavan. 6. Vastaa järjestelmää (product) Toiminta vastaavia toiminnallisuuksia tai toimintamalleja joita samassa järjestelmässä käytetään. 7. Vastaa tarkoitustaan (purpose) Toiminto vastaa sen käyttötarkoitusta. Englanniksi: HICCUPP Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testiaineiston ominaisuuksista Lähde: Craig & Jaskiel. 2003. Systematic Software Testing. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Aineiston suunnittelun haasteen muutos Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Erota käsitteet Testijakso Testiaineisto Testitapaus Testiympäristö Testikierros Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Mistä testitapausarkkitehtuurissa oikein puhutaan? • Testitapausarkkitehtuuri ei ole sama asia kuin sovelluksen arkkitehtuuri • Se on: – Jäsennys tehtävälle testaustyölle ja testitapauksille – Testaajan näkökulma – voi erota muista näkökulmista, mutta linkit on tärkeä ymmärtää – Apu testitapausten luomiseen ja valintaan testikierroksiin • Vaatimuksista testivaatimuksiin ja testitapauksiin kaikilla vaatimusten tasoilla Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Käyttäjän tehtävistä sovelluksen komponentteihin Komponentit Arkkitehtuuri Loppukäyttäjä Meidän pitäisi tietää merkittävät testit täällä Näin hahmotamme kehitystä Tiedämme mitä täällä muuttuu ”Suurennus” Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapausarkkitehtuuri • Raportoinnissa saa olla 10 -20 osa-aluetta – Tavoitteena yhteinen kieli ja ”liikennevalot”, jäljitettävyys testauksen sisällä • Loppukäyttäjän/testaajan/hallinnon yhteinen näkökulma – Tarvittaessa useampitasoinen hierarkia • Arkkitehtuuri suunnitellaan osana testaussuunnittelua (testijaksot jäsentämiseen ja suoritukseen) Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapausarkkitehtuuri Testien jäsentämisen testijaksot (staattinen): • Testattavat asiat • Aineistot • Ryhmittely • Tärkeysjärjestykseen laittaminen • Ajamisen valintakriteerien tukeminen Testauksen suorituksen testijaksot (dynaaminen): • Testattavat asiat vs. kokoonpanot • Testikierrokset • Linkki raportointiin (testiloki) Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testauksen suorittamiseen liittyvät tehtävät Testauksen suunnittelu ja valmistelu Testien suoritus ja jatkotoimenpiteet Muut tehtävät Kaksi tuntia käsin suoritettavaa testausta vaatii tyypillisesti kaksi päivää – testaaminen ei ole vain testin suoritusta. Lähde: Collard, Ross. 2004. Calculating Overheads. WTST (Workshop on Teaching Software Testing) 2004. http: //www. testingeducation. org Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

5 – Testitapaukset ja testien suorittaminen Käsiteltävät asiat Testitapaukset testauksen ohjaajana Testitapausten suunnittelu ja dokumentointi Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

IEEE 829 Testien määrittelyn dokumentit • Katetaan kolmella dokumenttityypillä – Testisuunnittelun määrittely – tarkentaa testauksen lähestymistapaa ja erittelee katettavat ominaisuudet sekä niihin liittyvät testit. Määrittelee ominaisuuksien hyväksymis-/hylkäämiskriteerit. – Testitapausmäärittely – käytetyt syötearvot ja niiden ennustetut tulokset. Erillään testien suunnittelusta, jotta voidaan käyttää yhtä tai useampaa mallia. – Testin toimintasarjan määrittely – erittelee kaikki järjestelmän operoinnin vaatimat askeleet. Tarkoitus seurata askeleelta. Vrt. testitapausarkkitehtuuri & testijaksot, testitapaukset ja testien askeleet. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testaushallinnan välineiden testitapauskäsite • Tarjoaa mallipohjan, jota voi käyttää monella tavalla – Testitapaus – Testiaskeleet – Odotetut tulokset kullekin askeleelle • Tasapaino: onko tarkoituksena tuottaa aukoton dokumentaatio vaiko tukea testauksen suorittamista • Välineiden käyttö mallipohjana tuottaa kokemuksen mukaan helposti heikkoja testitapauksia • Ohjaa välinettä palvelemaan prosessia, ei prosessia palvelemaan välinettä! Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Toimintosarjatestit • Monet eivät tuota askeleelta ohjeita testaukseen testitapauksissaan, perustellustikin. • Huolenaiheita ovat: – suuri osa ajasta kuluu dokumentointiin testauksen parantamisen ajattelun sijasta, sekä mitä ja miksi hämärtyy mekaanisiin yksityiskohtiin – testaajan tylsistyminen vie luovuuden ja uteliaisuuden ja testi olettaa että testin suunnitteluja tietää paremmin kuin toiminnan keskellä oleva testaaja mitä pitäisi käydä läpi – sitoudutaan jäykkiin ylläpitotöihin askeleiden muuttuessa järjestelmän kehittyessä eteenpäin, tai rakennetaan testit turhaan kun ylläpitoa ei ole tulossa. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Kaikesta skriptaamisesta luopuminen? • Tarkistuslistat (erotuksena skripteistä) ovat tietyissä tilanteissa hyödyllisiä. Ajatellaan esimerkiksi tuotteen julkaisua: – Paljon erilaisia tehtäviä – Kaikki ovat pakollisia – Tehtävät tehdään harvoin, joten ne on helppo unohtaa • Kerro, mitä pitää testata (mitä asioita kattaa) – älä, kuinka pitää testata. – “Kuinka”-kysymysten opettaminen ihmisille on koulutuskysymys, ei jotain, mikä on kirjoitettava testisuunnitelmiin uudestaan ja uudestaan. – Joissain tilanteissa tarkistuslista on oikea tapa esittää asia Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Älä ohjelmoi testaajaa • Esim: – ”Syötä 123 merkkiä” – ”Tallenna nimellä ”Project. WS” • Miksi näin? Tavoite ei selviä. • Kerro mitä testataan (mitä asioita katetaan) ei miten tehdään testi. – Koulutuksella vastaus ”kuinka” kysymykseen, ei kirjaamalla näitä asioita testitapauksiin – Motivoimalla mitä ja miksi aloitetaan ajatteleminen ja tavoite ohjaa käytännön toteutusta – Tarkastuslistalla yleisiä muistisääntöjä Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Automatisointi vaatii tarkat tiedot? • Vai vaatiiko? – Kokemukset ovat osoittaneet että suunnitellut testitapaukset kelpaavat harvoin suoraan automatisointiin, erilainen jäsennys • Automatisoidessa tulee tallennettua tarkat tiedot – Tietokoneen ”tyhmyys” – omat huomiot ja sisäänrakennetut huomiot • Huomioi oraakkelin moniulotteisuus – ”kirjoittaa ruudulle käyttäjän nimen” – ”tekee sen alle 10 sekunnissa” –. . . Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapaukset ja virheraportit • Harhoja: – Suunnittelemme tarkat testitapaukset ja vältymme virheraportoinnilta – Emme osaa raportoida virheitä, kun emme tiedä mitä teimme, jos meillä ei ole tarkkoja testitapauksia • Testitapaus, edes askeleittainen, ei tyypillisesti riitä virheraportiksi • Virheet useimmiten ”vähän vierestä” • Kaiken arvaamisen yrittäminen etukäteen ei ole järkevää ajankäyttöä Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Pohdi käytännössä • Kuvittele – halpa kadulta satunnaisesti valittu käyttäjä testaajana, ajamassa joukkoa yksityiskohtaisesti toimintosarjoina kuvattuja testejä – kokenut testaaja, joka tuntee järjestelmän rakenteita ja järjestelmän sovellusaluetta, ajamassa samoja testejä • Olettaisitko näiden kahden löytävän samat virheet? • Olettaisitko toisen ryhmän löytävän enemmän tai eri virheitä kuin toinen? • Miksi? Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

”Copy-paste”-kopioinnin välttäminen testitapauksissa Toisto pitäisi kommunikoida jotenkin muuten kuin ”leikkaa-liimaa”-kopioimalla testitapauksia Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Tehtävänanto (testitapaus) tutkivassa testauksessa • Tehtävänanto: Bugiraportointi – havaintolomake • Miksi: – Virheiden hallinta on tärkeimpiä komponentteja ja haluamme varmistaa, että virheet ja viitteet testiajoihin saadaan talletettua lokeihin oikein ja ettei tallentaminen ilman pakollisia tietoja onnistu • Mitä: – Havaintolomake – tietokantalomake havaintojen ja virheiden sekä niiden ilmenemisen ja toiminnallisuuden kirjaamiseen. • Kuinka: – Virheet talletetaan tietokannan väliaikaiseen tauluun siihen asti kunnes lomake on suljettu. Tiedon siirtäminen varsinaiseen tauluun vahvistetaan erikseen. – Painele vaihdellen sovelluksen eri painikkeita lomakkeen ollessa eri asteisesti täytetty. • Odotettuja ongelmia: – Virheet eri solujen välillä liikuttaessa – Sulkeminen ilman vaadittua informaatiota • Viittaukset – Ei ole Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapausten määrän mittaaminen aika Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Toiminnallisen testauksen syvyystasot 1. Aloitustestaus (smoke test) perustoiminnallisuuksille 2. Toimintojen testaus 3. Kyvykkyyden testaus – yksinkertaisempi aineisto 4. Luotettavuuden testaus – monipuolisempi ja laajempi aineisto Syvyys kehittyy kaikilla testaustasoilla Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Koska testitapaukset suunnitellaan? Katselmoi ennemmin kuin määrittele testitapauksia virheellisiin tai puutteellisiin vaatimuksiin pohjaten. Vertaiskatselmointien virheenpoistoteho 60 % Perspektiivipohjaisesti suunnattujen teho 35 % enemmän. 20 % virheistä menee läpi testaukseen saakka. Testitapaukset • vaiheittaisessa testauksessa (off-synch) • jatkuvassa testauksessa (in-synch) Virheet eivät ole tasaarvoisia. 80 % vältettävissä olevasta korjaustyöstä tulee 20 %: sta koodia. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapausten vertailukriteeristö • Tehokkaampia – todennäköisemmin paljastavat vian • Oleelliset tulokset todennäköisempiä – jollekin sellaiselle toimijalle jolla on väliä • Uskottavampia – niin realistisia kuin mahdollista • Vastaavien tilanteiden kohtaaminen käyttäjän toimesta todennäköisempää • Helpompaa arvioida läpimeno • Hyödyllisempiä vian jäljityksessä – mikä meni pieleen • Antavat enemmän tietoa • Sopivan monimutkaisia • Todennäköisemmin auttaa testaajaa tai ohjelmoijaa saamaan oivalluksia jostakin tuotteen ominaisuudesta, asiakkaasta tai ympäristöstä – kuten XP: n yksikkötestit [Kaner 2003] Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapausten priorisointi • Usein jaetaan kolmeen luokkaan – 1 – keskeisin perustoiminnallisuus – 2 – perustoiminnallisuuden täydennys – 3 – myös hyvä varmistaa • Mahdollisia tapoja ajatella uusintatestausta – Kaikki korkeimman prioriteetin testit uusittava muutosten jälkeen, mutta vain kerran kuukaudessa ja juuri ennen julkaisua. – Erillinen hyväksymistestausjakso uusintatestaukseen juuri ennen julkaisua – Uusintatestaus teknisten testitapausten tasolla – Eri priorisointi ennen ominaisuuksien kiinnitystä ja ominaisuuksien kiinnityksen jälkeen ohjaamaan uusintatestausta Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Hyvä testitapaussuunnittelu • Erinomainen testitapaus täyttää seuraavat kriteerit: – – – – Järkevä todennäköisyys löytää virhe Testaa kiinnostuksen kohteena olevaa aluetta Tekee kiinnostavia asioita Ei tee turhia asioita Ei liian yksinkertainen eikä liian monimutkainen Ei muiden testien jälkeen tarpeeton Näyttää virheet itsestäänselvästi Mahdollistaa virheiden tunnistamisen ja eristämisen Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testijaksojen arviointi • Testauksen hallinnan pitäisi sisältää testijaksojen arviointia – siihen käytetty aika on pois jostain muusta – onko se siis sen arvoista? • Jos testaajat eivät voi luottaa omiin testien suunnittelun kykyihinsä, testitapausten katselmoinneissa perusviesti on ”jeps, onhan tuo kyllä testi” • Paras tapa oppia eroista on katsoa toisten tekemiä testejä – Oma tapa ei välttämättä ole oikeampi, kysy miksi? Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Testitapauksilla on helppo johtaa harhaan • Testitapauksen määritelmä vaihtelee – – – Tuotteiden välillä Ominaisuuksien välillä Henkilöiden välillä Testattavien näkökulmien välillä (liiketoiminta vs. tekninen) Suoritustapojen välillä(toimintatapa/idea käsin vs. automaatisoitu) – Testattavan asian kohdistumisen suhteen (toiminnallinen vs. eitoiminnallinen) • Ehdotuksia – Älä perusta etenemisen seurantaa vain testitapausten suorittamiseen – Ota aina esille riskit ja kattavuudet testitapausten määrästä puhuttaessa. – Kerro testitapausten määristä vain tilanteissa, joissa voit myös selittää niiden merkityksen. Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Mitä sitten? • • • Komponenttilistat Riskilistat Aineistolistat Idealistat Muistiinpanot lupauksista ja toiveista Odotetut tulokset niiltä osin kirjoitettuna kuin ne ovat yllättäviä • Testaajan kykyjen kasvatus testaajan ohjelmoinnin asemesta Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Yhteenveto • Testitapaus voidaan käsittää toimintatapana tai ideana – Ei yhtä ehdotonta muotoa – Yksityiskohtainen muoto ei usein paras käytännössä toteutettavaksi • Odotettuja tuloksia on ajateltava aktiivisesti – Kuitenkin testitapaus voi olla avoin kysymys, jonka vastausta haetaan ohjelmasta • Testien rakenteistaminen ajatellen erikseen peruskokoelmaa ja suorituksen aikana tarvittavia idean toistoja on tarpeellista • Testitapauksiin liittyy muutakin toimintaa kuin vain sen suoritus • Testitapaus muuttuu ohjelmiston kypsyessä • Testitapaukset kannattaa suunnitella ajoissa, mutta ei liian aikaisin Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen

Linkkejä ja vinkkejä • Kirjoja: – Craig, Jaskiel. Systematic Software Testing. 2003. – Kaner, Cem. 1999. Testing Computer Software. – Kaner, C. , J. Bach, and B. Pettichord. 2002. Lessons Learned in Software Testing - A Context-driven Approach. Wiley Computer Publishing. • Artikkeleita: – Kaner, Cem. 2003. What Is a Good Test Case. In Proceedings of Star. East – Collard, Ross. 2004. Calculating Overheads. WTST (Workshop on Teaching Software Testing) 2004. http: //www. testingeducation. org • Täydentävä jatkokurssi: – Testitapausten suunnittelu (3) Tämä teos on lisensoitu Creative Commons Tekijä mainittava –lisenssillä. – Maaret Pyhäjärvi & Erkki Pöyhönen