Olemme perustaneet yhdistyksen, jonka tarkoituksena on kehittää ohjelmisto- ja järjestelmätestauksen tilaa tilannetekijäohjatun (context-driven) testauksen periaattein sekä toimia ohjelmistotestausosaamisen kehittämisestä kiinnostuneiden yhteistyöverkostona.

Tähän artikkeliin on kerätty yhteen perusajatuksia tilannetekijäohjatusta testauksesta, toivottamaan käytännön testaustyötä tekevät ja pohtivat mukaan rakentamaan osaavan testaajan arvostusta osana uutta yhdistystämme!

Artikkelin aiheesta on koonnut Maaret Pyhäjärvi. Tämä teos on lisensoitu Creative Commons Nimeä-Epäkaupallinen 4.0 Kansainvälinen -käyttöluvalla.

Creative Commons -käyttölupa

Tilannetekijäohjattu testaus – mistä on kysymys?

Tiedämme kaikki, että yksi koko ja tapa ei sovi kaikille – valinnat riippuvat tilanteesta.  Hyvien valintojen keskipisteessä on osaaminen – ajatus siitä, että testaaja on tietotyön tekijä, jolla on aktiivinen rooli.

Testauksen valintoja voi lähestyä kahdesta lähtökohdasta suhteessa tilannetekijöihin. Tilannetekijäohjatussa (context-driven) testauksessa mietitään lähtökohtana tilannetta, sidosryhmiä ja tarpeita ja luodaan sitten tilanteeseen soveltuvia käytäntöjä. Tilannetekijätietoisessa (context-aware) testauksessa valitaan käytäntö ja mukautetaan sitä paremmin tilanteeseen soveltuvaksi. Esimerkiksi testausstandardit ja testauksen sertifiointisisällöt ovat  usein tilannetekijätietoisia, ne lähtevät liikkeelle hyvän testauksen visiosta ja rohkaisevat muokkaamaan sidosryhmien tarpeen mukaan. Mukautustarve voi olla laajaa, jopa hyvän testauksen visio voi olla soveltumaton omaan tilanteeseen. Tilannetekijäohjattu lähestymistapa lähtee sidosryhmien vaatimusten syvemmästä ymmärtämisestä ja tilanteen käytännön rajoitteista ja mahdollisuuksista, tehden parasta mahdollista työtä tilanteeseen nähden.

Määritelmä

Tilannetekijäohjattu (engl. context-driven) määritellään seuraavasti (Cem Kaner, http://context-driven-testing.com/):

Tilannetekijäohjatut testaajat valitsevat testauksen tavoitteet, tekniikat ja tuotokset (sisältäen testausdokumentaation) katsoen ensin tietyn tilanteen yksityiskohtia, mukaanlukien testauksen tilanneiden sidosryhmien toiveita. Tilannetekijäohjatun testauksen ydin on projektiin soveltuvassa osaamissa ja harkinnassa. Tilannetekijäohjattu testaus sijoittaa tämän testauslähestymistavan humanistis-sosiaaliseen ja eettiseen viitekehykseen.

Viime kädessä tilannetekijäohjattu testaus on sitä  että teemme parasta mahdollista työtä. Sen sijaan, että yrittäisimme soveltaa huippukäytäntöjä (best practices), hyväksymme hyvin erilaisia käytäntöjä (myös erilaisia määritelmiä yleisistä testaustermeistä) parhaiten toimivina erilaisissa tilanteissa.

Tilannetekijäohjatun (engl. context-driven) testauksen seitsemän periaattetta (Cem Kaner, James Bach, Bret Pettichord. Lesson Learned in Software Testing, 2001):

  1. Minkä tahansa käytännön arvo riippuu sen tilannetekijöistä.
  2. On hyviä käytäntöjä tiettyihin tilannetekijöihin, mutta ei ole huippukäytäntöjä kaikkiin tilannetekijöihin.
  3. Ihmiset, yhdessä, ovat jokaisen projektin tilannetekijöiden tärkein osa.
  4. Projektit muuttuvat ja selkeytyvät ajan myötä tavoilla, joita ei usein voida ennustaa.
  5. Hyvät järjestelmät/tuotteet ovat ratkaisuja johonkin ongelmaan. Jos ongelmaa ei ole ratkaistu, järjestelmä/tuote ei toimi.
  6. Hyvä ohjelmistotestaus on haastava älyllinen prosessi.
  7. Vain käyttäen harkintaa ja osaamista, yhteistyössä eri osapuolien kanssa läpi projektin, voimme tehdä oikeita asioita oikeaan aikaan testataksemme järjestelmiä/tuotteita hyvin.

Ei huippukäytäntöjä

Koska yksi koko ja tapa eivät sovi kaikille, ei ole huippukäytäntöjä (best practices), jotka toimisivat kaikille. On hyviä käytäntöjä erilaisiin tilannetekijöihin. Oppiaksemme lisää testauksesta, on tärkeää keskustella eri käytäntöjä korostavien ryhmien kesken oppimistarkoituksissa – mitkä ajatukset ja kokemukset johtavat erilaisiin johtopäätöksiin siitä mikä toimii ja mikä ei.

Sen sijaan että lähdetään soveltamaan väitettyä huippukäytäntöä, selvitetään tarkemmin kyseisen hyvän käytännön vaatima konteksti suhteessa omaan kontekstiin hyödyllisyyttä arvioiden. Osa kontekstia on organisaatiossa olevat ihmiset – itsemme mukaanlukien – ja se mikä toimii yhdelle ei välttämättä toimi samalla  tavalla toiselle.

Konteksti on tärkein ja hyvä testaus on viime kädessä osaamisen, ei toimintamallin määrittämää. Tilannetekijäohjattu testaaja lähestyy jokaista testaustilannetta kuin se olisi ainutlaatuinen tärkeillä tavoilla, huomatakseen erot, ja kehittää osaamistaan reagoida tilanteeseen laajalla ja syvällä tietoisuudella projektin ongelmista ja niiden testaukseen liittyvistä ratkaisuista.

Keskiössä testaaja ja osaaminen

Testaaja on henkilö, joka tekee testausta. Testausta voidaan tehdä myös osana muita rooleja. Nykyisin voisi jopa sanoa, että testaus on liian tärkeää jätettäväksi vain ammattitestaajille, testausosaamista tarvitaan osana monia rooleja. Monet erinomaiset testaajat ovat päätoimeltaan liiketoiminta-asiantuntijoita tai ohjelmistokehittäjiä. On myös erinomaisia ammattitestaajia, jotka kokevat testauksen päätoimenaan. Tilannetekijäohjatun testauksen keskiössä on tietotyötä tekevä, aktiivinen, osaava ja oppiva testaaja.

Tilannetekijäohjatun testauksen keskeinen viesti on testausta tekevän henkilön – testaajan – osaamisen nostaminen keskiöön tuloksellisuutta tavoitellessa. Kaikki käytännöt ja niiden soveltuvuus perustuu tilannetekijöihin, joiden puitteissa käytäntö on hyödyllinen. Osaavan tekijän tulee tietää kuinka keksiä, arvioida, kritisoida ja mukauttaa käytäntöjä, eikä vain tietää niiden olemassaolosta. Sen sijaan että valitaan tapa testata joukosta kopioitavia ja muistettavia käytäntöjä, tarvitaan syvempää osaamista, joka kehittyy osana työtä – jokainen aktiivisen oppimisen päivä parantaa taitoja.

Tilannetekijäohjattu testaus on tapa korostaa testausta tietotyönä eikä vähätellä osaamisen roolia yksinkertaistaen tekeminen yksityiskohtaisiksi ohjeiksi siitä kuinka testaaja tekee työnsä, kiinnittäen huomiota enemmän siihen mitä tulee saada aikaan. Tilannetekijäohjatun testauksen puitteissa uskotaan, että testaajat ovat, ja heidän täytyy olla, älykkäitä ja ajattelevia yksilöitä, joihin voi ja pitää luottaa sen osalta, että osataan selvittää, miten testataan suhteessa tavoiteltuun tulokseen. Osaamisen tavoite kehittää osaamista.

Ihmiset eivät ole vaihdettavissa olevia koneen osia, vaan osaamiset vaihtelevat. Ihmisten osaamisen kehittäminen on tärkeää, jotta voimme organisaatioissamme tehdä tärkeitä asioita vaikka samat ihmiset eivät ole saatavilla. Emme ole robotteja emmekä orjia, olemme vastuussa työstämme, sen laadusta ja seurauksista. Vastaamme omasta ajankäytöstämme ja osaamisestamme sekä rohkeudesta tuoda oma panoksemme työhön. Emme toimi yksin, vaan yhdessä muiden kanssa sosiaalisessa verkostossa, jossa vastuita jaetaan ja joissa arvo syntyy.

Hyviä tuloksia ei saavuteta toistamalla edellisessä organisaatiossa opittuja temppuja toisenlaisessa organisaatiossa, vaan testaajan pitää ajatella organisaation ja tilanteen erityispiirteitä. Tilanteen tunnistamisen tärkeys korostuu, kun siirtyy organisaatiosta toiseen, esimerkiksi testauskonsultin roolissa. Yhtäällä hyvä testaus voi olla liian kallista tai puutteellisia tuloksia tuottavaa toisaalla.

Testaajan on hyvä tuntea erilaisia käytäntöjä. Teoriatieto ei kuitenkaan ole osaamista. Osaaminen on eri asia kuin tietämys, osaamisessa on käytännön soveltamisen piirteitä ja syvempää ymmärrystä. Teorian soveltaminen käytännössä muuttaa teoriaa osaamiseksi. On kuitenkin mietittävä, voisiko saman asian tehdä jollain toisella tapaa, tehokkaammin.

Reunaehtojen puitteissa toimiminen

Tilannetekijäohjattu testaus on sitä, että teemme parhaamme sillä, mitä meillä on käytettävissämme. Testaus tapahtuu tarjolla olevilla reunaehdoilla, esim. vaatimusdokumentaatio tai testaustiimin kokoonpano. Reunaehtoja voidaan muuttaa, mutta myös tehdä parasta mahdollista työtä tarjolla olevan puitteissa. Testauksen arvon määritellään kykynä tuottaa hyödyllistä tietoa ohjelmiston laadusta oikeaan aikaan.

Tilannetekijäohjatut testaajat valitsevat testauksen tavoitteet, tekniikat ja tuotokset (sisältäen testausdokumentaation) ensisijaisesti tarkastellen tilanteen yksityiskohtia, sisältäen testauksen tilanneiden sidosryhmien toiveet. Tilannetekijäohjatun testauksen ydin on osaamisen ja harkinnan käyttö projektiin sopivalla tavalla.

Tietotyössä on tärkeää kehittää lopputulosta – ohjelmiston ja testauksen laatua – mutta yhtä lailla keinoja jolla lopputulokseen päästään. Toimivien käytäntöjen lähtökohdista pyritään innovoiden parempaan. Ohjelmistokehityksessä toimitaan epävarmuuksien kanssa, eikä aina voida tietää mikä sopii tai toimii. Meidän on kokeiltava, joskus epäonnistuen kokeilussa ja siitä oppien. Tärkeää on valmius oppia ja muuttaa toimintaa.

Tieteelliset kriteerit toimiville testaustavoille

Tilannetekijäohjatun testauksen puitteissa katsotaan, että ei ole oikein ohittaa todistusaineistoa tilanteesta ja tehdä valintoja ilman empiriaa. Tilannetekijät tulevat ensin. Valitessamme toimintatavan ensin, etsimme helposti vahvistavaa todistusaineistoa ja ohitamme kumoavan todistusaineiston. Teemme työtä alueella, jota ei voida lineaarisesti ennustaa. Olisi vastuutonta tehdä työtä tavoilla, jotka eivät perustu todellisuuteen projekteissa.

Testauksen toimivien käytäntöjen opettamiseen sovelletaan tieteen  tekemisen kriteerejä. Ei yleistetä asioita,jotka eivät ole yleistettävissä. Kansantiede kontekstista irrotettuna ei ole arvossa pidettävän ammattikunnan perusta. Työmme testaajina perustuu todistusaineistoon ja emme voi vaatia vähempää todistusaineistoa menetelmiltä ja käytännöiltä kuin tuloksiltamme.

Käytännön kokemusten jakaminen ja niistä keskusteleminen on tärkeää. Keskusteleminen tuo esiin oleellisia tilannetekijöitä, ja auttavat levittämään hyviä käytäntöjä soveltuviin tilanteisiin tilannetekijöiden syvemmän ymmärryksen kautta.

Käytäntöjen vertailussa viitekehyksenä usein toimii panos-tuotto -analyysi. Panoksissa kustannukset tulkitaan laajasti, sisältäen myös vaihtoehtoiskustannuksen – mitä arvokkaampaa käytetyllä ajalla toisilla valinnoilla olisi voitu saavuttaa? Tarkasteleminen ohjelmistokehityksen kokonaisuuden osalta testauksen osaoptimoinnin sijaan on tärkeää, testaus on aina osa suurempaa kokonaisuutta.

Historia ja lisätiedot

Tilannetekijäohjatun testauksen lähestymistapa on nimetty 21.11.1999 ryhmässä, johon kuuluvat Cem Kaner, Brian Marick, James Bach ja Bret Pettichord. Lähestymistapa oli pohjana Kaner-Bach-Pettichord -kolmikon vuonna 2001 julkaisemassa kirjassa Lessons Learned in Software Testing, joka kuvaa kokoelman tarinoita erilaisista valinnoista.

Tilannetekijäohjatun testauksen yhteisö näkyy kahtena kansainvälisenä yhdistyksenä:

  • AST – Association for Software Testing (http://www.associationforsoftwaretesting.org/)  toimii Amerikasta käsin ja tunnetaan erityisesti Black-Box Software Testing -kurssisarjan edistäjänä. AST järjestää mainiota CAST-konferenssia.

  • ISST – International Society for Software Testing (http://www.commonsensetesting.org/) toimii Euroopasta käsin ja tähtää erityisesti tilannetekijäohjatun testauksen tunnettuvuuden nostamiseen päätöksentekijöiden keskuudessa. ISST  on mukana järjestämässä Let’s Test -konferenssia ja tarjoaa jäsenistölleen säännöllisiä webinaareja.

Me omalta osaltamme haluamme toimia paikallisesti – Suomessa ja suomen kielellä – testausosaamisen edistämisen asialla. Kysy lisää ja osallistu keskusteluun kommentoimalla artikkelia näillä sivuilla.