Testitapaukset ja testien suorittaminen

1. Testitapaukset ja testien suorittaminen Maaret Pyhäjärvi ja Erkki Pöyhönen Julkaisuversio 1.0 2005-01-23 tekijä mainittavahttp://creativecommons.org/licenses/by/1.0/fi/

2. 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

3. 5 – Testitapaukset ja testien suorittaminen Tehokas ohjelmistotestaus Testaustekniikat Testaus ohjelmisto-kehityksen osana Testauksen suunnittelu ja hallinta Virheraportointi ja virheasian ajaminen Testausvälineet ja testauksen automatisointi Katselmoinnit testaustoimintana Testausprosessin muuttaminen Testitapaukset ja testien suorittaminen

4. 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

5. Käsiteltävät asiat Testitapaukset testauksen ohjaajana Testitapausten suunnittelu ja dokumentointi 5 – Testitapaukset ja testien suorittaminen

6. 5 – Testitapaukset ja testien suorittaminen Käsiteltävät asiat Testitapaukset testauksen ohjaajana Testitapausten suunnittelu ja dokumentointi

7. Testauksen suunnittelu • Organisaation odotukset testaustoiminnalle • Laatupainotukset sovellusalueella Testauksen missio ja korkean tason tavoitteet • Järjestelmä / tuote / palvelukohtainen • Useita projekteja saman järjestelmän elinkaaressa Testausstrategia • Projektikohtainen • Projektin lähestymistapa, strategian räätälöinti Yleistestaussuunnitelma • Tarkentavat suunnitelmat ryhmittäin Testaussuunnitelma • Testattavien asioiden yksityiskohdat Testitapaukset

8. 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?

9. Testitapaus katselmoitavaksi • 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.

10. 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.

11. Esimerkkejä testitapauksista TKK:n testauskurssilta 2001 Testitapaus 1: Tarkista dialogi-ikkunan “Tabs” otsikko. 1. Käynnistä WordPad juuri luomastasi “Temp\TestThis”-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ä WordPad. 2. Kirjoita jotain WordPad: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.

12. 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

13. 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)

14. 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

15. Odotetut tulokset testauksessa Näyttää mielestäni ihan hyvältä... Oikeanlainen toiminta pitää kyetä tunnistamaan - joskus se vaatii analysointia etukäteen.

16. 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ä Vaaditaanko testitapaukseen odotettu tulos?

17. Testattava kohde ja testioraakkeliLähde: Mukaillen Doug Hoffman Tulos Testattava järjestelmä Syöte Odotettu tulos Aineisto ennen Aineisto jälkeen Ohjelman tila ennen Ohjelman tila jälkeen Testioraakkeli Ympäristö-syötteet Ympäristö-tulos

18. Vastaa historiaa (history)Nykyinen toiminta vastaa aiempaa toimintaa. Vastaa ulkoista kuvaa (image)Toiminta vastaa ulkoista kuvaa, jonka organisaatio haluaa itsestään antaa Vastaa verrattavia järjestelmiä (comparable products)Toiminta vastaa vastaavanlaisia toimintoja vastaavissa tuotteissa. Vastaa väitteitä (claims)Toiminta vastaa sitä mitä ihmiset sanovat sen olevan. Vastaa käyttäjän arvoja (user values)Toiminta vastaa sitä mitä oletamme käyttäjien haluavan. Vastaa järjestelmää (product)Toiminta vastaa vastaavia toiminnallisuuksia tai toimintamalleja joita samassa järjestelmässä käytetään. Vastaa tarkoitustaan (purpose)Toiminto vastaa sen käyttötarkoitusta. Yhdenmukaisuuden heuristiikatLähde: James Bach Englanniksi: HICCUPP

19. Testiaineiston ominaisuuksistaLähde: Craig & Jaskiel. 2003. Systematic Software Testing.

20. Aineiston suunnittelun haasteen muutos

21. Erota käsitteet Testijakso Testiaineisto Testitapaus Testiympäristö Testikierros

22. 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

23. ”Suurennus” Käyttäjän tehtävistä sovelluksen komponentteihin Komponentit Meidän pitäisi tietää merkittävät testit täällä Näin hahmotamme kehitystä Tiedämme mitä täällä muuttuu Arkkitehtuuri Loppukäyttäjä

24. 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)

25. 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)

26. Testauksen suorittamiseen liittyvät tehtävät Testauksen suunnittelu ja valmistelu Testien valmistelu Testien suoritus ja jatkotoi-menpiteet 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

27. 5 – Testitapaukset ja testien suorittaminen Käsiteltävät asiat Testitapaukset testauksen ohjaajana Testitapausten suunnittelu ja dokumentointi

28. 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 askel askeleelta. Vrt. testitapausarkkitehtuuri & testijaksot, testitapaukset ja testien askeleet.

29. 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ä!

30. Toimintosarjatestit • Monet eivät tuota askel 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.

31. 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

32. Älä ohjelmoi testaajaa • Esim: • ”Syötä 123 merkkiä” • ”Tallenna nimellä ”ProjectWS” • 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ä

33. 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” • ...

34. 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öä

35. 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?

36. ”Copy-paste”-kopioinnin välttäminen testitapauksissa Toisto pitäisi kommunikoida jotenkin muuten kuin ”leikkaa-liimaa”-kopioimalla testitapauksia

37. 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

38. Testitapausten määrän mittaaminen aika

39. Toiminnallisen testauksen syvyystasot • Aloitustestaus (smoke test) perustoiminnallisuuksille • Toimintojen testaus • Kyvykkyyden testaus • yksinkertaisempi aineisto • Luotettavuuden testaus • monipuolisempi ja laajempi aineisto Syvyys kehittyy kaikilla testaustasoilla

40. 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. Virheet eivät ole tasa-arvoisia. 80 % vältettävissä olevasta korjaustyöstä tulee 20 %:sta koodia. • Testitapaukset • vaiheittaisessa testauksessa (off-synch) • jatkuvassa testauksessa (in-synch)

41. 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 Testitapausten vertailukriteeristö [Kaner 2003]

42. 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

43. 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

44. 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?

45. 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. ei-toiminnallinen) • 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.

46. 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

47. 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

48. 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 StarEast • Collard, Ross. 2004. Calculating Overheads. WTST (Workshop on Teaching Software Testing) 2004. http://www.testingeducation.org • Täydentävä jatkokurssi: • Testitapausten suunnittelu (3)