Toistettavuus vs. varioitavuus

Keskusteltaessa siitä, mitkä ovat suunnitelmallisen, ammattimaisen testauksen keskeisimpiä etuja, joskus nousee ajatus testien toistettavuudesta. Kun testitapaukset suunnitellaan riittävän yksityiskohtaisesti, tiedetään täsmälleen, mitä testaaja on testannut, ja samat testit ovat suoritettavissa täsmälleen samanlaisina kierroksesta toiseen, jolloin saadaan eksaktia dataa siitä, milloin jokin toiminto hajonnut. Testit voidaan myös automatisoida.

Toistettavuus on kyllä tärkeää siinä mielessä, että bugiraportoinnissa keskeisimmässä roolissa on tarjota riittävät tiedot virhetilanteeseen johtaneesta toimenpideketjusta, jotta korjauksen tekevä kehittäjä voisi löytää virheen koodista ja korjata sen. Sen sijaan on kyseenalaista, kuinka tarkkaan on tarpeen dokumentoida ne polut, joiden varrelta virheitä ei jollakin testikierroksella löytynyt.

Huomionarvoista on kuitenkin myös se, että yksikään testikierros ei voi testata kaikkia mahdollisia polkuja, joita pitkin todellinen käyttäjä voi järjestelmää käyttää. Myös testauksessa käytetty testidata on vajavaista verrattuna todellisten tilanteiden aikana mahdollisesti tarvittavaan dataan. 

Suunnitelmalliseen testaukseen toki kuuluu miettiä, mitkä ovat sellaisia rajatapauksia, joissa virheet todennäköisimmin ilmenevät jos niitä on, mutta ovelimmat virheet ovat sellaisia, joita ei voi ennakoida. Siksi testauksen kokonaiskattavuuden parantamiseksi testaajan on hyvä varioida toimintaansa kierrokselta toiseen siirryttäessä.

Sattuma on testaajan paras ystävä.

Esimerkiksi, jos prosessin B läpivienti ennen prosessia A aiheuttaa virhetilanteen prosessissa A, asia ei koskaan selviä testaajalle joka testaa prosessin A aina ennen prosessia B. Samoin jos hakutoiminnossa jokin tietty hakutermien yhdistelmä aiheuttaa virhetilanteen, sitä tuskin löydetään miettimällä etukäteen, millaisia yhdistelmiä testaajan tulisi testata.

On myös vaikea nähdä, mitä haittaa testien varioimisesta olisi. Koska yksittäistä testikierrosta ei voida suunnitella niin, että se olisi varmasti se kaikkein tehokkain löytämään virheitä, vaihtaminen toiseen yhtä hyvään seuraavalla kierroksella ei heikennä testauksen laatua lainkaan. 

Lisäksi testauksessa puhutaan hyönteismyrkkyparadoksista, jonka mukaan toistettaessa täsmälleen samaa testijoukkoa, sen kyky löytää virheitä vähitellen heikkenee. Kehittäjät ikään kuin oppivat välttämään niitä virheitä, joita joutuvat toistuvasti korjaamaan.

Toki variaatiot testauksessa asettavat korkeammat vaatimukset bugiraportoinnille, koska tällöin muuta informaatiota virhetilanteeseen johtaneista syistä ei ole käytettävissä. Yksityiskohtainen bugiraportointi on kuitenkin niitä perustaitoja, jotka erottavat hyvän testaajan huonosta testaajasta.

Mitä bugille tapahtuu?

Kaikki tietävät, mitä ensin tapahtuu. Testaaja lähtee käymään läpi testitapauksia, hetken päästä prosessi katkeaa. Tilanne dokumentoidaan tekstein, kuvakaappauksin, nauhoittein, miten milloinkin, kuitenkin mahdollisimman yksityiskohtaisesti. Sitten se tallennetaan bugitietokantaan ja jäädään odottamaan korjausta.

Mutta mitä sitten tapahtuu?

Testaaminen on välttämätöntä toimintavarman ohjelmiston rakentamiseksi. Joskus voi kuitenkin käydä niin, että testaus tuottaa bugeja paljon nopeammin kuin niitä ehditään korjaamaan. Yksikin testaaja saattaa raportoida kymmeniäkin bugeja päivässä, ja samaan aikaan kehittäjät ovat ehkä kiinni uusien ominaisuuksien kehittämisessä tai jopa muissa projekteissa. Tai jos bugeja korjataankin, yksittäinen korjaus saattaa avata testaajalle tien löytää monta uutta bugia. Muutamassa päivässä bugitietokanta saadaan niin täyteen, että sen perkaaminen käy työstä. Ja todella se perkaaminen vie myös aikaa. Bugien korjaamista ohjataan käymällä listaa läpi, delegoimalla ja priorisoimalla. Kehittäjät etsivät itselleen mielekkäitä kokonaisuuksia korjattaviksi. Testaaja kahlaa läpi aktiivisten bugiraporttien listaa tarkistaakseen, muistiko eilen raportoida sen yhden kummallisen bugin, jonka selvittely jäi kesken, tai etsii viime viikolla löytyneen bugin täydentääkseen sen kuvausta uudella tilanteella, jossa sama ongelma toistuu. Kenties muukin projektihenkilöstö raportoi löytämiään bugeja joko suoraan samaan tietokantaan luoden duplikaatteja, tai kyselemällä sähköpostitse testaajalta, joko olet huomannut tämän ja tämän asian. Kehittäjien tehdessä uutta toiminnallisuudet saattavat myös muuttua tavalla, jonka myötä vaivalla dokumentoituja bugeja ei enää saada toistumaan, ja niiden moniportainen käsittely vie turhaan aikaa niin kehittäjiltä kuin testaajilta.

Ei kuulosta ihan hirveän tehokkaalta.

Soppa saadaan kasvamaan entisestään, kun kirjataan bugeina kaikki testaushavainnot, ja oletetaan, että ne hoituvat kehittäjien ja testaajien välisellä pingiksellä.

Testaaja ei kuitenkaan yleensä ole projektipäällikkö, ei suorassa yhteydessä asiakkaaseen eikä vastuussa määrityksestä tai vaikkapa käyttöliittymäsuunnittelusta. Tarkentavat kysymykset, joiden oleellinen sisältö on "pitääks tää oikeesti tehdä?" tai "mitä tää määrityksen kohta oikeesti tarkoittaa?" pitäisi ohjata jonnekin muualle. Esimerkiksi suoraan asiakkaalle. Testaaja kun ei voi yksinään antaa kehittäjälle lupaa oikaista.

Miten tilanteen sitten saisi pysymään hanskassa?

Bugien löydettävyyttä parannetaan paitsi hyvällä nimeämisellä myös linkityksillä (esim. käyttötapauksiin) ja luokitteluilla (esim. mihin toiminnallisuuteen liittyy). Sotkun syntymistä voi vähentää myös niin, että sovitaan tarkkaan testauksen tavoitteet, ja vain niihin liittyviä bugeja raportoidaan. Jätetään se kaikesta jännästä nipottaminen vähän myöhempään, kun keskeisimmät asiat toimivat. (Tämä toki tarkoittaa, että testaukseen on oltava käytettävissä riittävästi kalenteriaikaa, eli testaus on aloitettava heti kun toteutus on siinä vaiheessa, että testaaminen on mielekästä.) Voidaan myös jakaa testaushavainnot esim. bugeihin, keskeneräisiin toiminnallisuuksiin ja lähdemateriaalien ongelmiin, ja sopia näille toisistaan poikkeavat käsittelytavat. Kunhan projektissa mietitään, mitä testaukselta aikuisten oikeasti halutaan, ja miten organisoimalla se saadaan mahdollisimman hyvin tukemaan ja mahdollisimman vähän tukkimaan kehitystä.

Jos kaikki oikeasti tietävät, ettei olla vielä stabilointivaiheessa, on hyvä jos testaaja voi työskennellä kehittäjien lähellä, jolloin tieto kulkee myös ilman bugitietokantaa. Kysymyksiä on silloin helppo pallotella suullisesti, ja arvioida yhdessä, miten paljon testauspanoksia kannattaa laittaa mihinkin toiminnallisuuteen juuri nyt. Tätä keskustelua on toki mahdollista käydä sähköisestikin, jos vain kaikki osapuolet ymmärtävät sen olevan yhteinen etu.

Lopulta tärkeää on myös se, ettei pelätä nostaa kissaa pöydälle. Jos toteutuksen ja testauksen lähdemateriaaleissa kuten määrityksessä on ongelmia, joiden takia ei ole mielekästä jatkaa, tieto tästä pitää saada mahdollisimman pian etenemään sinne, missä asioista päätetään. Ongelmien raportoiminen ei koskaan saa hilpeää vastaanottoa, mutta tämä asia ei yleensä odottamalla parane.Näiden maton alle lakaistujen asioiden esiin nostaminen on yksi testauksen tärkeimmistä tehtävistä, ja niiden edistämiseen onkin löydyttävä kanavat, joita käyttäen ongelmat myös ratkotaan. 

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?