TIE-21201 Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori
Työn yleiset järjestelyt 20.9.2016 2
Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut Lue kahden ensimmäisen vaiheen ohjeistus Selvitä kuka on työsi ohjaaja (Antti, Matti vai Ulla-Talvikki) Ohjaajajako löytyy harkkatyösivulta Ohjaajasi vastaa kysymyksiin yksittäisistä työn tehtävistä ja arvostelee työsi Kysymykset projektin yleisistä järjestelyistä Antille Käy aiheeseen liittyvissä viikkoharjoituksissa (vapaaehtoista) 20.9.2016 3
Rakenne ja aikataulu Kolme vaihetta: 1. Tutkivan järjestelmätestauksen suunnittelu 2. Tutkivan järjestelmätestauksen suoritus ja raportointi 3. Mallipohjainen testaus Karkea aikataulu (tarkat ajat harjoitustyösivuilla): Viikko 38 Vaiheiden 1 ja 2 ohjausluento Viikko 41 Vaiheen 1 deadline Viikko 43 Vaiheen 1 palaute Viikko 46 Vaiheen 3 ohjausluento Viikko 46 Vaiheen 2 deadline Viikko 48 Vaiheen 2 palaute Viikko 49 Vaiheen 3 deadline Viikko 51 Vaiheen 3 palaute 20.9.2016 4
Palautukset Palautukset tehdään sähköpostitse To: testaus@cs.tut.fi From: @student.tut.fi-mailiosoitteesta Subject: TIE-21201_2016_<VAIHE>_<OHJAAJAN_NIMIKIRJAIMET> Liite: palautettavat tiedostot Onnistuneesta palautuksesta lähetetään kuittaus Tarkasta täsmälliset ohjeet harjoitustyösivuilta 20.9.2016 5
Arvostelu Harjoitustyöstä saatavilla kaikkiaan 16 pistettä Puolet koko kurssin pisteistä 1. vaiheesta (tutkivan testauksen suunnittelu) saatavilla 4 pistettä 2. vaiheesta (tutkivan testauksen toteutus) saatavilla 6 pistettä 3. vaiheesta (mallipohjainen testaus) saatavilla 6 pistettä Yksittäiselle palautukselle ei ole läpäisyrajaa, tyhjäkin palautus hyväksytään nollalla pisteellä Kussakin vaiheessa on tehtävä palautus Kaikista vaiheista yhteensä on saatava vähintään 5 pistettä 20.9.2016 6
Harjoitustyön vaiheet 1 ja 2 20.9.2016 7
Yleistä 1/2 Testikohde: ohjelmoijan tekstieditori jedit, versio 5.3CE CE tarkoittaa kurssin omaa versiota (course edition), johon on kylvetty bugeja version 5.3 päälle CE-versio tulee saataville vasta kun suunnitteluvaihe on ohi Perusversio ja loppukäyttäjän dokumentaatio ovat saatavilla jeditin sivulla: http://www.jedit.org/ Varsinaisia spesifikaatioita ei ole tarjolla jedit on liian suuri tässä työssä kokonaan testattavaksi, joten priorisointia ja testattavien asioiden valintaa tarvitaan 20.9.2016 8
Yleistä 2/2 Testaustapa: tutkiva toiminnallinen GUI-testaus Ohjelmaa käytetään manuaalisesti käyttöliittymän läpi, kuten tavallinen käyttäjä Mustalaatikkotestausta, lähdekoodia ei tarkastella Ei yksityiskohtaisia testitapauksia, vain yleisiä suuntaviivoja siitä, mitä ominaisuuksia tarkastellaan ja miten Ei-toiminnallisia ominaisuuksia kuten käytettävyyttä tai suorituskykyä ei testata Virallinen testiympäristö: TTY:n Linux-etätyöpöytäympäristö Työasemia luokassa TC217, ohjeita etäkäyttöön Tutkassa https://www.tut.fi/tutka/it/tietokoneluokat/yhteiskayttoiset-linuxkoneet/index.htm Muita ympäristöjä saa käyttää, mutta ohjelman pystyttäminen niihin on omalla vastuulla (ei kylläkään pitäisi olla vaikeaa) Lisätietoja vaiheiden 1 ja 2 ohjeistuksessa 20.9.2016 9
Palautettavat dokumentit Vaihe 1 Testisuunnitelma Vaihe 2 Testiraportti Korjattu testisuunnitelma (jos suunnitelman palautteessa sanottiin, että jotain on korjattava) Tarkasta täsmälliset ohjeet harjoitustyösivuilta 20.9.2016 10
Dokumentoinnin tärkeydestä Erityisesti järjestelmätestauksessa dokumentaatio on välttämätöntä kommunikoinnille Yksi tiimi voi kirjoittaa päätestaussuunnitelman, toinen tarkan testisuunnitelman, kolmas suorittaa testauksen, neljäs korjaa löydetyt virheet, ja projektin johto päättää onko softa valmis julkaistavaksi Dokumentaatiota voidaan tarvita myös osoittamaan muille tahoille, että testaus on tehty riittävän hyvin Kirjoita dokumentit muita ihmisiä ajatellen Voiko joku muu suorittaa testit suunnitelmasi avulla kuten tarkoitit? Voiko jonkun muun testituloksia verrata omiisi? Voiko joku muu lukea testiraporttisi ja hahmottaa testikohteen tilanteen? Voiko joku muu paikantaa löytämäsi virheet raporttiesi perusteella? Dokumentteja pitäisi voida lukea omillaan, älä oleta lukijan tuntevan kurssin muuta ohjeistusta 20.9.2016 11
Testisuunnitelma Johdanto Mitä olet tässä testaamassa? Ominaisuudet ja prioriteetit Mitä ominaisuuksia testikohteella on? Miten päätät, kuinka tärkeä ominaisuus on? Mitä ominaisuuksia testaat ja mitä et? Lähestymistapa Miten pääset käsiksi testikohteeseen ja käytät sitä tarvittavalla tavalla? Mitä testauksen aikana pitää tehdä, ja miten? Läpäisykriteerit Miten päätät, kuinka vakava virhe on? Kuinka paljon ja kuinka vakavia virheitä testikohteessa voi sietää? 20.9.2016 12
Ominaisuudet ja prioriteetit Priorisointimenetelmä tarvitaan, jotta muut voivat määrittää vertailukelpoisia prioriteetteja muille ominaisuuksille Vaatimusmäärittelyä ei ole tarjolla tässä auttamaan Mikä ei ole harvinaista yrityksissäkään Harvat spesifikaatiot muutenkaan kuvaavat yleistä editorin toimintaa Mieti käyttäjän tarpeita: jedit on ohjelmoijan tekstieditori Menetelmän voi valita itse Esimerkiksi: ominaisuuksien yleisyys / vakavuus -analyysi Numeerinen arvio käytön yleisyydestä Numeerinen arvio häiriön aiheuttamasta haitasta Yhdistä prioriteetiksi Testaukseen pitäisi ottaa mukaan ainakin kaikkein tärkeimmät ominaisuudet, ja vähän jotain muutakin 20.9.2016 13
Lähestymistapa Tekninen ohjeistus: missä ympäristössä testaus suoritetaan, miten testikohteen saa siellä käyntiin, miten tarvittavia työkaluja käytetään, jne. Käytännöllinen ohjeistus: tutkivassa testauksessa ei ole testitapauksia tai muita yksityiskohtaisia toimintaohjeita, mutta jonkinlaista suuntaviivaa tarvitaan silti varmistamaan, ettei mitään vahingossa unohdu Käyttöskenaarioita: käytä softaa tavalla, jolla sitä käytettäisiin oikeasti Esimerkkikäyttäjiä: käytä softaa kuten tietynlainen käyttäjä sitä käyttäisi Varmista, että tärkeät ominaisuudet ja niiden eri käyttötavat tulevat katetuiksi Muista negatiivinen testaus 20.9.2016 14
Läpäisykriteerit Miten virheen vakavuus määräytyy? Ominaisuuksien prioriteetit ovat relevantteja mutta eivät kerro kaikkea Yhdenkin ominaisuuden virheillä voi olla monenlaisia vaikutuksia: kosmeettinen haitta, vaivalloinen käyttää, estää ominaisuuden toiminnan Miten virheen todelliset vaikutukset otetaan huomioon? Läpäisykriteerit Virheettömyyden vaatiminen ei ole realistista, yleensä joitakin virheitä on vain siedettävä Kuinka paljon ja millaisten vakavuuksien virheitä testikohteessa saa sitten olla? Onko muita kriteereitä joiden on täytyttävä? 20.9.2016 15
Testiraportti Johdanto Mitä olet testannut? Muutokset suunnitelmaan Suorititko testauksen suunnitelman mukaisesti? Kattavuusarvio Kuinka hyvin testikohde on nyt testattu? Tulokset Millaisessa kunnossa testikohde kaikkiaan on? Mitkä ovat merkittävimmät ongelmat? Arviointi Kuinka vakavia ovat löytämäsi virheet? Onko testikohde riittävän hyvässä kunnossa julkaistavaksi? Liitteenä myös virheraportit ja testiloki 20.9.2016 16
Muutokset suunnitelmaan Testaus ei aina suju suunnitelmien mukaan Suunnitelmat ovat vanhentuneita Suunnitelmat ovat virheellisiä Kaikkea ei osattu ottaa etukäteen huomioon Puutteellista tai virheellistä suunnitelmaa ei kannata noudattaa sokeasti Testaa niin kuin on järkevää Kirjaa ylös, mitä teit eri tavoin, niin että tilanne voidaan jälkeenpäin arvioida uudelleen 20.9.2016 17
Kattavuusarvio Kuinka hyvin testaus on kattanut testikohteen eri osat? Yksikkötestauksessa mitataan usein koodia vasten Järjestelmätestauksessa katsotaan vaatimuksia ja ominaisuuksia Järkeviä numeerisia arvioita ei tässä työssä oikein saa aikaiseksi, koska kanonista listaa vaatimuksista tai ominaisuuksista ei ole Luotetaan siis testaajan omaan tuntumaan Tärkeä osa arviointia vaikka numeerisia kattavuuslukemia tuotettaisiinkin! Jos kattavuudessa on puutteita, niin mistä ne johtuvat? 20.9.2016 18
Tulokset Kerro testikohteen kunnosta Millaisia virheitä testikohteessa havaittiin? Millainen on testikohteen yleistuntuma, mitkä osa-alueet toimivat ja mitkä eivät, vaikuttaako loppukäyttöön sopivalta? Tarkoituksena antaa yleiskuva testikohteen kunnosta ja suurimmista ongelmakohdista Ei liikaa yksityiskohtia, varsinaiset virheraportit ovat erikseen 20.9.2016 19
Arviointi Kuinka vakavia löydetyt virheet ovat? Vakavuuden arviointitapa määritetty suunnitelmassa Onko testikohde riittävän hyvässä kunnossa julkaistavaksi? Kriteerit tähänkin määritetty suunnitelmassa Onko lopputulos järkevä? 20.9.2016 20
Virheraportit Kerro mitä testikohteessa on vialla Otsikko ja lyhyt kuvaus Selosta missä ja miten ongelma ilmenee Testiympäristö, ajankohta Suoritettavat toiminnot, syötteet Odotetut ja todelliset tulokset Muut oleelliset havainnot Arvio häiriön takana olevasta virheestä Motivoi ihmisiä korjaamaan ongelma Vaikutukset loppukäyttäjään Vaikutukset kehitykseen ja testaukseen 20.9.2016 21
Testiloki Tutkivassa testauksessa ei ole testitapauksia osoittamassa, mitä on tarkkaan ottaen tehty Tarvitaan testilokeja: testaaja tekee muistiinpanoja siitä, mitä ominaisuuksia testaa ja miten Pitää kirjaa testikattavuudesta Auttaa jäljittämään hankalasti toistettavia bugeja 20.9.2016 22