maanantai 11. toukokuuta 2015

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ä:

Ei kommentteja :

Lähetä kommentti