Testaaja samoilee sienimetsällä
Erittäin herkullisen, mutta kuitenkin myrkyllisen korvasienen satokausi lähestyy kovaa kyytiä. Sehän tarkoittaa samoilemista hiekkapohjaisissa kangasmetsissä. Kokenut korvasienestäjä tietää parhaat paikat ja löytää fiiliksellä myös uudet apajat.
Uuden kauden tullen Simo Sienestäjä ajelee jälleen tutun metsätien päähän ja lähtee patikoimaan saalisrepun kanssa. Tavoitteena on päästä makkaranpaistoon läheisen lammen rantaan, kuten aina keväisin. Simo samoilee kangasmaastossa bongaillen aktiivisesti reitillään olevia korvasieniä. Saalistakin löytyy ja reppu painaa mukavasti makkarapaikoille päästessä. Simo on tyytyväinen
Simon päivätyö on ohjelmistotestaus. Hän päättää kokeilla tällä kaudella työpaikalta tuttua menetelmää ja kirjaa reittinsä alla olevalle kartalle tarkasti. Askel askeleelta. Kun Simo on saanut edellisen saaliin ryöpättyä ja pataan, hän lähtee uudelle metsäretkelle. Vieläkö saalista mahtaa kertyä, jos Simo samoilee makkarapaikoille samoja jalanjälkiä?
Että näin. Toteaa Simo makkarapaikoilla. Toisella kerralla kuljetut kilometrit eivät tuottaneet odotettua tulosta. Sienimatkan dokumentointi vei kohtuuttomasti aikaa ja matkan uudelleen kulkemisen konkreettiset tulokset jäivät laihoiksi. Simo saattoi vain todeta itsestään selvyyden. Parhaat tulokset syntyvät, kun hän valitsee hieman uuden reitin jokaisella reissulla erikseen.
Aivan sama pätee ohjelmistojen testaukseen. Uusia bugeja ja uutta tietoa testattavasta tuotteesta löytyy joka kerta vähemmän, kun testaajalle puetaan ravihevosen silmälaput ja laitetaan kulkemaan samaa polkua kerran toisensa jälkeen.
Jos rahaa ja aikaa on rajallisesti käytettävissä, niin kannattaa keskittyä olennaiseen. Testien suunnittelussa tärkeintä on kuvata tavoite. Se, mitä tulee tulla testatuksi. Kun testaaja saa valita reitin itse, tuloksia syntyy varmasti enemmän.
Herkullinen esimerkki! Tuo dokumentointiasia on myös mielenkiintoinen. Moderni teknologia tekee reitin dokumentoinnin itsestään, eikös esimerkiksi GPS:ssä ole semmonen mahdollisuus, että kuljettu reitti otetaan muistiin. Ja seuraavalla kerralla vehje neuvoo, että mihin pitää kävellä?
Onkohan testauspuolella samanlaisia työkaluja, joka katsoo mitä tutkivalla testauksella tehdään ja seuraavalla kerralla kone osaa tehdä samat temput itsekseen?
Kiitos Jaakko,
Osut aivan oikeaan. Ajattelussa voi tosiaan mennä juuri mainitsemasi askelen pidemmälle. GPS voisi tallentaa reitin automaattisesti ja reittiohjeeseen tallennetaan vielä erityisesti ne parhaat sieniapajat. Sitten seuraavalla kerrala voidaankin hommata automaatti, joka kulkee Simon puolesta tuota samaa reittiä vaikka joka päivä. Se ilmoittelee heti, kun saalista ilmestyy jälleen näköpiiriin.
Näin testausautomaatio ja Bugien metsästys voivat toimia erinomaisesti ja käsi kädessä parhaan lopputuloksen saavuttamiseksi.
Esimerkki on hyvä – pystyin helposti kuvittelemaan itseni hetkeksi metsässä samoilemassa 🙂
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.
Hei Ammattitestaaja,
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 🙂