Hupaisia bugeja

Testaajana saa välillä käyttää luovuutta etsiessään mielekkyyttä omasta työstään. On hirveän masentavaa etsiä virheitä muiden luomuksista, vääntää kättä siitä että nämä ongelmat ovat ihan oikeasti ongelmia, ja esiintyä pessimistinä kun arvioidaan projektin mahdollisuuksia päästä maaliin sovitussa aikataulussa.

Työssään voi kokea aidosti onnistuvansa, kun löytää aikaisessa vaiheessa vakavia virheitä, joiden korjaamiseksi palaveerataan, järjestellään töitä, huokaillaan raskaasti ja tehdään pitkää päivää. Silloin voi riemuita siitä, että mitä varhaisemmassa vaiheessa virhe löytyy, sitä pienempi sen vaikutus on työmäärään ja projektin aikatauluun, jos se vain osataan käsitellä tilanteen vaatimalla tavalla. Ja jos projektin aikataulu viivästyykin, niin sen kanssa on kuitenkin sitä helpompi elää, mitä aikaisemmin tieto asiasta saadaan.

Bugit kun eivät häviä silmät ummistamalla. Tuotantoympäristössä sama virhe voisi aiheuttaa pr-katastrofin niin järjestelmän tilanneelle asiakkaalle kuin sen toteuttaneelle ohjelmistotalollekin.

Toisaalta on kuitenkin hirveän hyvä asia, että tällaisia isoja show stoppereita ei tule ihan joka projektissa vastaan ollenkaan. Silloin voi iloita siitä, että määrityksessä ja suunnittelussa on onnistuttu riittävän hyvin, ja koodarit ovat saaneet keskittyä työhönsä. Testaajan rooliksi jää motkottaa pikkuasioista. Vaikka käyttäjän kannalta monet niistäkin ovat oikeastaan melko isoja asioita.

Joskus ohjelmistovirheistä on helppo löytää myös oma huumoriarvonsa. Usein nämä liittyvät bugeihin, jotka eivät varsinaisesti häritse itse prosessin läpi viemistä, mutta tarkkasilmäinen huomaa että jotain tapahtuu toisin kuin pitäisi. Nauraminen on tietysti sitä helpompaa, mitä kauempana tulevaisuudessa julkaisuajankohta siintää, mutta toisaalta epätoivon hetkilläkin nauraminen saattaa tehdä hyvää.

Kieliversiot ovat perinteisesti asia, jossa jotain pientä unohtuu, ja lopputulos voi näyttääkin sitten yllättävän hassulta. Myös esimerkiksi aikaleimat ja muut automaattisesti luotavat tiedot saattavat elää aivan omaa elämäänsä, samoin kuin vaikkapa tilaisuuksiin liittyvät kellonajat tilaisuuksia siirreltäessä ja kopioitaessa. Joskus kaikkien kenttien sisällöt eivät tallennu oikein, tai tekstissä olevat skandit hajoavat yllättäen.

Yksi hupaisimmista koskaan kuulemistani bugeista oli tapaus, jossa rajapintahaku tyhjensi tietokannan joka yö, mutta haki uudet tiedot vain arkipäiviksi. (Tosin tämän bugin löytyminen tai syyn jäljittäminen tuskin oli hupaisaa kenestäkään prosessiin osallistuneesta.) Myös testattavan ohjelmiston hitaus ja sitkeät sovellusvirheet herättävät joskus ajatuksen, että pitäisikö brändätä slow-food-henkinen ajatus hitaista ohjelmistoista, jotka kannustavat ihmisiä irrottautumaan tietokoneistaan ja kännyköistään, nauttimaan rauhassa aamukahvit, käymään lenkillä ja kohtaamaan toisensa kasvokkain. Parantaisiko se meidän elämänlaatuamme enemmän kuin jatkuva toiminnan tehostaminen?

Testaamisen mielekkyydestä

Joskus kuulee ihmettelyä, miten kukaan voi haluta olla ohjelmistotestaaja. Sellaiselle, joka on joutunut muun työn ohessa kliksuttelemaan läpi liudan jonkun muun naputtelemia testitapauksia testaus varmasti näyttäytyykin tylsänä ja aikaavievänä tehtävänä, josta on vaikea sanoa, turhauttaako enemmän jos kaikki menee läpi, vai jos mikään ei toimi kunnolla.

Tämä on kuitenkin hyvin kapea näkökulma testaukseen. Hyvin tehty ohjelmistotestaus saattaa alkaa jo myyntivaiheessa kun mietitään, kuinka työläitä asiakkaan toiveet ovat täyttää. Testausnäkökulma on avuksi myös luotaessa ohjelmistomääritystä, sillä yksi keskeisimpiä hyvän määrityksen ominaisuuksista on että sen perusteella voi testata, täyttääkö ohjelmisto sille asetetut vaatimukset. Testaussuunnittelua on mahdollista käyttää myös toteutuksen tukena, sillä testitapaukset saattavat tarjota paitsi konkreettisen ja selkeästi jäsennellyn tavan lähestyä määritystä, myös eräänlaisen muistilistan poikkeustilanteista, joista ohjelmiston on selviydyttävä vaikka määritys ei niitä käsittelekään.

Toki testaustehtävien suorittaminen on välillä myös suunnattoman tylsää. Mutta harva työnkuva on pelkkää hupia. Siksi kai meille työstä maksetaan, että olemme hetkittäin valmiita tinkimään omasta mukavuudestamme saadaksemme jonkin tärkeän tehtävän tehdyksi. Testauksen tehtävä on suojella liiketoimintaa niiltä katastrofeilta, joita bugit voivat aiheuttaa, eikä sankaritekojenkaan tekeminen ole pelkkää riemua.

Testaamisen mielekkyyteen voi myös vaikuttaa. Testitapauksia voi suunnitella niin, että niiden läpikäynti on ennemminkin uteliaisuutta herättelevä kuin uneliaisuutta aiheuttava kokemus. Automatisointi saattaa joskus pelastaa tekemästä niitä puuduttavimpia tehtäviä. Mielekkyyden luominen ja ylläpitäminen testauksessa lieneekin yksi niistä testauksen tehtävistä, joilla ammattilaiset erotellaan harrastelijoista, ja joissa kovimmallakin asiantuntijalla on aina mahdollisuuksia kehittyä vielä paremmaksi.