Ohjelmistotestauksen perusteet. versio 1.0

Koko: px
Aloita esitys sivulta:

Download "Ohjelmistotestauksen perusteet. versio 1.0"

Transkriptio

1 Ohjelmistotestauksen perusteet versio 1.0

2 Sisällysluettelo Sisällysluettelo... 2 Johdanto... 4 Luku 1 Mitä on ohjelmistotestaus?... 5 Testauksen määritelmä... 5 Testauksen psykologia ja tavoitteet... 5 Virheiden eliminointi ja aikainen testaus... 5 Testaus osana laadunvarmistusta... 6 Virheet, viat ja häiriöt... 7 Virheiden tunnistaminen ja luokittelu... 7 Virheiden vakavuus ja vaikutukset... 8 Virheenjäljitys... 9 Luku 2 Testaus ohjelmiston elinkaaressa V-malli ja testaustasot Moduulitestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus Ylläpito- ja uudelleentestaus Luku 3 Testausprosessi ja sen hallinta Testaustyön roolit ja tehtävänjako Testauksen suunnittelu Testausstrategia Testaussuunnitelma Testauksen kohdentaminen ja priorisointi Testitapausten suunnittelu Testauksen toteuttaminen

3 Vaihekohtainen testaus Testitulosten tarkastelu ja raportointi Testauksen riittävyyden arviointi ja testauksen päättäminen Testauksen kattavuus Virheiden analysointi Testauksen tehokkuuden arvioiminen Testauksen päättämistehtävät Yhteenveto testauksen työvaiheista ja tuotoksista Luku 4 Testaustekniikat Staattiset testaustekniikat Katselmukset Tarkastukset Dynaaminen testaus Valkolaatikkotestauksen menetelmät Mustalaatikkotestauksen menetelmät Kokemukseen perustuvat menetelmät Luku 5 Testauksen työkalut Testausprosessin hallintaan liittyvät työkalut Staattisen testauksen työkalut Dynaamisen testauksen työkalut Yksikkötestauksen työkalut Toiminnallisen testauksen työkalut Suorituskykytestauksen työkalut Tietoturvatestauksen työkalut Testiaineistogeneraattorit Lähteet Liite 1. Testaustermien suomi-englanti sanasto

4 Johdanto Tämän oppaan tarkoituksena on tutustuttaa lukija ohjelmistotestauksen käsitteisiin, näkökulmiin ja tekniikoihin sekä havainnollistaa mitä ohjelmistotestaus käytännössä on. Oppaan keskeinen ajatus on tarjota lukijalle käytännön perustiedot ja työkalut, joilla testauksen suunnittelua, toteutusta ja analysointia pääsee itsenäisesti harjoittelemaan. Opas on jaettu viiteen lukuun. Ensimmäisessä luvussa määritellään testauksen käsitteitä sekä esitetään näkökulmia miksi testausta tarvitaan. Toinen luku kuvaa V-mallin avulla testausprosessin vaiheet osana ohjelmiston elinkaarta. Kolmannessa luvussa käsitellään testauksen perusprosessia ja sen hallintaa. Neljännessä luvussa esitellään staattisen ja dynaamisen testauksen lähestymistapoja, menetelmiä ja tekniikoita. Viidennessä luvussa käsitellään testauksen työkalutukea sekä luetellaan vapaan lähdekoodin ohjelmistoja, joita voidaan hyödyntää testauksen eri työvaiheissa. Oppaan lopussa olevat liitteet sisältävät tärkeimpien testaustermien suomi-englanti sanaston sekä hyödyllisiä dokumenttipohjia testauksen suunnittelua ja raportointia varten. 4

5 Luku 1 Mitä on ohjelmistotestaus? Testauksen määritelmä Glenford J. Myers esittää vuonna 1979 ilmestyneessä alkuperäisteoksessaan The Art of Software Testing käsitteen ohjelmistotestaus, johon yhä edelleen viitataan testaustyön keskeisimmän tehtävän ja tavoitteen määritelmänä: Testing is the process of executing a program with the intent of finding errors (Myers 1979, 5). Samaan tapaan muotoilee myös Haikala & Märijärvi (2002, 282), joiden mukaan ohjelmistotestaus on systemaattista, ohjelmaa suorittamalla tapahtuvaa virheiden etsintää ohjelmasta tai sen osasta. Testaaminen ei siis ole mitä tahansa kokeilua niin kuin arkikielessä usein testaamisella tarkoitetaan vaan tarkoituksena on toteuttaa systemaattinen ja suunnitelmallinen prosessi. Testauksella on ohjelmistokehityksessä erityinen tehtävä, jossa pyrkimyksenä on löytää ohjelmassa olevia vikoja ja puutteita. Määritelmän mukainen testaus perustuu ohjelmakoodin suorittamiseen, josta käytetään myös termiä dynaaminen testaus. Dynaamisen testauksen lisäksi virheiden ja ongelmakohtien etsintää tehdään myös staattisilla testausmenetelmillä, jotka perustuvat ohjelmakoodin analysointiin ja tarkastamiseen ilman, että ohjelmaa varsinaisesti käytetään. Testauksen psykologia ja tavoitteet Testaus nähdään usein toimenpiteenä, jonka tavoitteena on osoittaa, että ohjelma toimii oikein. Myers (1979, 5) tuo vahvasti esiin testauksen psykologisen näkökulman. Ihmisen toimintaan vaikuttaa olennaisesti se, kuinka tavoitteet asetetaan. Jos testauksen tavoitteena on vahvistaa, että ohjelma toteuttaa sille määritellyt tehtävät oikein, testaaja alkaa alitajuisesti toteuttaa testausta tavoitteensa mukaisesti. Tämä voi johtaa tilanteeseen, jossa testaaja välttää testitapauksia, jotka tuovat esiin virheitä. Seurauksena on, että testauksen lisäarvo jää saavuttamatta. Testauksen onnistumisen edellytyksenä on oikea asenne ja näkökulma testauksen tavoitteisiin. Kun tavoitteena on löytää ohjelmassa olevia virheitä, testit todennäköisemmin myös löytävät niitä. Kaner & al. (1999, 25) kiteyttää testauksen ydinajatuksen toteamalla, että onnistunut testi paljastaa ongelman, kun taas testi, joka ei tuo esiin virheitä on hukkaan heitettyä aikaa. Virheiden eliminointi ja aikainen testaus Ohjelmat sisältävät virheitä. Jo pitkään käytössä olleissa ohjelmissakin arvioidaan olevan noin yksi virhe tuhatta ohjelmariviä kohden (Haikala & Märijärvi 2002, 285). Tietoa tuotetaan, muunnetaan ja 5

6 siirretään kehitysprosessin vaiheiden läpi eri toimijoiden käyttöön, mikä on otollista maaperää virheiden syntymiselle. Suurin osa (jopa %) ohjelmavioista saa alkunsa jo ohjelmistokehityksen määrittely- ja suunnitteluvaiheessa (Kit 1995, 19). Mitä pitemmälle kehitystyö etenee sitä jyrkemmin virheiden etsinnästä ja erityisesti niiden korjauksesta aiheutuvat kustannukset kasvavat. Kaikkein kalleimmaksi tulevat virheet, jotka tulevat ilmi ohjelman julkaisun ja käyttöönoton jälkeen, jolloin kalliiden korjauskustannusten lisäksi voi aiheutua ikävää haittaa myös yrityksen imagolle. Ohjelman täydellinen testaaminen ei ole mahdollista, eikä ohjelman virheettömyyttä pystytä testauksella osoittamaan. Aivan yksinkertaisia tapauksia lukuun ottamatta ohjelman kaikkien mahdollisten ohjelmapolkujen ja syötekombinaatioiden määrä on niin suuri, että niiden läpikäyminen testaamalla on mahdoton tehtävä (Kaner & al. 1999, 17). Testauksen ensisijaisena pyrkimyksenä onkin löytää mahdollisimman paljon virheitä mahdollisimman varhaisessa vaiheessa, jotta niiden korjaamisesta aiheutuva lisätyö voidaan minimoida. Virheiden aikainen havaitseminen estää niiden siirtymisen ja ennaltaehkäisee uusien virheiden syntymistä. Testauksen hyöty saavutetaan, kun löytyneet virheet korjataan ja sen myötä ohjelman luotettavuus ja laatu paranee. Testaus osana laadunvarmistusta Ohjelma tai järjestelmä joutuu testattavaksi aina kun sitä käytetään. Ohjelmistotestausta tarvitaan, jotta tiedetään mitä käyttäjälle ollaan tarjoamassa ja kuinka hyvin ohjelman todellinen toiminta vastaa sitä mitä alun perin on lähdetty tekemään. Laatu on käsite, jolla kuvataan tuotteen ja tuotantoprosessin ominaisuuksia ja onnistumista suhteessa asetettuihin tavoitteisiin. Korkealaatuinen ohjelmistotuote täyttää sille asetetut tekniset vaatimukset ja vastaa käyttäjän odotuksia ja tarpeita. Laadukkaan tuotantoprosessin tuloksena lopputuote valmistuu asetetun aikataulun ja budjetin mukaisesti. Prosessin vaiheiden ja vaihetuotteiden seurannalla, arvioinnilla ja mittaamisella pyritään varmistamaan, että asetetut tavoitteet saavutetaan käytettävissä olevien resurssien puitteissa. Termejä verifiointi ja validointi (suom. todentaminen ja kelpoistaminen; engl. verfication & validation) käytetään laadunvarmistuksen yhteydessä kuvaamaan menettelytapoja tuotteen ja tuotantoprosessin laadun arvioinnissa (Haikala & Märijärvi, 2002, 49). Verifioinnilla tarkoitetaan toimenpiteitä, joilla pyritään todentamaan, että tuote on tehty suunnitelmien mukaan ja toteuttaa sille määritellyt toiminnot oikein ( are we building the product right ). Validoinnilla puolestaan pyritään varmistamaan, että toteutettu ohjelmisto täyttää sille määritellyt vaatimukset ( are we building the right product ). Ohjelmistotuotannon näkökulmasta testaus on keskeinen osa ohjelmistoprojektin laadunvarmistusta, jonka avulla ohjelmiston ja tuotantoprosessin laatu saadaan näkyväksi. Testaus lisää luottamusta, että toteutettu tuote vastaa asetettuja tavoitteita ja vaatimuksia. Hyvin toteutettu testaus 6

7 auttaa hallitsemaan ohjelmistonkehitykseen liittyviä riskejä. Testausprosessista saatua tietoa voidaan käyttää apuna päätöksenteossa sekä hyödyntää tulevissa projekteissa ja testausprosessin kehittämisessä. Laadunhallinnan kannalta on kuitenkin tärkeää huomioida, että ohjelmiston laatu on kehitystyön tulos ja laatua rakennetaan koko ohjelmistokehityksen ajan. Testaus ei paranna laatua eikä testauksella voida korjata huonosti suunnitellun tai huonosti tehdyn työn tulosta. Testaus todentaa ja vahvistaa olemassa olevan laadun. Mikäli ohjelmiston laatu on huono testauksen alussa, laatu on huono myös testauksen lopussa (Pressmann 2005, 356). Virheet, viat ja häiriöt Standardi IEEE (IEEE Standard Glossary of Software Engineering Terminology) esittää termeille virhe, vika ja häiriö seuraavanlaiset määritelmät: Mistake, error (virhe, erehdys) tarkoittaa virhettä, joka on seuraus ihmisen virheellisestä toiminnasta tai erehdyksestä. Inhimillinen virhe voi olla ohjelmointivirhe, virhe dokumentaatiossa tai dokumentaation tulkinnassa. Fault, bug, error (virhe, vika) on ohjelmavirhe, joka on seuraus inhimillisestä virheestä. Ohjelmavika voi johtaa ohjelman toimintahäiriöön. Failure (häiriö) on ohjelmavirheen seurauksesta aiheutuva toimintahäiriö, joka näkyy virheellisenä tuloksena ohjelman suorituksessa. Määritelmien mukaisesti ohjelmassa tai ohjelman dokumentaatiossa olevat virheet ovat seuraus ihmisen virheellisestä toiminnasta tai erehdyksestä. Virheellisen kohdan suorittaminen voi aiheuttaa ohjelmavian, jonka seurauksena ohjelma ei toimi niin kuin pitäisi. Kaikki virheet eivät välttämättä johda ohjelman virheelliseen toimintaan. Virheen vaikutukset eivät aina myöskään tule käyttäjälle näkyviin, sillä vika voi peittyä tai kumoutua jonkin toiminnon tai toisen virheen seurauksena (Haikala & Märijärvi 2002, 285). Toisaalta on myös tilanteita, joissa ohjelman toimintahäiriön syynä on jokin ulkoinen tekijä esimerkiksi häiriö tietoliikenneverkossa, laitteiston vioittuminen, sähkökatkos tai järjestelmään päässyt haittaohjelma. Ohjelmavirheiden etsinnän lisäksi testauksella selvitetään myös järjestelmän toimintakykyä ja reagointia normaalista poikkeavissa tilanteissa. Virheiden tunnistaminen ja luokittelu Testauksen yhteydessä ohjelmavirhe todetaan poikkeamana spesifikaatiosta (Haikala & Märijärvi 2002, 285). Jotta tiedetään mitä etsitään, tyypillisten ja yleisesti esiintyvien virheiden tunnistamiseksi on laadittu luokitteluja ja ns. tarkistuslistoja (checklists). Jo olemassa olevien luokittelujen lisäksi uusia virheiden tarkistuslistoja muodostetaan aina tarpeen mukaan kutakin ohjelmistoa ja sen testausta varten. Tarkistuslistaa voidaan hyödyntää sekä testien suunnittelussa 7

8 että testausta suoritettaessa esim. kooditarkastusten yhteydessä. Proseduuriin kuuluu, että tarkistuslistaa täydennetään iteratiivisesti testausprosessin aikana. Esimerkiksi Beizer (1990, ) on laatinut kattavan taksonomian, jossa virheet on jaettu niiden alkuperän mukaan kahdeksaan pääkategoriaan: 1. Vaatimusten määrittelyyn liittyvät virheet 2. Vaatimusten toteutukseen liittyvät virheet 3. Ohjelmakoodin rakenteelliset virheet 4. Tietorakenteiden ja tiedon määrittelyyn, toteutukseen ja käyttöön liittyvät virheet 5. Toteutukseen ja ohjelmointiin liittyvät virheet 6. Integraatioon liittyvät virheet 7. Järjestelmä- ja ohjelmistoarkkitehtuuriin liittyvät virheet 8. Testauksen määrittelyyn ja suorittamiseen liittyvät virheet Virheiden luokittelun lisäksi Beizerin taksonomiassa on esitelty kuhunkin luokkaan kuuluvia virheitä ja esitetty niistä havainnollisia esimerkkejä. Vastaavia virheiden luokitteluja ja tarkistuslistoja löytyy runsaasti internetistä esim. hakusanoilla code checklists, code review checklists ja inspection checklists ja niitä ovat laatineet myös mm. Myers (1979, 25-36) ja Kit (1995, ). Virheiden vakavuus ja vaikutukset Ohjelmavirheen vakavuus riippuu virheen esiintyvyydestä, korjauskustannuksista ja virheen aiheuttamista seuraamuksista (Beizer 1990, 27). Pienten ja vähäisten virheiden vaikutukset ovat paikallisia ja ne ovat myös helppoja korjata esim. kirjoitusvirhe, huono asemointi, tarpeeton tai harhaanjohtava tuloste jne. Vakavien virheiden seuraukset eivät rajoitu yksittäisiin ja paikallisiin tapauksiin. Ongelmat ovat usein kumuloituvia, jolloin sekä vaikutukset että kustannukset kertautuvat, leviävät ja kasvavat. Pahimmassa tapauksessa kriittisen järjestelmän ongelma voi aiheuttaa vakavan uhan ihmisten ja ympäristön turvallisuudelle. Alla olevassa taulukossa on Beizerin (1990, 28-29) luokittelu virheen vakavuusasteesta 1-10 ja esimerkkejä seuraamuksista, joita eri vakavuusasteen virheet voivat aiheuttaa. Aste Vakavuus Seuraus/oire 1 Vähäinen Kirjoitusvirhe tai huono asettelu tulosteessa Kosmeettinen haitta 2 Kohtalainen Harhaanjohtava tai tarpeeton tuloste Suorituskyvyn aleneminen 8

9 3 Ärsyttävä Hankalat komennot, vaikeasti ymmärrettävät tai turhat toiminnot ja tulosteet Esim. järjestelmä lähettää 0.00 Euron laskun 4 Häiritsevä Sallittua transaktiota ei suoriteta Esim. automaatti ei anna rahaa 5 Vakava Transaktio ei kirjaudu eikä siitä jää merkintää Esim. tilin laskenta menee sekaisin 6 Hyvin vakava Järjestelmä suorittaa väärän transaktion Esim. talletus muuntuu nostoksi 7 Erittäin vakava Ongelmat eivät rajoitu yksittäisiin ja poikkeaviin tapahtumiin vaan ovat toistuvia normaaliolosuhteissa esiintyviä häiriöitä 8 Sietämätön Vääristynyttä dataa pitkältä ajanjaksolta, jota on vaikea havaita ja palauttaa 9 Katastrofaalinen Järjestelmä katuu 10 Infektoiva Vika siirtyy ja tuhoaa muita järjestelmiä Aiheuttaa peruuttamatonta ja jopa henkeä uhkaavaa vahinkoa ympäristölle ja ihmisille Virheenjäljitys Testauksella havaittu vika paljastaa ongelman mutta ei useinkaan vian alkuperäistä syytä tai tarkkaa sijaintia. Testaajan tehtäviin kuuluu havaitun vian tai ongelman dokumentointi, jonka jälkeen vastuu ongelmakohdan paikantamisesta ja korjaamisesta siirtyy ohjelman kehittäjille. Virheenjäljitys (debugging) on kehitystyöhön liittyvä toimenpide, jonka tarkoituksena on jäljittää, analysoida ja poistaa testauksella havaitut virheet. Virheiden paikantamista helpottaa merkittävästi mitä aikaisemmin virhe havaitaan. Kun virhekohta löydetään, se korjataan ja ohjelma palautetaan takaisin testaajien testattavaksi. Mikäli virheenjäljityksellä ei suoraan löydetä virhekohtaa, voidaan sen avulla kuitenkin tehdä päätelmiä virheen todennäköisistä syistä ja mahdollisesta alkuperästä. Tiedon perustella testaajat voivat kohdentaa lisätestausta epäiltyihin virhekohtiin. (Pressman 2005, ). 9

10 Virheenjäljitystä tehdään ohjelmoinnin yhteydessä ohjelmoijan toimesta ja siihen tarkoitettu työkalu sisältyy usein kehitysympäristöön (voidaan myös käyttää erillistä ohjelmaa). Virheenjäljittäjän (debugger) perusominaisuuksiin kuuluu, että ohjelman kulkua ja muuttujia voidaan seurata vaiheittain esim. rivi tai funktiokutsu kerrallaan ja ohjelmaan voidaan tehdä hallitusti muutoksia. Esimerkiksi ohjelmoijan tyypillinen manuaalinen debuggaus -tapa, jossa ohjelman etenemistä seurataan ylimääräisillä tulostuksilla ohjelmakoodin seassa sisältää turhan riskin ylimääräisille virheille. Virheenjäljittäjä soveltuu erityisesti loogisten ohjelmavirheiden paikantamiseen. Useimpiin virheenjäljittäjiin sisältyy myös hyödyllisiä kooditarkastustoimintoja kuten syntaksivirheiden etsintä, automaattinen kooditäydennys ja koodimuotoilun asetustoiminto. Luku 2 Testaus ohjelmiston elinkaaressa Ohjelmiston elinkaari on aika, joka kuluu ohjelmiston kehittämisen aloittamisesta sen poistamiseen käytöstä (Haikala & Märijärvi 2002, 36). Ohjelmiston elinkaari ja siihen sisältyvän työn jakaminen vaiheisiin muodostaa ohjelmistokehityksen prosessimallin, jonka tunnetuin muoto ns. vesiputousmalli on esitetty kuvassa 1. Kuva 1. Vesiputousmalli (Haikala & Märijärvi 2002, 36). Vesiputousmallissa elinkaaren vaiheet esitetään peräkkäisinä askelmina mutta käytännössä ohjelmistokehitys ei koskaan etene suoraviivaisesti vaihe vaiheelta alusta loppuun vaan usein seuraava vaihe aloitetaan ennen kuin edellinen vaihe on saatu päätökseen ja kertaalleen suoritettuihin vaiheisiin joudutaan palaamaan uudelleen prosessin aikana. Vesiputousmalli antaa kuitenkin perusmallin kehitystyön vaiheistamiseen ja sen pohjalta on kehitetty useita prosessimallityyppejä (protoilumalli, evo-malli, spiraalimalli, RUP, ketterät menetelmät jne.), joita voidaan soveltaa käytäntöön kunkin ohjelmistoprojektin erityispiirteiden mukaan. 10

11 Riippumatta siitä, mitä ohjelmiston kehitysmallia käytetään, testaus on keskeinen osa ohjelmiston elinkaarta. Seuraavassa kappaleessa esitetään testauksen V-malli, joka on yksi tapa kuvata testausprosessi ja siihen sisältyvät vaiheet ohjelmiston elinkaaressa. V-malli ja testaustasot V-malli on testauksen prosessimalli, joka jakaa testaustyön osavaiheisiin eli testaustasoihin. Testaustyön vaiheistaminen mahdollistaa tehokkaamman ja tarkemman testauksen, sillä eri testaustasoilla testausta voidaan kohdentaa erityyppisten ja eri kehitysvaiheille ominaisten virheiden etsintään. Kuvassa 2 on esitetty nelitasoinen V-malli, jonka testaustasot ovat moduulitestaus, integrointitestaus, järjestelmätestaus ja hyväksymistestaus. Käytännössä testaustasojen määrä vaihtelee riippuen ohjelman elinkaarimallista ja ohjelmistoprojektin koosta ja luonteesta. Kuva 2. Testauksen V-malli. V-mallin mukaisesti testauksen suunnittelua tehdään vastaavalla tasolla ohjelmiston suunnittelun kanssa. Suunnittelu aloitetaan mahdollisimman varhaisessa vaiheessa ja suunnittelua täydennetään ohjelmistoprosessin edetessä. Testauksen suunnittelu ja testaustulosten todentaminen perustuvat ohjelmistolle asetettuihin tavoitteisiin ja vaatimuksiin, jotka on määritelty ohjelmiston määrittely- ja suunnitteludokumentaatiossa. Testauksen suorittaminen aloitetaan ohjelmointivaiheessa moduulitason testauksella. Moduulien suunnittelu, ohjelmointi, testaus ja integrointi määritellään usein ohjelman toteutusvaiheeksi, jonka aikaisesta testauksesta käytetään myös nimitystä alemman tason testaus. Alemman tason testausta tekevät tavallisesti ohjelman kehittäjät ja testauksen tavoitteena on ohjelmointi- ja suunnitteluvirheiden eliminointi. Ylemmän tason testauksella tarkoitetaan ohjelman toteutusvaiheen jälkeen tapahtuvaa erillistä testausvaihetta, jonka suorittavat testaukseen erikoistuneet ammattilaiset. Ylemmän tason testaukseen kuuluvat V-mallin järjestelmä- ja hyväksymistestaus. Järjestelmätestauksen tavoitteena on löytää ristiriidat ja virheet ohjelman todellisen toiminnan ja sille määriteltyjen 11

12 ohjelmistovaatimusten välillä. Hyväksymistestaus on testausprosessin viimeinen vaihe, jossa varmistetaan, että toteutettu järjestelmä vastaa tarkoitustaan eli niitä tavoitteita ja tarpeita, joita varten järjestelmää on alun perin lähdetty tekemään. Moduulitestaus Moduuli- eli yksikkötestauksessa (module testing, unit testing) tarkastelun kohteena on ohjelman pienin itsenäinen yksikkö eli moduuli/komponentti. Moduulin testaaja on yleensä moduulin tekijä eli ohjelmoija ja tyypillisesti moduuli testataan välittömästi ohjelmoinnin jälkeen kehitysympäristöön sisältyvillä yksikkötestauksen työkaluilla. Ohjelmarakenteen testaaminen moduuli kerrallaan parantaa testauksen hallittavuutta ja tehokkuutta. Ohjelman eri osia voidaan testata samanaikaisesti, usean eri henkilön toimesta ja toisistaan riippumatta. Lisäksi virheen paikallistaminen tiettyyn moduuliin mahdollistaa ongelmakohdan eristämisen ja nopeuttaa virheen korjausta. (Myers 1979, 77). Moduulin toteutusperiaatteesta johtuen moduulin toimintaa testataan kahdesta näkökulmasta: 1) moduulin ulkoista toimintaa analysoimalla, missä selvitetään toteuttaako moduuli spesifikaation mukaiset toiminnot ja 2) etsimällä virheitä ohjelmakoodin sisäisestä rakenteesta ja loogisesta toteutuksesta. Tyypillisiä testauksen kohteita ovat moduulin rajapintafunktiot, paikalliset tietorakenteet ja tiedon käyttö, loogiset ohjelmapolut, ohjausrakenteet, silmukat, virheidenkäsittely ja arvoalueiden rajakohdat (Pressman 2005, 363). Ohjelmakoodin rakenteen ja loogisen toiminnan analysointiin käytetään ns. valkolaatikkotestauksen menetelmiä (ks. sivu 35, Valkolaatikkotestauksen menetelmät). Tavoitteena on kehittää joukko testitapauksia, jotka testaavat ohjelmakoodin mahdollisimman kattavasti. Testitapausten suunnitteluun käytetään sekä ohjelman lähdekoodia että ohjelman toiminnan määrittelevää spesifikaatiota. Valkolaatikkotestauksella saavutettua kattavuutta täydennetään moduulin toiminnallisella testauksella, jossa tapauskohtaisesti sovelletaan erilaisia mustalaatikkotestauksen menetelmiä (ks. sivu 38, Mustalaatikkotestauksen menetelmät). Ohjelmamoduulien testaaminen voidaan aloittaa vaikka koko ohjelma ei olekaan valmis. Tällöin testauksen suorittamiseksi tehdään ns. testipetejä (test bed). Testipeti sisältää testiajureita (test driver), jotka simuloivat ohjelman ympäristöä (esim. testattavan moduulin funktioiden tai metodien kutsuminen) ja tynkiä (stub), jotka korvaavat puuttuvia ohjelmakomponentteja, joita testattava moduuli tarvitsee suorituksen aikana. (Haikala & Märijärvi 2002, 287). Integrointitestaus Moduulitestausta seuraava taso on integraatiotestaus (integration testing), jossa arkkitehtuurisuunnitelman mukainen ohjelmarakenne kootaan ja samalla etsitään virheitä liitettyjen komponenttien rajapinnoista. Testitapausten kehittäminen perustuu ohjelman arkkitehtuurin kuvaukseen ja mo- 12

13 duulien rajapintamäärittelyihin. Vaiheittaisessa integraatiossa uusi, yksikkötestattu komponentti lisätään aina jo aiemmin testattuun rakenteeseen. Vastakohtana vaiheittain etenevälle integraatiolle on ns. kertarysäys (big-bang), jossa testatut komponentit liitetään kerralla yhteen. Vaiheittaisessa menetelmässä uuden integraation testaaminen aiheuttaa aina myös kaikkien aiemmin integroitujen osien uudelleen testaamisen, jolloin testausta tehdään määrällisesti enemmän sekä monipuolisemmin kuin kertarysäysmenetelmässä (Myers 1979, 91). Luonnollisesti myös virheiden etsintää, jäljitystä ja korjausta on huomattavasti helpompi tehdä, kun integrointi toteutetaan komponentti kerrallaan. Kertarysäysmenetelmää voidaan hyödyntää esim. tilanteessa, jossa halutaan arvioida järjestelmän valmiutta integraatiotestaukseen tai tilanteessa, jossa järjestelmään tehty muutos on pieni ja paikallinen (Kasurinen 2013, 55). Vaiheittainen integraatio toteutetaan tavallisesti joko alhaalta ylöspäin tai ylhäältä alaspäin. Kokoava integrointi (bottom-up) aloitetaan komponenttihierarkiassa alimpana olevista, riippumattomista komponenteista. Riippumaton komponentti on päätekomponentti, josta ei kutsuta muita moduuleja. Komponentin integraatioon riittää ylemmän tason toimintaa simuloivan testiajurin kehittäminen. Integraatiojärjestyksestä johtuen kokoavassa integroinnissa ei tarvita testitynkiä. Komponenttien lisäysjärjestys voidaan muutoin valita vapaasti, kunhan alemman tason moduuli on testattu ennen sitä kutsuvaa ylemmän tason moduulia. Alhaalta ylöspäin etenevässä integraatiossa toimiva ohjelma on valmis vasta, kun viimeisinkin komponentti on lisätty ohjelmaan. Kuva 3. Kokoava integrointi (Bottom-up) 13

14 Päinvastainen vaiheittaisen integraation lähestymistapa on osittava integrointi (top-down), jossa integroimissuunta on ylhäältä alaspäin ja lähtöpisteenä on ylin tai keskeisin komponentti esim. pääohjelma. Testattavaa komponenttia varten toteutetaan tarvittavista alemman tason komponenteista testityngät. Testitynkien kehittäminen aloitetaan jo moduulivaiheessa ja usein moduulitestaus ja integrointitestaus etenevät rinnakkain. Testauksen edetessä testityngät korvautuvat valmiilla, testatuilla komponenteilla kunnes ohjelman integraatio on valmis. Ylhäältä alaspäin etenevässä integraatiossa on useita vaihtoehtoisia etenemispolkuja ja ohjelmasta voidaan jo aikaisessa vaiheessa rakentaa toimiva ns. luurankoversio. Menetelmän haasteena on toteuttaa yksinkertaisia testitynkiä, jotka simuloivat lopullisia toteutuksia oikein. Yhdestä testityngästä voidaan joutua tekemään useita eri versioita, jotta kaikki testitapaukset saadaan testatuksi. Työläs menetelmä houkuttelee myös jättämään osan testitapauksista odottamaan alempien komponenttien valmistumista, jolloin riskinä on niiden unohtuminen ja testauksen jääminen vaillinaiseksi. Testityngät ovat aina myös mahdollisia virheiden lähteitä, joten ohjelmakomponenttien lisäksi myös sijaiskomponentit tulee testata ennen käyttöönottoa. Kuva 4. Osittava integrointi (Top-down) Integraation toteutustapa valitaan aina tapauskohtaisesti. Hyvä lähestymistapa on integroida ohjelman kriittiset ja virhealttiit osat mahdollisimman aikaisessa vaiheessa. Tällaisia ovat esim. uudet algoritmit, monimutkaiset moduulit ja syöte- ja tulostustoimintoja sisältävät moduulit. Jos ohjelman kriittiset osat ovat enemmän painottuneet komponenttihierarkian alemmille tasoille, on järkevää aloittaa integroiminen alhaalta ylöspäin. Alhaalta ylöspäin edetessä testitapausten toteuttaminen 14

15 on usein myös yksinkertaisempaa ja helpompaa. Ylhäältä alaspäin integroitaessa etuna on, että ohjelman lopullista toimintaa voidaan demonstroida jo varhaisessa vaiheessa ja hyödyntää esim. käytettävyyden testaamisessa. (Myers 1979, ). Edellä kuvattu itsenäisten ohjelmakomponenttien integraatio kuuluu alemman tason testaukseen. Vaiheittaista integraatiota käytetään myös järjestelmätason integroinnissa esimerkiksi, kun itsenäisiä ohjelmia liitetään yhteen, alijärjestelmistä kootaan yhdessä toimiva ylemmän tason järjestelmä tai paikallisista järjestelmistä muodostetaan verkon yli kommunikoivia hajautettuja järjestelmiä. Top-down ja bottom-up eivät myöskään ole ainoita integraation toteutustapoja. Esimerkiksi voileipä- eli sandwich-integraatio on kokoavan ja jäsentävän tavan yhdistelmä, jossa integrointia lähdetään toteuttamaan yhtä aikaa molemmista päistä. Menetelmä tehostaa integraatiota mutta sen hallinta on huomattavasti haasteellisempaa. Järjestelmätestaus Järjestelmätestaus (system testing) suoritetaan testiympäristössä ohjelmistolle, jossa ei ole enää sijaiskomponentteja. Testauksessa järjestelmää tarkastellaan kokonaisuutena ja tapauskohtaisesti sovelletaan erilaisia korkean tason testausmenetelmiä. Objektiivisuuden säilyttämiseksi järjestelmätestauksen toteuttajina ovat kehitystiimin ulkopuoliset testaajat, jotka voivat olla kehittäjäyrityksen työntekijöitä tai ulkopuolisia, testaukseen erikoistuneita ammattilaisia. Järjestelmätestauksen tavoitteena on selvittää täyttääkö järjestelmä sille asetetut tavoitteet ja esiintyykö järjestelmän/ohjelman ja sen määrittelyn välillä ristiriitoja. Ohjelmalle asetettujen toiminnallisten tavoitteiden lisäksi järjestelmätestauksessa tarkastellaan ei-toiminnallisia vaatimuksia kuten suorituskykyä, käytettävyyttä, tietoturvaa ja luotettavuutta. Testaustyypistä riippuen järjestelmän laadullisia ominaisuuksia tarkastellaan ns. normaaliolosuhteissa ja normaalista poikkeavissa kuormitustilanteissa. Järjestelmätason testausta tehdään erityisesti ohjelmistotuotteille, jotka toteutetaan sopimusperusteisesti tai laajan asiakaskunnan käyttöön. Pienten ohjelmien kuten kokeellisten tai ohjelmoijan omaan käyttöön tarkoitettujen ohjelmien testauksessa riittää usein ohjelman toiminnallisuuden testaaminen (Myers 1979, 106). Toiminnallinen testaus Ohjelman toiminnallisen testauksen (functional testing, function testing) tarkoituksena on löytää ristiriitaisuudet ohjelman ulkoisen toiminnan ja toiminnallisen määrittelyn välillä. Toiminnallinen määrittely on spesifikaatio, jossa jokainen ohjelman toiminto on kuvattu yksityiskohtaisesti käyttäjän näkökulmasta. Myös toimintojen testaus suoritetaan järjestelmän ulkoista eli käyttäjälle näkyvää käyttäytymistä analysoimalla. Testitapausten suunnittelussa hyödynnetään pääasiallisesti mustalaatikkotestauksen menetelmiä. Esimerkiksi ekvivalenssiositus, raja-arvoanalyysi, syyseuraus-mallinnus ja virheenarvaus ovat tyypillisiä toiminnalliseen testaukseen sovellettuja tekniikoita (Myers 1979, 108). Toiminnallinen testaus voidaan aloittaa heti, kun toimintoja on valmiina 15

16 suoritettavaksi tai sitten, kun yksikkö- ja integraatiotestaus on saatu päätökseen. Toiminnallinen testaus sijoitetaankin usein omaksi vaiheeksi ennen varsinaista järjestelmätestausta (Myers ym. 2012, 117; Kit 1995, 98-99). Käytettävyystestaus Käytettävyydeltään hyvä ohjelma on tehty käyttäjän tarpeisiin, mikä tarkoittaa, että ohjelma sovitetaan käyttäjän toimintatapoihin eikä päinvastoin (Kit 1995, 96). Käytettävyystestauksessa (usability testing) pyritään löytämään järjestelmän toiminnot ja käyttötilanteet, jotka ovat hankalia tai vaikeaselkoisia käyttäjille. Käytettävyyden vaatimukset toteutetaan käyttöliittymässä. Käytännössä käytettävyystestaus painottuukin juuri käyttöliittymän toimivuuden ja tarkoituksenmukaisuuden analysointiin (Kasurinen 2013, 70). Käytettävyyden testausta voidaan suorittaa kaikissa ohjelmistokehityksen vaiheissa ja erilaisia menetelmiä sovelletaan ohjelmiston valmiusasteen mukaisesti. Tavallinen tapa on järjestää koetilanne, jossa käyttäjä kertoo ääneen ajattelemalla, mihin hänen toimintansa käyttötilanteessa perustuu. Tarkempaa analysointia varten koetilanne myös taltioidaan. Ongelmia paljastavasta käytettävyystauksesta on sitä enemmän hyötyä, mitä aikaisemmin sen tuloksia saadaan. Esimerkiksi ns. pikatestit käyttöliittymän näköiskuvilla ilman toiminnallisuutta mahdollistavat käytettävyystestauksen jo käyttöliittymän suunnitteluvaiheessa. Luotettavuustestaus Luotettavuustestaus (reliability testing) perustuu ohjelmassa esiintyvien vikojen ja häiriöiden mittaamiseen ja tilastolliseen analyysiin. Järjestelmän luotettavuustason arvioinnissa kiinnitetään huomiota mm. häiriöiden esiintymistiheyteen ja vakavuuteen. Lisäksi voidaan kerätä tietoa vikojen korjaamiseen käytetystä ajasta. Testausprosessin aikana kerättyjen tietojen perusteella voidaan todentaa milloin ohjelmiston luotettavuus (ohjelman häiriötön toiminta tietyssä ympäristössä tietyn ajanjakson aikana) vastaa vaatimusmäärittelyssä asetettuja tavoitteita. Luotettavuudelle määriteltyä tavoitetasoa voidaan käyttää myös testauksen lopetuskriteereinä esim. tuotantoon julkaisua varten. (Kit 1995, 159). Tietoturvatestaus Tietoturvatestauksella (security testing) selvitetään järjestelmään toteutettujen tietoturvatoimintojen (palomuuri, tiedon salaus ja käyttöoikeudet) kykyä torjua väärinkäytöksiä ja uhkia, jotka tulevat järjestelmän ulkopuolelta (virukset, haittaohjelmat tai asiattomat käyttäjät). Tietoturvatestauksella pyritään löytämään järjestelmässä olevia heikkoja kohtia ja haavoittuvuuksia, jotka aiheuttavat tietoturva-aukkoja järjestelmään. Testeillä voidaan simuloida hyökkäyksiä, jotka kohdistuvat havaittuihin tai mahdollisiin tietoturva-aukkoihin. Tietoturvaan liittyviä ongelmia voi syntyä missä ohjelmistonkehitysvaiheessa tahansa, joten myös tietoturvatestausta tulisi tehdä kaikilla testauksen tasoilla. 16

17 Tietoturvan ylläpito ja testaus ovat keskeisiä toimintoja myös ohjelmiston käyttöönoton jälkeen. (Pressman 2005, 377). Toipuvuustestaus Toipuvuustestaus (recovery testing) on järjestelmätestauksen muoto, jossa testataan järjestelmän kykyä toipua erilaisista häiriötilanteista. Toipuvuustestaus voi liittyä myös tietoturvatestaukseen, jossa järjestelmä kaatuu ulkopuolisen hyökkäyksen seurauksena. Toipuvuustestaukseen sisältyy häiriötilannetestausta, jossa arvioidaan järjestelmän toimintakykyä poikkeustilanteissa sekä toipumismenettelyjen testausta, jossa arvioidaan järjestelmän kykyä palautua häiriötilanteesta ns. normaalitilaan. (Pressman 2005, 377). Suorituskykytestaus Monilla sovelluksilla on erityisiä suorituskykyyn ja tehokkuuteen liittyviä vaatimuksia kuten vastausaika, välityskyky, saatavuus ja resurssien käyttöaste (muisti, CPU), joilla mitataan järjestelmän kykyä suoriutua sille määritellyistä tehtävistä. Suorituskykytestauksen (performance testing) tavoitteena on testata vastaako järjestelmän toiminta asetettuja suorituskykyvaatimuksia ja löytyykö järjestelmästä ns. pullonkauloja, jotka heikentävät järjestelmän toimintaa kokonaisuutena. Suorituskykytestausta voidaan tehdä kaikilla testaustasoilla (yksittäisille komponenteille, integraation yhteydessä ja järjestelmätasolla) riippuen toteutettavasta ohjelmasta/järjestelmästä ja sille asetetuista suorituskykyvaatimuksista. Suorituskykytestausta varten määritellään kuormitustaso ja laite- ja ohjelmistokonfiguraatio, joilla testausta suoritetaan sekä suorituskyvyn tavoitetaso, johon tuloksia verrataan. Suorituskykytestaukseen on olemassa erityisiä ohjelmallisia työkaluja, joilla voidaan simuloida käyttötilanteita ja mitata haluttuja ominaisuuksia dynaamisesti ohjelman suorituksen aikana (ks. Luku 5 Testauksen työkalut). Järjestelmän suorituskykyä voidaan arvioida myös käyttäjän subjektiivisen kokemuksen perusteella eli kuinka järjestelmä käyttäjän mielestä suoriutuu sille määrätyistä tehtävistä (Pressman 2005, 378) Kuormitustestaus ja stressitestaus Kuormitustestauksella tutkitaan järjestelmän käyttäytymistä erilaisilla kuormituksilla esim. samanaikaisten käyttäjien määrä (load testing) tai käsiteltävän tiedon määrä (volume testing). Kuormitustestauksella pyritään myös selvittämään maksimitaso kuormitukselle, jonka järjestelmä kestää kaatumatta. 17

18 Stressi- eli rasitustestauksella (stress testing) tutkitaan kuormitushuippuja, joissa järjestelmä joutuu äärirajoille ja selvitetään kuinka järjestelmä niihin reagoi. Rasitustestauksella voidaan myös selvittää yläraja rasitukselle, jonka ylittyessä järjestelmä ei enää kykene suoriutumaan tehtävistään vaatimusten mukaisesti esim. samanaikaisten käyttäjien maksimimäärä, yhtäaikaiset tietokantatransaktiot, palvelimelle tehtävien pyyntöjen tiheys jne. Kuormitus- ja stressitestauksessa käytetään tavallisesti apuna simulaattoreita, joilla voidaan luoda virtuaalisia käyttäjiä ja simuloida yhtäaikaisia tapahtumia. (Myers 1979, 113; Kasurinen 2013, 71-72) Muita tärkeitä järjestelmätestauksen muotoja ovat: Yhteensopivuustestaus (compatibility testing), jossa selvitetään ohjelman/järjestelmän yhteensopivuutta laiteympäristön, käyttöjärjestelmän, tietokannan ja muiden ohjelmistojen kanssa esim. selaimet. Asennettavuus- ja asennustestaus (installability/installation testing), joissa varmistetaan ohjelmiston asennettavuus. Käyttäjädokumentaation (user documentation testing) testaus, jolla varmistetaan sekä käyttöohjeiden että ohjelmiston käytettävyyden laatu. Näillä kaikilla pyritään varmistamaan, että järjestelmä on valmis siirrettäväksi lopulliseen käyttöympäristöön, jossa suoritetaan testauksen viimeinen vaihe eli virallinen hyväksymistestaus. (Myers 1979, ; Kit 1995, 128). Hyväksymistestaus Hyväksymistestauksella (acceptance testing) todennetaan kuinka hyvin lopputuote vastaa tarkoitustaan eli niitä tarpeita ja odotuksia, joita asiakas- ja käyttäjävaatimusten määrittelyssä asetettu. Jos kyseessä on sopimusasiakkuus, hyväksymistestauksella myös varmistetaan, että asiakkaalle luovutettava ohjelmisto täyttää ne tavoitteet, joita sopimukseen on kirjattu. Asiakasprojekteissa virallinen hyväksymistestaus tehdään tavallisesti asiakkaan toimesta. Testaus voidaan toteuttaa pitempänä ajanjaksona ja usean testin sarjana, jolloin virheiden kumuloituvat vaikutukset voidaan paremmin havaita (Pressman 2005, 375). Hyväksymistestauksen lopputuloksena vahvistetaan virallisesti, että tuote siirtyy asiakkaan omaisuudeksi ja ohjelmiston kehitystyö päättyy. Alfa- ja beta-testaus Laajalle asiakaskunnalle suunnattujen off-the-shelf -ohjelmistotuotteiden kohdalla käytetään alfa- ja beta-testauksena tunnettua hyväksymistestauksen muotoa, jossa valitaan rajattu joukko 18

19 asiakkaita ja/tai loppukäyttäjiä testaamaan tuotetta. Prosessissa löytyvät virheet ovat tyypillisesti sen kaltaisia, joita erityisesti loppukäyttäjät ovat hyviä havaitsemaan (Pressman 2005, 375). Alfa-testaus tehdään yleensä ohjelman toimittajan tiloissa, jolloin kehittäjillä on mahdollisuus seurata ja kontrolloida testauksen suoritusta. Beta-testauksessa valitut asiakaskunnan edustajat testaavat ohjelmaa omissa tiloissaan itsenäisesti ja raportoivat havaitsemistaan ongelmista ohjelman kehittäjille. Alfa- ja beta-testauksen tavoitteena on varmistaa, että valmis ohjelmaversio täyttää potentiaalisen asiakaskunnan odotukset. Pyrkimyksenä on kehittää kaupallisesti kannattava tuote, joten testaustulosten perusteella tuotteeseen voidaan tehdä isojakin muutoksia ennen virallista julkaisua. Ylläpito- ja uudelleentestaus Kun ohjelmaan tai järjestelmään tehdään mikä tahansa muutos, tulee uusi versio testata. Uudelleentestaus eli regressiotestaus on jatkuva prosessi, jonka tarkoituksena on varmistaa, että tehtyjen muutosten tai korjaustoimenpiteiden jälkeen aiemmin havaittuja virheitä ei enää esiinny ja että muutokset eivät ole aiheuttaneet uusia virheitä. (Pressman 2005, 369). Uudelleentestausta kohdennetaan muutoskohtien lisäksi valikoidusti myös muutosten ulkopuolisille alueille. Muutosten vaikutusten arviointia voidaan käyttää perusteena testitapausten valinnassa. Uudelleentestaus voi tulla erittäin kalliiksi, joten siinä pyritään hyödyntämään mahdollisimman paljon automatisointia. Esimerkkejä testaustyökalujen automatisoiduista toiminnoista ovat mm. testitapausten ja testidatan automaattinen generointi, testitapausten nauhoittaminen ja automaattinen toistaminen sekä testitulosten automaattinen kirjaaminen ja vertaaminen odotettuihin lopputuloksiin. (Haikala & Märijärvi 2002, ). Ylläpitotestauksella tarkoitetaan muutostestausta, jota tehdään ohjelman käyttöönoton jälkeen. Esimerkkejä ylläpitotestauksesta ovat mm. uuden päivitetyn ohjelmaversion testaaminen ennen julkaisua, korjattujen vikojen seurauksena tehtävä uudelleentestaus, muunnos- eli konversiotestaus (esim. järjestelmä siirretään uudelle alustalle) tai testaus tilanteessa, kun järjestelmää ollaan poistamassa käytöstä. Luku 3 Testausprosessi ja sen hallinta Testausprosessin vaiheet ovat testauksen suunnittelu, testauksen suorittaminen, tulosten tarkastelu ja testausprosessin päättäminen (Haikala & Märijärvi 2002, 281). Testausprosessin onnistunut läpivienti perustuu samoihin elementteihin kuin minkä tahansa hyvin hallitun projektityön. Niihin kuuluvat mm. hyvin organisoitu ja johdettu testaustiimi 19

20 ammattitaitoiset tekijät työn jakaminen helpommin hallittaviin osavaiheisiin työn suunnittelu ja tarvittavien resurssien määrittäminen työtä helpottavien käytäntöjen, menetelmien ja välineiden omaksuminen ja käyttöönotto projektin seuranta ja riskien hallinta Katselmoinnit, arvioinnit ja testaustoiminnan mittaaminen ovat konkreettisia käytännön toimia, joilla prosessin eteneminen tehdään näkyväksi ja varmistetaan testaustyön laatu. Testaustyön roolit ja tehtävänjako Testausta tehdään tiimityönä ja siinä tarvitaan erilaisia osaajia. Testaustiimin koko vaihtelee testattavan kohteen ja projektin koon mukaisesti mutta pienenkin projektin kohdalla työtehtävien ja vastuiden jakaminen mahdollistavat hallitun ja tehokkaan työskentelyn. Testaustiimi toimii myös tiiviissä yhteistyössä ohjelman kehittäjien kanssa. Testauksen organisointi, roolit ja vastuut määritellään testaussuunnitelmassa, jonka mukaisesti työtehtäviä jaetaan. Tyypillisesti testaustiimin vetäjänä toimii testauspäällikkö, jonka vastuulla on testauksenhallintaan liittyvät tehtävät kuten testaussuunnitelman laatiminen, tarvittavien resurssien määrittely ja hankkiminen, prosessin etenemisen seuranta ja ohjaus sekä testaustulosten arviointi ja loppuraportin laatiminen. Varsinaisen testaustyön tekevät testaajat, jotka suunnittelevat, suorittavat ja dokumentoivat testit. Testaajien tehtäviin kuuluu myös havaittujen poikkeamien analysoiminen ja raportointi. Lisäksi testaajat voivat toimia testausprosessissa tuotettujen dokumenttien tarkastajina ja katselmoijina. Testaustiimin muut roolit määräytyvät työtehtävien mukaan. Osa tehtävistä vaatii erityisasiantuntemusta, jolloin vastuuhenkilön tehtävänä voi olla pelkästään esim. testiympäristön rakentaminen, työkalujen asentaminen ja ylläpito, testauksen automatisointi, testitulosten analysointi jne. Testauksen organisoinnissa pyritään testauksen riippumattomuuteen ja testaustiimin itsenäisyyteen (Kit 1995, 174). Alemman tason testausta tekevät usein ohjelman kehittäjät. Isot ja vaativat projektit toteutetaan usealla testaustasolla, jolloin vastuut voidaan jakaa eri tahoille. Ylemmän tason testaus voidaan esimerkiksi ulkoistaa osittain tai kokonaan kehitysorganisaation ulkopuolisille testaukseen erikoistuneille ammattilaisille. Testauksen suunnittelu Testauksen suunnittelu aloitetaan mahdollisimman varhaisessa vaiheessa yhdessä ohjelmiston suunnittelun kanssa. Testauksen suunnittelun tavoitteena on liittää testaus osaksi hyvin suunniteltua ja onnistuneesti etenevää ohjelmistoprojektia. Resurssit ovat usein rajalliset, joten testauksessa joudutaan tekemään valintoja kuinka paljon ja kuinka kattavasti testejä suoritetaan. Hyvä suunnittelu 20

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Ohjelmiston testaussuunnitelma

Ohjelmiston testaussuunnitelma Ohjelmiston testaussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä lukaa antaa yleiskuvan koko testausdokumentista.

Lisätiedot

Convergence of messaging

Convergence of messaging Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO

Lisätiedot

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan

Lisätiedot

Kontrollipolkujen määrä

Kontrollipolkujen määrä Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

T Testiraportti - järjestelmätestaus

T Testiraportti - järjestelmätestaus T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

Lisätiedot

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa: Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/jekahkon/wclique/testplan.html WCLIQUE Ohjelmistoprojekti Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com, 75014C,

Lisätiedot

58160 Ohjelmoinnin harjoitustyö

58160 Ohjelmoinnin harjoitustyö 58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista

Lisätiedot

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tieran toiminta perustuu osaamisverkoston rakentamiseen, mikä

Lisätiedot

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli

Lisätiedot

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut

Lisätiedot

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma PULSU Syksy 2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Heikki Manninen Noora Joensuu

Lisätiedot

Ohjelmistotuotteen hallinnasta

Ohjelmistotuotteen hallinnasta Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista

Lisätiedot

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II 7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja

Lisätiedot

Kuopio Testausraportti Asiakkaat-osakokonaisuus

Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi 1 Yleistä Palvelun kehitys jakautuu vaiheisiin, joiden väleissä

Lisätiedot

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tiera on vuonna 2010 perustettu yli 200:n kuntatoimijan omistama

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Katselmointi osana laadunvarmistusta... 2 2 Yleistä katselmoinneista...

Lisätiedot

Testaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science

Testaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science Testaustyökalut Luento 11 Antti-Pekka Tuovinen 25 April 2013 1 Tavoitteet Työkalutyyppejä Testauksen hallinta Testien määrittely Staattinen analyysi Dynaaminen testaus 25 April 2013 2 1 Työkalut ja testaus

Lisätiedot

Laadunvarmistustekniikat

Laadunvarmistustekniikat Laadunvarmistustekniikat Ohjelmistojen laadunvarmistustekniikoita: testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia

Lisätiedot

Kuopio Testausraportti Kalenterimoduulin integraatio

Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio Testausraportti Kalenterimoduulin integraatio Kuopio, testausraportti, 22.4.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 22.4.2002 Matti Peltomäki Ensimmäinen versio 0.9 22.4.2002 Matti

Lisätiedot

Hirviö Laadunvarmistussuunnitelma

Hirviö Laadunvarmistussuunnitelma Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 30. marraskuuta 2004 1 Sisältö 1 Johdanto 3 1.1 Testauksen tavoitteet

Lisätiedot

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

Dynaaminen analyysi I

Dynaaminen analyysi I Dynaaminen analyysi I Luento 6 Antti-Pekka Tuovinen 4 April 2013 1 Tavoitteet Testitapausten suunnittelun ja suorituksen perusteet Black-Box testitapausten suunnittelu Ekvivalenssiluokat Raja-arvo (reuna-arvo)

Lisätiedot

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0 TESTIRAPORTTI - VYM JA KANTA Versio 1.0 i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen

Lisätiedot

Yksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen

Yksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen Yksikkötestaus Kattava testaus Moduulitestaus Ohjelman testaus 1 Kattava testaus Testauksen perimmäinen tarkoitus on LÖYTÄÄ VIRHEITÄ Testaus pitäisi olla täydellinen: - Jokainen pyydetty arvo pitäisi testata

Lisätiedot

Määrittelyvaihe. Projektinhallinta

Määrittelyvaihe. Projektinhallinta Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti

Lisätiedot

Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle

Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle Tarkistuslista on suunniteltu käytettäväksi hyväksymistestauksen suunnittelussa, valmiuksien arvioinnissa ja katselmoinnissa.tämä tarkistuslista

Lisätiedot

Testauspäällikön tarinoita Arto Stenberg

Testauspäällikön tarinoita Arto Stenberg Testauspäällikön tarinoita Arto Stenberg 2.12.2013 A software foundry that helps companies create breakthrough product innovations. We help our clients to: 1. Create new products 2. Scale out their product

Lisätiedot

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista

Lisätiedot

Standardi IEC Ohjelmisto

Standardi IEC Ohjelmisto Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,

Lisätiedot

Testaussuunnitelma Labra

Testaussuunnitelma Labra Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

LAATURAPORTTI Iteraatio 1

LAATURAPORTTI Iteraatio 1 LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja

Lisätiedot

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita 581259 Ohjelmistotuotanto 378 Lemström, 2006-2011 581259 Ohjelmistotuotanto Kiitos Tuomolle kuvasta 379 Ohjelmistotuotannon perustehtävät projektinhallinta:

Lisätiedot

Hirviö Laadunvarmistussuunnitelma

Hirviö Laadunvarmistussuunnitelma Hirviö Laadunvarmistussuunnitelma Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 8. helmikuuta 2005 1 Sisältö 1 Johdanto 3 1.1 Testauksen tavoitteet

Lisätiedot

Menetelmäraportti Ohjelmakoodin tarkastaminen

Menetelmäraportti Ohjelmakoodin tarkastaminen Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5

Lisätiedot

Katselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988)

Katselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988) Katselmoinnit Johdatus ohjelmistotekniikkaan Sami Kollanus 19.10.2004 Katselmoinnin määritelmä (IEEE 1988) An evaluation of software element(s) or projects status to ascertain discrepancies from planned

Lisätiedot

Katselmoinnin määritelmä. Katselmoinnit osa 1. ja vielä ajatuksia katselmoinneista. Katselmointi. Katselmointi, katselmus (review) IEEE Std

Katselmoinnin määritelmä. Katselmoinnit osa 1. ja vielä ajatuksia katselmoinneista. Katselmointi. Katselmointi, katselmus (review) IEEE Std Katselmoinnin määritelmä Katselmoinnit osa 1 Sami Kollanus 1.12.2006, katselmus (review) IEEE Std 1028-1988 Ohjelmiston osien tai projektin tilan arviointi (evaluation), jonka tarkoitus on tunnistaa tuotosten

Lisätiedot

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004 Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen

Lisätiedot

TESTIRAPORTTI - XMLREADER-LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)

TESTIRAPORTTI - XMLREADER-LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2) TESTIRAPORTTI - XMLREADER-LUOKKA Versio 1.0 (luonnos 2) Copyright Comptel Oyj i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin

Lisätiedot

Automaattinen yksikkötestaus

Automaattinen yksikkötestaus Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä

Lisätiedot

Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi

Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi 10. Tarkastukset Tarkastus (inspection) on tehokas analyysitekniikka, jota voidaan käyttää minkä tahansa projektin tuotoksen läpikäyntiin. Tarkastus on systemaattinen ja yksityiskohtainen katselmointi

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

VÄLI- JA LOPPURAPORTOINTI

VÄLI- JA LOPPURAPORTOINTI Tuija Nikkari 2012 VÄLI- JA LOPPURAPORTOINTI Raportointikoulutus 23.8.12 Raportoinnin tarkoitus Raportoinnin tehtävänä on tuottaa tietoa projektin etenemisestä ja tuloksista rahoittajalle, yhteistyökumppaneille

Lisätiedot

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS 20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien

Lisätiedot

Harjoitustyön testaus. Juha Taina

Harjoitustyön testaus. Juha Taina Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida

Lisätiedot

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/~jekahkon/wclique/testplan.pdf WCLIQUE Ohjelmistoprojekti WCLIQUE_TP Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com

Lisätiedot

SALON SEUDUN KOULUTUSKUNTAYHTYMÄN SISÄISEN VALVONNAN JA RISKIENHALLINNAN PERUSTEET

SALON SEUDUN KOULUTUSKUNTAYHTYMÄN SISÄISEN VALVONNAN JA RISKIENHALLINNAN PERUSTEET SALON SEUDUN KOULUTUSKUNTAYHTYMÄN SISÄISEN VALVONNAN JA RISKIENHALLINNAN PERUSTEET Hall. 01.04.2014 Valt. 29.04.2014 1 Voimaantulo 01.07.2014 1 Lainsäädännöllinen perusta ja soveltamisala Kuntalain 13

Lisätiedot

TIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE Ohjelmistojen testaus 2016 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori 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

Lisätiedot

Opiskelija osaa määritellä ohjelmiston tiedot ja toiminnot, suunnitella ohjelmiston rakenteen ja laatia ohjelmiston teknisen spesifikaation.

Opiskelija osaa määritellä ohjelmiston tiedot ja toiminnot, suunnitella ohjelmiston rakenteen ja laatia ohjelmiston teknisen spesifikaation. 1(7) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ Tutkinnon osa: Ohjelmiston prototyypin toteuttaminen 30 osp Tavoitteet: Opiskelija osaa määritellä ohjelmiston tiedot ja toiminnot, suunnitella ohjelmiston

Lisätiedot

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista

Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 582101 - Ohjelmistotekniikan menetelmät, Ohjelmistotuotannon työkaluista 1 Ohjelmistotuotannon työkaluuista Projektinhallintatyökalut (ei käsitellä tällä kurssilla) CASE- ja mallinnustyökalut (esim. Poseidon)

Lisätiedot

T Testiraportti - integraatiotestaus

T Testiraportti - integraatiotestaus T-76.115 Testiraportti - integraatiotestaus 22. maaliskuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 22.03.2002 Jani Myyry Versiohistoria

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

Lisätiedot

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Muutamia ajatuksia siitä, miten testaus pärjää lama-ajan säästötalkoissa. Laman patologioita ja mahdollisuuksia. Säästämisen strategioita.

Lisätiedot

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa

Lisätiedot

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka

Lisätiedot

5. Luento: Rinnakkaisuus ja reaaliaika. Tommi Mikkonen, tommi.mikkonen@tut.fi

5. Luento: Rinnakkaisuus ja reaaliaika. Tommi Mikkonen, tommi.mikkonen@tut.fi 5. Luento: Rinnakkaisuus ja reaaliaika Tommi Mikkonen, tommi.mikkonen@tut.fi Agenda Perusongelmat Jako prosesseihin Reaaliaika Rinnakkaisuus Rinnakkaisuus tarkoittaa tässä yhteydessä useamman kuin yhden

Lisätiedot

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 582101 - Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 1 Toteutuksesta ja testauksesta Suunnitteluprosessista Tarkan tason luokkasuunnittelu Siirtyminen UML-kaavioista Java-toteutukseen

Lisätiedot

SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus

SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus Lehmus, Auvinen, Pihamaa Johdanto Käyttäjätestauksella tarkoitetaan tuotteen tai sen prototyypin testauttamista todellisilla käyttäjillä. Kehittäjät

Lisätiedot

Kahdenlaista testauksen tehokkuutta

Kahdenlaista testauksen tehokkuutta Kahdenlaista testauksen tehokkuutta Puhe ICTexpo-messuilla 2013-03-21 2013 Tieto Corporation Erkki A. Pöyhönen Lead Test Manager Tieto, CSI, Testing Service Area erkki.poyhonen@tieto.com Sisällys Tehokkuuden

Lisätiedot

Testiautomaatio tietovarastossa. Automaattisen regressiotestauksen periaate ja hyödyt

Testiautomaatio tietovarastossa. Automaattisen regressiotestauksen periaate ja hyödyt Testiautomaatio tietovarastossa Automaattisen regressiotestauksen periaate ja hyödyt Sisältö 2 Testaus kiinteänä osana DW-toteutusta Regressiotestauksen merkitys Robot Framework Automatisoitu DW:n regressiotestaus:

Lisätiedot

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe LU. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T3

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe LU. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T3 T-76.115 Tietojenkäsittelyopin ohjelmatyö Testiraportti, vaihe LU Sisältö Tästä dokumentista ilmenee LU-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 14.4.2003

Lisätiedot

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia OAMK / Luova 4.5. ja 11.5. Sisäinen auditointi osa Oamkin ympäristöohjelmatyötä Sisältö 1. päivä Johdanto Auditoinnin tavoitteet Ympäristöstandardin (ISO 14001) pääkohdat Alustava ympäristökatselmus Auditoinnin

Lisätiedot

Dynaaminen analyysi II

Dynaaminen analyysi II Dynaaminen analyysi II Luento 7 Antti-Pekka Tuovinen 9 April 2013 1 Tavoitteet Black-box testitapausten suunnittelutekniikat II Tilamallien käyttö Syys-seurausverkot ja päätöstaulut Käyttötapaukset Yhteenveto

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys

Lisätiedot

OTM - Katsaus sisältöön. Sidosryhmäseminaari

OTM - Katsaus sisältöön. Sidosryhmäseminaari OTM - Katsaus sisältöön Sidosryhmäseminaari 24.10.2013 Projektiryhmän esittely Katja Arstio, Helsingin yliopisto Sami Hautakangas, Tampereen yliopisto Tuomas Naakka, Helsingin yliopisto Inka Paukku, Aalto

Lisätiedot

Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland

Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland Epäonnistuminen ei ole vaikeaa Approximately 40% of mission-critical mainframe projects

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

Lisätiedot

A4.1 Projektityö, 5 ov.

A4.1 Projektityö, 5 ov. A4.1 Projektityö, 5 ov. Kurssin esitietovaatimuksia Kurssin tavoitteista Kurssin sisällöstä Luentojen tavoitteista Luentojen sisällöstä Suoritustavoista ja -vaatimuksista Arvostelukriteereistä Motivointia

Lisätiedot

Uuden vieritestin käyttöönotto avoterveydenhuollossa

Uuden vieritestin käyttöönotto avoterveydenhuollossa Uuden vieritestin käyttöönotto avoterveydenhuollossa HUSLAB Kliininen kemia ja hematologia 2009 kemisti Paula Pohja-Nylander Tavallisimmat vieritestit avoterveydenhuollossa Hemoglobiini Anemiadiagnostiikka

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

T SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B

T SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B T-76.5158 SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B T-76.5158 SEPA - Pariohjelmointi 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 5.12.2006 Tuomas Tolvanen Ensimmäinen

Lisätiedot

Sisäisen tarkastuksen ohje

Sisäisen tarkastuksen ohje Sisäisen tarkastuksen ohje Kuntayhtymähallitus 17.3.2009 SISÄLLYSLUETTELO 1 TARKOITUS JA PERIAATTEET 3 2 TEHTÄVÄT JA ARVIOINTIPERUSTEET 3 3 ASEMA, TOIMIVALTA JA TIETOJENSAANTIOIKEUS 3 4 AMMATILLINEN OSAAMINEN

Lisätiedot

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio 1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...

Lisätiedot

Raitiotieallianssin riskienhallintamenettelyt

Raitiotieallianssin riskienhallintamenettelyt Riskienhallintamenettelyt 1 (7) Raitiotieallianssin riskienhallintamenettelyt Riskienhallintamenettelyt 2 (7) SISÄLTÖ 1 PERIAATTEET JA TAVOITTEET... 3 2 ORGANISOINTI JA VASTUUT... 4 3 RISKIENHALLINTAPROSESSI...

Lisätiedot

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen 16.06.2014 Ohjaaja: Urho Honkanen Valvoja: Prof. Harri Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston

Lisätiedot

Ohjelmiston testaus ja laatu. Testaus yleistä

Ohjelmiston testaus ja laatu. Testaus yleistä Ohjelmiston testaus ja laatu Testaus yleistä Määritelmä Testaus on systemaattinen lähestymistapa ohjelmistoissa esiintyvien virheiden löytämiseksi ohjelmaa suorittamalla. Testattaessa pyritään luomaan

Lisätiedot

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1 Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän

Lisätiedot

Harjoitus 7: NCSS - Tilastollinen analyysi

Harjoitus 7: NCSS - Tilastollinen analyysi Harjoitus 7: NCSS - Tilastollinen analyysi Mat-2.2107 Sovelletun matematiikan tietokonetyöt Syksy 2006 Mat-2.2107 Sovelletun matematiikan tietokonetyöt 1 Harjoituksen aiheita Tilastollinen testaus Testaukseen

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

TIETOTILINPÄÄTÖS. Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto. Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä

TIETOTILINPÄÄTÖS. Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto. Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä TIETOTILINPÄÄTÖS Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä 20.5.2014 TSV:n tsto/ylitarkastaja Arto Ylipartanen 2 LUENNON AIHEET 1.

Lisätiedot

Testaus osana ohjelmistojen elinkaarta I

Testaus osana ohjelmistojen elinkaarta I Testaus osana ohjelmistojen elinkaarta I Luento 3 Antti-Pekka Tuovinen www.cs.helsinki.fi 19 March 2013 1 Oppimistavoitteet Ohjelmistokehityksen V-malli Testauksen tasot Komponenttitestaus Integrointitestaus

Lisätiedot

MÄÄRÄYS SIJOITUSPALVELUYRITYKSEN RISKIENHALLINNASTA JA MUUSTA SISÄISESTÄ VALVONNASTA

MÄÄRÄYS SIJOITUSPALVELUYRITYKSEN RISKIENHALLINNASTA JA MUUSTA SISÄISESTÄ VALVONNASTA lukien toistaiseksi 1 (5) Sijoituspalveluyrityksille MÄÄRÄYS SIJOITUSPALVELUYRITYKSEN RISKIENHALLINNASTA JA MUUSTA SISÄISESTÄ VALVONNASTA Rahoitustarkastus antaa sijoituspalveluyrityksistä annetun lain

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure Automaattinen regressiotestaus ilman testitapauksia Pekka Aho, VTT Matias Suarez, F-Secure 2 Mitä on regressiotestaus ja miksi sitä tehdään? Kun ohjelmistoon tehdään muutoksia kehityksen tai ylläpidon

Lisätiedot

Vakuutusyhtiöiden testausinfo

Vakuutusyhtiöiden testausinfo Vakuutusyhtiöiden testausinfo ATJ:n ulkoisten liittymien testaaminen Jonna Hannukainen ja Markku Noukka 12. ja 17.5.2006 (Päivitetty 18.5.2006) ATJ:n integraatiotestaus vakuutusyhtiöiden kanssa Testauksen

Lisätiedot

7. Verifiointi ja validointi

7. Verifiointi ja validointi 7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja

Lisätiedot

LUKU 5: SUUNNITTELU. Suunnitteluun liittyviä käsitteitä:

LUKU 5: SUUNNITTELU. Suunnitteluun liittyviä käsitteitä: LUKU 5: SUUNNITTELU Suunnitteluun liittyviä käsitteitä: abstrahointi (abstraction) epäolennaisten yksityiskohtien häivyttäminen, informaation piilottaminen (information hiding) rakenteen osan (moduulin)

Lisätiedot