sunnuntai 8. marraskuuta 2015

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.

1 kommentti :

  1. Eeva, kiitos jakamisesta. Koska testausstrategia on "ideat jotka ohjaavat testaamista ja testien suunnittelua", on lienee paikallaan että olet käyttänyt aikaa yhteisen ymmärryksen luomiseen ja jakamiseen. Olisi todella mielenkiintoista nähdä konkreettisesti millaisia asioita strategiassa nousi. Odotan innolla seuraavia kirjoituksiasi testauksen saralta, ja laita ihmeessä näitä rohkeasti jakoon twitter / facebook -kanavissa, esim. testausyhdistys.

    VastaaPoista