Näytä minulle hyvä testitapaus
Testitapaukset ovat yleensä paskoja. Ne on suunniteltu huonosti ja ne on kirjoitettu auki vielä huonommin!
Jos et usko väitettäni, niin kokeile itse:
Laadi 100 testitapausta ja tee kolmelle eri testaajalle samanlainen toimeksianto niiden ajamisesta.
Kaikki kolme testauskierrosta tuottavat erittäin suurella todennäköisyydellä erilaiset tulokset. Niiden ajaminen vie jokaiselta testaajalta eri ajan ja testien läpäisyprosenttikin eroaa kaikissa. Veikkaisin vielä että raportoitujen virheiden määrä jokaisella testaajalla on eri.
Kun asiaa pysähtyy hetkeksi ajattelemaan syykin on selvä. Testien laatija on liian usein eri henkilö kuin testien ajaja. Vaara piilee siinä että testien kirjoittajista oikeasti vain pieni osa on hyviä ohjelmoimaan ihmisten käyttäytymistä. Testitapausten kuvaukset harvoin onnistuvat luomaan jokaiselle lukijalle saman kuvan testin tavoitteista, taustoista ja suoritustavoista.
Tarkkojen testitapausten suunnittelu onkin tästä nimenomaisesta syystä erittäin riskialtista puuha. Testitapausten tarkkaa speksaamista perustellaan usein hyvän ja vertailukelpoisen historiatiedon keräämisellä erityisesti regressiotyyppisestä testauksesta. Kuitenkin testejä ajavat henkilöt vaihtuvat usein ja siten muuttuvat myös testitulokset. Perinteisessä speksipohjaisessa testausprosessissa palaakin hurjat määrät työaikaa testitulosten tarkistamiseen ja normalisointiin.
Se voi olla järkevää ajan käyttöä ainoastaan silloin kun projektin laskutusperiaate on tuntipohjainen ja työn maksajalla on pohjaton kassa.
Siksi suosittelenkin pohtimaan erikseen jokaisen projektin kohdalla edellä mainittua ongelmaa. Ratkaisu voi löytyä esimerkiksi näin:
- Jokainen testaaja ajaa vain itse suunnittelemiaan testitapauksia. Itse laaditut proseduurit yleensä onnistutaan ymmärtämään oikein. Näin säästetaan aikaa testitulosten tarkastamisesta ja normalisoinnista.
- Luovutaan testitapausten liian tarkasta laatimisesta. Siirrytään testitapausten kuvauksissa käyttämään vaikkapa tarkistuslistoja tai tutustutaan säikeistettyyn prosessimalliin. Näin säästyy aikaa paitsi testitulosten tarkastuksesta ja normalisoinnista, myös testispeksausesta, katselmoinneista.
Hassua. Yhtäkkiä en osaakaan kertoa mikä on hyvä testitapaus. Osaatko sinä?
Suosittelemme myös:
Mahdoton tehtävä on usein uskon puutetta
Mielenhäiriöstä siinä kai oli kysymys. Tein nimittäin eilen illalla ihan pimeän lupauksen. Lupasin kirjoittaa tänään alkavassa European...
Oivalluksellakin on hintansa
Jos kysymys ei ole uskomattomasta munkista, mäihästä tai tuurista, niin onnistumisilla on aina hintansa. Hinta on mahdollista maksaa etukäteen ja...
Maaret Pyhäjärvi tiivisti saman 140 merkkiin Twitterissä:
A colleague said its easy to show examples of what a good test case looks like. I live in parallel universe, hasn’t been easy for years… @maaretp
Kuulostaa tutulta. Testaussuunnittelija X tekee testitapauksen A ja siihen tarkat stepit voimassa olevan vaatimuksen 106 mukaan. Kehitys kehittyy ja vaatimukset elävät. Testaaja Y ajaa testitapauksen A tarkasti steppien mukaan, kuten on ohjeistettu, löytää virheen ja raportoi sen, huomatakseen, että virhe hylätään, koska vaatimus 106 on muuttunut vaatimukseksi 106b, jossa steppien mukainen toiminnallisuus on sallittua. Ainakin kolmen henkilön aikaa meni hukkaan. Tässä tapauksessa vikaa on muuallakin kuin liian tarkoissa testitapauksissa.
Tämä on mielenkiintoinen aihe jota tulee tarkastella useasta perspektiivistä. Tilannetta testitapausten ympärillä voi verrata hyvin tilanteeseen hologrammista josta jokainen katsoja saa erin kuvan ulos riippuen perspektiivistä.
Tällä filosofisella avauksella tarkoitan seuraavaa: joissain tapauksissa sellaista testikeissiä joka usein paljastaa eri virheitä, pidetään loistavana. Ketterien menetelmien maailmassa jossa testitapaus on kirjoitettu väljäsi ja suunniteltu siten, että jokainen voi ajaa sen melkeimpä miten parhaaksi katsoo, niin toivottu lopputulema usein on, että keissi paljastaisi yllättäviäkin virheitä joita kukaan ei osannut edes kuvitella.
Toki tässä on nyt tarkastelun alla enempi tuollaiset tarkoituksella tarkasti kirjoitetut keissit ja niihin liittyvät haasteet. Kyllä, on haastavaa kirjoittaa ja ylläpitää tarkkoja keissejä ja eri testaajat saavat niistä kaiken lisäksi eri tuloksia irti. Näin se on. Testaus on aivan oma tieteenhaara joka on äärimmäisen moninainen ja mahdollisuuksia täynnä. Riippuu useista tekijöistä se, että millä filosofialla testaus kannattaa rakentaa. Itse suosin ketteriä ja väljiä keissejä joilla eri testaajat todennäköisesti löytävät eri virheitä. Välillä teen kuitenkin sellaisiakin projekteja joissa ketterät menetelmät ovat mahdottomuus ja silloin keskitytään tarkkoihin keisseihin ja niiden ylläpitoon.
Ja sitten vielä vastaus kysymykseen: ”mikä on hyvä testitapaus”. Minun näkemys hyvästä testitapauksesta on se, että sen suunnittelussa on otettu huomioon ympäristö jossa sitä tullaan ajamaan.
Kiitos kommenteistanne herrat!
Nykyisin testitapauksen rooli tosiaan tuntuu muuttuneen enemmän ohjenuoraksi. Minusta se on hyvä asia ja tulee tiedostaa myös suunnittelussa. Kuitenkin käytännön projekteja tarkastellessa testisuunnittelussa käytetään edelleen aivan liikaa aikaa testitapauksen hienosäätöön sen sijaan että keskityttäisiin tavoitteisiin ja kokonaiskuvaan.
Eli pointti on se että testaussunnittelulla ei kannata tavoitella hienoa tulosmetriikkaa (kypsyys, pass rate, jne) managereille. Nykyisin kannattaa huolehtia siitä että mahdollisimman suuri siivu virheistä löytyy ja loppukäyttäjän kokemukset saadaan paremmiksi. Se ei onnistu käyttämällä aikaa testisuunnitteluun tai testitapausten ja vaatimusten liian tarkkaan kyttäämiseen. Se onnistuu kun panostetaan enemmän tutkivaan ja kokeilevaan testaukseen.
Loppuun täytyy vielä vinkata vanhempaan juttuumme testispeksauksesta: http://ohjelmistotestaus.fi/2010/06/vaatimukset-tayttyvat-entas-sitten/