4. Verifiointi ja validointi. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina
|
|
- Teemu Aaltonen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 4. Verifioinnissa varmennetaan, että järjestelmä on toimiva ja optimaalinen. Yleensä se muotoillaan kysymykseksi Kehitämmekö järjestelmää oikein? Validoinnissa varmennetaan, että järjestelmä vastaa siitä kirjattuja vaatimuksia. Yleensä se muotoillaan kysymykseksi Kehitämmekö oikeaa järjestelmää? Verifiointia ja validointia (V&V) tehdään koko projektin keston ajan. Verifiointi- ja validointitekniikat Tärkeimmät V&V-tekniikat ovat tarkastukset ja testaus: tarkastukset: selvitetään ohjatussa kokouksessa dokumentin puutteita ja virheitä. (dynaaminen) testaus: annetaan ohjelmalle syötteitä ja katsotaan, minkälaisia tuloksia se antaa niillä. Muita V&V-tekniikoita ovat mm. mallinnus, simulaatiot ja todistaminen. 1 2 Verifioinnin ja validoinnin luonne V&V:n lait ja hypoteesit V&V on laadunvarmistusta, ryhmätyötä ja rinnakkaisia menetelmiä. Miksi? Fagan: Tarkastukset parantavat merkittävästi tuotteen laatua. Hezer-Myers: Parhaat tulokset saadaan yhdistelemällä V&V:n tekniikoita. Weinberg: Ohjelmoijan ei pidä testata omaa koodiaan. Djikstra: Täydellinen testaus ei onnistu. Oppikirjassa esitellyt V&V:n lait ovat käytännöllisiä. Siten ne eroavat selvästi esimerkiksi vaatimusmäärittelyn laeista. Lakien ja hypoteesien sanoma voidaan tiivistää näin: V&V on laadunvarmistuksen työkalu. Siinä tarvitaan yhteistyötä sekä menetelmien että tekijöiden välillä. 3 4 V&V:n lait ja liittyminen ohjelmistotekniikkaan V&V:n lait ja liittyminen ohjelmistotekniikkaan 2 Seuraavassa ovat lait ja hypoteesit ja niiden liittyminen ohjelmistotekniikkaan: Faganin laki: tarkastukset Porter-Vottan laki: tarkastukset Basilin laki: tarkastukset Hetzel-Myersin laki: tarkastukset, mustalaatikkotestaus, lasilaatikkotestaus Mills-Jonesin hypoteesi (ei käsitellä): laadunvarmistus, prosessinhallinta Maysin hypoteesi: mustalaatikkotestaus Hoaren hypoteesi (ei käsitellä): verifiointi Sackmanin ensimmäinen laki (ei käsitellä): virheenjäljitys Djikstran laki: mustalaatikkotestaus, lasilaatikkotestaus Weinbergin laki: mustalaatikkotestaus Pareto-Zipf laki: ohjelmistotekniikka Gray-Serlin laki (ei käsitellä): rasitustestaus 5 6 1
2 V&V:n lait ja liittyminen ohjelmistotekniikkaan 3 Nielsen-Normanin laki (ei käsitellä): käytettävyystestaus Gutjahrin hypoteesi (ei käsitellä): mustalaatikkotestaus Weyukerin hypoteesi (ei käsitellä): lasilaatikkotestaus Endres-Glatthaar hypoteesi (ei käsitellä): lasilaatikkotestaus Hamletin hypoteesi: mustalaatikkotestaus V&V:n lait ja liittyminen ohjelmistotekniikkaan 4 Kuten edellisestä listasta nähdään, V&V:n lakeja ja hypoteeseja on paljon ja niillä on usein täsmällinen merkitys. Näin ne eroavat selvästi yleisemmistä vaatimusmäärittelyn ja suunnittelun laeista. Itse asiassa varsinkin lasilaatikkotestauksesta olisi enemmänkin lakeja, mutta ne eivät kuulu eot:n piiriin. 7 8 V&V:n lait ja liittyminen ohjelmistotekniikkaan 5 Eniten kaivattaisiin lisää mustalaatikkotestauksen teoriaa ja menetelmiä. Tällä hetkellä mustalaatikkotestaus perustuu pääasiassa syöteavaruuden ositukseen. Tarkastusten tilanne on parempi. Teoria on osoittautunut hyväksi ja uutuudet ovat olleet kosmeettisia. Lasilaatikkotestaus on matemaattisesti parhaiten hallittu V&V-tekniikka Faganin laki Tarkastukset parantavat merkittävästi tuottavuutta, laatua ja prjektien stabiiliutta. Fagan esitti 1970-luvulla IBM:lla, miten dokumenteista voidaan tehokkaasti löytää virheitä muodollisilla tarkastustilaisuksilla. Tarkastusten hyvyys on yksi vahvimmista EOT:n laeista. Sitä on sekä validoitu että varmennettu käytössä yli 30 vuoden ajan. 10 Faganin lain taustaa Faganin tarkastukset ovat tuttuja: 1. Joukko tarkastajia saa tarkastettavan dokumentin luettavaksi useita päiviä ennen sovittua tarkastustilaisuutta. 2. Tarkastustilaisuutta johtaa puheenjohtaja. 3. Tarkastajat esittävät tilaisuudessa löytämiään dokumentin puutteita ja virheitä. 4. Puutteet ja virheet kirjataan ylös. 5. Lopuksi päätetään dokumentille tehtävät toimenpiteet. 11 Faganin lain taustaa 2 Faganin lakia voidaan soveltaa minkä tahansa prosessin dokumenttiin. Parhaimmillaan se on kuitenkin silloin, kun dokumentti on saatu monesta lähteenä ryhmätyönä. Tarkastuksia pidetään aiheesta kaikkein tehokkaimpana V&V:n tekniikkana. Tästä huolimatta tarkastuksia tehdään yrityksissä edelleen yllättävän vähän. 12 2
3 Faganin lain perusteluja Faganin lain perusteluja 2 Fagan perustaa tuloksensa empiiriseen kokeeseen. Hän vertaili kahta prosessia, joista toisessa tarkastusten avulla tuotosta muokattiin aikaisin, ja joista toisessa ilman tarkastuksia muokkaus tehtiin testauksen jälkeen. Faganin mukaan tarkastukset antoivat 23% tuottavuuslisän. 13 Tuottavuuden lisäksi Fagan vertasi laatua. Faganin mukaan tarkastusryhmässä kaikkien löydettyjen virheiden lukumäärä oli 38% pienempi kuin vertailevassa ryhmässä. Myös muista lähteistä on saatu vastaavia tuloksia: jopa lähes 100% kaikista virheistä on löydetty tarkastuksissa. 14 Faganin lain teoria Faganin laki on oikeastaan seurauslause Boehmin ensimmäisestä laista. Tarkastusten avulla virheet löydetään aikaisin, joten niiden kustannus pysyy pienenä. Tarkastukset eivät kuitenkaan korvaa testausta. Varsinkin monimutkaisten oliopiirteiden virheiden löytäminen tarkastuksilla voi olla hyvin vaikeaa Porter-Vottan laki Tarkastusten tehokkuus ei juurikaan riipu niiden järjestelytavasta. Porter ja Votta pyrkivät selvittämään empiirisin kokein, miten tarkastuksia kannattaisi järjestää. Heidän tutkimuksensa tulos oli, että järjestelyt eivät erityisesti vaikuta. Alkuperäiset järjestelyt ovat ihan hyvät. Tarkastusprosessia on vaikea parantaa Porter-Vottan lain taustaa Porter-Vottan lain taustaa 2 Faganin tarkastukset on kuvattu aika yleisesti, joten niistä on tehty useita variaatioita. Esimerkiksi seuraaviin kysymyksiin on vastattu eri tavoin: Onko tarkastustilaisuuden tarkoituksena tehdä päätöksiä valmisteluvaiheessa löytyneistä virheistä, vai pitääkö virheet tunnistaa tarkastustilaisuudessa? Käytetäänkö dokumenttia kohden yhtä vai useaa tarkastustilaisuutta? 17 Intuitiivisesti tuntuisi, että yritykselle räätälöity tarkastusprosessi antaisi yleistä parempia tuloksia. Porter-Vottan lain mukaan intuitio on väärässä. Tarkastusvariaatioiden väliset erot ovat pienet. Merkittävin poikkeus laista ovat näkökulmaperustaiset tarkastukset, joita käsitellään Basilin laissa. 18 3
4 Porter-Vottan lain perusteluja Porter ja Votta perustavat lakinsa tapaustutkimukseen. He analysoivat Lucent Technologiesin puhelinkeskusjärjestelmän tarkastuksia. Porter ja Votta kävivät läpi 88 puhelinkeskusjärjestelmän tarkastusta 18 kuukauden aikana. He saivat varsin mielenkiintoisia tuloksia. 19 Porter-Vottan lain perusteluja 2 Empiirisen kokeen tulokset: Virheiden luokitteluun perustuva lähestymistapa korkeampi virheiden tunnistustahti: pätee Fyysinen tapaaminen korkeampi virheiden tunnistustahti: heikko yhteys Ositetut tarkastukset korkeampi virheiden tunnistustahti: heikko yhteys Enemmän kuin kaksi tarkastajaa korkeampi virheiden tunnistustahti: ei päde 20 Porter-Vottan lain perusteluja 3 Näin ollen Porter-Vottan perustelujen mukaan tarkastuksille pätee: Tarkastuksessa kannattaa keskittyä ennalta määrätyn tyyppisiin virheisiin. Kaksi ihmistä tarkastaa paremmin kuin yksi, neljä ei tarkasta paremmin kuin kaksi. Yhteistä tilaisuutta ei ole pakko järjestää. Tarkastusta ei kannata osittaa peräkkäisiksi istunnoiksi. 21 Porter-Vottan lain teoria Jokainen tarkastaja käyttää omaa virheiden tunnistuksen menetelmää. Nämä menetelmät ovat jonkun verran päällekkäisiä, mutta kuitenkin erilaisia. Kahdella tarkastajalla ei ole paljon päällekkäisyyttä, kolmella on enemmän, neljällä vielä enemmän jne. Päällekkäisyys on resurssien tuhlausta ja johtaa tehottomaan prosessiin. 22 Porter-Vottan lain teoria 2 Tarvittaviin resursseihin verrattuna paras tulosparannus saadaan siirryttäessä yhdestä tarkastajasta kahteen tarkastajaan. Kahta useamman tarkastajan käyttö ei enää juuri paranna tulosta, paitsi jos tarkastajille sovitaan toisistaan eroavat näkökulmat dokumenttiin. Muut tekijät ovat toisarvoisia Basilin laki Näkökulmaperustaiset tarkastukset ovat (erittäin) tehokkaita. Näkökulmaperustaisessa (perspectivebased) tarkastuksessa etsittävät virhetyypit luokitellaan sidosryhmittäisiksi näkökulmiksi. Näkökulmia käyttämällä tarkastajien keskinäinen päällekkäisyys minimoidaan, ja tarkastettava dokumentti saadaan katettua paremmin. 24 4
5 Basilin lain taustaa Porter-Vottanin lain yhteydessä mainittiin virheiden luokitteluun perustuvat tarkastukset. Niissä tunnettuja virhelähteistä sadaan näkökulmat tarkistuslistan kohdille. Basilin laissa idea viedään askelta pitemmälle käyttämällä sidosryhmiä näkökulmien lähteenä. Basilin lain taustaa 2 Näkökulmaperustaisessa tarkastuksessa kullekin tarkastukseen osallistujalle valitaan rooli. Roolissaan hän esittää jonkin sidosryhmän edustajaa, ja toimii sekä valmistautumisessa että tarkastustilaisuudessa roolinsa mukaan. Roolien avulla tarkastajat keskittyvät eri tyyppisiin virheisiin virheluokittelun tapaan Basilin lain perusteluja Basilin lain teoria Basili käytti tutkimuksessaan ohjattua koetta. Toisessa ryhmässä käytettiin tavallista tarkastusprosessia, toisessa näkökulmapohjaista tarkastusprosessia. Oppikirjan mukaan näkökulmapohjainen tarkastus oli tehokkaampi kuin tavallinen tarkastus. Kirjassa ei kuitenkaan anneta tarkkoja lukuarvoja. Aivotyö on raskasta ja kallista. Jos joukolla saman alan asiantuntijoita on sama tarkastus, he hyvin helpolla saattavat nähdä ongelman samasta suunnasta ja näin löytää samat viat. Roolijaolla kukin asiantuntia keskittyy toisista eroavaan näkökulmaan, jolloin ongelmat nähdään eri suunnista Hezel-Myersin laki Hezel-Myersin lain taustaa Useaa V&V-tekniikkaa käyttämällä saavutetaan parempia tuloksia kuin yhdelläkään menetelmällä yksinään. Hezel-Myersin laki käsittelee kolmea V&Vtekniikkaa: tarkastuksia, mustalaatikkotestausta ja lasilaatikkotestausta. Hetzel vertasi tekniikoita 1976 ja Myers julkaisi tulokset Tarkastukset ja testausmenetelmät täydentävät toisiaan. Kaikkia tarvitaan. Tarkastuksilla löydetään parhaiten vaatimusmäärittelyn ja korkean tason suunnittelun virheitä Mustalaatikkotestauksella löydetään parhaiten määrittelyvirheitä Lasilaatikkotestauksella täydennetään mustalaatikkotestauksen testitapaukset kattamaan koko ohjelmakoodi. 30 5
6 Hezel-Myersin lain perusteluja Hezel-Myersin lain perusteluja 2 Hezel-Myersin lain ohjatussa kokeessa testaajalle annettiin testattavaksi ohjelma, johon oli upotettu 15 virhettä. Testaajat eivät tienneet virheistä. Osallistujat jaettiin kolmeen ryhmän, joista yhdessä testattiin mustalaatikkotestauksella, yhdessä lasilaatikkotestauksella ja yhdessä tarkastuksilla. 31 Kokeen tulokset olivat mielenkiintoiset. Eniten Myersia yllätti, että löydettyjen virheiden määrä vaihteli vahvasti osallistujien kesken. Tästä hän päätteli, että on erityisen tärkeää selvittää, kuka käyttää mitäkin menetelmää. Seuraavalla kalvolla on Hezel-Myersin ohjatun kokeen yhteenveto. 32 Hezel-Myersin lain perusteluja 3 Hezel-Myersin lain teoria Löydettyjen virheiden keskiarvo Löydettyjen virheiden keskihajonta Löydettyjen virheiden mediaani Löydettyjen virheiden vaihteluväli Löydettyjä virheitä yhteensä Hakuaika minuuttia/virhe Lasilaatikko Mustalaatikko 4,5 4,8 4, ,4 5,5 5, Tarkastukset 5,7 3, Mustalaatikko + tarkastukset 7,6 4, Hezel-Myersin lain menetelmät eivät kilpaile keskenään. Kullakin menetelmällä on vahvuudet ja heikkoudet. Ne käsittelevät virheiden löytymistä eri suunnilta. Kaikki virheet eivät ole samanlaisia tai esiinny samassa kehitystyön vaiheessa. Eri tyyppisten virheiden etsintään pitää olla erilaisia menetelmiä Maysin hypoteesi Virheiden välttäminen on parempi kuin virheiden poistaminen. Maysin hypoteesi on vain hypoteesi, sillä sen todistaminen on äärimmäisen vaikeaa. Silti kaikki vähänkään testauksen kanssa tekemisissä olleet uskovat, että Maysin hypoteesi pätee. Jos virheitä ei synny, niiden korjaukseen vaadittavia resursseja ei myöskään tarvita. Maysin hypoteesin taustaa Jokainen virhe, vaikka miten pieni ja aikaisin havaittu, vaatii ylimääräistä työtä ja lisäkustannuksia. Siis virheiden synty kannattaa estää. Estäminen vaatii sekä virheiden syiden tunnistamista että syiden poistamista. Hypoteesi on voimassa, jos virheiden syntymisen estäminen vaatii vähemmän resursseja kuin virheiden korjaus
7 Maysin hypoteesin perusteluja Mays esitteli artikkelissaan 1990 IBM:lla kehitettyä virheiden välttöprosessia. Prosessissa havaitut virheet analysoitiin, ja analysoinnin perusteella kehitettiin strategia vastaavien virheiden välttämiseksi. Artikkelissa ei kerrottu, miten tehokkaaksi prosessi osoittautui. Maysin hypoteesin perusteluja 2 Vastaava tutkimus tehtiin 1994 myös IBM:lla. Tällöin käytettiin seuraavaa prosessia: 1. Etsitään ja korjataan tuotteen virheet 2. Etsitään ja eliminoidaan virheiden syyt 3. Etsitään prosessin syitä, joiden takia virheitä ei huomattu ajoissa. Korjataan prosessia. 4. Etsitään samanlaisia toistaiseksi havaitsemattomia virheitä ja eliminoidaan myös ne Maysin hypoteesin perusteluja Djikstran laki Jälkimmäisen tutkimuksen tuloksena saatiin seuraavaa: 85% kaikista virheistä löydettiin ennen koodin liittämistä kehitysversioon, siis ennen testausta. 7% virheistä löydettiin testauksessa. Tulokset ovat hyviä, vaikka eivät kerro virheiden korjauskustannuksista suhteessa prosessin kustannuksiin. Testauksella voidaan löytää virheitä mutta ei osoittaa ohjelmaa virheettömäksi. Djikstran laki on testauksen tärkein laki. Djikstra esitteli lakinsa 1970, ja siitä lähtien se on esitelty varmaankin kaikilla testaukseen liittyvillä kursseilla Djikstran lain taustaa Djikstran laki asettaa testaukselle selkeän rajan: testaus ei voi koskaan olla täydellistä. Täydellinen testaus vaatisi ainakin seuraavat testit: kaikki syötekombinaatiot, kaikki reitit ohjelman alusta loppuun, kaikki ajoitukset. Käytännössä tämä on mahdotonta. 41 Miksi täydellinen testaus on mahdottomuus? Koska kaikissa ei-triviaaleissa ohjelmissa testitapausten määrä kasvaa hetkessä niin suureksi, että yksikään kone ei pysty ajamaan niitä järjellisessä ajassa. Koska kaikkien mahdollisten reittien määrä ei-triviaalissa ohjelmassa kasvaa niin suureksi, että yksikään kone ei pysty suorittamaan niitä järjellisessä ajassa. Koska triviaaleja ohjelmia ei kannata speksata, joten kaikki ovat ei-triviaaleja. 42 7
8 Djikstran lain perusteluja Djikstran laki on luonteeltaan matemaattinen, joten siitä ei ole empiirisiä tuloksia. Matemaattisesti se voidaan osoittaa oikeaksi konstruoimalla sellainen ohjelma, jossa on niin monta virheellistä polkua, että yksikään tietokone ei voi käydä niitä läpi järkevässä ajassa. Djikstran lain teoria Djikstran laki pätee, koska minkä tahansa ei-triviaalin ohjelman syötteiden, tilojen, siirtymien ja ajoitusten kombinaatioiden lukumäärä kasvaa hallitsemattomiin lukuihin. Djikstran laki on erinomainen esimerkki siitä, että pelkkä mustalaatikkotestaus ei takaa virheetöntä ohjelman toimintaa Weinbergin laki Weinbergin lain taustaa Ohjelmoija on soveltumaton testaamaan kirjoittamaansa koodia. Weinbergin laki on laadunvalvonnan peruslaki. Sillä voidaan perustella laadunvarmistuksen käyttö. Faganin laki tarkastuksista ja Weinbergin laki testauksesta ovat saman asian kaksi puolta: laadunvarmistus vaatii ulkopuolista työpanosta. 45 Weinbergin laki esiintyy jatkuvasti projekteissa. Jokainen löytää tietyt virheet, mutta hankalissa tapauksissa virheen löytää vasta ulkopuolinen silmäpari. Sen jälkeen kun ohjelmoija on vakuuttunut, että hänen koodinsa on virheetön, siitä löytyy vielä 1-3 virhettä/100 koodiriviä! 46 Weinbergin lain perusteluja Weinbergin lain teoria Vaikka miten katsoo kirjoittamaansa koodia ja etsii sieltä virheitä, niin sen näkee samalla tavalla kuin sen kirjoitti. Omat ajatuskulut ohjaavat koodin näkemistä. Jos koodissa on virhe, sen huomaa paremmin sellainen henkilö, jonka ajatuskulut eivät liity ohjelmakoodin kirjoitukseen. Omille virheilleen tulee sokeaksi. 47 Weinbergin laki perustuu psykologian teoriaan, jonka mukaan ihmiset haluavat ennen kaikkea olla itselleen rehtejä. Vaikeiden virheiden löytyminen vaatisi ratkaisusta poikkeavaa ajatuskulkua. Koska ulkopuolinen ei ole tehnyt ratkaisua, hänen ajatuskulkunsa poikkeaa ratkaisusta. 48 8
9 4.8. Pareto-Zipf -tyyppiset lait Arviolta 80% virheistä esiintyy 20% moduuleista. Pareto-Zipf lait tunnetaan paremmin tuttuna sääntönä. Laki esiintyy myös muussa tieteessä. Esimerkiksi kielitieteessä sääntö selittää sanojen frekvenssejä. Taloustietissä sääntö selittää tulojakaumia. Pareto-Zipf -lakien taustaa sääntö esiintyy lähes kaikkialla ohjelmistotekniikassa: 80% virheistä on 20% moduuleista. 80% suoritusajasta kulutetaan 20% moduuleista. 80% viittauksista tehdään 20% moduuleihin. 80% käyttäjistä käyttää 20% ohjelman ominaisuuksista Pareto-Zipf -lakien perusteluja Pareto-Zipf lakien perusteluja 2 Endres (yksi oppikirjan kirjoittajista) teki tutkimuksen ohjelmistojen virheistä Hän tutki DOS/VS käyttöjärjestelmää. Järjestelmästä löytyi 740 ongelmaa, joista 430 tulkittin virheiksi. Virheet löydettiin testattaessa noin 500 käyttöjärjestelmän moduulia. Endresin tutkimuksen tulokset olivat: Yli puolet virheistä oli vaatimusmäärittelyja suunnitteluvirheitä. Arviolta 80% virheistä oli 20% moduuleista Arviolta 85% virheistä koski yhtä moduulia. Pienten moduulien virhetiheys oli suurten moduulien virhetiheyttä suurempi. Koodin muuttaminen oli virhealttiimpaa kuin uuden koodin kirjoittaminen Pareto-Zipf -lakien teoria 4.9. Hamletin hypoteesi Pareto-Zipf lait tuntuvat esiintyvän jatkuvasti ohjelmistotekniikassa ja tietojenkäsittelytieteessä sääntöjen tapauksissa aineisto on jakautunut mitattavan suureen suhteen logaritmisesti. Ei ole selvää, miksi useat aineistot käyttäytyvät näin. Epäilyihin perustuva testaus voi olla useimpia muita testaustapoja tehokkaampi. Toistaiseksi testauksen lait ovat olleet aika negatiivisia. Hamletin hypoteesi ei ole. Epäilyihin (suspicion) perustuva testaus kohdistaa testit niihin osiin ohjelmaa, joissa virheitä uskotaan olevan entien. Hypoteesiin sopii myös Pareto-Zipf laki
10 Hamletin hypoteesin taustaa Testauksen tarkoituksena on löytää virheitä. Oppikirjan mukaan sellainen testitapaus, joka ei paljasta virhettä, on resurssien tuhlausta. (Luennoijana olen eri mieltä asiasta. Jo testattua asiaa testaava testitapaus on resurssien tuhlausta. Toimiva uusi testitapaus ei sitä ole.) Hamletin hypoteesin taustaa 2 Testaus on sekä kallista että vaikeaa. Toteutuessaan Hamletin hypoteesi antaisi sellaisen testausstrategian, jonka avulla riittävän kattava testaus voidaan tehdä vähemmillä resursseilla. Valitettavasti Hamletin hypoteesi ei ole laki. Varmoja empiirisiä todisteita hypoteesin oikeudesta ei vielä ole Hamletin hypoteesin perusteluja Pelkkä moduulien rakenne ei yksin kerro virheistä, vaan muutakin tietoa voidaan käyttää testattaessa hyväksi: ohjelmoijien kokemusta (kokemattomien koodiin enemmän testausta), tilastotietoa virheiden jakaumista, tietoja moduulien tarkastushistoriasta, tietoja tehdyistä muutoksista, ohjelmoijan omaa arviota moduuleista. Hamletin hypoteesin perusteluja 2 Edellä listattuja ominaisuuksia voidaan käyttää täsmäaseena etsimään virheitä. Pitää kuitenkin muistaa, että virheitä on muuallakin kuin epäilyttävissä ohjelman osissa. Vaikka 80% virheistä löytyisi epäilystrategialla, jäljellä on vielä 20% virheistä (Pareto-Zipf laki) Esiteltyjen lakien seurauksia Esiteltyjen lakien seurauksia 2 Tarkastukset ovat tehokas keino havaita virheitä aikaisessa vaiheessa. Faganin, Porter-Vottanin ja Basilin lait johtavat tähän tulokseen. Tulokset pätevät osittain myös muihin vähemmän muodollisiin katselmointitekniikohin, kuten koodin läpikäyntiin (walkthrough) tai tekniikkapalaveriin. Katselmointi: tilaisuus, missä kaksi tai useampi henkilö etsii samasta dokumentista vikoja. V&V-tekniikoita pitää käyttää rinnakkain. Ne eivät ole toisaan poissulkevia vaan antavat yhdessä parhaan tuloksen. Hetzel-Myersin, Djikstran ja Weinbergin lait johtavat tähän tulokseen. Lait sopivat myös ketterien prosessimallien parityöskentelyyn. Sekä pariohjelmointi että -testaus ovat katselmointeja, joten niihin voidaan soveltaa V&V:n lakeja
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ätiedotHarjoitustyö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ätiedotMenetelmä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ätiedot1. Johdanto. Empiirinen ohjelmistotutkimus. Empiirisen tutkimuksen perusta. Havainnot, laki, teoria. Havainto-laki-teoria
1. Johdanto Building software will always be hard. There is inherently no silver bullet. F. Brooks, 1987. Ohjelmisto- ja järjestelmätekniikka (software engineering, software systems engineering) määrittelevät,
LisätiedotOhjelmiston 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ätiedotKatselmoinnit. 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ätiedotYlläpidon merkitys. Ylläpidon lakien suhde ohjelmistotuotantoon. Ylläpidon osa-alueet. Ylläpidon lakien suhde ohjelmistotuotantoon 2
5. tarkoittaa niitä toimintoja, jotka tehdään ohjelmalle sen käyttöönoton jälkeen. on kallein työvaihe. Glassin mukaan 40-80% kustannuksista kuluu siihen. Kumma kyllä tätä ei ole listattu ylläpidon laeissa.
LisätiedotKatselmoinnin 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ätiedotOnnistunut 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ätiedotdokumentin 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ätiedotConvergence 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ätiedottsoft 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ätiedotVerifioinnin 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ätiedotTestaus 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ätiedotOhjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 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ätiedot7. 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ätiedotOhjelmistojen testaus
Ohjelmistojen testaus Juha Taina 1. Perusteet (P&Y:1-4) Kurinalainen insinöörityö sisältää suunnittelun ja rakentamisen lisäksi välttämättä tehtäviä, joiden tarkoitus on tunnistaa ja poistaa keskeneräisestä
LisätiedotTestausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
LisätiedotSEPA 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ätiedotOhjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
LisätiedotTIE 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ätiedotTestaussuunnitelma. 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ätiedotDynaaminen analyysi IV
Dynaaminen analyysi IV Luento 9 Antti-Pekka Tuovinen 16 April 2013 1 Tavoitteet Kokemusperäinen testitapausten suunnittelu Yhteenvetoa suunnittelutekniikoista 16 April 2013 2 1 Testitapausten kokemusperäinen
Lisätiedot2. Vaatimusmäärittely. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina
2. on ensimmäinen projektin osavaihe. Sitä pidetään myös tärkeimpänä vaiheena. Miksi? Ehkä seuraavat lait selittävät asiaa: Glass: huono vaatimusmäärittely on todennäköisin epäonnistuneen projektin syy.
Lisätiedot58160 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ätiedotOhjelmiston 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ätiedotTik-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ätiedotSEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus
SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön
LisätiedotDynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen
Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Kokemusperäinen testitapausten suunnittelu Yhteenvetoa suunnittelutekniikoista 23 April 2018 2 Testitapausten kokemusperäinen
LisätiedotProjektinhallinnan merkitys
6. ei ole työvaihe, vaan se on läsnä koko tuotteen elinkaaren ajan. Se siirtää ohjausvastuun pois kehitystiimiltä. Työvaihe sisältää prosessin ohjaukseen liittyviä tehtäviä: koko- ja kustannusarviot, aikataulun
LisätiedotVirheiden etsintä: katselmoinnit vai testaaminen?
hyväksymispäivä arvosana arvostelija Virheiden etsintä: katselmoinnit vai testaaminen? Timo Usenius Helsinki 10.11.2009 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS
LisätiedotOhjelmistotuotantoprojekti
Ohjelmistotuotantoprojekti Ryhmä Muppett TESTAUSDOKUMENTTI Helsinki 5.8.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Ohjelmistotuotantoprojekti, kesä 2008 Projekti: Muutos- ja korjauspyyntöjen
LisätiedotLaatu ohjelmistotyössä
Laatu ohjelmistotyössä Laatuongelmia Budjetin ylitys Aikataulun viivästyminen Bugit lopputuotteessa Sädehoitokone Asiavirheet sisällössä Ylläpito-ongelmat Dokumentointi Arkkitehtuuri Sisäiset kustannukset
LisätiedotLAATU, 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ätiedotKuopio 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ätiedotOhjelmiston 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ätiedotOhjelmistojen 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ätiedotAutomaattinen 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ätiedotSovellettu todennäköisyyslaskenta B
Sovellettu todennäköisyyslaskenta B Antti Rasila 16. marraskuuta 2007 Antti Rasila () TodB 16. marraskuuta 2007 1 / 15 1 Epäparametrisia testejä χ 2 -yhteensopivuustesti Homogeenisuuden testaaminen Antti
LisätiedotLaadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versi Päiväys Tekijä Kuvaus o 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ätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria
LisätiedotGood 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ätiedot10. Tarkastukset. Tarkastusten rakenne
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ätiedotTarkastusten 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ätiedotTestausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausraportti Orava Helsinki 5.5.2005 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Juhani Bergström Peter
LisätiedotTestaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
LisätiedotLaadunvarmistuksen 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ätiedotMihin 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ätiedotYksikkö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ätiedotMihin 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ätiedotTESTIRAPORTTI - 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ätiedotKehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!
Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Testauksen loppuraportti v. 1.0 Päivitetty 23.4.2001 klo 19:05 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0
LisätiedotT 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ätiedotT Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä
Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan
LisätiedotKäyttäjäkeskeinen suunnittelu
Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan
LisätiedotTestaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri
Testaussuunnitelma Oppimistavoitteiden hallintajärjestelmä harri Helsinki 15.11.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
LisätiedotTestaaminen 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ätiedotVersio 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ätiedotLohtu-projekti. Testaussuunnitelma
Lohtu-projekti Testaussuunnitelma Versiohistoria: 1.0 19.2.2003 1. versio Mari 1.1 20.2.2003 Muutoksia Mari 1.2 25.2.2003 Katselmoinnissa esiin tulleet Mari muutokset 1.3 17.3.2003 2. syklissä tehtävät
LisätiedotSEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T. Sisällysluettelo. 1 Johdanto. 2 SEPA harjoittelu käytännössä.
Sivu 1 (5) SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T Versio Päiväys Tekijä Kuvaus 0.1 27.10.2004 Timo Sallinen Ensimmäinen versio 1.0 31.10.2004 Timo Sallinen Korjauksia,
LisätiedotCT60A4150 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ätiedotTestauksen 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ätiedotTutkittua 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ätiedotWCLIQUE. 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ätiedotSiis mikä suunnittelun haastavuus ja ristiriitaisuus? Suunnittelun työvaiheet. Suunnittelun lait ja hypoteesit
3. on teknisesti kaikkein haastavin ja luonteeltaan kaikkein ristiriitaisin työvaihe. Miksi? Curtis: Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa. Dyer: Siirtyminen vaatimusmäärittelystä
LisätiedotTestaus-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ätiedotTestaussuunnitelma 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ätiedotOhjelmistotuotanto s
Laadunvarmistustekniikoita Ohjelmistotuotanto 1 testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia dokumentin (voi olla
LisätiedotOhjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)
581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun
LisätiedotOnnistunut 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ätiedotTestausprosessin 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ätiedotSYSTEEMITYÖ. Tärkeitä sanoja
SYSTEEMITYÖ Tärkeitä sanoja SYSTEEMITYÖN TÄRKEITÄ SANOJA Laatu (itse tuotteessa ja sen tekemisessä) Dokumentaatio Riskienhallinta Vaatimustenhallinta Uudelleenkäytettävyys Versionhallinta 2 LAATU Parityönä:
LisätiedotLaadunvarmistustekniikat
Laadunvarmistustekniikat Ohjelmistojen laadunvarmistustekniikoita: testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia
LisätiedotOhjelmiston 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ätiedot2. TILASTOLLINEN TESTAAMINEN...
!" # 1. 1. JOHDANTO... 3 2. 2. TILASTOLLINEN TESTAAMINEN... 4 2.1. T-TESTI... 4 2.2. RANDOMISAATIOTESTI... 5 3. SIMULOINTI... 6 3.1. OTOSTEN POIMINTA... 6 3.2. TESTAUS... 7 3.3. TESTIEN TULOSTEN VERTAILU...
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
LisätiedotTestaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PUSU-ryhmä Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Jussi Hynninen
LisätiedotMallintarkistus ja sen
VERSIO 0.1 LUONNOS Mallintarkistus ja sen soveltaminen PLCohjelmien verifioinnissa AS-0.3200 Automaatio- ja systeemitekniikan projektityöt -projektisuunnitelma Markus Hartikainen 2/1/2009 Sisältö 1. Projektityön
LisätiedotMenetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
LisätiedotLAATURAPORTTI 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ätiedotTIE 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ätiedotTestausdokumentti. Sivu: 1 / 10. Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto. Versiohistoria
Sivu: 1 / 10 Testausdokumentti Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto Versiohistoria Versio Päivitykset 0.4 Lisätty mod_form.php -tiedostoon liittyvät testit 0.5 Lisätty johdanto 1.0 Dokumentti
LisätiedotTestauspää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ätiedotKontrollipolkujen 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ätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
LisätiedotYhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014
Yhtälönratkaisusta Johanna Rämö, Helsingin yliopisto 22. syyskuuta 2014 Yhtälönratkaisu on koulusta tuttua, mutta usein sitä tehdään mekaanisesti sen kummempia ajattelematta. Jotta pystytään ratkaisemaan
LisätiedotTestauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen
Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia
LisätiedotTestaussuunnitelma. Asdf. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Asdf Helsinki 22.2.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Kuisma Sami Louhio
LisätiedotMiten selvitä matematiikasta? Tutkitusti hyviä opiskelutaitovinkkejä
Miten selvitä matematiikasta? Tutkitusti hyviä opiskelutaitovinkkejä Panu Erästö Matemaatikko-tilastotieteilijä (Ph.D) Opettaja/pedagogi/opetuksen kehittäjä Kaikilla on edellytykset Usko omiin kykyihin
LisätiedotMat Tilastollisen analyysin perusteet, kevät 2007
Mat-2.2104 Tilastollisen analyysin perusteet, kevät 2007 2. luento: Tilastolliset testit Kai Virtanen 1 Tilastollinen testaus Tutkimuksen kohteena olevasta perusjoukosta esitetään väitteitä oletuksia joita
LisätiedotKÄ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ätiedotOhjelmoinnin perusteet Y Python
Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2011 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2011 1 / 39 Kertausta: tiedoston avaaminen Kun ohjelma haluaa lukea tai kirjoittaa tekstitiedostoon, on ohjelmalle
Lisätiedot7. Tutkimuksen teko. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina
7. 7.1. Johdanto Tämä luku perustuu kirjaan C. Wohlin et al., Experimentation in Software Engineering, An Introduction, Kluwer Academic Publishers, 2000. ISBN 0-7923-8682-5. Tähän asti olemme käsitelleet
LisätiedotTIE-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ätiedotTIE-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ätiedotTestausraportti. Oppimistavoitteiden hallintajärjestelmä harri
Testausraportti Oppimistavoitteiden hallintajärjestelmä harri Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
LisätiedotHY / Matematiikan ja tilastotieteen laitos Johdatus logiikkaan I, syksy 2018 Harjoitus 5 Ratkaisuehdotukset
HY / Matematiikan ja tilastotieteen laitos Johdatus logiikkaan I, syksy 2018 Harjoitus 5 Ratkaisuehdotukset 1. Päättele resoluutiolla seuraavista klausuulijoukoista: (a) {{p 0 }, {p 1 }, { p 0, p 2 },
LisätiedotLaatukustannukset. Laadun hallinta. Laadun kustannuksista
Laatukustannukset Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 13.2.2007 US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria
LisätiedotAvainsanojen poimiminen Eeva Ahonen
Avainsanojen poimiminen 5.10.2004 Eeva Ahonen Sisältö Avainsanat Menetelmät C4.5 päätöspuut GenEx algoritmi Bayes malli Testit Tulokset Avainsanat Tiivistä tietoa dokumentin sisällöstä ihmislukijalle hakukoneelle
Lisätiedot