Arkisto: kesäkuu 2010



Vaatimus Juhannukselle

24. kesäkuuta, 2010 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 1

Ihmiset ovat kehittäneet itselleen ja muille roppakaupalla juhannusperinteitä. Olosuhteista riippumatta niitä on pakko tai ainakin hyvä noudattaa. Tässä yksi:

Hauskaa Juhannusta lukijoille, olosuhteista riippumatta!

Paljonko virhe maksaa?

23. kesäkuuta, 2010 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 5

Testaus on investointi. Investoinnin tarkoituksena on löytää virheet siinä vaiheessa, kun niiden korjaaminen on halvinta.

LinkedInin keskustelupalstalta bongasin linkin, jonka takaa löytyi varsin mielenkiintoinen artikkeli. Artikkelissa käydään läpi 10 kalleimmaksi tullutta softavirhettä. Melko karua tekstiä, tässä  muutama ns. herkkupala.

Marsiin lähetettiin luotain. NASA oli tehnyt speksi SI-yksiköissä, mutta koodaaja oli käyttänyt imperial unitteja. Laskeutuminen Marsin pinnalle meni ns. käteen ja luotain hajosi. Kustannus 125 miljoonaa dollaria.

CIA väitti, että Neuvostoliitto varastaa USAn öljyputkinen ohjausteknologiaa. CIA ujutti pikkuriikkisen bugin varastettavaksi. Seuraksena Neuvostoliitossa räjähti öljyputki, jonka Wikipedia toteaa olleen ”monumentaalisin ei-ydinräjähdys koskaan avaruudesta nähtynä.” Kukaan ei kuollut, mutta on saattanut tovi mennä korjaillessa.

Toimittaja teki softan julkishallinnolle UK:ssa. Uusi ohjelmisto ei ollut yhteensopiva tilaajan järjestelmien kanssa. Kustannus tähän asti, 1000 miljonaa puntaa.

Sädehoitolaite antoi turhan paljon säteilyä. Viisi ihmistä kuoli.

Loput virheet ja tarkemmat kuvaukset löytyy täältä.

Aika hienosti noissa virheissä ja kustannuksissa tiivistyy likipitäen kaikki ongelmat, mistä mekin Antin kanssa olemme tässä blogissa keskustelleet. CIA:n huijaus on sinällään nerokas, mutta muuten. Määritysongelmia, osto-osaamisen puutetta, kiirettä jne.

Siksi en malta olla toistamatta.

Testaus on investointi. Investoinnin tarkoituksena on löytää virheet siinä vaiheessa, kun niiden korjaaminen on halvinta.

Vaatimukset täyttyvät, entäs sitten?

16. kesäkuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 1

Teimme jokin tovi takaperin aasialaispohjaisella testaustiimillä kaksi testikierrosta ihan kokeilumielessä. Ensimmäiselle testikierrokselle laadittiin hyvin selkeäsanainen testispeksi testattavan tuotteen vaatimusten pohjalta.

Testaustyö tehtiin Intiassa ja tulokset olivat odotetunlaiset. 40 testitapauksen joukosta löytyi 18 virhettä. Yhtä paljon kuin testien suunnitteluvaiheessakin oli jo löydetty (*). Toisen testikierroksen tehtävänanto oli selvästi erilainen. Käytettävissä oli yhtä paljon aikaa testaustyöhön kuin edelliselläkin kerralla.

Toimeksiantoon lähetettiin ainoastaan testattava tuote ja ranskalaisin viivoin lista asioista jotka kannattaa tsekata testaustyön ohessa. Ei siis vaatimuksia, eikä testitapauksia:

Test this product to your best knowledge and report all issues in a way you find best suited

Lopputuloksena raportteja saatiin 25. Virheiden raportointiin testaustiimi käytti vielä kekseliäästi videonkaappausta, joten kenellekään ei jäänyt epäselväksi minkälaisista virheistä oli kysymys. Myös ohjelmistokehittäjät kiittivät!

Suorittavaan testaustyöhön käytetystä ajasta saatiin tarkalleen ottaen 38% parempi tulos kun testaajan käsiä ei sidottu vaatimusten tai testitapausten kyttäämisellä. Testaaja otti loppukäyttäjän hatun päähänsä ja raportoi virheistä parhaan kokemuksensa mukaan.

Kuilu vaatimusten mukaan toimivan ja oikeasti toimivan välillä meinasi tässä tapauksessa jäädä hurjan kokoiseksi. Probleema onkin juuri siinä että vaatimusmäärittelyt tehdään lähes poikkeuksetta ennen tuotteen rakentamista. Vaatimukset ovat etukäteen suunnittelijan pään sisällä muodostettu käsitys siitä miten lopputuotteen pitäisi pelata. Pidä se mielessä kun suunnittelet testausta.

Muista että vaatimusten mukaan toimiva tuote ei ehkä ole toimiva tuote. Vasta avoimin mielin tehty testaus voi kertoa miten oikeasti kävi!

(*) Testauksen suunnitteluvaiheessa jouduttiin tutustumaan sekä toiminnallisiin vaatimuksiin että tutkimaan itse tuotetta, eli tekemään tutkivaa testausta. Suunnitteluvaihe siis vei myös reilusti aikaa.

Testaa ajoissa

8. kesäkuuta, 2010 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 4

Mitä aikaisemmin virheet löydetään, sitä edullisemmaksi niiden korjaaminen tulee. Jotta virheet löydetään ajoissa, pitää testaukseen panostaa mieluummin kehityskaaren alkuvaiheessa.

Tietenkin testauksen laatu ja tarkoitus täytyy aina suhteuttaa tuotekehityksen vaiheeseen. Arkkitehtuurin suunnitteluvaiheessa ei voida todentaa napin paikkaa ja väriä. Mutta ilman muuta voidaan varmistaa, että arkkitehtuuri mahdollistaa myöhemmin nappuloiden sijoittelun halutulla tavalla!

Projekteissa on jatkuva kiire ja rahakin on tiukalla. Siitä huolimatta varmista, että suunta on oikea.