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