4. Verifiointi ja validointi. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina

Samankaltaiset tiedostot
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

Harjoitustyön testaus. Juha Taina

Menetelmäraportti Ohjelmakoodin tarkastaminen

1. Johdanto. Empiirinen ohjelmistotutkimus. Empiirisen tutkimuksen perusta. Havainnot, laki, teoria. Havainto-laki-teoria

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

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

Ylläpidon merkitys. Ylläpidon lakien suhde ohjelmistotuotantoon. Ylläpidon osa-alueet. Ylläpidon lakien suhde ohjelmistotuotantoon 2

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

Onnistunut Vaatimuspohjainen Testaus

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

Convergence of messaging

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen

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

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

Ohjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi

7. Verifiointi ja validointi

Ohjelmistojen testaus

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

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

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

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

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

Dynaaminen analyysi IV

2. Vaatimusmäärittely. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina

58160 Ohjelmoinnin harjoitustyö

Ohjelmiston testaus ja laatu. Testausmenetelmiä

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

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus

Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen

Projektinhallinnan merkitys

Virheiden etsintä: katselmoinnit vai testaaminen?

Ohjelmistotuotantoprojekti

Laatu ohjelmistotyössä

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

Kuopio Testausraportti Asiakkaat-osakokonaisuus

Ohjelmiston testaus ja laatu. Testaus yleistä

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Automaattinen yksikkötestaus

Sovellettu todennäköisyyslaskenta B

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

T Testiraportti - integraatiotestaus

Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä

10. Tarkastukset. Tarkastusten rakenne

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

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma Labra

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

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

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

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

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

T Testiraportti - järjestelmätestaus

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä

Käyttäjäkeskeinen suunnittelu

Testaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri

Testaaminen ohjelmiston kehitysprosessin aikana

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

Lohtu-projekti. Testaussuunnitelma

SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T. Sisällysluettelo. 1 Johdanto. 2 SEPA harjoittelu käytännössä.

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen Kevät 2016

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

Tutkittua tietoa. Tutkittua tietoa 1

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Suunnittelun työvaiheet. Suunnittelun lait ja hypoteesit

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

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

Ohjelmistotuotanto s

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)

Onnistunut SAP-projekti laadunvarmistuksen keinoin

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

SYSTEEMITYÖ. Tärkeitä sanoja

Laadunvarmistustekniikat

Ohjelmiston testaus ja laatu. Testaustasot

2. TILASTOLLINEN TESTAAMINEN...

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

Testaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Mallintarkistus ja sen

Menetelmäraportti - Konfiguraationhallinta

LAATURAPORTTI Iteraatio 1

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

Testausdokumentti. Sivu: 1 / 10. Ohjelmistotuotantoprojekti Sheeple Helsingin yliopisto. Versiohistoria

Testauspäällikön tarinoita Arto Stenberg

Kontrollipolkujen määrä

Ohjelmistojen suunnittelu

Yhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014

Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen

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

Miten selvitä matematiikasta? Tutkitusti hyviä opiskelutaitovinkkejä

Mat Tilastollisen analyysin perusteet, kevät 2007

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

Ohjelmoinnin perusteet Y Python

7. Tutkimuksen teko. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina

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

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

Testausraportti. Oppimistavoitteiden hallintajärjestelmä harri

HY / Matematiikan ja tilastotieteen laitos Johdatus logiikkaan I, syksy 2018 Harjoitus 5 Ratkaisuehdotukset

Laatukustannukset. Laadun hallinta. Laadun kustannuksista

Avainsanojen poimiminen Eeva Ahonen

Transkriptio:

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

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. 9 4.1. 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

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. 4.2. 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. 15 16 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

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. 23 4.3. 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

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. 25 26 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. 27 28 4.4. 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 1978. 29 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

Hezel-Myersin lain perusteluja Hezel-Myersin lain perusteluja 2 Hezel-Myersin lain ohjatussa kokeessa 1978 59 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,5 1-7 13 37 5,4 5,5 5,5 2-9 14 29 Tarkastukset 5,7 3,0 6 3-9 11 75 Mustalaatikko + tarkastukset 7,6 4,3 8 5-10 14 75 33 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ä. 34 4.5. 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. 35 36 6

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. 37 38 Maysin hypoteesin perusteluja 3 4.6. 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. 39 40 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

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

4.8. Pareto-Zipf -tyyppiset lait Arviolta 80% virheistä esiintyy 20% moduuleista. Pareto-Zipf lait tunnetaan paremmin tuttuna 80-20 sääntönä. Laki esiintyy myös muussa tieteessä. Esimerkiksi kielitieteessä 80-20 sääntö selittää sanojen frekvenssejä. Taloustietissä 80-20 sääntö selittää tulojakaumia. Pareto-Zipf -lakien taustaa 80-20 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. 49 50 Pareto-Zipf -lakien perusteluja Pareto-Zipf lakien perusteluja 2 Endres (yksi oppikirjan kirjoittajista) teki tutkimuksen ohjelmistojen virheistä 1974. 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. 51 52 Pareto-Zipf -lakien teoria 4.9. Hamletin hypoteesi Pareto-Zipf lait tuntuvat esiintyvän jatkuvasti ohjelmistotekniikassa ja tietojenkäsittelytieteessä. 80-20 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. 53 54 9

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. 55 56 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). 57 58 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. 59 60 10