Kiitos kommenteistanne! Huomaan, että olette aihepiirin kanssa painiskelleet ennenkin.

Mielestäni testauksessa pitää olla aina tavoitteena löytää mahdollisimman paljon tietoa ja bugeja sijoitettuun aikaikkunaan, eli rahamäärään nähden. Kovin usein kaikki muu on epäolennaista tekemistä.

Tuntuu, että tuota ajatusta tuotteen elinkaaren pidentämisestä sovelletaan erityisesti suurissa tietojärjestelmähankkeissa. Usein sellaisten hankkeiden ylläpito ja tukimaksut ovat sen verran jämerää kokoluokkaa, että fiksailu jälkikäteen on aivan kannattavaa bisnestä. Minusta vika ei kuitenkaan ole toimittajan päässä vaan monesti kysymys on heikosta osto-osaamisessa.

Jo vuonna 2000 julkaistu Dilbert kiteyttää tämän tarinan erinomaisesti. Se komeilee isona printtinä myös meidän toimiston jääkaapin ovessa: http://dilbert.com/strips/comic/2000-03-19/

Tänään kävimme Proven toimiston aamukahvipöydässä kiinnostavan keskustelun juuri tästä lähestymiskulmasta. Kaikki riippuu siitä, minkälainen järjestelmä testattavana on. Jos ajatellaan esimerkiksi vaatimusta siitä, että tuotteen pitää olla 99,9% toimiva. Sehän on aivan hyvän kuuloinen prosentti.

Jos sinulla on analoginen kello, joka tekee virhettä 1 sekunnin 1000:sta, niin ehkä sen kanssa voisi mökkiolosuhteissa elääkin.

Toisaalta jos sinulla on lentokone, joka putoaa 1 lennolla 1000:sta, niin silloin voisi sanoa, että kyseessä on vakavan laatuinen ongelma.

Kaikki siis riippuu siitä mitkä tavoitteemme ovat. Ne vain täytyy tunnistaa :)

Rahan suhteen pitää olla kuin ison maalaistalon pojat. He tietävät, että rahaa on, mutta se tulee käyttää viisaasti. Jokaisen tällä alalla toimivan tulee tietää, että mitä aiemmin vika löydetään, sitä halvempaa sen korjaaminen on. Eli kannattaa panostaa katselmointeihin ja alemmantason testaamiseen, kuin siihen, että testataan tuote vain systeemitasolla. Mielestäni tämä on suurin virhe missä projekti päällikkö “säästää”.

Joidenkin tutkimusten mukaan, yli 50% virheistä johtuu epäselvistä tai puutteellisista vaatimuksista. Toisin sanoen, yli puolet vioista tehdään ja testataan “tahallaan väärin”. ja sitten niitä aletaan korjaamaan jälkikäteen. Ei ihmekkään, että aikaa ja rahaa ei ole niiden korjaamiseen.

Toinen tutkimus kertoo, että 64% featureista on lähes turhia. Miksi niitä edes tehdään, jos niitä ei kukaan käytä? Miksi niiden testauksessa sitten “säästetään” ja annetaan vikojen mennä läpi? Eikö olisi parempaa säästöä olla tekemättä ko. featurea, jos sitä ei tarvita tai jos se saa mennä toimimattomana ulos?

Sanoisin, että kuten monessa muussakin asiassa, niin myös tässä esimerkissä pätee universaalisääntö: se ei ole niin, että oikein on tämä TAI tuo. Sillä oikea vastaus on se, että yhtä aikaa pätee tämä JA tuo.

Eli samaan aikaan kun eri reitit pyytävät mitä todennäköisimmin enemmän saalista ohjelmistotestauksessa, niin toisinaan on intresseissä kulkea nimenomaan aina sama reitti uudestaan ja uudestaan ja silloin tyypillisesti halutaan saada ns. nolla-saalis. Puhutaan regressiotestauksesta. On olemassa tuotteita ja seikkoja joiden luonne on semmoinen, että toiminta testataan aina uudestaan juuri samalla tavalla. Tämmöinen tuote voi olla sellainen, että siinä on yksi tai kaksi toimintoa jotka ovat niin tärkeitä, että jos ne eivät toimi, niin koko tuotteella ei tee mitään.

Pidetään kuitenkin mielessä mitä aluksi sanoin: sääntö on se, että yhtä aikaa on totta tämä JA tuo. Voimme siis jatkaa ajatusta edelleen ja todeta, että toisinaan regressiotestausta voi tehdä sienimetsä-periaatteella ja saada hyviä tuloksia. Riippuu asiasta jota olemme testaamassa, että mikä lähestymiskulma on osuvin.