Testausheuristiikat 2/7

CIDTESTD

Tämä heuristiikka viittaa projektiin ja ympäristön tuomiin testausajatuksiin. C = Customer, I = Information, D = Developers, T = Test team, E = Equipment, S = Schedule, T = Test item, D = Deliverables. Näillä heuristiikoilla on tarkoitus suunnitella ja priorisoida tulevaa testausta. Näillä heuristiikoilla helpotetaan kontekstin havaitsemista, ja tuotteen ja testaajien sijoittumista ympäristöönsä.

Asiakkaan tapauksessa testi-ideointi tapahtuu lähinnä sellaisella tasolla, että "mitä tietoa asiakas voi meille tarjota ko. asiasta, jota emme jo tiedä tai ole huomanneet kysyä". Tämä ei siis tarkoita, että asiakas on testausidea itsessään, mutta asiakkaan huomioiminen testausta ideoitaessa voidaan löytää asioita, joita projekti tai projektiryhmä itsessään ei pystyisi tarjoamaan. Asiakasta kannattaa ja pitääkin kyseenalaistaa, koska usein on niin, että asiakas ei itsekään aivan tarkkaan tiedä mitä haluaa. Kyseenalaistamalla voidaan parantaa asiakkaan tietämystä omista haluistaan ja vaatimuksistaan. Testaajalla on suuri rooli parantaa kaikkien sidosryhmien tietämystä ja ymmärrystä tuotteesta.

Informaation toimii heuristiikkaana käytännössä asettamalla fokuksen dokumentteihin. Tässä kohtaa painota, että dokumentteihin luottaminen ei saa olla testauksen pääasia. Dokumentit ovat vanhentuneita, viallisia, saavuttamattomissa, jne. Ne saattavat kuitenkin sisältää sellaista tietoa, mitä testauksessa tarvitaan. Ne ovat yksi heuristiikka eli ne "voivat olla päteviä ko. kontekstissa". Dokumentit ovat kuitenkin hyödyllisiä ja niiden olemassaoloon on usein syy. Ne tapaavat tuoda lisää tietoa asioihin, mutta niihin ei kannata sokeasti luottaa. Dokumentteihin pätee samat kyseenalaistamisen säännöt kuin ihmisiinkin!

Kehittäkät ja testaustiimi tuovat oman panoksensa testien ideoinnissa. Testausryhmän sisäinen dynamiikka yleensa johtaa tiettyihin painotuksiin ja jokaisen panos on tärkeä testi-ideoita mietittäessä. Jokainen nimittäin testaa eri lailla ja jokaiselle eri asiat ovat tärkeämpiä kuin toiselle. Kehittäjien mielipiteet, taidot, mieltymykset antavat myös omat ideansa testaukseen. Jonkin kehittäjän tuotteista saattaa löytyä tietynlaisia vikoja, joten kehittäjän passiivinen mukanaolo saattaa tuoda ideoita testaukseen. Tämän takia kannattaa aina käyttää ideoinnissa mukana eritasoisia ja jopa eri ryhmien asiantuntijoita. Taas kerran: käytetään hyväksi kyseenalaistamista ja kysymistä, jotta saadaan esille ne asiat, jotka pitää saada esille.

Työkalut, välineet, ympristöt vaikuttavat omalta osaltaan testaukseen. Voidaan miettiä asioita työkalujen kannalta ottamalla huomioon käytössä olevat työkalut ja niiden hyväksikäyttäminen testauksessa sekä tarpeet työkaluille, joita mahdollisesti tarvitaan. Esimerkiksi testausryhmässä on kokemusta suorituskykytestaustyökaluista, mutta integraatiotyökalut ovat vähemmän käytettyjä. Voisiko heuristiikkana olla tehdä tutkivaa testausta integraatiotyökalulla? Olisiko yrityksessä joku integraatioasiantuntija? Aikataulu saattaa myös herättää testausaiheisia kysymyksiä priorisoinnista ja testausryhmän kokoonpanosta. Aikataulu tuo yleensä oman leimansa testauksen suorittamiseen. Esimerkiksi aikataulun yhdistäminen vaikkapa asiakkaan vaatimiin suorituskykytesteihin määrittää tiettyjen alueiden testaamisen ennen toisia. Tai jos toteutus on pilkottu releaseihin, joissa testaus pitää kohdistaa tiettyihin osa-alueisiin, koska toisia ei ehkä vielä ole toteutettu.

Testauksen kohde on aina hyvä herättämään kysymyksiä: "Mikä tämä on? Mitä se tekee?" Se herättää todennäköisesti jatkokysymyksiä ja nostaa muita heuristiikkoja esiin. Jamesbachmainen heuristiikka "Huh? Really? So?" (HRS) pätee hyvin usein, kun kysytään ihmisiltä juuri noita kysymyksiä. Kyseenalaistamalla saamasi vastauksen testauksen kohteesta voi nousta uusi kysymyksiä ja ehkä juuri ne kysymykset ovat niitä, mitkä pitää kysyä.

Testaustuotteet voivat myös nostaa ideoita, esimerkiksi bugilistoista voi löytyä ideoita. Kaikki testauksen tuottama materiaali, opitut asiat, raportit, jne. voivat nostaa asioita esiin, joita täytyy miettiä tässä kyseisessä testausprojektissa. Testaustuotteena on tietenkin myös taitopääoma, joten käytännössä kaikki testausmateriaali ja taito, mitä yrityksessä on saatavilla kannatta jollakin tasolla hyödyntää.

Heuristiikan käyttäminen toimii myös muussa kuin dynaamisessa testauksessa. Kyseenalaistaminen ja katselmointi hyödyntävät myös näitä heuristiikkoja. Jokainen kehittäjä pystyy parantamaan omaa työtään kyseenalaistamalla määrittelyitä tai suunnitelmia hyväksykäyttäen testaukseen käytettäviä heuristiikkoja. Eikä pelkästään projektin alkuvaiheessa vaan pitkin toteutusta ja lopulta koodin valmistuttua koodikatselmoinneissa ja korjaus/muutospyynnöissä.