Yhdentekevä testitapausten määrä
Minä väitän, että minkä tahansa softan voi testata yhdellä testitapauksella! Testitapauksen ei tarvitse edes olla monimutkainen. Kysymys on vain siitä, että testaaja ymmärtää lukemansa ja tekee työnsä. Paljastan salaisuuden. Esittelen tämän juuri hetki sitten verkkopalvelulle Twitter.com suunnittelemani testitapauksen.
Step1: Test Twitter.com
Expected result 1: Twitter.com works
Ei siis sen suurempaa mystiikkaa. Yhdellä testitapauksella saadaan järjestelmä testattua ja sillä voidaan tietysti mitata myös järjestelmän toimivuutta luotettavasti. Eikö niin?
Testaukseen edes vähän perehtynyt projektipäällikkö pitää tietysti logiikkaani huterana. Eihän mitään järjestelmää voi arvioida yhden testitapauksen perusteella. Eihän sellaisesta saada edes mitään mittatietoa.
No niinhän se tietysti on. Nyt kuuluukin vain kysymys, että montako testitapausta sitten tarvitaan, että kunnon mittatietoa saadaan? Kuinka tarkaksi testiseulan resoluutio pitää vääntää, että mittatieto on luotettava? Minä en ainakaan osaa vastata. Eikä takuulla osaa projektipäällikkökään.
Juttua voit kokeilla itsekin. Kirjoita vapaavalintaisesta kohteesta yksi edelläkuvatun kaltainen testitapaus. Sitten ala vääntämään testiseulasi resoluutiosäätimestä. Jaa siis aina jokainen testitapaus kahdeksi uudeksi ja katso kuinka pitkälle pääset ennen kuin alkaa turhauttamaan.
Testitapausten määrä on joutava mittari. Heitä se mäkeen kun vielä voit!
Suosittelemme myös:
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...
Mielenterveys on työtäni
Hämmästynyt katse seuraa lähes poikkeuksetta kun vastaan siihen yhteen kysymykseen. Mitäs sinä teet Antti? Tai mitäs tuo teidän yritys...
Testitapausten määrän mittaamisen turhuudesta olemme varmaan samansuuntaista mieltä, mutta esittelisitkös vaihtoehdon projektipäälliköille siihen miten arvioisivat josko työ on sinne päinkään tehtynä siten ettei mennä pelkästään sillä että työmäärä on käytetty?
Et liene kuitenkaan ole tällä mittaamattomuudella ja seulakokeilulla argumentoimassa että suunnittelemattomuus ja pilkkomattomuus on hyvä idea? Kuitenkin muistaen että ihmisen muisti on viehättävän rajallinen (2001 enää 4+-1 asiaa), muistia pitää ruokkia erilaisin tukilistoin ja jäsennyksin jotka muistuttelevat mieleen ideoita. Ja kun vielä toimitaan paineen alla sen projektipäällikön koputellessa testauslabran ovelle julkaisuajankohdan painaessa, tulee aika helposti kuittailtua asioita tehdyksi vaikkei olisikaan.
Olen viime aikoina mittaroinut kuinka monta tuotannonkaltaista aineistoa on käyty läpi prosessin. Siinä ei ehkä käytä ihan samaa seulaa kuin mikä sinulla on twitter-kommentissasi (toiminto vs. aineistointensiivinen järjestelmä, ihan erilainen pilkkomislogiikka) mutta vastaavasti voi kysyä että onko 10 – 100 – 1000 ollenkaan siellä päinkään.
Moro Maaret ja pisteet ripeästä kommentoinnista!
Tietysti ensimmäisenä minulla herää kysymys siitä, että onko työmäärän käyttäminen väärä tai huono tapa mitata? Tutkivaa testaustyötähän voidaan esimerkiksi laatikoida kätevästi aikaikkunoihin eikä menestyskään ole huonoa näillä tavoilla.
Olet oikeassa siinä, että suunnittelemattomuus ja pilkkomattomuus ei varmasti kanna kauhean pitkälle. Kysymys lieneekin siitä mitkä asiat ovat mittaamisen kannalta olennaisia. Lisäksi ilahduin suuresti, että otit puheeksi tukilistat ja jäsennykset. Yhden tavan kirjailimmekin ylös alkuvuodesta aivan tänne blogin sivuillekin: http://ohjelmistotestaus.fi/2011/03/tarkistuslistapohjainen-tutkiva-testaus/
Ja koska testauksen maailmassa asiat harvoin ovat kovin mustavalkoisia, on tosiaan erinomaista pureskella samaa ongelmaa myös sisältöintensiivisen järjestelmän näkökulmasta. Hyvä!
Käsittääkseni en sanonut että työmäärän käyttäminen olisi hyvä tai oikeakaan. Koitin muotoilla että se on varsin yleinen tapa projektipäälliköille seurata että valmistuuko testaus aikataulussa, seurataan että onko vielä tunteja käytössä ja jos ei, ollaan valmiita. Aikaikkunointi on ihan toisenlainen malli seurata työmäärän kulumista ja ehkä myös hieman sitä mitä saavutetaan.
Kuitenkin tämä testitapausten määrä on pitkälti yksinkertaistus aikaikkunoista. Vielä kun saisi opetettua paremmin että tehty on tehty vain kunnes parasta ennen päivämäärä osuu kohdalle, eli joku menee ja koskee softaan korjatakseen tai muuttaakseen sitä, joko omiin tai muiden osiin, niin pääsisi viestimään oikeista asioista.
Olisin kuitenkin itse varovainen seuraamasta maailman trendiä jossa korostetaan testitapausten mittaamisen huonoa ideaa. Pahempaakin on, kuten se ettei ollenkaan edes yritetä. Tai että kuvitellaan että kaikki pitäisi tehdä tai että suunnitelman pitäisi olla tarkka tietääkseen missä mennään.
Tuo ajatus ajan käyttämisestä mittarina on vähän nurinkurinen. Aika ei kerro kattavuutta, vain käytetyn ajan. Toisaalta kattavuutta voidaan numeroistaa myös subjektiivisen arvion perusteella.
Meillä on käytössä ns. kolmiportainen kattavuus.
-Ykköskattavuus on savu- ja saniteettitestit, joilla todetaan että ”hei! Meillä on testattavaa ja se pirulainen näyttää toimivan edes jotenkin”. Tämä on se kattavuus mitä James Bachin testauskilpailussa ”Miyagi-Do” kuvasi ”testauksen arvoinen” -sanoilla.
– Toinen kattavuus on kaikki ko. järjestelmäalueen antavat toiminnallisuudet ja niiden positiivisten tapausten testaus. Eli se perustestaus.
– Kolmas kattavuus on kaikki ne järkevästi kontekstiin sopivat ja lisäarvoa tuottavat testit käyttäen järkevästi käsillä olevia tekniikoita ja metodeita, jotta voidaan asettaa järjestelmä sellaiselle koetukselle että voidaan olla hyvinkin varmoja siitä, että järjestelmän lisätutkiminen ja testaus ei tuo meille oleellista lisätietoa.
Aikaa käytetään mittarina arvioimaan se työmäärä, millä ko. kattavuus on saavutettu. Kuitenkin bugit, ongelmat, kaikki asiat estävät käytetyn ajan tuoman kattavuuden kasvamisen, joten meidän täytyy osata priorisoida se, että mihin kattavuustasoon käytämme sen ajan, mitä meillä arvion mukaan on jäljellä. Kuinka voimme kommunikoida projektin johdolle, että olemme aikataulusta jäljessä, jos mittaamme vain testaukseen käytettävää aikaa? Sama kuin sanoisi, että ”vanhenen liian hitaasti”.
Olen saman ”jännän äärellä” omassa blogissani: http://mitenmatestaan.blogspot.com/2011/05/tunteet-pinnassa.html Sieltä inspiraatiota kommentteihin.
Kommentoin tätä ehkä hieman tylsästi nyt, mutta riippuu siitä että mitä ollaan tekemässä, että mikä malli parhaiten istuu tai edes hyvin. Tietty määrä keissejä jotka ajetaan aina uudestaan ja uudestaan, voi tosiaan parhaimmillaan osoittaa tuotteen maturiteetin riittävällä tarkkuudella jonka pohjalta voidaan tehdä jatkopäätöksiä liiketoiminnan suhteen. Tämä on kiistatta yleisin ammattitestauksen pig picture -malli tällä hetkellä.
Itse työskentelen projektissa jossa ei ole ensimmäistäkään testikeissiä, tai siis ne eivät näy minulle. Projektin tuotoksena valmistuva tuote toki testataan monessakin tuotekehityksen vaiheessa satoja ellei tuhansia keissejä käyttäen. Minun tehtävä projektissa on tutkia virheet jotka ovat kaikesta huolimatta päässeet läpi. Tutkin ja toistan epäiltyä virhettä niin kauan kunnes löydän reitin sen toistamiseen. Kun tiedän miten virhe saadaan toistettua, niin esittelen sen devaajille tyyliin: ”kuulkaas muistatteko sen yhden issukan joka sieltä Intiasta raportoitiin, niin kyllä siellä semmoinen hassi tosiaan on ja näin sen saa toistumaan”. Sitten kodarit sen korjaa ja kun olen varmistanut että paikka todellakin on pitävä, niin korjaus laitetaan eteenpäin.
Sitten kommentti Pekalle. Tuo sun kirjoitus oli jälleen niin tiukka, että viittä vaille henkeä salpasi. Kuten kommentoin blogiisi, niin minä testaan vain ja ainoastaan tunteella. Teen töitä tunteella, en enää edes osaa muunlaista tapaa. Suhtaudun testaukseen intohimolla ja minun olemuksesta voi lukea, että mikä testitulos on ennen kuin edes sen verbaalisesti kerron. Kerran tässä viime aikoina tein niin, että kun kodari viimein sai tehtyä kunnon toimivan fiksi bugiin joka oli piinannut meitä kauan, niin pistin musiikit päälle ja otin pari kolme tanssiaskelta ja sekös koodaria ilostutti entisestään P.s. menee muuten tuo Boltonin blogi seurantaan.
Pekka: Ei siinä testauskilpailussa (olin paikalla!) kyllä kuvattu tason 1 testausta sanoilla ”testauksen arvoinen”. Koko sovelluksen osalta loukattiin toteuttajaa antamalla neljän tunnin testauksen päätteeksi kokonaisarvio laadusta juurikin noilla sanoin. Se oli nk. ei-hyvä esimerkki, vaikka kuinka kovia kavereita testaamaan ovatkin.
Aikaa käytän kyllä edelleen arvioimaan että koska budjetti on käytetty. Emme ole olleet kai tarpeeksi tekemisissä että tietäisit miten minä tiimiäni tutkivan testauksen periaatteiden puitteissa hallinnoin. Testauksia on erilaisia, ja varsin monet niistä loppuvat kun aika loppuu – kuitenkin kuvaten sen mitä sillä investoinnilla tietona on voitu saavuttaa.
Intän vielä kerran: minä en ole missään vaiheessa väittänyt että mitattaisiin pelkkää aikaa. Sarkastisesti totesin että jos ei ymmärrä testauksen dynamiikkaa, siitä saattaa aloittaa ja testitapaukset (tämän blogikirjoituksen otsikko) mittaroinnin pohjana on HUOMATTAVA parannus. Ei kuitenkaan riittävä sillä samalla (tai pienemmällä) investoinnilla voi saada paljon parempaa.
Kun nyt kärjistellään puolin ja toisin, minusta on huvittavaa ratsastaa testaustrendien aallonharjalla. Yksi suuressa muodissa olevia asioita on tämä testitapausten mittarina käyttämisen mollaaminen enimmäkseen tarjoamatta käytännöllisiä vaihtoehtoja. Eli haastanpa teidät laittamaan tästä käytännöllisestä vaihtoehdosta seuraavan blogipostinne!
Hyvä! Taas kerran osutaan siihen fokusoimisen maalitauluun. Kun tullaan pattitilanteeseen, niin yleistämällä, kärjistämällä, jopa vääristämällä saadaan uusia näkökulmia esiin. Jopa sillä että joku on tahallaan väärässä (vaikka sitä pelätään, niin se on hienoa! 😉 ) voidaan saada esiin sellainen näkökulma, joka vie tilannetta eteenpäin. Mielestäni tiimissä voi (saa, ja joskus pitää) olla vastaäni, joka on rakentavasti asioiden toisella kannalla.
Ja meillä aikaa OIKEASTI käytetään pääasiallisena mittarina, mutta kiinnitettynä sellaisiin mitattaviin asioihin, joissa se aika oikeasti merkitsee jotakin. Ja Maaret, ”Challence duly accepted!” 😉 On jo drafti valmiina…
No nyt pyörähti jälleen kerran keskustelu hyvällä sykkeellä käyntiin,
Kukaan järkevä ihminen tietenkään perusta projektin mittaamista yhdelle ainoalle suureelle. Kuitenkin hirveän iso siivu tuotekehityksestä ylöspäin osoitetuista raporteista pyörii ja piehtaroi yksinomaan testitapausmääriin perustuvien prosenttien ja lukemien suossa. Joskus tarvitaan jyrkkää herättelyä, jotta päästään jumiutuneista tavoista. Testaustrendien aallonharjalla ratsastavat rupelihatut tietysti ymmärtävät etteivät asiat ole niin mustavalkoisia.
Taustalla tässä keskustelussa kummittelee yhä tuo pohjimmainen ongelma. Testitapausten lukumäärä on erittäin subjektiivista mitattavaa. Jokainen järki-ihminen osaa kertoa, että yksi testitapaus ei riitä. Kuitenkin kun kysytään kouralliselta testausihmisiä mikä määrä riittää ja pakotetaan arvioimaan, jakauma leviää täysin käsiin. Yleensä sopiva määrä on vedetty täysin hatusta. Siksi väitän yhä, että testitapausten määrä ja laskeminen on joutavaa puuhastelua.
Maaret peräänkuulutti kritisoinnin sijasta ratkaisuehdotuksia. Minusta testitapausten sopivan määrän ongelmaan tuli tuossa tekstissäkin kokeilemisen arvoinen lääke. Lähdetään liikkeelle siitä yhdestä ainoasta tapauksesta ja aletaan kääntämään resoluutiota isommalle, kunnes kaikille kelpaa!
Kelpaako teille?
Antti: jakauma on muuten huomattavasti suppeampi kun kysyy tarvittavaa aikaa perusteluineen kuin jos kysyy ”testitapauksia”. Testaamisen määrä on itsessäänkin subjektiivista mitattavaa ja kun liikaa koittaa asiaa suunnitella, maksaa suunnittelusta niin ettei rahat riitä enää tekemiseen.
Ja edelleen väitän että joutava puuhastelu on oikeasti auttanut monia eikä pelkkä resoluution parantaminen ratkaisuehdotuksena nyt vielä kovin pitkälle kanna. Minusta ongelma ei ole joutavassa puuhastelussa, vaan sen aiheuttamassa hitausmomentissa, jolla korvataan varhain suunniteltu huono testaus täyttämään kaikki aika oikeiden tulosten tekemisen sijaan.
Ja Pekka: osaan minäkin kärjistää, syyllistää ja ajaa asiaa. Mutta jos jotain on ollut vuosien varrella tarttuvinaan, siihen kuuluu se että kaikki ongelmat joita aiheuttaa on oltava valmiina korjaamaan. Joskus se onnistuu, joskus ei. Jos räksyttää, pitäisi itsellä olla edes se visio johon tähtää mielessä. Ehkä onkin?
Maaret: Olet aivan oikeassa tuossa, että ei ole minkäänarvoista vaan lytätä ajatuksia. Diili-ohjelmassa Donald Trump erottaa porukkaa, jos he eivät anna perusteluita mielipiteilleen tai lyttäävät ilman parannusehdotusta. Ja mitä ongelmanratkaisuun tulee, niin pitääkö yhdellä ihmisellä olla avaimet kaikkiin ongelmiin? Voiko ryhmä keksiä ratkaisun kollektiivisesti? En minä osaa ratkaista koodausongelmia, mutta kun sellaisen näen, niin sanon että ”tuossa on ongelma ja se vaikuttaa tähän ja tähän”. Joku muu ryhmässä voi ratkaista sen.
Ja kun omassa blogissani peräänkuulutin haastamista, niin mielestäni viimeisen viikon aikana olemme ainakin pariin blogiin saaneet sellaista haastelua aikaiseksi, että suunta on varmasti oikea!
Ja meillä on niin monimuotoinen testauskulttuuri (ja lisäksi kontekstiriippuvainen), että myös pelkkä testitapausten mittaaminen VOI olla ratkaisu johonkin ongelmaan. Ehkä tämä keskustelu ei tavoita kaikkia mielipideryhmiä, mutta ainakin joitakin on jo saatu.
Naulan kantaan Maaret!
Lisäisin vielä tuohon seuraavaa: Kuten totesitkin, niin tässä tekstissä tarkoitettu joutava puuhastelu aiheuttaa hitausmomenttia. Tärkeintä olisikin oppia tunnistamaan mikä sitä joutavaa on… ja milloin? Siinä olet oikeassa, että väärin ajoitettu ja tarpeettoman laaja testisuunnittelu on yksi näistä pullonkauloista.
Oikeassa elämässä testitapausten laatiminen ja mittaaminenkin ovat varmasti erittäin toimivia pelivälineitä. Niiden taakse tarvitaan vain riittävän osaavat kädet ja myös ripaus itsekritiikkiä 🙂
Testitapausten määrä ei ole mielestäni joutava mittari. Mutta mitä sillä mitataan on jo eriasia. Sillä voi mitata testaamista, mutta ei välttämättä työmäärää (koska työmäärä riippuu testi tapauksen lopputuloksesta: failaava testi case vie enemmän aikaa kuin passaava).
Itse olen tottunut mittaamaan testitapausten määrää ja niiden statusta esim viikottain ja keräämään siitä (pidempi aikaista) trendiä. Se kertoo esim kuinka testi setti elää ajan funktiona. Testi tapauksia on pidettävä yllä jatkuvasti; niitä voi yhdistää, poistaa turhia ja on lisättävä uusia. Jos settiä ei ylläpidetä, niin vikoja ei silloin löydy (paitsi regressio).
Joku viisaampi onkin sanonut: ”Everything can be measured in a way that is better than not to measure at all.”
..ja sorry mahdollisista typoista. iPad ei salli scrollata kommentin alkuun ja tarkistaa tekstiä. Ehkä kommentoinnissa on ollut vain yksi test case ja bugia ei ole siksi löydetty? 🙂
Terve Marko ja kiitos hyvästä näkökulmastasi,
Itse ajattelen testitapausten mittaamisen haastavana siksi, että jokainen testitapaus on niin hirveän subjektiivinen. Toinen suunnittelija saattaa laatia yhden hyvinkin laajan tapauksen, kun toinen pilkkoo testitapausten resoluution niin tiukaksi, että samasta asiasta saa 100 erilaista tapausta.
Michael Bolton sanoi joskus koulutuksessaan, jotakin tämän tyylistä: ”Test case is like a suitcase, U never know what is inside”. Minusta se on yksi testitapausten mittaamisen keskeisimmistä ongelmakohdista.
Mielestäni ulkopuolinen tarkastelija, eli raporttien ja mittaustulosten lukija ei saa tästä tiedosta mitään konkreettista hyötyä. Jos testitapausten määrää haluaa tästä dilemmasta huolimatta yrittää mitata, niin ehdottaisin, että raportissa ei tule yhtään numeerista mittaustulosta ilman siihen liittyvää tarinaa. Avaamalla lukuarvoa vapaasanaisesti, päästään ainakin osaksi irti yleensä niin kovin subjektiivisesta mittaustulosten tarkastelusta.
Olen samaa mieltä: testi raportissa pitä olla lukuja avaavaa tekstiä. Kun testaus sanoo, että kaikki (E2E) testit on ajettu ja kaikki on Passed, niin projekti päällikkö tai vastaava saattaa lukea sen niin, että SW on bugi vapaa ja alkaa pukkaamaan softaa ulos.. vaikka samaan aikaan on saatettu sivuuttaa katselmoinnit, alemman tason testaaminen ja staattinen analyysi.
Itse testi tapauksista. Minusta ne on hyvä olla, mutta niiden tarkoitus on auttaa testaajaa hiffaamaan, mistä oikeasti oikein on kyse testattavassa tuotteessa. Testi tapauksia tehdessä, testaaja oppii tuotteesta paljon ja saa varmuutta epävarmoihin ja avoimiin asioihin. Mutta entäpä myöhemmin esim parin-kolmen testi rundin jälkeen? Silloin hän on jo oppinut tuotteesta lisää ja on myös jo nähnyt missä bugeja on (koska ne löydetään aina alussa). Kannattaako testaajan enää orjallisesti testata testi tapausten mukaan? Mielestäni ei, vaan testaajan tulee kehittyä projektin aikana ns. Oracle-testaajaksi, joka tuntee tuotteen kuin omat taskunsa. Väitän, että silloin saavutetaan parempi kattavuus, koska testit ajetaan hiukan erilailla, eri järjestyksessä jne. Samalla kuin itse testaaminen nopeutuu, koska ei tarvitse kirjata ylös mikä toimii vaan silloin kirjataan ylös mikä EI toimi (= bugi raportointi). Se mitä hävitään on pass ja run ratet ja tulee epävarmuus siitä, testattiinko kaikki. Mutta anyway, olemenne taas jutun ytimessä: tartteeko pass ja run ratea mitata; miksei riittääkö testaajan sana kuvastamaan tuotteen laatu? Miksi se pitäisi laskea laskimella testi tapauksista desimaalien tarkkuudella?
Erinomaisia kysymyksiä Marko,
Uskon, että mainitsemasi Oracle-testaajaksi kehittyminen on yksi avain siihen, miten testaustyön lopulta optimoituu. Enemmän tuloksia sijoitettuun työaikaan nähden.
Mikäli pass ja run-rateja halutaan projektissa mitata, olen usein evästänyt asiakkaita valitsemaan mahdollisimman kevyen lähestymisen. Esimerkiksi käyttämään testitapauksia vain otsikkotason tukisanalistana, jolla voidaan organisoida Bug Hunting -tyyppistä testaustyötä.
Näin syntyy kevyellä toimintaformaatilla jonkin verran mittaustuloksia ja toisaalta uusien bugien löytyminen on todennäköisempää. Samalla myös ajatusvirheestä johtuvien testauksen katvealueiden jääminen on epätodennäköisempää.