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

Mikä on testauksesi tavoite?

Testata voi monella tavalla. Harvassa ovat järjestelmät, jotka ovat niin yksinkertaisia, että niiden täydellinen bugittomuus kannattaa varmistaa - ainakaan kaikissa projektin testausta sisältävissä vaiheissa. Riippuu jossain määrin myös testattavan järjestelmän kypsyydestä, mistä näkökulmasta ja millaisin tavoittein testausta kannattaa tehdä. Siksi testauksen tavoitteitakin on syytä arvioida testauskierrosten välillä uudelleen.

Tavoitteiden järkevään asettamiseen vaikuttaa mm. testaukseen käytettävissä oleva aikataulu, testaajien määrä ja osaaminen, sekä se, miten valmis testattava järjestelmä on. Tärkeä näkökulma on myös se, minkälaista tietoa testaamisella halutaan saada. Onko tavoitteena jonkin toiminnallisuuden määrityksenmukaisuuden verifioiminen, yleiskuvan muodostaminen koko järjestelmän tai jonkin tietyn moduulin kunnosta, vai jotain ihan muuta? Kaikkea ei välttämättä kannata tavoitella kerralla.

Yksi lähestymistapa on ad hoc testaus, jonka tarkoituksena on nopeasti ja sen kummemmin suunnittelematta löytää bugeja. Itse tykkään aloittaa uuden toiminnallisuuden testauksen näin, ikään kuin kokemattomana käyttäjänä selvittäen, miten rakennelma toimii. Samaa näkökulmaa tulee usein käytettyä silloin kun on tarve kevyelle regressiotestaukselle. Tämä on suhteellisen tehokas tapa löytää server errorit ja muut isot mokat, joiden vastaantuleminen on myös vähemmän turhauttavaa ad hoc-tyylillä kuin yritettäessä kurinalaisesti kahlata läpi testitapauksia. Kovin pitkälle tällä tyylillä ei kuitenkaan päästä.

Järjestelmän käyttäjien kannalta keskeisintä lienee prosessin mukainen testaus, mikä tarkoittaa käytännössä sitä, että käydään läpi toiminnallisuuden kuvaavat käyttötapaukset. Yhteen käyttötapaukseen voi liittyä useampia testitapauksia, mutta periaate on kuitenkin sen tarkistaminen, että käyttäjän toimiessa oikein myös järjestelmä toimii oikein.

Tätä on kuitenkin syytä laajentaa myös sen tarkistamiseen, että järjestelmä osaa toimia myös tilanteissa, joissa käyttäjä ei toimi oikein - esimerkiksi julkista verkkokauppaa käyttävän asiakkaan ei voida olettaa ymmärtävän selaimensa teknisiä ominaisuuksia tai selaavan manuaalia samalla kun asioi.

Hyvä testaaja yrittää välillä myös rikkoa testattavan järjestelmän. Siis esimerkiksi syöttää kenttiin vääränlaisia arvoja, luoda liian paljon uusia kohteita massaluontitoiminnoilla, kulkea edestakaisin kuin ei ihan tietäisi mihin haluaa mennä, palauttaa muokattuja arvoja oletusasetuksiin, ja tehdä kaikkea mahdollista kiellettyä, mihin käyttöliittymä antaa mahdollisuuden.

Yleensä näitä mahdollisia väärin toimimisen tapoja on niin monia, ettei kaikkia ole mahdollista käydä läpi. Hyvään testaussuunnitteluun kuuluukin miettiä, mitkä ovat niitä oleellisimpia kokeiltavia asioita. Jos vielä suunnitelmat tehdään riittävän väljästi mahdollistamaan se, että negatiivinen testaus tehdään jokaisella testikierroksella vähän eri tavalla (toki tekemiset huolella dokumentoiden, jos bugeja tulee vastaan), testauksen kattavuutta saadaan tavallaan kasvatettua kierros kierrokselta.

Käyttötapauksien ympärille rakennettavaan testaukseen saa lisäväriä saippuaoopperatekniikalla. Testaussuunnittelu voidaan tehdä vähän kuin käsikirjoitettaisiin näytelmää, joka on täynnä värikkäitä henkilöitä ja yllättäviä juonenkäänteitä.

Oma inhokkini testauksessa lienee testaaminen vaatimusluetteloa vastaan. Pahimmillaan eteen lyödään satoja rivejä pitkä excel, jonka sisällöstä ei aina oikein edes selviä, mihin asiaan mikäkin esitetty vaatimus liittyy. Osa riveistä kuvaa hyvin nopeasti tarkistettavia asioita (esim. "järjestelmä sisältää kalenterin"), osan läpikäynti vaatii paljonkin aikaa (esim. kieliversioiden toiminnan vastaavuus toisiinsa nähden, tai pitkän prosessin loppupään toiminnallisuus, johon liittyvä testiaineisto on ensin luotava käsin). Vaatimuksien järjestys ei yleensä ole mitenkään looginen suhteessa järjestelmän normaaliin käyttöön. Ja joukossa on ehkä myös yleisiä ei-toiminnallisia vaatimuksia, joiden testaamista ei oikein ole mahdollista upottaa järjestelmätestaukseen.

Silti vaatimusluetteloa ei voi vain unohtaa, sillä kaikkien vaatimuksien upottaminen käyttötapauksiin ei aina ole mielekästä. Niistä muodostettavat testitapaukset voidaan kuitenkin usein linkittää käyttötapauksiin luoden niiden testaamiselle mielekkäämmän asiakokonaisuuden.

Tärkeää on myös toteutettavan järjestelmän ulkoasun testaaminen visuaalista ilmettä ja rautalankamalleja vasten. Selainkäyttöisissä ohjelmistoissa tähän liittyy myös selainriippumattomuuden testaaminen, eli sen tarkistaminen, että kokonaisuus toimii kaikilla sovituilla selaimilla. Yhä useammin järjestelmiä käytetään myös mobiililaitteilla. Riippuen sovitusta tukitasosta testaaminen eri selaimilla ja laitteilla voi viedä paljonkin aikaa.

Usein järjestelmätestaaminen alkaa käytännössä kun testattavat toiminnallisuudet ovat vielä kovin raakileita. Tämä asettaa myös omat haasteensa testaamiselle, vaikka sinällään testauksen aloittaminen mahdollisimman varhaisessa vaiheessa on hyvä asia.

Toteutusvaihetta tukeva erillisen testaajan tekemä testaus voi vähentää turhaa työtä kun virheitä löydetään ennen kuin niiden päälle rakennettavia kokonaisuuksia ehditään viimeistellä. Joskus se myös voi vähentää kehittäjän työtaakkaa, kun testimateriaalin luomiseen ja rakentuvan kokonaisuuden testaamiseen saa reaaliaikaista apua.

Toisaalta kommunikaatiokatkokset voivat johtaa turhaan työhön, jos testaaja päätyy raportoimaan bugeina asioita joita ei ole vielä toteutettu, tai asioita jotka aiheutuvat niistä jännyyksistä, joita kehittäjän yhtäaikainen tekeminen järjestelmässä aiheuttaa.

Ihanteellisimmillaan yhtäaikainen toteutus ja testaus tapahtuukin niin, että testaajat ja kehittäjät työskentelevät vierekkäin, jolloin kysyminen on helppoa ja myös hiljainen tieto välittyy kaikille. Jos tämä ei ole mahdollista, voidaan projektiviestintään käyttää myös sähköisiä välineitä. Tämä kuitenkin vaatii kaikilta osapuolilta tietynlaista aktiivisuutta - ei esimerkiksi voida olettaa, että testaaja pystyy aina arvaamaan, milloin hänelle annettu tieto tavoitetilasta tai testattavuudesta on riittämätöntä.