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

Täh?! Oikeesti?! Mitä sitten?!

Michael Bolton mainitsi kollegansa James Bachin käyttävän äärimmäisen tehokasta kyseenalaistamisen heuristiikkaa: Huh? Really? So? (aiemmin viittamani HRS-heuristiikka) Päätin ottaa itsekin tuon heuristiikan käyttöön ja olen nyt kokeillut sitä erinäisissä tilanteissa, jopa testannut omia puheitani ja kirjoituksiani tuon heuristiikan kautta.

Huh? Täh? Siis mitä?

Oletko koskaan istunut neukkarissa, kun joku "sankari" esittää kuninkaan elkein hienoja prosessimalleja tai pitää yhteenvetoa asiasta, josta et ole kuullutkaan? Sinut on kutsuttu paikalle, koska se ehkä liippaa sinun asiantuntemusaluetta jollakin tasolla (normaali kriteeri palaverikutsulle). Mies tai nainen edessä selittää, osoittelee graafeja ja vuokaavioita, ja jokatoinen neukkarissa oleva henkilö piirtelee tikku-ukkoja paperin reunaan tai näpyttelee puhelintaan. Osa saattaa jopa tuijottaa taululle, koska luulee ymmärtävänsä jotakin, mutta silmissä on tyhjä katse.

Tässä vaiheessa taitava testaaja kysyy: "Täh?" Kaikki tuijottavat testaajaa kuin tämä olisi sanonut jotakin tyhmää - varsinkin "sankari". "Niin mitä tämä tarkoitti? Voitko selittää tämän niin, että testaajakin ymmärtää? En ehkä ole käynyt kaikkia kouluja enkä ole tehnyt kehitystä vuosia, mutta tiedän kuitenkin että en ymmärrä kaikkea, mitä sanot. Onko minun tarpeellista siis edes ymmärtää tätä (ja päätellen paikallaolostani ON)? Mielestäni on. Voitko siis kertoa, mitä tuo tarkoittaa?" Tässä vaiheessa kynät lopettavat tuhertelun ja kännykät menevät taskuun.

Muut ajattelevat ehkä: "Olipas fiksu testaaja. Vitsi, kun olis itse ymmärtänyt kysyä asiaa hetki sitten, niin en olisi niin pihalla." Kukaan tuskin ajattelee, että "onpa tyhmä kaveri kun ei ymmärrä, mistä puhutaan". Todennäköisesti tässä vaiheessa "sankari" selittää hieman matalammalla tai korkeammalla tasolla (riippuen kumpi on selkeämpi tai hänen mielestään selkeämpi). Tämän jälkeen suurin osa kallistuu tuolissaan taaksepäin ja alkaa taas tuhertelemaan. "Anteeksi, en kyllä vielä ymmärtänyt. Meneekö se oikeesti niin?"

Really? Oikeesti? Ootko ihan varma?

"Sankari" tuijottaa ja toteaa, että näinhän se menee. Esimerkkiä pyydettäessä taas kaikkien mielenkiinto palautuu. Nyt "sankari" esittää prosessimallia hieman käytännön tasolta tai raporttia henkilönäkökulmasta. Tässä vaiheessa testaajalla nousee useita kysymyksiä käytännön asioita. "Entäs tapaus 1? Entäs tapaus 1a?"

Tässä vaiheessa muut ajattelevat, että "olisiko minun pitänyt tietää kysyä näitä asioita? Olenko niin fiksu, kun luulen olevani?" Sankari kysyy tätä varmasti itseltään. Kun sankari on joko "oikeesti" pystynyt selittämään asian tai todennut, että ei ole miettinyt asiaa tuolta kantilta vaikka olisi ehkä pitänyt. Taas porukka rentoutuu... "Mitä tällä siis haetaan? Miksi näitä asoita esitellään?"

So? Mihin se johtaa? Mitä sitten?

... ja taas porukan mielenkiinto nousee taas. "Tämä saattaa koskea minua. Tämä seuraava lause voi vaikuttaa minun tulevaisuuteeni tai työntekooni."

Testaajan tehtävä on nostaa esille asoita, mitä muut eivät ole vielä osanneet miettiä. Testaajan tehtävä on tarjota tietoa asiayhteydestä siitä kiinnostuneille sidosryhmille. Testaaja itse on osa yhtä sidosryhmää, joten hänen tehtävänsä on vaatia se tieto, mikä hänelle kuuluu. Ei ole olemassa tyhmiä kysymyksiä - on olemassa kysymyksiä, joita pidetään tyhminä kunnes ne kysytään. Usein on tyhmää olla kysymättä. Näiden "tyhmien" kysymysten tarkoitus on herättää uusia kysymyksiä - kysymyksiä, joita kukaan ei ole vielä kysynyt. Käyttäkää tätä heuristiikkaa tulevissa palavereissa ja olkaa kriittisiä. Kyseenalaistakaa oma toimintanne siinä missä muidenkin.

Todennäköisesti palaverin jälkeen muu porukka kyselee asioita testaajalta eikä "sankarilta".