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

Ohjelmiston testaus ja laatu. Testaustasot Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

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

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 EDELLISELLÄ KERRALLA TAPAHTUNUTTA Täydellinen testaus on mahdotonta. Testataan, koska virheiden löytyminen ajoissa

Lisätiedot

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

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 NOPEA KERTAUS TESTAUS HYVIN LYHYESTI Miten normaali testaajan arki ohjelmistoprojektissa sitten rullaa? Käytännössä

Lisätiedot

Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza

Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza Testaussuunnitelma Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Versio 1.0 Ehdotus Laatija Raine Kauppinen VERSIOHISTORIA Versionotyyppi Versio- Päiväys Tekijä

Lisätiedot

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

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

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Project-TOP QUALITY GATE

Project-TOP QUALITY GATE Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä

Lisätiedot

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

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 NOPEA KERTAUS VIIME KERROISTA ERILAISIA T YÖKALUT YYPPEJÄ Millä työkaluilla testausta sitten tehdään? Suurin osa ohjelmistojen

Lisätiedot

Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg

Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg Symbio lyhyesti Innovatiivinen tuotekehitys- ja testauskumppani Juuret Suomessa, perustettu 1997 Laadukkaat ohjelmistotoimitukset

Lisätiedot

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

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 JATKUU VIIME KERRASTA OHJELMISTOTUOTANTO JA OHJELMISTOTESTAUS Ohjelmistotuotannon prosessi Suunnittelu Määrittely Toteutus

Lisätiedot

Ohjelmistotestaus -09

Ohjelmistotestaus -09 Ohjelmistotestaus Testaustyökalut- ja automaatio Testaustyökalut ja -automaatio Testaustyökaluilla tuetaan testaustyötä sen eri vaiheissa Oikea työkalu oikeaan tarkoitukseen Testausautomaatio perustuu

Lisätiedot

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille 1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei

Lisätiedot

Onnistunut Vaatimuspohjainen Testaus

Onnistunut Vaatimuspohjainen Testaus Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

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

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

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 28.10.2013 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

Lisätiedot

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori

TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori Vaiheet 3 & 4: Järjestelmätestaus 27.10.2014 2 Päämäärä jedit-ohjelmointieditorin järjestelmätestaus

Lisätiedot

Ohjelmistotestauksen perusteita II

Ohjelmistotestauksen perusteita II Ohjelmistotestauksen perusteita II Luento 2 Antti-Pekka Tuovinen 14 March 2013 1 Luennon oppimistavoitteet Testausprosessin perustoiminnot Testauksen psykologiaa Testauksen seitsemän periaatetta 14 March

Lisätiedot

Testaus elinkaaressa. Testaustasot ja vaiheet

Testaus elinkaaressa. Testaustasot ja vaiheet Testaus elinkaaressa Testaus kehittämisen tukena Yksikkötestaus Integrointitestaus Testaustasot ja vaiheet Testaustaso = tietyn testauksen kohteen ja tavoitteen mukainen testaus joka jatkuu koko ajan tai

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

KEYAQUA-VERKKOTIETOJÄRJESTELMÄN TESTAUS

KEYAQUA-VERKKOTIETOJÄRJESTELMÄN TESTAUS KARELIA-AMMATTIKORKEAKOULU Tietotekniikan koulutusohjelma Heikki Majoinen KEYAQUA-VERKKOTIETOJÄRJESTELMÄN TESTAUS Opinnäytetyö Toukokuu 2015 OPINNÄYTETYÖ Toukokuu 2015 Tietotekniikan koulutusohjelma Karjalankatu

Lisätiedot

Testausprosessin vaatimukset. 2. Testausprosessi (Artikkelit) Vesiputousmallin ongelmia. V-mallin neljä osavaihetta. Testausprosessimalli V-malli

Testausprosessin vaatimukset. 2. Testausprosessi (Artikkelit) Vesiputousmallin ongelmia. V-mallin neljä osavaihetta. Testausprosessimalli V-malli 2. ausprosessi (Artikkelit) Nykyisin useimpien prosessimallien lähtökohta on, että testaus on oleellinen osa ohjelmistotuotantoprosessia. Itse asiassa huolellinen testaus vie helposti 50% tai enemmän käytettävistä

Lisätiedot

Ohjelmistojen virheistä

Ohjelmistojen virheistä Ohjelmistojen virheistä Muutama sana ohjelmistojen virheistä mistä niitä syntyy? Matti Vuori, www.mattivuori.net 2013-09-02 1(8) Sisällysluettelo Ohjelmistojen virheitä: varautumattomuus ongelmiin 3 Ohjelmistojen

Lisätiedot

Ohjelmiston testaus ja laatu. Testausmenetelmiä

Ohjelmiston testaus ja laatu. Testausmenetelmiä Ohjelmiston testaus ja laatu Testausmenetelmiä Testausmenetelmiä - 1 Testauksen menetelmien päälähestymistapoina ovat black-box testi testaaja ei voi tutkia lähdekoodia testaus perustuu sovellukselle suunnitteluvaiheessa

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

Testaus elinkaaressa

Testaus elinkaaressa Testaus elinkaaressa Järjestelmätestaus Järjestelmätestaus Tarkoittaa koko järjestemän laajuuteen kohdistuvaa testausta, koko järjestelmän toiminnan näkökulmasta Järjestelmän ei tarvitse olla valmis vaan

Lisätiedot

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa Sisältö 1. Koneenrakentajan haasteita koneiden turvallistamisessa 2.

Lisätiedot

Wipron Suomen toimipisteen ohjelmistotestauksen kehittäminen. Marko Isoaho

Wipron Suomen toimipisteen ohjelmistotestauksen kehittäminen. Marko Isoaho 0 Wipron Suomen toimipisteen ohjelmistotestauksen kehittäminen Marko Isoaho Tampereen yliopisto Tietojenkäsittelytieteiden laitos Tietojenkäsittelyoppi Pro gradu -tutkielma Ohjaaja: Marko Helenius Toukokuu

Lisätiedot

Järjestelmätestauksen vaatimukset. 6. Järjestelmätestaus (B, 14) Järjestelmätestauksen korkean tason testausstrategia

Järjestelmätestauksen vaatimukset. 6. Järjestelmätestaus (B, 14) Järjestelmätestauksen korkean tason testausstrategia . Järjestelmätestaus (B, ) Järjestelmätestaus (system testing) tehdään integrointitestauksen jälkeen. Siinä järjestelmää testataan kokonaisuutena, johon kuuluvat ohjelmiston lisäksi laitteisto ja järjestelmän

Lisätiedot

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versio Päiväys Tekijä Kuvaus 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto

Lisätiedot

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

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 ILMOITUSASIAA Projekti 2:n lyhyt kuvaus Nopassa. Harjoituksissa tehtäviä joiden tuotoksia voi hyödyntää projektin toteutuksessa.

Lisätiedot

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

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 NOPEA KERTAUS VIIME KERROISTA TESTAUSTASOT Testauksen tasot: Yksikkötestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus

Lisätiedot

TESTAUSMENETELMIEN KÄYTTÖ SOVELLUKSEN SYSTEEMITESTAUSVAIHEESSA

TESTAUSMENETELMIEN KÄYTTÖ SOVELLUKSEN SYSTEEMITESTAUSVAIHEESSA Tiina Tersa TESTAUSMENETELMIEN KÄYTTÖ SOVELLUKSEN SYSTEEMITESTAUSVAIHEESSA Tietotekniikan pro gradu -tutkielma Ohjelmistotekniiikan linja 20.8.2002 Jyväskylän yliopisto Tietotekniikan laitos Tekijä: Tiina

Lisätiedot

Testauksen hallinta ja johtaminen

Testauksen hallinta ja johtaminen Testauksen hallinta ja johtaminen Luento 10 Antti-Pekka Tuovinen 18 April 2013 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia

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

@Tampereen Testauspäivät (2012-06)

@Tampereen Testauspäivät (2012-06) @Tampereen Testauspäivät (2012-06) Testausodotukset räätälöityjen järjestelmien projekteissa Maaret Pyhäjärvi, testausasiantuntija Twitter: maaretp Testausvastaava @ Granlund Oy Yrittäjä

Lisätiedot

Yritysten valmius soveltaa uusia ohjelmistotuotteiden testaus- ja laatustandardeja (ISO/IEC 29119 ja 25010)

Yritysten valmius soveltaa uusia ohjelmistotuotteiden testaus- ja laatustandardeja (ISO/IEC 29119 ja 25010) Lappeenrannan teknillinen yliopisto Tietotekniikan osasto Kandidaatintyö Yritysten valmius soveltaa uusia ohjelmistotuotteiden testaus- ja laatustandardeja (ISO/IEC 29119 ja 25010) Työn ohjaaja ja tarkastaja:

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

Ohjelmistotestaus: Testausprosessin luonti ja. kehittäminen

Ohjelmistotestaus: Testausprosessin luonti ja. kehittäminen Ossi Savolainen Ohjelmistotestaus: Testausprosessin luonti ja kehittäminen Tietojärjestelmätieteen Kandidaatin tutkielma 3.3.2005 Jyväskylän yliopisto Tietojenkäsittelytieteen laitos Jyväskylä 2 Tiivistelmä

Lisätiedot

L models. Testisuunnitelma. Ryhmä Rajoitteiset

L models. Testisuunnitelma. Ryhmä Rajoitteiset Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Testisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset

Lisätiedot

Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen

Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä Simo Tauriainen www.ponsse.com 25.8.2011 Ponsse-konserni Ponsse Oyj on tavaralajimenetelmän metsäkoneiden myyntiin, tuotantoon, huoltoon ja

Lisätiedot

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011 LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011 TEHTÄVÄ Määrittele laatu Mitä riskien hallintaan kuuluu? Jouni Huotari & Esa Salmikangas 2 LAATU JA LAADUNVARMISTUS

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

Lakki. Lisää ot sik k o osoit t am alla. Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010

Lakki. Lisää ot sik k o osoit t am alla. Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010 Lakki Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy vierailuluentosarja OTM kurssi 2010 2.luento: ohjelmistokehityksen päivärutiinit Lisää ot sik k o osoit t am alla Siitä vain reunasta Miten

Lisätiedot

9. Luento: Ohjelmistotyö. Tommi Mikkonen, tommi.mikkonen@tut.fi

9. Luento: Ohjelmistotyö. Tommi Mikkonen, tommi.mikkonen@tut.fi 9. Luento: Ohjelmistotyö Tommi Mikkonen, tommi.mikkonen@tut.fi Agenda Johdanto Ristikäännös Testaus ja virheen jäljitys Yleensä Kehitysympäristössä Käyttöympäristössä Laitteiston testaus Iteratiivisesta

Lisätiedot

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant On mahdollista löytää Se Oikea! Luotanko sattumaan? Onnistuminen on aloitettava heti Onnistumisen kaava on 4 x

Lisätiedot

0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen

0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 24.10.2005 Elina Kontro Laatuasiat siirretty omaan dokumenttiin jatkotyöstetty 0.2 27.10.2005 Santeri Saarinen Bugien elinkaari yms. asioita jatkettu 0.3 28.10.2005

Lisätiedot

T-76.115 Tietojenkäsittelyopin ohjelmatyö. Testisarja Ray tracing. Tietokonegrafiikka-algoritmien visualisointi. Testisarja Ray tracing

T-76.115 Tietojenkäsittelyopin ohjelmatyö. Testisarja Ray tracing. Tietokonegrafiikka-algoritmien visualisointi. Testisarja Ray tracing T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Keimo-visualisointijärjestelmän Ray tracing - visualisaation testisarja. Sarja sisältää testitapaukset ja testilokit Päivämäärä 13.4.2003 Projektiryhmä

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

3.5 Hyväksymistestaus

3.5 Hyväksymistestaus 3.5 Hyväksymistestaus Hyväksymistestauksen perusteella voidaan päätellä onko tuote sopimusten mukainen Mikäli kehitys on ulkoistettu, saatetaan hyväksymistestaussuunnitelma ja siihen liittyvät testitapaukset

Lisätiedot

Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi

Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen

Lisätiedot

TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL Virtuaaliyhteisöjen muodostaminen Versio 1.0

TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL Virtuaaliyhteisöjen muodostaminen Versio 1.0 TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL i Sisällysluettelo DUMENTIN VERSIOT 1 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI

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

Soft QA. Vaatimusten muutostenhallinta. Ongelma

Soft QA. Vaatimusten muutostenhallinta. Ongelma Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei

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

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

LAADUNHALLINTA. Prof. Jouko Kankainen JoKa-konsultit Oy

LAADUNHALLINTA. Prof. Jouko Kankainen JoKa-konsultit Oy LAADUNHALLINTA Prof. Jouko Kankainen JoKa-konsultit Oy TEHTÄVÄN LAADUNVARMISTUS Yksittäisen tehtävän hyvälle laadunvarmistukselle on ominaista, että: laatuvaatimukset on yksilöity ja konkreettisesti esitetty

Lisätiedot

Kooste kotitehtävien vastauksista. Kotitehtävä 6 - Ylläpito- ja kehittämismalli 29.4.2011

Kooste kotitehtävien vastauksista. Kotitehtävä 6 - Ylläpito- ja kehittämismalli 29.4.2011 Kooste kotitehtävien vastauksista Kotitehtävä 6 - Ylläpito- ja kehittämismalli 29.4.2011 1.) Järjestelmän ylläpitomalli? ja 2.) Järjestelmän jatkokehittämismalli? OPH on omistaja ja ylläpitäjä ja huolehtii

Lisätiedot

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa 1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä

Lisätiedot

Orientaatio ICT-alaan. Projekti

Orientaatio ICT-alaan. Projekti Orientaatio ICT-alaan Projekti Projekti Ajallisesti rajoitettu, kertaluonteinen tehtävä määrätyt resurssit sekä oma (linjaorganisaatiosta poikkeava) organisaatio Toteutus tapahtuu suunnitelmallisesti ennalta

Lisätiedot

Periaatteet standardien SFS-EN ISO/IEC 17025:2005 ja SFS-EN ISO 15189:2007 mukaisen näytteenottotoiminnan arvioimiseksi

Periaatteet standardien SFS-EN ISO/IEC 17025:2005 ja SFS-EN ISO 15189:2007 mukaisen näytteenottotoiminnan arvioimiseksi Periaatteet standardien SFS-EN ISO/IEC 17025:2005 ja SFS-EN ISO 15189:2007 mukaisen näytteenottotoiminnan arvioimiseksi FINAS - akkreditointipalvelu Espoo 2012 ISBN 978-952-5610-85-7 1(7) Periaatteet standardien

Lisätiedot

Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä

Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu

Lisätiedot

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTAUSSUUNNITELMA LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 2.1 Tila: hyväksytty Päivämäärä: 12.12.2000

Lisätiedot

Testaus osana ohjelmistojen elinkaarta II

Testaus osana ohjelmistojen elinkaarta II Testaus osana ohjelmistojen elinkaarta II Luento 4 Antti-Pekka Tuovinen www.cs.helsinki.fi 21 March 2013 1 Oppimistavoitteet Ohjelmistoversioiden testaus Testityyppejä www.cs.helsinki.fi 21 March 2013

Lisätiedot

Lyhyt yhteenveto ohjelmistovaatimuksista standardissa ISO 13849-1

Lyhyt yhteenveto ohjelmistovaatimuksista standardissa ISO 13849-1 Lyhyt yhteenveto ohjelmistovaatimuksista standardissa ISO 13849-1 Dr. Michael Huelke, BGIA in close collaboration with Philippe Lubineau and Daniel Renault, CETIM Käännös/m atti.sundquist@ sundcon.fi Sichere

Lisätiedot

Julkaisemattomia koulutusmateriaaleja 2003-2010

Julkaisemattomia koulutusmateriaaleja 2003-2010 Matti Vuori Julkaisemattomia koulutusmateriaaleja 2003-2010 Luettelo vuosina 2003-2010 tuotetuista geneerisistä koulutusmateriaaleista (yrityskohtaiset aineistot ovat asia erikseen), ja joihin laatijalla

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

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Laajuus Jatkuva laajeneminen sekä maantieteellisesti että sisällön kannalta: Yhdestä

Lisätiedot

Tietohallinnon nykytilan analyysi. Analyysimenetelmä (sovitettu Tietohallintomallista) 9.10.2013

Tietohallinnon nykytilan analyysi. Analyysimenetelmä (sovitettu Tietohallintomallista) 9.10.2013 Tietohallinnon nykytilan analyysi Analyysimenetelmä (sovitettu Tietomallista) 9.10.2013 Haastattelurunko Kerättävät perustiedot Budjetti (edellisvuoden) Henkilöstökustannukset IT-ostot Muut Liite - Kypsyysanalyysin

Lisätiedot

Kuntokirjuri. Testausraportti. Miika Alonen Jarkko Laine Jesse Honkanen Veli Matti Huovinen Jani Jäntti. Versio 1.1 16.5.2008

Kuntokirjuri. Testausraportti. Miika Alonen Jarkko Laine Jesse Honkanen Veli Matti Huovinen Jani Jäntti. Versio 1.1 16.5.2008 Kuntokirjuri Testausraportti Miika Alonen Jarkko Laine Jesse Honkanen Veli Matti Huovinen Jani Jäntti Versio 1.1 16.5.2008 Jakelu: Asiakas Jukka Rantala Ohjaaja Erkki Pesonen Opponoiva ryhmä 1 Kuopion

Lisätiedot

Suorituskyky- ja tietoturvatestaus Kelassa

Suorituskyky- ja tietoturvatestaus Kelassa Suorituskyky- ja tietoturvatestaus Kelassa TTY: TIE-21204 Ohjelmistojen testaus 16.11.2015 Kaisa Tirkkonen Kehittämispäällikkö, Kela, Tietohallinto-osasto Testausryhmä / Suorituskyky- ja tietoturvatestaus

Lisätiedot

Ketterä vaatimustenhallinta

Ketterä vaatimustenhallinta Ketterä vaatimustenhallinta ja miksi se on useimmiten hyvä asia K A R I A L HO C E O I M P R OV EIT OY Sisältö ImproveIt Oy Perinteinen vaatimushallinta Ketterä vaatimustenhallinta Monenlaista softakehitystä

Lisätiedot

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti Järjestelmäprojekti 1 projektisuunnitelma ICT4TN007-2 SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti Versio 0.1 Tekijät Keijo Nykänen Tarkastanut Hyväksynyt HAAGA-HELIA

Lisätiedot

Käytettävyyslaatumallin rakentaminen verkkosivustolle

Käytettävyyslaatumallin rakentaminen verkkosivustolle Käytettävyyslaatumallin rakentaminen verkkosivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -tutkielma Timo Laapotti 9.6.2005 Esityksen sisältö Kirjoittajan

Lisätiedot

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset

Lisätiedot

Testaus teoriassa ja käytännössä. Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos

Testaus teoriassa ja käytännössä. Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos Testaus teoriassa ja käytännössä Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos Teoria = tutkimus IEEE Transactions on Software Engineering, 2000-2002 Software Testing, Verification &

Lisätiedot

Harjoituskoe Vastaukset. ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus

Harjoituskoe Vastaukset. ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus Harjoituskoe Vastaukset ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus Alkup. versio 1.0 Käännösversio 1.0 Tekijänoikeushuomautus Tämän dokumentin saa kopioida kokonaisuudessaan

Lisätiedot

Opiskelija tekee työasemaympäristöön ja sen hankintaan liittyviä toimistotehtäviä ja laskutoimituksia sekä hyödyntää kielitaitoaan.

Opiskelija tekee työasemaympäristöön ja sen hankintaan liittyviä toimistotehtäviä ja laskutoimituksia sekä hyödyntää kielitaitoaan. 1(7) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ Tutkinnon osa : Järjestelmän hankinta ja käyttöönotto 20 osp Tavoitteet: Opiskelija toimii työasemaympäristössä asentaen sekä laitteistoja että ohjelmistoja,

Lisätiedot

Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille

Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille TraFin ulkoinen integraatio Aineistosiirron testauksen aloituksen ohje Trafin sopimuskumppaneille Ohje 26.2.2014 Versio 1.1, Hyväksytty Luottamuksellinen Vastuutaho Trafi MUUTOSHISTORIA Versio Päiväys

Lisätiedot

Ohjelmistotestaus -09

Ohjelmistotestaus -09 Ohjelmistotestaus Johdanto ohjelmistotestaukseen "Beware of bugs in the above code; I have only proved it correct, not tried it." 1 Sisältö Mitä testaus on? Mitä arvoa testaus tuottaa? Testauksen prosessi.

Lisätiedot

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

ITK130 Ohjelmistojen luonne

ITK130 Ohjelmistojen luonne ITK130 Ohjelmistojen luonne Luennon sisältö Ohjelmistotekniikka ja vaatimukset Ohjelmistotuote Ei-toiminnallisten vaatimusten luokittelu Sisäiset ja ulkoiset vaatimukset Oikeellisuus Luotettavuus Kestävyys

Lisätiedot

OTM-HANKE. Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus

OTM-HANKE. Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus OTM-HANKE Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus Taustaa Aalto-yliopisto, Helsingin yliopiston ja Tampereen yliopiston yhteishanke opintohallinnon tietojärjestelmien modernisoinniksi

Lisätiedot

1.1. MITEN ITSEARVIOINTIVÄLINETTÄ KÄYTETÄÄN. Väline kattaa kolmen osan kolme tärkeintä prosessia: hakijoiden valinta (laskentataulukon työkirja 1)

1.1. MITEN ITSEARVIOINTIVÄLINETTÄ KÄYTETÄÄN. Väline kattaa kolmen osan kolme tärkeintä prosessia: hakijoiden valinta (laskentataulukon työkirja 1) Liite 1 1.1. MITEN ITSEARVIOINTIVÄLINETTÄ KÄYTETÄÄN Väline kattaa kolmen osan kolme tärkeintä prosessia: hakijoiden valinta (laskentataulukon työkirja 1) hankkeiden toteuttaminen tuensaajien toimesta,

Lisätiedot

Testauspalvelu laadunvarmistajana Arekin monitoimittajaympäristössä. Satu Koskinen Teknologiajohtaja, Arek Oy

Testauspalvelu laadunvarmistajana Arekin monitoimittajaympäristössä. Satu Koskinen Teknologiajohtaja, Arek Oy Testauspalvelu laadunvarmistajana Arekin monitoimittajaympäristössä Satu Koskinen Teknologiajohtaja, Arek Oy Agenda Arek yrityksenä Testauspalvelun uudelleen järjestelyt 2014 Vastuut ja käytännön työnjako

Lisätiedot

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa 13.05.2015 Terveydenhuollon ATK-päivät Tampere-talo Yleistä Riskienhallintaan löytyy viitekehyksiä/standardeja kuten ISO 31000

Lisätiedot

Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna

Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Finesse-seminaari 22.03.00 Matias Vierimaa 1 Mittauksen lähtökohdat Mittauksen tulee palvella sekä organisaatiota että projekteja Organisaatiotasolla

Lisätiedot

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Mittaaminen ja ohjelmistotuotanto seminaari 18.04.01 Matias Vierimaa 1 Miksi mitataan? Ohjelmistokehitystä ja lopputuotteen laatua on vaikea arvioida

Lisätiedot