Löydä se mitä on vaikea nähdä

Tiimillämme on pyrkimyksenä pitää kahden viikon välein retroja. Jokainen valitsee vuorollaan aihepiirin, jonka puitteissa laittaa muut täyttämään post-it-lappuja, joita ryhmitellään etsien työskentelyn kipukohtia.

Tällä viikolla pääsimme isojen kysymyksien äärelle etsimällä asioita, jotka eri vaiheissa prosessia tuottavat arvoa, hämmennystä tai ajanhukkaa. Iso tussitaulu peittyi post-it-lapuilla minulle ennennäkemättömällä tavalla.

Suurimmaksi ongelmaksi keskustelussa nousivat isot muutostyöt, joissa usein speksauskin on hieman epämääräinen. Niitä on vaikea edistää, ne vievät paljon aikaa, ja niissä on tavanomaista suurempi riski päätyä tekemään vääriä asioita.

Se, minkä itse koin erityisen mielenkiintoiseksi, oli että puhuimme tavallaan ihan samoista asioista, joilla vain pari viikkoa aikaisemmin olin perustellut testausstrategian luomista: hyödyllistä puuhasteltavaa riittää aina, joten ikäviin tai hankaliin hommiin ei välttämättä koskaan tule tartuttua ainakaan riittävällä tarmolla, jos ei ole tiettyä kurinalaisuutta omassa tekemisessä. 

Siinä missä minä testaajana tarvitsen strategista ajattelua edes nähdäkseni ne kokonaisuudet, jotka eivät mukavuusalueella pysytellen tule testatuksi, kehittäjä tarvitsee kurinalaisuutta ja strategista ajattelua jotta nuo isot ja vaikeat kokonaisuudet saataisiin pilkottua ja tehtyä pois alta. Vaihtoehto on, että niitä joko vältellään, tai edistetään vastahakoisesti mitenkuten milloin ehditään. Ja kun ympärillä tapahtuu koko ajan, rakennettava tuote saa jatkuvasti uusia ominisuuksia, pieniä parannuksia tai vähintään bugifiksejä, vältellen ja nitkutellen edistettävät kokonaisuudet helposti kasvavat, muuttuen yhä vaikeammiksi toteuttaa loppuun asti. 

Ja lopulta aika usein ne hankalimmin edistettävät asiat ovat kuitenkin tärkeitä.

Keskustelimme tavoista, joilla näiden isojen asioiden edistymistä voisi nopeuttaa, ja pohdimme syitä jotka ovat estäneet tässä onnistumista. (Ja vain pari päivää myöhemmin kävimmekin yhteistuumin pilkkomaan yhtä elefanttia.)

Jälkikäteen aloin muistella asioita, joita olen pitänyt testaajan urani suurimpina saavutuksina. Niistä lopulta aika harvat liittyvät tilanteisiin, joissa olen löytänyt bugin toteutetusta järjestelmästä. Parhaita ovat olleet hetket, kun olen keksinyt esittää kysymyksen, joka on paljastanut vältellyn aiheen. Usein ne ovat olleet asioita, jotka ovat selvästi vaivanneet kehittäjiä itseäänkin, mutta kissaa ei ole tullut nostettua pöydälle koska ei ole ollut pakko, ja muita, akuutimpia asioita on riittänyt enemmän kuin omiksi tarpeiksi. Joskus kyse on ollut asioista, jotka vain on ymmärretty eri tavoin, eikä kukaan ole pysähtynyt ajattelemaan asiaa huomatakseen ongelman laajuutta.

Kun puhutaan laadunvarmistuksesta, softan testaaminen on vain pieni osa kokonaisuutta. Vaikutuksiltaan merkittävintä on löytää niitä asioita, joita vältellään tai ei edes nähdä. Vaikeaa tästä tekee se, että testaajan näkökulmasta ne kaikki saattavat olla näkymättömiä. Kehittäjän taas voi olla vaikea nähdä juuri näiden asioiden esiin nostamista oleellisena, ne voivat tuntua joko vähäpätöisiltä tai kaikkien tuntemilta kollektiivisesti vaietuilta asioilta, mikäli niiden olemassaoloon edes kiinnitetään huomiota.

Tässä mielessä retrot ovat loistavia. Loistavia ovat myös hetket, kun löytää paljastavia kysymyksiä. Hyvä alku ovat "miten tämän voi testata", "kuka tätä käyttää", "mihin tämä vaikuttaa" ja "miksi tämä asia ei ole edennyt".

Testaajien ja kehittäjien välillä on joskus melko voimakastakin vastakkainasettelua. Itse pidän enemmän yhteistyömeiningistä. Toivon, että kehittäjät voivat nähdä minun ongelmani yhteisinä ongelminamme. Tämän viikkoinen retro konkretisoi itselleni myös sitä sinänsä aika itsestäänselvää asiaa, että myös kehittäjien ongelmat ovat minun ongelmiani. Lopultahan ne testaajan turhauttavimmat pulmat liittyvät usein juuri asioihin, joista myös kehittäjä on ollut epävarma. Meistä jokainen tekee osansa löytääkseen ja selkiyttääkseen epämääräisiä asioita. Myös minun tehtäväni on tarttua tähän työhön mahdollisimman varhaisessa vaiheessa.

Testausstrategiaa luomassa osa 1

Aloitin hiljattain uudessa työpaikassa. Siinä missä aikaisemmin olin yksi testausasiantuntija testaustiimissä, osana satojen henkien kokoista organisaatiota, nyt olen ainoa testaaja, ja muut työntekijät ovat kaikki kehittäjiä. Aikaisemmin työskentelin käytännössä vesiputousmallilla, nyt tarkoitus olisi päästä osaksi ketterää tekemistä. Ennen testasin useita tuotteita, nyt keskityn vain yhteen. Monet asiat ovat siis hyvin eri tavalla kuin edellisessä työssäni.

Testauksen näkökulmasta monet asiat ovat hyvin. Käytössä on TDD, kaikki koodi katselmoidaan, ja normaaliin työskentelyrytmiin on varattu aikaa vapaamuotoiselle toiminnan kehittämiselle sekä yhteisille retrospektiiveille. Organisaatio on testausmyönteinen, vaikka osaaminen sen suhteen on ollut jossain määrin rajoittunut tekniseen näkökulmaan. Tätä olisi nyt tarkoitus laajentaa.

Viime viikolla aloitin testausstrategian muodostamisen. Pidimme tiimin kanssa session, jossa kerroin lyhyesti, mitä testausstrategia tarkoittaa, ja sitten pureuduimme pohtimaan testauksen nykytilaa ja kehitystarpeita käyttäen työkaluna Sami Söderblomin FIT(Q)CODES-mallia. 

Selvitin jokaisen näkökulman osalta, minkä tyyppisiä asioita siihen liittyy (käyttäen pitkälti lähteenä James Bachin heuristista testausstrategiaa). Sitten tiimi sai äänestää, ovatko nämä asiat oleellisia lasilaatikko- vai mustalaatikkonäkökulmasta vai molemmista, kuinka tärkeästä kokonaisuudesta on kyse tuotteemme kannalta, ja kuinka hyvin pärjäämme siihen liittyvien piirteiden testauksessa. Sitten keskustelimme siitä, mitkä asiat ovat tästä näkökulmasta tärkeitä, ja mitkä vaatisivat enemmän huomiota. (Mustalaatikkopuolelta olin jo itse listannut näitä asioita.)

Vaikka tiimi ei ollut osannut odottaa ihan näin interaktiivista sessiota, keskustelu oli vilkasta, ja paikoin sen ohjaaminen tarkkaan suunnitelmani mukaan tuntui turhalta, niin luontevasti pohdinta eteni. Sain uusia eväitä oman testaustyöni suunnitteluun, ja esiin nousi myös joitakin tuotteen kipukohtia, joiden ratkaiseminen ei ole kiinni minun testauksestani.

Kirjasin parhaani mukaan muistiinpanot esiin nostetuista havainnoista ja listasin muutamia asioita, jotka vaativat erityistä huomiota sekä ideoita testauksen parantamiseen prosessin eri vaiheissa. Tällä mennään nyt muutama viikko, ja sitten jatkamme aiheesta etsien konkreettisempia tavoitteita ja vastuita. Sitä ennen minun olisi toki hyvä keksiä jotain uutta ajatuksia herättämään.

Tämä on varmasti hidas tapa luoda testausstrategia, mutta itse näen tärkeämmäksi tiimin yhteisen pohdinnan ja tavoitteiden etsinnän kuin nopean lopputuloksen. En myöskään näe mielekkäänä luoda testausstrategiaa vain oman työni lähtökohdista, ja vielä oudommalta tuntuisi lähteä suoraan ohjeistamaan kehittäjiä heidän työnsä tekemisessä, kun asiat ovat kuitenkin pääpiirteissään hyvin. Koen myös, että minulle yksi syy testausstrategian muodostamiseen on nimenomaan hakea eväitä yhteiseen keskusteluun. Ainoana testaajana joudun näkemään hieman vaivaa löytääkseni tiimistä tukea oman työni kehittämiseen, strategian muodostaminen ja myöhemmin sen arviointi ja eteenpäin kehittäminen tarjoaa tähän yhden työkalun.

Miten vanhemmuus kouluttaa testaajaksi

Lapset ovat pohjimmiltaan aika mainiota juttuseuraa. Parasta on päästä mukaan erilaisiin ongelmanratkaisusessioihin, joko osallistuen tai ihan vain seuraillen: miten vuosikas etsii paikkaa josta ylettyisi pinnasängyn kaiteen toisella puolella olevaan leluun, mistä kaikesta taapero voi esittää "miksi"-kysymyksen, millaisiin teknisiin pohdintoihin eskarilainen voi yltää, tai mistä löytyvät leikkiin ne tärkeät asiat, joita ei (aikuisen mielestä) löydy lelulaatikosta.

Lapset ovat taitavia muistuttamaan testaajalle tärkeistä asioista: mikään ei ole itsestäänselvää, ja aina voi löytää jonkin uuden tavan käyttää tuttuja esineitä.

Äitiydessä itsessään on myös paljon samaa kuin testaamisessa. Toisessa opitut ajattelutavat ja toimintamallit voivat tukea toista. Tässä muutamia asioita, joissa näen yhtymäkohtia:

1) Kun työt alkavat, et tiedä, mikä ongelma vaatii korjaamista. On kuitenkin muutama vaihtoehto, joiden tiimoilta kannattaa aloittaa asian selvittely. 

2) Ajan myötä arvauksesi tutuissa tilanteissa paranevat, mutta vastaan tulee uusia, monimutkaisempia ongelmia. Asioiden merkitykset muuttuvat.

3) Kirjallisuutta aiheesta on paljon. Suurin osa siitä ei ole sinulle erityisen hyödyllistä. Oikeiden kirjojen löytäminen voi olla aluksi vaikeaa. Kaikki vastaan tulevat ratkaisumallit eivät sovi omaan kontekstiisi, eivätkä kaikki omat ratkaisusi toimi muualla.

4) Vertaistuki on tärkeää. Jos et ole tarpeeksi onnekas elääksesi muiden samassa elämäntilanteessa olevien keskellä, tukea löytää helpoiten sosiaalisen median kautta. 

5) Pidemmän päälle yksi keskeisimmistä menestyksen avaimista on siinä, miten hyvin saat muut näkemään, miksi tietyt asiat ovat tärkeitä, miksi toiset ongelmia. Joskus on kärsivällisesti etsittävä parempia tapoja selittää ja havainnollistaa asioita uudella tavalla. 

6) Tärkeää on myös saada toiset tekemään kanssasi yhteistyötä. Jos haluat tulla kuunnelluksi ja otetuksi vakavasti, älä ole se joka aina vain valittaa. Älä ole ilkeä äläkä ylimielinen.

7) Älä jätä tärkeitä asioita sanomatta silloinkaan kun tiedät niiden herättävän vastustusta. Ole valmis kohtaamaan muiden negatiivisia tunteita ottamatta niistä itseesi. Ymmärrä, että roolisi on erityisellä tavalla vastuullinen, mutta parhaiten onnistut myös ristiriitatilanteissa olemalla myös osa tiimiä.

8) Kuuntele tiimiäsi. Myös he opettavat sinua. Paras tapa löytää oman ajattelun puutteet on ottaa harkintaan asioita, joita joku eri tavalla maailmaa katsova nostaa esiin.

9) Joskus paras tapa edistää asioita on esittää kysymyksiä.

10) Jos haluat olla oikeasti hyvä, ymmärrä oma epätäydellisyytesi ja pyri jatkuvasti parempaan. Jokainen epäonnistuminen on tilaisuus oppia tekemään asiat ensi kerralla paremmin. Oman mielenrauhan nimissä kannattaa myös oppia hyväksymään epätäydellisyys sekä tietty määrä elämän yleistä kaoottisuutta.

Toistettavuus vs. varioitavuus

Keskusteltaessa siitä, mitkä ovat suunnitelmallisen, ammattimaisen testauksen keskeisimpiä etuja, joskus nousee ajatus testien toistettavuudesta. Kun testitapaukset suunnitellaan riittävän yksityiskohtaisesti, tiedetään täsmälleen, mitä testaaja on testannut, ja samat testit ovat suoritettavissa täsmälleen samanlaisina kierroksesta toiseen, jolloin saadaan eksaktia dataa siitä, milloin jokin toiminto hajonnut. Testit voidaan myös automatisoida.

Toistettavuus on kyllä tärkeää siinä mielessä, että bugiraportoinnissa keskeisimmässä roolissa on tarjota riittävät tiedot virhetilanteeseen johtaneesta toimenpideketjusta, jotta korjauksen tekevä kehittäjä voisi löytää virheen koodista ja korjata sen. Sen sijaan on kyseenalaista, kuinka tarkkaan on tarpeen dokumentoida ne polut, joiden varrelta virheitä ei jollakin testikierroksella löytynyt.

Huomionarvoista on kuitenkin myös se, että yksikään testikierros ei voi testata kaikkia mahdollisia polkuja, joita pitkin todellinen käyttäjä voi järjestelmää käyttää. Myös testauksessa käytetty testidata on vajavaista verrattuna todellisten tilanteiden aikana mahdollisesti tarvittavaan dataan. 

Suunnitelmalliseen testaukseen toki kuuluu miettiä, mitkä ovat sellaisia rajatapauksia, joissa virheet todennäköisimmin ilmenevät jos niitä on, mutta ovelimmat virheet ovat sellaisia, joita ei voi ennakoida. Siksi testauksen kokonaiskattavuuden parantamiseksi testaajan on hyvä varioida toimintaansa kierrokselta toiseen siirryttäessä.

Sattuma on testaajan paras ystävä.

Esimerkiksi, jos prosessin B läpivienti ennen prosessia A aiheuttaa virhetilanteen prosessissa A, asia ei koskaan selviä testaajalle joka testaa prosessin A aina ennen prosessia B. Samoin jos hakutoiminnossa jokin tietty hakutermien yhdistelmä aiheuttaa virhetilanteen, sitä tuskin löydetään miettimällä etukäteen, millaisia yhdistelmiä testaajan tulisi testata.

On myös vaikea nähdä, mitä haittaa testien varioimisesta olisi. Koska yksittäistä testikierrosta ei voida suunnitella niin, että se olisi varmasti se kaikkein tehokkain löytämään virheitä, vaihtaminen toiseen yhtä hyvään seuraavalla kierroksella ei heikennä testauksen laatua lainkaan. 

Lisäksi testauksessa puhutaan hyönteismyrkkyparadoksista, jonka mukaan toistettaessa täsmälleen samaa testijoukkoa, sen kyky löytää virheitä vähitellen heikkenee. Kehittäjät ikään kuin oppivat välttämään niitä virheitä, joita joutuvat toistuvasti korjaamaan.

Toki variaatiot testauksessa asettavat korkeammat vaatimukset bugiraportoinnille, koska tällöin muuta informaatiota virhetilanteeseen johtaneista syistä ei ole käytettävissä. Yksityiskohtainen bugiraportointi on kuitenkin niitä perustaitoja, jotka erottavat hyvän testaajan huonosta testaajasta.

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.

Olenko hyvä testaaja

Minulle esitettiin hiljattain suora kysymys: oletko hyvä testaaja?

Kysymys on hyvä, mutta siihen on vaikea vastata. Mistä tunnistaa hyvän testaajan? Miten voi arvioida omaa hyvyyttään testaajana, jos ei pääse juurikaan tekemään töitä hyvien testaajien kanssa, joiden tekemisiin voisi omaa puuhasteluaan verrata? Ja toisaalta, hyvätkin testaajat ovat erilaisia. Jos saisin työskennellä gurun kanssa, joka saisi minut tuntemaan itseni jollain testauksen osa-alueella kädettömäksi, silti saattaisi olla jokin toinen osa-alue, jolla hänellä olisi opittavaa minulta.

Kehittäjiltä saatu palaute on tietenkin yksi mittari. Esim. "keksii luovia tapoja rikkoa asioita" on luonnehdinta, jonka otan kehuna. Myös kysymykset kuten "miten tämän sinun mielestäsi pitäisi toimia" ja "tiedätkö, onko tämä android-puhelinten yleinen virhe" luovat vaikutelmaa, että ammattitaitooni luotetaan. Samoin tuoteomistajilta, projektipäälliköiltä ja asiakkailta tuleva palaute kertoo paljon siitä, miten hyvin työssään onnistuu.

Pohjimmiltaan he ovat kuitenkin kaikki ihmisiä, joiden oma osaaminen kohdistuu johonkin muuhun kuin testaamiseen - ehkä he eivät vain tiedä paremmasta?

Ehkä hyvän testaajan on hyväkin olla hieman epävarma omasta ammattitaidostaan. Olemme kaikki vain ihmisiä. Kuka tahansa saattaa tehdä virhearvioita, olla keksimättä jotain oleellista tapaa väärinkäyttää järjestelmää tai jopa olla tunnistamatta jotakin testauksen osa-aluetta, joka olisi juuri käsillä olevan projektin kannalta äärimmäisen tärkeä. Tästä syystä testaaja ei voi eristäytyä yksin omaan kammioonsa, vaan hänen tulee jatkuvasti löytää uusia näkökulmia työhönsä. Tähän tärkeä väline on keskusteleminen muiden projektin osapuolten kanssa. Joskus yksinkertainen kysymys voi olla vaikuttavampi kuin päivän testausrupeama.

Niin kauan kuin on pienikin epäilys oman osaamisen riittämisestä, mieli etsii aukkoja omasta päättelystä. Ilman tätä uusia oivalluksia ei tule. Olisi vaarallista kuvitella osaavansa ja ymmärtävänsä jo kaiken.

Testausta on monenlaista. Kurinalaisuuden ja järjestelmällisyyden yhdistäminen luovuuteen ja jatkuvaan oppimisprosessiin on haasteellinen kokonaisuus, jossa minkä tahansa kulman laiminlyöminen voi johtaa kalliisiin epäonnistumisiin.

Siksi ei ole yhdentekevää, kuka tuotettasi testaa.

Ryhmässä on voimaa, myös testauksessa - oppeja tutkivan testauksen työkurssilta vol 2

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

Paritestaus

Yksi parhaista puolista koulutuksessa oli mahdollisuus päästä kokeilemaan paritestausta. Siinä ideana on, että kaksi testaajaa työskentelee yhdessä samalla tietokoneella yhteisen tehtävän parissa. Paritestausta voidaan tehdä monella tavalla:

• Toinen testaa vieressä istujan ohjeiden mukaan
• Toinen testaa ja vieressä istuja esittää kysymyksiä
• Testausta ohjataan tasa-arvoisella ideoinnilla (tämä vaatii onnistuakseen melko tasavahvan testaaja-parin, mutta voi onnistuessaan olla hyvinkin hauskaa ja hedelmällistä)
• Yksi vaihtoehto on myös käydä testitapauksia läpi yhdessä mutta käyttäen eri laitteita

Paritestauksen etuja on mm.

• Mahdollisuus oppia toiselta testaajalta, millaisiin asioihin testauksessa voi kiinnittää huomiota
• Dialogin myötä testatuksi tulee sellaisiakin alueita, joita kumpikaan ei olisi yksinään keksinyt
• Testaamisen flowta ei aina tarvitse keskeyttää bugiraportoinnin takia, kun toinen voi jatkaa toiminnon tutkimista toisen tehdessä muistiinpanoja (tätä kautta tilanteessa, joissa bugeja on suhteellisen paljon, paritestaus ei välttämättä edes vie yhtään sen enempää aikaa kuin jos testaajat testaisivat yhtä aikaa eri asioita)
• Pari auttaa myös muuten keskittymään käsillä olevaan tehtävään (ulkoset ärsykkeet helpompi jättää huomiotta)
• Hiljaisen tiedon jakaminen niin, että esim. yhden testaajan sairastuessa projektin testaus ei henkilövaihdosten takia hidastu

Kun testaajapareja on useita

Testasimme kolme 25 minuutin sessiota kolmen parin voimin keräten samalla bugihavaintoja. Tuona aikana vain muutamasta kaikkein ilmeisimmästä bugista tuli päällekkäisiä bugiraportteja, yhteensä erilaisia bugeja löytyi kuitenkin kymmeniä. Maaretin mukaan on ihan tyypillistä, että eri parit lähestyvät testattavaa kohdetta niin eri suunnista, ettei päällekkäistä raportointia juurikaan tule. Näin siinäkin tilanteessa, että kaikilla oli yhteinen varsin tarkkaan rajattu testauksen kohde.

Sessioiden päätteeksi käytiin läpi kaikkien havainnot. Tämä tarjosi taas oppimismahdollisuuksia, kun sai kuulla, mitä kaikkea muut parit olivat keksineet kokeilla. Tulosten yhteinen läpikäynti antaa myös mahdollisuuksia saada laajemman joukon näkemyksiä jatkotestauksen suunnitteluun.

Jos havainnot kerätään esim. post-it-lapuille ja ryhmitellään, on tätä kautta helppo kerätä myös tietoa siitä, mistä osa-alueista bugeja löytyy, ja mihin testausta kenties kannattaa keskittää seuraavaksi. Tutkivan testauksen sessiomme tuotti yli 20 erillistä bugihavaintoa, mikä tekee miltei yhden bugin minuutissa, joten ryhmätyö selkeästi toimii, jos halutaan lyhyen ajan sisällä saada paljon informaatiota testauksen kohteen tilasta.

Itselleni jäi vaikutelma, että tällainen useamman parin tekemä tutkiva testaus on hyvinkin tehokas tapa bugien löytämiseen, kun testataan ajallisesti suhteellisen lyhyissä sessioissa. 25 minuuttia oli ehkä vähän liian lyhyt aika, mutta esim. sessiopohjaisen testausmallin mukainen 90 minuuttia voisi tuntua jo turhankin pitkältä tarkoitukseen.


Paritestauksen ja ryhmätestauksen eduista sekä mahdollisuuksista ryhmäsessioiden toteuttamiseen voi lukea lisää esim. Klaus Olsenin Bug Hunt -materiaaleista.

Kuinka testaus kannattaa rakentaa - oppeja tutkivan testauksen työkurssilta vol 1

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, joita toivoakseni saan puhtaaksikirjoitettua vielä lähipäivinä. 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.

Kurssi oli rytmitetty niin, että lyhyitä teoriasessioita seurasi aina lyhyt paritestaussessio, jonka tulokset purettiin lyhyesti ennen siirtymistä seuraavaan teoriasessioon. Työskentelytapana tämä oli erinomainen, vaihtelu piti hyvin hereillä ja tekeminen konkretisoi läpikäytyjä asioita. Lisäksi paritestaus soi mahdollisuuden oppia parin tapaa testata, mikä toi mainion lisän kurssin antiin. Suosittelenkin lämpimästi kurssia kenelle tahansa testauksesta kiinnostuneelle.

Testasimme FreeMind-sovellusta, joka on ilmainen Java-pohjainen ideakarttatyökalu. Kukaan kurssille osallistunut ei ollut käyttänyt sitä aikaisemmin, mutta osalla oli kokemusta muista vastaavista sovelluksista.

Ad hoc -testaus

Ensimmäinen testisessiomme oli ad hoc -testausta. Saimme 25 minuuttia aikaa tutustua sovellukseen parhaaksi katsomallamme tavalla. Koska käytettävissä olevan ajan puitteissa ei ollut mielekästä lähteä tutustumaan dokumentaatioon, lähdimme yksinkertaisesti kokeilemaan, miten järjestelmä toimii. Tähän on oleellisesti kaksi mahdollista lähestymistapaa.

• Miettiä, mihin sovellusta on tarkoitus käyttää, ja lähteä kokeilemaan, kuinka hyvin se tämän tarpeen täyttää
• Katsoa, mitä toimintoja käyttöliittymästä löytyy, ja lähteä kokeilemaan, mitä ne tekevät

Ad hoc -testaus on hyvä tapa lähteä tutustumaan uuteen testauskohteeseen. Kun testaajalla ei ole juurikaan tietoa testattavasta toiminnallisuudesta, hän on vapaampi tekemään havaintoja. Esimerkiksi käytettävyyteen liittyvät omituisuudet jäävät ehkä helpommin kiinni, jos käyttäjän näkökyky ei ole ohjeiden ja määritysten tuomien odotusten rajoittama - useinhan loppukäyttäjäkään ei ole speksiä koskaan nähnyt. (Tämä ei tietenkään varsinaista käytettävyystestausta korvaa, mutta voi silti olla yksi kustannustehokas tapa parantaa käytettävyyttä.) Myös määrityksen lukeminen testausnäkökulmasta on helpompaa, jos on saanut jo hieman pyöritellä testattavaa järjestelmää.

Huono puoli ad hoc -testauksessa on, että kun toimintaa ei fokusoida millään tavalla, ei ole mitään takeita siitä, että sillä saavutettasiin relevantteja havaintoja. Keskeisiä toiminnallisuuksia saattaa jäädä testaamatta kokonaan, jos ne eivät ole käyttöliittymässä riittävän ilmeisesti tyrkyllä, ja testauksesta raportointi (muuten kuin löytyneiden bugien osalta) on vaikeaa. Lisäksi riski sille, että bugiraporttien joukosta löytyy käyttäjän virheestä tai ymmärtämättömyydestä johtuvia ihmeellisyyksiä, on suurimmillaan kun järjestelmää vain käydään summittaisesti läpi.

Myös käyntiin pääseminen uuden järjestelmän kanssa kestää jonkin aikaa, kun testaaja joutuu pohtimaan, mitä sen kanssa voisi yrittää tehdä ja mihin sitä voisi haluta käyttää, mutta tätä pidän itse väistämättömänä osana testausta. Oppiminen on prosessi joka vie aikaa, ja tehdäkseen hyvin testausta on opittava ja havainnoitava testattavaa kokonaisuutta. Ad hoc -testaus on siis parhaimmillaan testaukseen valmistautumista, ensivaikutelman hakemista testauksen kohteeseen, sekä ajatusten keräämistä testauksen suunnittelun tueksi.

Tavoitteellinen tutkiva testaus

Toiseen testisessioomme saimme tehtäväksi tietyn kokonaisuuden testaamisen. Ohjeena oli puolen sivun kuvaus kokonaisuudesta, joka kertoi, miten siihen pääsi käsiksi, mihin tarkoitukseen se oli rakennettu, sekä listasi siihen kuuluvat keskeisimmät toiminnallisuudet.

25 minuuttia kului nopeasti, ja vaikka toiminnallisuus oli meille uusi, pääsimme heti täysipainoisesti käsiksi työhön. Toki ohjelman toimintalogiikka oli tullut jo edellisen testisession yhteydessä hieman tutuksi.

Toiminnallisuus oli sen verran keskeneräinen, että paritestaus sujui varsin jouhevasti toisen testatessa ja toisen kirjoittaessa ylös havaintoja. Bugeja löydettiin lähes kaksinkertainen määrä edelliseen testisessioon verrattuna, ja tuntuma oli että ne myös olivat käytön kannalta relevantimpia.

Tutkivan testauksen etuja on useita. Tekniikkana se minimoi testaussuunnitteludokumentaation tarpeen viemättä kuitenkaan testaukselta suunnitelmallisuutta ja kurinalaisuutta. Näin vähäinen käytettävissä aika saadaan käytettyä mahdollisimman tehokkaasti, painottaen testausta eikä testausta ohjaavan dokumentaation luomista ja ylläpitämistä. Tutkiva testaus on myös hauskaa, se auttaa testaajaa pysymään valppaana ja tekemään siten myös sellaisia huomioita, joita suunnitteluvaiheessa ei ole osattu ennakoida.

Testaus käyttötapauksia (tai testitapauksia) vasten

Kolmanteen testisessioon saimme taas uuden rajatun kokonaisuuden testattavaksi. Tällä kertaa testauksen tueksi annettiin kahden sivun mittainen vaatimusmääritys, joka oli kirjoitettu luettelemalla kokonaisuuden keskeiset toiminnallisuudet sekä kuvaamalla askeleittain niistä jokaisen käyttö.

Kuten odottaa saattoi, mitä orjallisemmin testaajat seurasivat määritystä, sitä vähemmän bugeja löytyi. Määrityksessä kuvatut toiminnot pystyi kaikki viemään läpi virheittä. Kuitenkin niiden ympärille oli rakennettu käyttöliittymään yhtä jos toista, jonka käyttötarkoitus ei ollut käyttäjän näkökulmasta ollenkaan itsestäänselvä, eikä niiden kokeileminen vakuuttanut siitä että toiminnot olisivat valmiita. Kaiken lisäksi listan loppupäässä kuvattiin toiminnallisuuksia, joiden käyttäminen teki testimateriaalista oleellisesti monimutkaisempaa, ja täten tiettyjä listassa aikaisemmin kuvattuja toimintoja olisi syytä testata uudelleen listan läpikäymisen jälkeen. Tähän ei kuitenkaan testisession antaman ajan puitteissa ollut mahdollisuutta. Kenties testaus olisikin kannattanut tehdä takaperoisessa järjestyksessä.

Todettiin, että tällaista dokumettia voi käyttää testauksessa hyödyksi muutamallakin tavalla

• Dokumentti kuvasi keskeisten toimintojen käytön, joten se toimi tapana perehdyttää testaaja testattavaan kokonaisuuteen.
• Tällaista dokumenttia voisi jopa käyttää rajaamaan testauksesta pois dokumentin kuvaamat toiminnot. Työnsä vakavasti ottava kehittäjä on todennäköisesti testannut ne jo. (Pidemmän määrityksen kanssa näin ei luonnollisestikaan voida toimia. Tässä tapauksessa dokumentti näytti siltä kuin se olisi kirjoitettu pintapuolisen testauksen ohessa ikään kuin käyttöohjeeksi toiminnoille.)
• Mikäli dokumentti kuvasi korkeimman prioriteetin toiminnallisuudet, sitä voisi käyttää eräänlaisena muistilistana, johon palata myöhemmässä testauksen vaiheessa sen tarkistamiseksi, onko oleellisimmat toiminnallisuudet testattu riittävän perusteellisesti ja riittävän myöhäisessä vaiheessa. Esim. regressiotestauksen suunnitteluun se voisi olla toimiva työkalu.

Samat hyödyt voitaisiin kuitenkin saavuttaa muillakin tavoin. Esimerkiksi demosessiossa, jossa kehittäjä esittelee testaajalle rakentamansa toiminnallisuuden, testaaja saa sekä perehdytyksen toiminnallisuuteen että käsityksen siitä, mitä toimintoja kehittäjä on testannut. Tällaisen istunnon lisäetuna olisi testaajan mahdollisuus esittää kysymyksiä, jotka voisivat johtaa joko testaajan entistä parempaan testaukseen, tai siihen että kehittäjä löytäisi toteutuksestaan korjattavaa jo ennen varsinaisen testauksen alkua.

Mitä jäi käteen

Sekä päivän aikana käyty keskustelu että käytännön harjoitukset tukivat käsitystäni, että tehokkain tapa löytää bugeja on nimenomaan tavoitteellinen tutkiva testaus. Tämä ei kuitenkaan tarkoita, että tutkiva testaus olisi ainoa tekniikka, jota kannattaa käyttää. Ad hoc -testauksella on myös oma arvonsa haluttaessa löytää järjestelmään uusia näkökulmia. Lisäksi määritettyjen toiminnallisuuksien läpikahlaamiseen sekä työn priorisointiin myös rakenteeltaan melko perinteinen testaussuunnittelu puolustaa paikkaansa, kunhan suunnittelu tehdään järkevästi, riittävän karkealla tasolla. Yksityiskohtaiset ohjeet kun toimivat kuin laput silmillä, vaikeuttaen muiden asioiden huomioimista.

Myös paritestaus sekä testauksen jakaminen eri teeman ympärillä pyöriviin sessioihin vaikuttivat toimivilta tavoilta hakea tehoja testaukseen.

Myös testauksen automatisoinnista keskusteltiin lyhyesti. Erityisesti yksikkötestipuolella automatisointi on erinomainen väline, mutta järjestelmätestauspuolella sen käyttö on jossain määrin kyseenalaista. Automaation rakentaminen vie moninkertaisen ajan verrattuna manuaaliseen testaukseen, ja automaattitestien ylläpitäminen järjestelmän muuttuessa on työlästä. Tämä ei kuitenkaan tarkoita, etteikö automaattitesteilläkin voisi olla paikkansa myös järjestelmätestausvaiheessa. Kaikkea ei aina ole edes mahdollista testata käsin käyttöliittymästä, ja lisäksi joskus testiautomaatiota on mahdollista pienin variaatioin monistaa tavalla, joka parantaa testikattavuutta tai helpottaa testimateriaalin luomista niin, että testien kirjoittamiseen käytetty aika saadaan ainakin osin kompensoitua niiden ajamisen nopeudella. Lisäksi suhteellisen muuttumattomien kokonaisuuksien testauksen automatisointi voi tuoda regressiotestaukseen merkittävän avun. Oleellista automatisoinnissa onkin analysoida, missä siitä saavutetaan suurin hyöty, sekä tietenkin ymmärtää, ettei se yksin riitä testattaessa järjestelmiä, joita ihmisten on tarkoitus käyttää.

Mustalaatikkotestaus ja testauksen kattavuus

Testaukseen on monenlaisia tekniikoita. Yksi tapa jaotella testaustekniikoita on jako ns. mustalaatikkotekniikoihin ja lasilaatikkotekniikoihin sen mukaan, onko testaajalla pääsy testattavaan koodiin vai ei.

Silloin tällöin vastaan tulee käsityksiä, joiden mukaan mustalaatikkotekniikat olisivat huonompia, ja esimerkiksi listattessa mittareita testauksen kattavuudelle usein luetellaan asioita, jotka liittyvät nimenomaan lasilaatikkotestaukseen.

Itse näen vastakkainasettelun mielettömänä. Molempia tarvitaan.

Niin hienoa kuin testaajana olisikin helpottaa kehittäjien työmäärää, loistavakaan mustalaatikkotestaaja ei poista tarvetta kehittäjän tekemälle testaukselle. Samalla loistavakaan kehittäjä ei poista tarvetta käyttäjänäkökulmasta tehdylle järjestelmätestaukselle. On vaarallista olettaa, että toinen korvaa toisen. Jos on järjestelmä, jota elolliset olennot tavalla tai toisella käyttävät, on sitä koekäytettävä mahdollisimman realistisissa olosuhteissa, jotta voidaan varmistua, että se toimii myös tuotantokäytössä, eikä tämän koekäyttämisen kannalta ole oleellista nähdä koodia. Samalla kuitenkin koodi voi sisältää virheitä, jotka jäävät helposti kiinni vaikkapa koodikatselmoinnissa, mutta mustalaatikkotestaaja tarvitsee satumaisen tuurin osatakseen valita testaukseen juuri ne arvot, joilla virhe ilmenee.

Mitä muita tapoja siis on arvioida testauksen kattavuutta kuin koodikattavuus? Mustalaatikkotestauksen kattavuutta voidaan lähestyä esim. seuraavanlaisista näkökulmista:

• Vaatimuskattavuus. Onko kaikki sovitut ominaisuudet toteutettu, ja toimivatko ne siinä käyttötarkoituksessa johon niitä tarvitaan? Hyvän kehittäjän mind set on yksinkertaistava, ja joskus tulee yksinkertaistettua liikaa, jolloin toteutettu kokonaisuus ei enää vastaakaan siihen tarpeeseen, johon se tilattiin. Joskus joku kokonaisuus voi myös yksinkertaisesti unohtua. Vaikka testaisit koodin kuinka perusteellisesti, tämäntyyppiset virheet voivat jäädä huomaamatta.
• Prosessikattavuus. Menevätkö kaikki prosessit läpi alusta loppuun todellisilla käyttäjärooleilla? Pääsevätkö käyttäjät käsiksi tarvitsemiinsa tietoihin ja toimintoihin, tai näkevätkö he sellaisia tietoja tai toimintoja joihin heillä ei pitäisi olla oikeuksia?
• Tilasiirtymäkattavuus. Etenevätkö prosessit tilasta toiseen ja työlistalta toiselle kuten pitääkin? Toimivatko tilasiirtymät myös muihin suuntiin kuin suoraviivaisesti eteenpäin, esim. asian palauttaminen käsittelyn edelliseen vaiheeseen? Onko prosessin etenemiseen vaikuttavia raja-arvoja, kuten kurssipaikkojen täyttyminen ja siirtyminen varasijojen täyttämiseen, tai tietyn summan tai painorajan jälkeen muuttuvat postituskulut?
• Toiminnallisuuskattavuus. Toimivatko kaikki käyttöliittymästä löytyvät toiminnallisuudet niin kuin pitääkin? Esimerkiksi erilaisten listanäkymien sivutukset, suodatukset ja järjestämiset sekä hakutoiminnot ovat esimerkkejä toiminnallisuuksista, joista löytyy paljon testattavaa, mutta joista ei välttämättä määritysvaiheessa sovita yhtään mitään.
• Selain- tai laitekattavuus. Web-sovellusta tehtäessä kehittäjä ehkä testaa kaiken vain Chromella. Testaajalle jää selvittää, että myös muut vaaditut selaimet ja myös mobiililaitteet toimivat. 

Testausta ei myöskään tarvitse ajatella vain teknisenä asiana. Järjestelmiä käyttävät ihmiset, joista monet ovat kaikkea muuta kuin teknisiä. Siksi testaukseen voi - ja on syytäkin - hakea ideoita myös muualta.

Muita ajatuksia testauksen kattavuuden arvioimiseen voi löytää esim. seuraavista linkeistä:

• Testing without a map
• FEW HICCUPPS
• Heuristic Test Strategy Model
• Heuristics Cheet Sheet
• You Are Not Done Yet

Hakutoiminnon testaus

Hakutoimintoja on erilaisia, ja siksi niiden testauskin on tilannesidonnaista. Tässä kuitenkin listaus asioista, jotka voivat olla relevantteja hakutoimintoa testattaessa.

Haun testaamista hankaloittaa mustalaatikkotestaajan näkökulmasta se, että hakutulokset riippuvat siitä joukosta, johon haku kohdistuu. Testaajan voi olla vaikea saada riittävästi tietoa tuosta joukosta sen arvioimiseksi, löytääkö haku varmasti kaikki tulokset joita sen pitäisi löytää. Usein kuitenkin on mahdollista kokeilemalla ja tuloksia tarkastelemalla saada hyvä käsitys haun toimivuudesta. Asioita, jotka eivät näy helposti hakutuloksista, mutta joita kuitenkin on mahdollista arvioida, on esim. löytääkö haku tuloksia kaikista sivuston sivuhaaroista.

• Antaako haku tuloksia? Ovatko hakutulokset uskottavia?
• Vaikuttaako hakutermien vaihtaminen tuloksiin?
• Sisältävätkö tulokset käytettyjä hakutermejä niissä kentissä, mihin haku kohdistuu? Ovatko kenttien painoarvot oikein, esim. tyypillisesti sivun nimessä oleva sana saa isomman painoarvon kuin leipätekstistä löytyvä. Kohdistuuko haku kaikkiin kenttiin joihin sen pitäisi?
• Kohdistuuko haku useampiin sisältötyyppeihin (esim. sisältösivut + liitetiedostot)? Jos näin, löytääkö se tuloksia kaikista sisältötyypeistä?
• Mitä tietoa hakutuloksista näytetään hakutuloslistauksessa? Onko se relevanttia käyttäjälle? 
• Näytetäänkö hakutuloksista tietoja, joihin käyttäjällä ei pitäisi olla oikeuksia?
• Näytetäänkö hakutuloksina kohteita, joihin käyttäjällä ei ole oikeuksia?
• Onko käyttäjän mahdollista vaikuttaa hakutuloksista näytettäviin tietoihin tai järjestää hakutuloksia? Toimivatko nämä toiminnot?
• Tulosten sivuttuminen ja sivutuksen selaaminen? Pysyykö hakutulosten järjestys? Saako kaikki tulokset myös samalle sivulle, tai voiko yhdellä sivulla näytettävien tulosten määrää vaihtaa?
• Voiko hakutuloksia edelleen suodattaa? Toimiiko se?
• AND OR NOT haut ja näiden yhdistelmät? Asteriskin käyttö? Pitääkö haun löytää myös esim. hakusanojen taivutusmuotoja?
• Erikoismerkkien käyttö?
• Onko hakutoiminnossa alasvetovalikoita, checkboxeja tms? Ovatko kielitermit paikoillaan, toimivatko eri hakukriteerit ja niiden yhdistelmät? Jos hakutoiminto sisältää päivämäärähaun, käyttääkö se oikeaa formaattia ajasta?
• Voiko hakukriteerit tyhjentää? Voiko sen jälkeen tehdä uuden haun?
• Löytääkö haku uusia tai hiljattain muuttuneita hakukohteita?
• Mitä tapahtuu, jos haku ei palauta tuloksia?
• Näytetäänkö hakutulosten lukumäärä? Onko se riittävän oikea?
• Pääseekö samaan hakuun useammasta paikasta? Antavatko samat hakutermit eri paikoista käytettynä samat tulokset?
• Saako hakutuloksen avattua? Pitäisikö siitä voida palata hakutulokseen?

Layoutin testaus

Nettisivuston ulkoasu on osa brändin rakentamista. Siksi myös ulkoasun virheettömyys on tärkeää. Oman haasteensa testaukseen tuo se, mobiililaitteiden merkitys netinkäytössä kasvaa koko ajan, ja mobiililaitteiden kirjo on valtava. Ulkoasu ei myöskään aina tarkoita vain sitä, näyttääkö jokin näkymä kivalta, vaan joskus ulkoasuvirheet voivat myös piilottaa informaatiota tai toiminnallisuuksia.

Ulkoasun oikeellisuus on helpointa verifioida luomalla testisivuja täsmälleen visuaalisen suunnitelman mukaisilla sisällöillä. Tällöin virheet väreissä, fonteissa, kuvapaikkojen ja ikonien koossa, elementtien keskinäisessä sijoittelussa, marginaaleissa jne. on suhteellisen helppo huomata yksinkertaisesti vertaamalla visuaaliseen suunnitelmaan. Kuvasta kannattaa etsiä linjoja, joiden avulla voit tarkistaa eri elementtien keskinäisen asemoinnin, esim. vierekkäisten palstojen otsikkopalkkien ylä- ja alareunat, tai näyttääkö teksti tai kuva keskitetyltä pysty- tai vaakasuunnassa. Tarkista myös, onko käyttöliittymän eri osien välillä esim. vaaka- tai pystyviivoja erottamassa elementtejä toisistaan, ja jos näillä elementeillä on esimerkiksi keskenään erilaiset taustavärit, vaihtuuko taustaväri täsmälleen tuon erottavan viivan kohdalla vai ei. Jos tekstien eteen tulee jossain checkboxeja tms. listamerkkejä, tarkista niiden asemoituminen suhteessa ko. rivin tekstiin. Muista myös hover-efektit, aktiiviset linkit ja käydyt linkit, sekä milloin hiiren kursori indikoi alla olevan linkin.

Lisäksi on tärkeää luoda testisivuja, joiden sisällöt eivät ole ihan niin nättejä.

Tyypillisiä esimerkkejä tilanteista, jotka luovat ulkoasuongelmia, ovat

• tavanomaista pidemmät sanat
• rivittyvät kuvatekstit
• rivittyvät linkin nimet
• bannerien määrän muuttuminen
• eri määrä sisältöä vierekkäisissä listaelementeissä
• kuvattoman uutisen julkaisu listalla, joka näyttää uutisista ingressikuvia
• kuvagallerian kuvien rivittyminen niin että viimeinen rivi ei ole täynnä kuvia
• bulletpoint-listat rivittyvillä tekstinpätkillä

Lisäksi huomio kannattaa kiinnittää myös seuraaviin

• Onko käytössä eri tyyppisiä mutta keskenään saman näköisiä listaelementtejä (esim. blogilista, uutislista, tapahtumalista)? Jos niitä näytetään samalla sivulla, ovatko marginaalit yms. oikeasti samanlaiset?
• Kieliversiot ja niihin liittyvien merkistöjen näkyminen. Nappien tekstien mahtuminen nappeihinsa.
• Sivujen leveydet. Onko esim. jollain sivulla "turha" vierityspalkki kertomassa, että sivu onkin leveämpi kuin sen pitäisi
• Sivukarttasivu, hakutulossivu, palautelomakesivu yms. Näistä ei aina ole visuaalista suunnitelmaa olemassa, mutta yhtä kaikki niidenkin tulisi näyttää hyvältä.
• Elementtien kulmien pyöristykset, liukuvärit
• Murupolku

Responsiivista sivustoa testattaessa tarkista myös mm.

• Pysyykö kuvien kuvasuhde vakiona eri selaimen leveyksillä? Venyvät kuvat eivät ole hyvää brändin rakentamista
• Navigaation saavutettavuus

Mitä muuta testaisit?

Lomaketestaus

Alla muistilistaa asioista, jotka voivat olla relevantteja testattaessa täytettäviä www-lomakkeita mutta myös muita toiminnallisesti vastaavia kohteita kuten erilaisia tietokortteja. Lista ei ole täydellinen, se ei esim. ota kantaa tietoturvaan liittyviin asioihin kuten sql-injektioihin tai captcha-toiminnon testaamiseen. Toisaalta se on myös ehkä jo turhankin pitkä testisession tueksi. Millaista listaa itse käyttäisit?

• Löytyvätkö vaaditut kentät? Onko ne nimetty oikein? Onko ylimääräisiä kenttiä?
• Onko pakollisia kenttiä? Onko ne merkitty asteriskein? Voiko lomakkeen merkitä valmiiksi täyttämättä pakollisia kenttiä? Onko ehdollisia tai vaihtoehtoisia vaatimuksia, ja toimivatko ne oikein kaikissa tilanteissa?
• Validoidaanko syötteiden sisältöjä, esim. sähköpostiosoitteen muoto? Toimivatko validoinnit? Esim. puhelinnumeron voi syöttää monella tavalla, välilyönneillä, väliviivoilla, maakoodilla,..
• Onko päivämäärä/kellonaika-kenttiä? Missä formaatissa aika syötetään niihin ja validoidaanko syötteitä?
• Onko rajoitteita käytettävistä merkeistä, ja miten se toimii?
• Kuinka monta merkkiä kenttään voi syöttää? Kulkeeko maksimimerkkimäärä myös rajapinnan yli ja tallentuuko se tietokantaan oikein?
• Checkboxit, radiobuttonit
• Voiko käyttöliittymässä lisätä kenttiä? Voiko niitä poistaa, järjestää tai vaihtaa toisenlaisiin? Hajoaako käyttöliittymä tätä kokeiltaessa? Poistuvatko oikeat kentät, tulevatko lisättävät kentät oikeaan paikkaan?
• Voiko käyttäjä lisätä kuvia tai liitetiedostoja? Sallitut tiedostotyypit? Tiedostojen sallitut koot? Voiko dokumentteja liittää useita? Voiko liitettyjä dokumentteja poistaa? Onko tiedostonlisäyskontrolleja yksi vai useampia? Jos useampia, toimivatko ne toisistaan riippumattomasti? Mitä käyttöliittymälle tapahtuu tiedostoja lisättäessä ja poistettaessa?
• Onko lomakkeella ohje-toiminnallisuuksia? Ovatko ne siellä missä pitääkin ja toimivatko ne?
• Onko lomakkeella linkkejä? Vievätkö ne sinne minne pitääkin?
• Voiko kentästä toiseen liikkua tabulaattorilla? Voiko kaikki kentät täyttää näin? Mitä tapahtuu jos käyttäjä painaa enteriä?
• Onko sivuja useampia kuin yksi? Voiko eteen ja taakse liikkua menettämättä täytettyjä tietoja?
• Onko esikatselutoimintoa? Näyttääkö se kaikki tiedot oikein? Voiko siitä palata muokkaamaan tietoja? Jäävätkö muokkaukset voimaan?
• Onko toimintoa kenttien tyhjentämiseen? Tyhjentääkö se ne kaikki? Ovatko ne tyhjiä myös esikatselussa ja lähetettäessä?
• Toimiiko lähettäminen? Mitä sen jälkeen tapahtuu, mitä käyttäjälle näytetään? Toimiiko tulostaminen? Tuleeko sähköpostivahvistus ja sisältääkö se tarvittavat tiedot?
• Onko kieliversioita?
• Tuetut selaimet ja laitteet?

Ninjakin tarvitsee mestaria

Testaus on käsityöläisammatti, jonka oppimiseen on vain yksi tie: harjoitus. Työn tekeminen ja tulosten kriittinen analysointi ovat edellytys sille, että voi osata testausta.

Käsityöläisammatit eivät kuitenkaan ole kehittyneet vain yksittäisten ihmisten kekseliäisyyden varassa. Ammattilaiseksi kehitytään mestarin ohjauksessa, ja mestareista parhaat ovat hakeneet oppia useammaltakin mestarilta, tyypillisesti myös ulkomailta.

Tavallaan testausta voidaan verrata myös kamppailulajien harjoittelemiseen. Opetellaan uusia tekniikoita, hiotaan niitä, opetellaan tunnistamaan tilanteita joissa niitä käytetään, ja opetellaan käyttämään niitä tehokkaasti. Hyvät harjoitukset rakennetaan vastaamaan mahdollisimman realistisia todellisia tilanteita.

Myös jokaisella dojolla on oma mestarinsa, jonka oppeja seurataan, vaikka opetuksesta tyypillisesti huolehtiikin joku muu.

Nykypäivänä emme ole täysin suullisen tiedon varassa. Kirjastoista ja netistä löytää tietoa niin käsitöistä, kamppailulajeista kuin testauksestakin. Pyörää ei tarvitse keksiä kokonaan itse, vaikka ei mestarin ohjauksesta saisikaan nauttia.

Silti, ilman ohjausta voi olla vaikea löytää tietään parhaan tiedon luo. Tarvitaan myös mahdollisuuksia kysymiseen ja keskustelemiseen. Näihinkin netti tarjoaa onneksi mahdollisuuksia.

Netin kautta mestari ei kuitenkaan voi korjata virheellistä ranteen asentoa tai jalan väärää liikerataa. Tekniikan hioutumiseen on mahdollisuuksia vain siellä, missä oppija itse näkee tarpeen kehittymiselle.

Voiko myöskään testauksessa koskaan toteuttaa täyttä potentiaaliaan, jos ei saa tilaisuuksia harjoitella yhdessä mestarin kanssa?