Mene meetupiin!

Osallistuin viime torstaina testausaiheiseen meetupiin. Tapahtuman otsikkona oli Exploring Allure. Googlaamattakin oli selvää, että kyse tuskin olisi työkalusta, jonka ottaisin ensi viikolla käyttöön työssäni. Tämä olisi sitä toisenlaista testaamista, jota en koe osaavani.

Vielä samana päivänä mielessä risteili ristiriitaisia ajatuksia: Siitä ei varmaan ole suoraa hyötyä työni kannalta. Siellä on vieraita ihmisiä. En tiedä, mitä siellä tapahtuu. Se vie matkoineen ihan koko illan. En oikeastaan edes tiedä, mihin olen menossa. Entä jos en ymmärrä siitä yhtään mitään?

Menin kuitenkin, koska tässä oli tarjolla helppo tapa päästä juttelemaan muiden testaajien kanssa, ja ajattelemaan jotain vähän uudenlaista. Jos ei koskaan poistu mukavuusalueeltaan, on kovin vaikea oppia mitään uutta.

Löysin itseni tutkimasta testausraportointityökalun käyttöä mob-koodauksen keinoin. 

Ryhmä toimi tosi hyvin yhteen siihen nähden, että olimme aika vieraita toisillemme. Omaa epävarmuutta helpotti kovasti, ettei kukaan muukaan osannut asiaa täydellisesti. Ratkaisut löytyivät keskustellen, ja lopulta tuntui ettei ollut juuri väliä, kuka oli navigaattorin tai driverin roolissa. Tehtävänasettelu oli riittävän kapea, ettei päämääristä tarvinnut vääntää kättä, ja päämäärät riittävän yksinkertaisia, että niiden toteutuksessa pysyi varsin hyvin kärryillä, vaikka asia oli alkuun vierasta.

Kun tekee jotain uutta, oppii jotain uutta, jos vain antaa itselleen mahdollisuuden oppia. Joskus opit liittyvät yllättäviin asioihin, tai niistä saavuttaa hyötyjä yllättävissä yhteyksissä. Mitä enemmän ymmärtää itselleen vieraiden roolien tekemistä, sitä helpompaa on luoda siltoja niitä kohti, osallistua keskusteluihin, esittää kysymyksiä, tuoda ymmärrettävästi esiin omia näkökulmiaan, saada rakennettua jotain uudenlaista. Siksi hyötyjä saa myös sellaisten asioiden oppimisesta, joille ei heti keksi käytännön sovelluksia omassa tekemisessään. Ja pitkällä tähtäimellä omakin rooli voi muuttua tavoilla joita ei juuri nyt näe mahdolliseksi.

Oppiminen myös tapahtuu tavallaan portaittain, aina aikaisemman tiedon päälle, ja sitä kautta samojenkin asioiden läpikäynnistä voi eri kerroilla oppia eri asioita. Vieraat asiat muuttuvat vähin erin tutummiksi. Askel kerrallaan, vaikka ne askelet olisivat ajallisesti kaukanakin toisistaan.

Session jälkeen istahdimme osalla porukkaa vielä yksille juttelemaan. Ilmeni, että joukossa oli yksi kehittäjä joka ei edes asunut Suomessa, sekä yksi matkaopas. Että ehkä testaajana on turha tuntea itseään ulkopuoliseksi testaajien meetupissa, vaikka käsiteltävä aihe ei osuisi ollenkaan omalle osaamisalueelle.

Dokumentointia ja raportointia - ajatuksia tutkivan testauksen työkurssilta vol 3

Minulla oli ilo päästä osallistumaan Maaret Pyhäjärven järjestämälle Tutkivan testauksen työkurssille. Kerään päivästä käteen jääneitä ajatuksia muutamaankin blogipostaukseen, joista tämä on kolmas. Tarkoitus ei ole referoida koulutusta vaan jäsentää omia ajatuksia aiheen tiimoilta, eli tekstit ovat pitkälti omaa tulkintaani ja sen ympärille kietoutuvia ajatuksiani ja kokemuksiani.


Dokumentaatiota voi tehdä monella tavalla ja monesta syystä. Byrokraattisten asiakasorganisaatioiden kanssa työskennellessä saattaa mieleen hiipiä ajatus, että dokumentaatiota tehdään koska asiakas haluaa sellaista. Myös laatujärjestelmät saattavat asettaa vaatimuksia dokumentaatiolle, jota sitten tehdään laatujärjestelmän itsensä takia. Joskus dokumentointi saatetaan kokea uuvuttavana ja turhana, ja tällöin helposti käy niin, että dokumentti tehdään vain jonkun muun toiveen täyttämiseksi arkistoihin pölyyntymään.

Toisaalta dokumentointiin voi ottaa myös toisenlaisen näkökulman. Millaisia asioita on tarpeen kirjata muistiin, jotta en unohtaisi, mitä on sovittu? Millaisia asioita on tarpeen kirjata muistiin, jos joku muu joutuukin yllättäen ottamaan projektista kopin? Millaisia asioita on tarpeen kirjata muistiin, jos asiakkaan kanssa täytyy jälkikäteen vääntää kättä siitä, onko sovitut asiat tehty vai ei? Entä kun sovitaan muutoksista, miten dokumentaatio saadaan pysymään ajantasalla?

Suunnitteludokumentaatio

Esimerkiksi testaussuunnitelman tarkoitus voi olla kuvata asiakkaalle käytettävä testausprosessi, tai asettaa reunaehdot muille projektin osapuolille siitä, millaisten asioiden on toteuduttava jotta testaaja voisi tehdä työnsä. Itse olen kuitenkin kokenut, että ellei joku näitä asioita erikseen pyydä, on turha odottaa että kukaan muu kuin testaaja itse koskaan lukisi koko dokumenttia. Siksi se kannattaa pitää kevyenä ja kirjoittaa siitä näkökulmasta, että se parhaalla mahdollisella tavalla tukee testaajan työskentelyä.

Testaussuunnitelma voisi siis sisältää seuraavanlaisia tietoja:

• Mistä löytyy oleellinen dokumentaatio (vaatimukset, käyttötapaukset, visuaaliset suunnitelmat yms.) johon testauksen on perustuttava? Jos dokumentaatiota ei ole, se voi kertoa lyhyesti, millaista tuotetta ollaan tekemässä, kenelle ja miksi. Dokumentissa voi olla myös listaus projektin vastuuhenkilöistä, joilta kysyä apua ongelmatilanteissa tai mielipidettä asioiden merkittävyydestä, mikäli nämä asiat eivät ole muuten ilmeisiä. 
• Hahmotelma testauksen strategiasta, hyödyllisistä menetelmistä ja työkaluista. 
• Pohdintaa riskeistä, joiden realisoitumisen mahdollisuuksia testauksella on syytä minimoida, sekä korkean tason jaottelua näkökulmista, joista testausta on tarpeen tehdä. Ideoita testauksen suunnitteluun löytyy esim. James Bachin ja Michael Boltonin kehitelemästä FEW HICCUPPS-mallista ja James Bachin heuristisesta testausstrategiamallista. 

Erilaiset tarkistuslistat ovat hyödyllistä testaussuunnitteludokumentaatiota, mutta niiden ei itsessään tarvitse olla projektikohtaisia eikä osa testaussuunnitelmaa.

Tärkeää testauksen suunnittelussa on tavoitteiden asettaminen testaukselle. Tavoitteita on hyvä tarkastella uudelleen projektin edetessä, ja sitä kautta tarvittaessa myös päivittää testaussuunnitelmaa. Tekemistä on suunnattava prioriteettien ja riskien näkökulmasta paitsi testauksen alkaessa myös matkan varrella.

Testausvaiheen dokumentaatio

Testauksen aikana syntyvästä dokumentaatiosta keskeisimpiä ovat bugiraportit. Aina niitäkään ei kaikkia tarvitse dokumentoida, vaan jotkut asiat voi hoitaa esim. suullisesti. Käytännössä monet bugit ovat kuitenkin sellaisia ettei niitä ole mahdollista heti korjata, ja silloin huolellinen dokumentointi on tarpeen jotta kehittäjä osaisi vaikkapa viikon kuluttua korjata ongelman ja mahdollisesti toinen testaaja tarkistaa korjauksen onnistumisen. Neuvoja bugiraportointiin löytyy esim. Cem Kanerin Bug Advocacy-mallista.

Bugiraporttien lisäksi voi olla tarpeen tehdä muistiinpanoja tai pieniä ohjeita hankalista asioista. Ne voivat olla esim. uusia checklistejä, lyhyitä käyttöohjeita asioihin jotka ovat itselle olleet vaikeita, huomioita toiminnoista jotka kaipaavat erityistä huomiota testaajalta esim. siksi että tuntuvat erityisen herkiltä hajoamaan muiden muutosten myötä, tai uusia ajatuksia alueista, joita testaajan olisi tarpeen tutkia enemmän kuin testaussuunnitteluvaiheessa on tullut ajateltua.

Näiden dokumenttien ensimmäinen hyöty on se, että testaajana voit antaa dokumentoitavan ajatuksen unohtua ja keskittyä siihen tehtävään, joka sinulla oli oikeasti työn alla. Kun sinulla on taas aikaa miettiä, mitä lähtisit tutkimaan seuraavaksi, tai joudut välillä siirtymään toisen projektin pariin ja sitten palaamaan taas nyt käsillä olevaan, kaivat vain esiin muistiinpanosi ja käyt hommiin käsiksi.

Toinen hyöty on se, että joskus voit joutua siirtämään projektisi toiselle henkilölle. Ei ole mahdollista luoda sellaista dokumentaatiota, jonka joku toinen pystyisi lukemaan ja sisäistämään, ja joka täydellisesti korvaisi kokemuksen tuotteesta ja projektista, mutta on paljon asioita, joiden löytyminen dokumentaatiosta helpottaa merkittävästi kärryille pääsemistä.

Lisäksi joskus asioiden merkitystä on helpompi arvioida, kun niihin ottaa vähän etäisyyttä. Kiinnostava bugi on aina hauskaa päästä raportoimaan, mutta joskus kysymys on asioista, joilla ei oikeasti ole merkitystä loppukäyttäjien kannalta, ja silloin voi olla parempi olla käyttämättä kehittäjän aikaa asiasta keskustelemiseen. Havainnon voi silloin vain kirjata itselleen ylös ja antaa asian hautua jonkin aikaa, onko tässä asia jonka tarkempaan tutkimiseen on syytä panostaa, ja miten se suhtautuu merkittävyydessään muihin tarjolla oleviin tehtäviin.

Testausvaiheen materiaali muodostuu tehtävänannoista, testaukseen käytettävistä aineistoista, työkaluista, sekä matkan varrella opituista asioista.

Analysointi

Jotta tekemistä voisi suunnata uudelleen ja lopputuloksista antaa relevantteja raportteja, on omaa työtä analysoitava jollain tapaa. Tähän voi käyttää esimerkiksi nk. proof-menetelmää, jota voi käyttää jokaisen testisession päätteeksi oman työn suuntaamiseen, mutta myös apuna siirrettäessä vastuu testauksesta toiselle. Menetelmässä arvioidaan testausta viidestä näkökulmasta: kuinka käytit ajan, mitä löysit, tarvitsetko apua tai työkaluja, onko vielä lisää tehtävää ja oliko tehtävänanto järkevä,

Raportointi

Suhteellisen yksinkertainen mutta vaikuttava ja informatiivinen tapa raportoida testausta on jaotella testauksen kohde muutamiin toiminnallisiin ja ei-toiminnallisiin osa-alueisiin, joihin liittyen testaaja tai projektitiimi antaa omat laatuarvionsa. Ei-toiminnallisia osa-alueita voivat olla esim. yleinen toimivuus, käytettävyys, luotettavuus, suorituskyky, turvallisuus ja ylläpidettävyys.

Laatuarvioita annetaan kolmiportaisin asteikoin, joita voidaan käyttää useampia yhtä aikaa arvion parantamiseksi. Laadun (hyvä / ei hyvä muttei kelvotonkaan / selkeästi keskeneräinen) lisäksi arvioidaan esitettävien käsityksien perusteluja (olenko varma väitteestä testattuani hyvin / olenko testaillut jonkin verran / oletanko vain) sekä tarvittaessa mielikuvaa ko. kokonaisuuden stabiiliudesta (eli kuinka luotettava nyt annettu laatuarvio olisi huomenna tai viikon päästä).

Testikattavuutta kannattaa pohtia siitä näkökulmasta, minkä tyyppiset asiat ovat merkityksellisiä, ja mistä raportointi on tärkeää. Ihmiset ovat erehtyväisiä, joten aina on riski että jokin testausta vaativa osa-alue on unohtunut kokonaan tarkastelusta.

Kuka vaan osaa testata - tai puhua kiinaa

Testaajana törmää hyvin monenlaisiin käsityksiin omasta ammatistaan. Toki moniin muihinkin ammatteihin yhdistetään eri tavoin hupaisia kuvitelmia siitä, mitä niiden taitajat työkseen tekevät, mutta itse en ole aikaisemmin työskennellyt tehtävässä, jonka sisällön samassa työpaikassa työskentelevät ihmiset näkisivät niin eri tavoin.

Kaikki osaavat testata

Yksi yleinen testaukseen liittyvä ajatus on, että kuka tahansa osaa testata. Tämä pitää ehdottomasti paikkansa, jokainen joka osaa käyttää tietokonetta, osaa myös jossain määrin testata siinä käyttämiään ohjelmia.

Osaamisen tasoissa on kuitenkin eroja. Kuka tahansa ei osaa käydä systemaattisesti läpi ohjelmistoa, keksiä erilaisia tapoja koetella sen tarjoamien toiminnallisuuksien rajoja ja väärinkäyttää sitä. Kuka tahansa ei osaa kertoa kohtaamistaan ongelmista tavalla, joka auttaa kehittäjää virheen löytämisessä. Hyvä testaus vaatii opiskelua, harjoitusta ja ajatustyötä.

Vähän niin kuin melkein kuka tahansa osaa ranskaa, jos kielitaidoksi riittää lukea ääneen ruokalistaa. Kuitenkaan ranskankielisen tekstin analysointi tai luontevan keskustelun käyminen ei luonnistu opettelematta.

Testaajat osaavat mm. suorituskykytestausta, käytettävyystestausta ja tietoturvatestausta

Moni testaaja varmasti hallitsee useampia testaustyyppejä. Niiden oppiminen ei kuitenkaan ole testaajalle sen helpompaa kuin ranskalaiselle on oppia portugalia, kiinaa tai arabiaa. Jos on kiinnostunut kielistä, niitä voi hallita useita. Jos osaa jo jotakin opeteltavan kielen sukulaiskieltä, helpottaa se niin kieliopin kuin sanastojenkin sisäistämistä, mutta silloinkin vaatii paljon harjoitusta ennen kuin voi sanoa olevansa hyvä siinä.

Jos et ole valmis palkkaamaan .NET-kehittäjäksi henkilöä, joka kertoo osaavansa html:ää, miksi luottaisit tietoturvatestauksen sellaisen henkilön käsiin, joka ei ole perehtynyt siihen kunnolla?

Laatuongelmista päästään, jos testaus suunnitellaan tarkemmin, automatisoidaan ja raportoidaan tarkemmin

Testaaja ei valitettavasti voi tehdä ohjelmistosta laadukasta, siihen tarvitaan kehittäjä. Testaajan toimilla toki voi olla paljonkin merkitystä siinä, miten laadukas lopputuloksesta tulee, vähän niin kuin kustannustoimittajan palautteella voi olla paljonkin merkitystä julkaistavan kirjan laadulle. Kirjailija on kuitenkin vastuussa syntyvästä tekstistä, samoin kuin kehittäjä on vastuussa toteutuksensa tuloksesta.

Testauksen suunnittelu on tärkeää testaamisen suuntaamiseksi oikeisiin asioihin, testauksen automatisointi on oiva työkalu joihinkin tilanteisiin, ja laadukas raportointi on korvaamatonta haluttaessa tietoa siitä, onko testaus ollut riittävän kattavaa ja onko järjestelmä riittävän valmis. Nämä ovat kuitenkin kaikki tehtäviä, joihin lisäpanosten laittaminen saattaa nostaa kustannuksia ja laskea laatua.

Testauksen yksityiskohtainen suunnittelu voi sokeuttaa testauskattavuuden puutteille. Jos testaaja keskittyy testitapausten täsmälliseen suorittamiseen, on hänen vaikea huomata niiden ulkopuolelle jääviä asioita. Myös itse suunnittelu saattaa kohdistua kapeammalle alueelle, jos sitä tehdessä keskitytään yksityiskohtiin eikä karkeamman tason näkökulmien etsimiseen.

Automatisointi on korvaamaton apu tilanteissa, joissa testataan asioita joita ei ole mielekästä tai mahdollista käsin testata, tai haluttaessa välttyä toistamasta käsin joitakin muuttumattomia tapahtumakulkuja. Sen rakentaminen ja ylläpitäminen vie kuitenkin paljon aikaa. Tämä voi tarkoittaa joko merkittävää kustannusten nousua tai merkittävää testauskattavuuden pienenemistä. Automatisointi voi myös johtaa prosessien läpiviemiseen aina keskenään identtisillä testisyötteillä. Ne, jotka saavat henkilökohtaista tyydytystä testien täydellisestä toistettavuudesta, voivat kokea tämän hyvänä tilanteena. Me, joille kokemus on osoittanut mitä ihmeellisimpien bugien nousevan esiin sattumanvaraisella testisyötteiden varioinnilla, pidämme tätä testauksen luotettavuutta heikentävänä tekijänä.

Mitä testauksen raportointiin tulee, siihen on pääpiirteissään kolme vaihtoehtoa.

Ajankäytöllisesti yksinkertaisin tapa raportoida on tarjota tilastoja bugeista ja testitapausten läpäisyprosenteista. Voidaan tarjota myös testitapauslista PASS/FAIL-tiedoin. Jos testitapaukset ovat kovin yksityiskohtaisia, niitä on todennäköisesti melko paljon, jolloin tällaisen listan informatiivisuus on hyvin kyseenalaista.

Toiseksi kevyin tapa raportointiin on sopia muutamia seurattavia asioita, joista tiimi saa antaa fiilispohjaisia arvioitaan, kuinka vakuuttavalla tolalla asiat ovat.

Jos raportilta halutaan jotain enemmän, täytyy huolella miettiä, mitä tietoa siitä olisi tarkoitus saada ulos. On myös hyväksyttävä se, että yksityiskohtaisen, eksaktin, luettavan ja relevantteja asioita esiin nostavan raportin koostamiseen saa helposti päivänkin aikaa kulumaan. Tämä aika on lisäkustannus, ja usein myös pois jostakin muusta.

Välitätkö informaatiota vai ylläpidätkö illuusiota?

Ihmismieli on siitä mielenkiintoinen, että se haluaa miellyttää. Tähän sillä on kaksi mitä nerokkainta tapaa: petos ja itsepetos.

Petoksella viittaan tilanteeseen, jossa toiselle ei haluta aiheuttaa pahaa mieltä kertomalla epämiellyttäviä tosiasioita. Projektipäällikkö saa kamppailla tätä tarvetta vastaan esimerkiksi kertoessaan asiakkaalle, mitkä toivotut asiat sisältyvät projektin laajuuteen ja mitkä eivät.

Itsepetos taas on sitä, kun eletään kuvitelmassa, että jostain saapuu maaginen pelastus ja tilanne ratkeaa parhain päin, vähän niin kuin elokuvissa, vaikka kaikki tosiasiat viittaavat siihen, että näin ei tule tapahtumaan. Siis esimerkiksi ajatellaan, että raportoidut sata bugia ovat niin yksinkertaisia korjata, että homma hoituu päivässä muiden töiden ohessa, ja kun ne on korjattu niin uusia ei enää löydy.

Testauksen tärkeimpiä tehtäviä on horjuttaa projektiin liittyvien petoksen ja itsepetoksen perustuksia organisaation sisällä. Siis tehdä lähes mahdottomaksi kenenkään ylläpitää epärealistisen positiivisia kuvitelmia toteutettavan järjestelmän tilasta.

Siksi on tärkeää miettiä, mikä on mielekkäin tapa testausraportointiin. Raportin tulee olla tarpeeksi lyhyt, että se luetaan, tarpeeksi selkeä, että sen viesti hahmotetaan, ja tarpeeksi jäsennelty, että sitä voidaan käyttää apuna resursoinnin suunnitteluun sekä tehtävien priorisoinnin ohjaamiseen. Jos sitä voi vieläpä vähällä työllä (tai jopa sellaisenaan) hyödyntää raportoitaessa asiakkaalle projektin tilasta, testaajan panos projektille on entistä helpompi nähdä positiivisena.

Asiakasta ei oikeasti kiinnosta bugien määrä tai laatu, vaan se, onko järjestelmässä jotain, mikä toimii luotettavasti, ja miten pian voi odottaa että muutkin asiat toimivat. Näistä ensimmäiseen testausraportin pitäisi pystyä antamaan suhteellisen luotettava vastaus. Jälkimmäisen arvioinnissa testausraportti on yksi keskeinen väline, vaikkakin riittämätön yksinään.

Skarpin testausraportin tärkeimpiä piirteitä on sen kyky konkretisoida tilanne. Testaaja nähdään helposti pessimistisenä valittajana, jolle mikään ei kelpaa, ja tällöin hänen mielipiteensä on myös helppo sivuuttaa - onhan itsepetoksen jatkaminen mukavampaa kuin tunnustaa ikävät tosiasiat. Jos testaaja voi konkreettisesti listata, kuinka suurta osaa käyttötapauksista ei voida suorittaa määrityksen mukaisesti, kuinka suurta osaa testitapauksista ei ole pystytty bugien tai keskeneräisyyden vuoksi testaamaan, ja kuinka paljon minkäkin prioriteettitason bugeja odottaa korjausta, hänen viestiinsä on vaikeampi suhtautua välinpitämättömästi.

Sisällön jäsentelyn lisäksi selkeyttä voi lisätä myös värien käytöllä. Esimerkiksi, vakaviin bugeihin liittyvät FAIL-rivit voi korostaa punaisella ja pienempiin liittyvät keltaisella. Yksittäiset vihreät PASS-rivit niiden seassa kertovat kenties selkeämmin tilanteen lohduttomuudesta kuin lukumäärät tai prosentit.