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.

Mustalaatikkotestaus ja testauksen kattavuus

Testaukseen on monenlaisia tekniikoita. Yksi tapa jaotella testaustekniikoita on jako ns. mustalaatikkotekniikoihin ja lasilaatikkotekniikoihin sen mukaan, onko testaajalla pääsy testattavaan koodiin vai ei.

Silloin tällöin vastaan tulee käsityksiä, joiden mukaan mustalaatikkotekniikat olisivat huonompia, ja esimerkiksi listattessa mittareita testauksen kattavuudelle usein luetellaan asioita, jotka liittyvät nimenomaan lasilaatikkotestaukseen.

Itse näen vastakkainasettelun mielettömänä. Molempia tarvitaan.

Niin hienoa kuin testaajana olisikin helpottaa kehittäjien työmäärää, loistavakaan mustalaatikkotestaaja ei poista tarvetta kehittäjän tekemälle testaukselle. Samalla loistavakaan kehittäjä ei poista tarvetta käyttäjänäkökulmasta tehdylle järjestelmätestaukselle. On vaarallista olettaa, että toinen korvaa toisen. Jos on järjestelmä, jota elolliset olennot tavalla tai toisella käyttävät, on sitä koekäytettävä mahdollisimman realistisissa olosuhteissa, jotta voidaan varmistua, että se toimii myös tuotantokäytössä, eikä tämän koekäyttämisen kannalta ole oleellista nähdä koodia. Samalla kuitenkin koodi voi sisältää virheitä, jotka jäävät helposti kiinni vaikkapa koodikatselmoinnissa, mutta mustalaatikkotestaaja tarvitsee satumaisen tuurin osatakseen valita testaukseen juuri ne arvot, joilla virhe ilmenee.

Mitä muita tapoja siis on arvioida testauksen kattavuutta kuin koodikattavuus? Mustalaatikkotestauksen kattavuutta voidaan lähestyä esim. seuraavanlaisista näkökulmista:

• Vaatimuskattavuus. Onko kaikki sovitut ominaisuudet toteutettu, ja toimivatko ne siinä käyttötarkoituksessa johon niitä tarvitaan? Hyvän kehittäjän mind set on yksinkertaistava, ja joskus tulee yksinkertaistettua liikaa, jolloin toteutettu kokonaisuus ei enää vastaakaan siihen tarpeeseen, johon se tilattiin. Joskus joku kokonaisuus voi myös yksinkertaisesti unohtua. Vaikka testaisit koodin kuinka perusteellisesti, tämäntyyppiset virheet voivat jäädä huomaamatta.
• Prosessikattavuus. Menevätkö kaikki prosessit läpi alusta loppuun todellisilla käyttäjärooleilla? Pääsevätkö käyttäjät käsiksi tarvitsemiinsa tietoihin ja toimintoihin, tai näkevätkö he sellaisia tietoja tai toimintoja joihin heillä ei pitäisi olla oikeuksia?
• Tilasiirtymäkattavuus. Etenevätkö prosessit tilasta toiseen ja työlistalta toiselle kuten pitääkin? Toimivatko tilasiirtymät myös muihin suuntiin kuin suoraviivaisesti eteenpäin, esim. asian palauttaminen käsittelyn edelliseen vaiheeseen? Onko prosessin etenemiseen vaikuttavia raja-arvoja, kuten kurssipaikkojen täyttyminen ja siirtyminen varasijojen täyttämiseen, tai tietyn summan tai painorajan jälkeen muuttuvat postituskulut?
• Toiminnallisuuskattavuus. Toimivatko kaikki käyttöliittymästä löytyvät toiminnallisuudet niin kuin pitääkin? Esimerkiksi erilaisten listanäkymien sivutukset, suodatukset ja järjestämiset sekä hakutoiminnot ovat esimerkkejä toiminnallisuuksista, joista löytyy paljon testattavaa, mutta joista ei välttämättä määritysvaiheessa sovita yhtään mitään.
• Selain- tai laitekattavuus. Web-sovellusta tehtäessä kehittäjä ehkä testaa kaiken vain Chromella. Testaajalle jää selvittää, että myös muut vaaditut selaimet ja myös mobiililaitteet toimivat. 

Testausta ei myöskään tarvitse ajatella vain teknisenä asiana. Järjestelmiä käyttävät ihmiset, joista monet ovat kaikkea muuta kuin teknisiä. Siksi testaukseen voi - ja on syytäkin - hakea ideoita myös muualta.

Muita ajatuksia testauksen kattavuuden arvioimiseen voi löytää esim. seuraavista linkeistä:

• Testing without a map
• FEW HICCUPPS
• Heuristic Test Strategy Model
• Heuristics Cheet Sheet
• You Are Not Done Yet