Viksumman testaamisen hidasteita asiakas-toimittajamaailmassa

Olen viime aikoina miettinyt varsin paljon taas tutkivaa testausta, asiakas-toimittajaprojektien näkökulmasta. Matkalla voi olla muutamia hidasteita:

- suunnittelun ja testaamisen erilainen hinnoittelu. Jos sattuu olemaan tilanne, jossa testaustyötä hinnoitellaan eri lailla riippuen sen vaativuudesta ja on luokiteltu, että suunnittelu on vaativaa ja testaaminen ei, tiessä on kyllä pieni kuoppa. Osittain tämä luokittelu kerjää sitä että tehtävät annetaan eri henkilöille, osittain sitä että valmistaudutaan mahdollisimman paljon, jopa yli sen hyödyllisen ja oikeasti tarpeellisen. Erityisesti haasteelliseksi muodostuu se että haluaisin sen halvemmalla hinnalla tehtävän työn sisältävän merkittävässä määrin nk. kalliimman hinnan töitä. Oikeasti noissa tilanteissa kyllä sanotaan että 100 tuntia testaukseen liittyvää työtä olisi keskimäärin jotain kahden hinnan väliltä.

- vaatimukset. Elisabeth Hendricksonilla oli jossain esityksessään oivaltava kommentti siitä, että lähes jokainen bugi on lopulta - toteuttajansa näkökulmasta - muutos vaatimuksiin. Jos ei ole ajateltu yllättävää vuorovaikutusta käyttöliittymän kanssa, vääränlaista syötettä naapuriohjelmalta tai että joku voisi joskus käydä kahvilla kesken tekemisen ja ohjelma ei tässä tilanteessa toimi, onhan se jollain tapaa perusteltua sanoa, että pyydetään uusia asioita. Mitä tarkempaan vaatimusdetaljiin mennään - jopa pseudokoodaukseen - sitä sidotummaksi suhteessa vaatimuksiin muuttuvat myös testaajan kädet.

- suojautumistarve. Varsin monesti sopimukseen ja projektisuunnitelmiin on osattu kirjata, että testit toimitetaan ennakkoon, ja toimittaja varaa luonnollisesti itsekin aikaa varmistaakseen, että luovutuksen tai hyväksynnän testit läpäistään. Se on paljon helpompaa toimittajan näkökulmassa, jos kerrotaan mahdollisimman täsmällisesti mitä aiotaan kokeilla ja miten. Niinpä asiakkaita tulee helposti ohjattu pois tutkivasta testauksesta, enemmän ennakkoon kirjattuun tyyliin.

- ajoitukset. Kun jostain on sovittu hankinnan alkuun, tuntuu että muuttaminen on tuskallista. Prosesseja pitäisi kehittää projektien ulkopuolella, erillisissä projekteissa, etteivät sotkisi tämän suunnitelmia ja työmääriä. Ja kun testausta tupataan valmistelemaan vasta kun projektin puitteet muuten on sovittu, aika on harvoin suoraan oikea.

Hidasteita, ei esteitä. Taidan alkaa miettiä seuraavaksi hyväksymistestausprosessia, ja siihen rakenteita, jotka sallivat ja tukevat fiksua testaamista.

Hyväksymistestauksen dokumentaation jakaminen toimittajalle

Keväällä IIR:n seminaarissa muutamassakin puheenvuorossa pohdittiin hyväksymistestauspuheenvuorojen osalta periaatetta dokumentaation jakelussa toimittajalle.

Testitapausten osalta silloin taisi vallitseva käsitys olla, että parempi olla antamatta. Syyt olivat kaiketi:
- Huoli siitä että toimittaja testaa vain näillä testeillä ja kokonaisuutena saadaan huonompaa laatua
- Riippuvuudet asiakkaan materiaaleihin aikataulullisesti sovittuina aiheuttavat tarpeettomia paineita asiakaspäässä materiaalin viimeistelyyn
- Asiakkaan materiaalin odottaminen antaa epävirallisen luvan luovuttaa oman testauksen valmistelun yrityksen kanssa ja vähentää vastuunottoa

Testitapausten osalta olen edelleen eri mieltä. Minusta ne kannattaa antaa. Parempi että edes ne toimivat, kuin että viimeisen hyväksymistestin aikana tarvitsee niistäkin huomata etteivät toimi. Kun lähtökohtaisesti lähtee siitä että testi ei ole äärimmäisen toistettava vaan lähinnä muistilistan omainen, näkisin että riskiä siitä että toimittaja kuvittelee vastuun testisuunnittelusta siirtyneen asiakaspäähän olisi hallittavissa. Ja korostetusti kannattaa varata oikeus ja mahdollisuus tutkivaan testaukseen, joka vielä entisestään täydentää suunniteltua kokonaisuutta.

Testaussuunnitelmat ovat minusta paljon haastavampi kysymys. Erityisesti nykymaailmassa missä lähestulkoon järjestelmä kuin järjestelmä koostuu eri tekijöiden osista, en aina ole ihan vakuuttunut että haluaisin avata kaikille osapuolille kaikki näkökulmat riskeihin, mitä osana hyväksymistestausta pitää pohtia. Jotkut asiat kun ovat vaan meidän organisaatiolle. Ja ainakaan minua ei kiinnosta tästä syystä että kirjaan suunnitelmaani nk. arkaluonteisia asioita ja arvioita pohjana riskiarvioilleni, kirjoittaa toista "siistittyä" suunnitelmaa. Sen osalta minusta saa riittää, että testaamme. Jos siinä on jotain minkä kertominen auttaa viestintää, pidän aiheesta mielellään silmäkkäin session. Ja sekin on tietysti lähestulkoon aina.

Paljonko testauksen pitää tuottaa hyötyä?

Vuodet testaushommissa ovat opettaneet, että testaajan tuottama lisäarvo ei ole lainkaan niin suoraviivaista, että testitapausten suunnittelun, suorituksen tai virhemäärien mittaamisella saataisiin kiinni sen tuottamasta arvosta. Testausnäkökulmalla ja testauksella on arvoa, se on hyödyllistä - usein.

Tämä ei kuitenkaan ole itsestäänselvyys. Olen aistivinani että testaus on tullut muotiin erityisesti asiakas-toimittajasuhteissa jopa siinä määrin, että koen että näissä tilanteissa vastaan on osunut kohtia, joissa testausotsikon alla tehty työ ei ehkä tuotakaan kovasti lisäarvoa.

Jos testauksessa käytetään varsin mittava työmäärä, tuotetaan kertakäyttötestitapauksia ko. projektin näkökulmaan ja katselmoidaan niitä suurella panoksella ja lopulta ei juurikaan löydetä ongelmia, voi minusta jo perustellusti miettiä että olikohan panokset oikein asetetut. Etenkin, jos jälkeen tulevat testausvaiheet osoittavat, että löydettävää kuitenkin olisi ollut.

Jos kohdalle osuu projekti, jonka osalta on perusteltua sanoa ettei se testaamalla juurikaan parane erilaisten reunaehtojen vuoksi, onko enää järkevää suositella että kuitenkin testaukseen panostetaan, ja vielä suuremmassa määrin. Vai voisiko testausihminen suositella jopa testaajien poistamista ja muiden ratkaisijoiden lisäämistä? Voisiko otos olla kattavuutta parempi tavoite hyötyjä ajatellen?

Välillä jää sellainen fiilis kaivertamaan, että erityisesti testauspalveluja tarjoavat osaoptimoivat testauksen, eivätkä ajattele testausta osana arvoketjua. Samoja tavoitteita voisi edistää halvemmilla ja tehokkaammilla keinoilla. Vai onko testausasiantuntijan kädet tosiaan niin sidottu ettei lähimaailmaa saa nytkäytettyä lähemmäs raiteita? En usko.

Me ollaan testaajia kaikki

Jossain verkossa surffaillessani GoogleAds päätti näyttää minulle kohdistetusti mainoksen, jossa Reaktor etsi "koodaavaa pääarkkitehtiä". Paikka ei ole kyllä missään määrin minulle kohdistettu, mutta termiin liittyvä teema sattui olemaan testauspuolelta juuri pohdiskelun alla.

Jos mietitään karkeasti ohjelmistokehityksen rooleja, niitä olisi kaiketi kolme: vaatimuskaveri, toteutuskaveri ja testauskaveri. Näistä kuka vaan voisi nk. edetä urallaan hallintovaihteelle ja ryhtyä vaikka projektipäälliköksi. Toteutuskaverista tulee kuitenkin omalla vaihteellaan edetessään arkkitehti, ja testauskaverista testauspäällikkö.

Erityisesti olen ihmetellyt viime aikoina sitä, että toteuttaja joka pomppaa projektipäälliköksi ei yleensä enää kuvaa itseään koodaajana. Testaaja joka siirtyy testauspäälliköksi on hyvinkin vahvasti edelleen testaaja. Erityisesti tämä jäi minua mietityttämään sen vuoksi, että olen ollut huomaavinani, että varsin monet testausasiantuntijat eivät olekaan henkilökohtaisesti vuosikausiin testanneet. Toiset, kuten minä, testaavat kepoisasti silloin tällöin, nauttien pinnallisista mutta silti korjauskelpoisista virheistä joita rajatussa ajassa voi löytää. Koen tiettyä tuskaa, kun niin suuri osa ajasta kuluu ohjatessa, neuvotellessa, mittareita kehitellessä ja nauttien katsoessa kun toiset tekevät rakastamaani työtä hyvin. Kai se on jonkinasteista kateutta. :)

Olen vakuuttunut, että testaus on sekä taito että ajatusmalli. Taito katoaa jos työtä ei harjoita. Ajatusmalli säilyy. Taitopuolella etääntyminen on liian helppoa, kuvaten työtä edelleen kuitenkin samalla sanalla - me ollaan testaajia kaikki, nekin meistä jotka eivät ehdi muilta testaustöiltään testaamaan.

Testauksen opettaminen - onko kaikki vaan peruskursseja?

Tieturin testausseminaarissa Tieturin testauskouluttaja Teppo Heikurinen kertoi puheenvuorossaan testaajien erilaisista profiileista ja tarpeista. Osana puheenvuoroaan Teppo esitti myös varsin vahvan väitteen siitä että kaikki testauskoulutus Suomessa on vain peruskursseja, joka luonnollisesti särähti omaan testauskouluttajakorvaani. Mitä ovat perusasiat ja mikä on edistyneempää testauksessa.

James Bach on mielestäni upeasti kuvannut suuren osan testauskurssisisällöistä termillä "testing folklore" - testauksen kansantiedettä. Kerromme kursseilla tarinoita testauksesta, opimmekin tarinoiden perusteella. Itse näkisin että opimme sekä perusasioita, että syvemmälle meneviä.

Toinen suuntaus testauskursseissa on sitten yritys opettaa testaamaan, eikä vain sujuvasti puhumaan testauksesta. Tässä suuntauksessa yleensä lähdetään siitä että testaus ei tapahtu paperiopetuksella, vaan testaukselle tarvitaan asennettu kohde. Ja niiltä osin kuin opetus tapahtuu luokkahuoneessa ilman konetta, harjoituspainotteisuus kuvista ja teksteistä analysoiden on vahvoilla.

Mikä on siis peruskurssi? Mitä ovat "testauksen perusteet"? Uskoisin pääseväni ISTQB-sertifikaattia syvemmälle, ja tuntuu pahalta ajatella että koulutan 20 päivää perusteita silti asioita suuressa määrin toistamatta. Niinkin toki voi olla.

Luin Cem Kanerin materiaalia tutkivasta testausautomaatiosta (exploratory test automation). Materiaalissa johdantona oli erinomainen jäsennys siitä että lähtien taidottomasta, edeten pikkukikkojen kautta tuottavaan ja lopulta oikeasti testausta osaavaan vaatii aikalailla erilaista koulutusta. Suhteessa tähän tunnustan: opetukseni taso on edelleen pikkukikkojen (quicktests, techniques) tasolla. Kuten Cem Kaner asian muotoili: "There are generically useful approaches to test design, like quicktests and tours and other basic techniques, but I think we add our greatest value when we apply a deeper understanding of the application. Testing instructors don’t teach this well because it takes so long to build a classroom-wide understanding of an application that is complex enough to be interesting."

Perusteissa siis mennään. Ja perusteissakin on eroja. :)

Oppeja testitapauksia vastaan

Olin viime vuonna lukenut nopeasti James Bachin esitysmateriaalin testitapauksia vastaan, ja eksyin siihen enemmän ajatuksella siivotessani kirjanmerkkejäni. Alkuperäisteos jota jäin pohtimaan löytyy täältä:
http://www.satisfice.com/presentations/againsttestcases.pdf

Erityisen viehättävä osa materiaalissa oli testauspandemiasanaleikit, 3 * OCD:
- Obsessive Case Disorder. Pakonomainen tarve uskoa ja antaa muiden uskoa että testitapausten suunnittelu on niin keskeinen aktiviteetti, että se sisältää kaiken testausajattelun ja suoritus on sitten mekaanista. Yleensähän annamme uskoa, kun ei vaan joka kerta jaksa selittää. On helpompaa sanoa että aikaa on varattava testitapausten suunnittelulle, eikä koittaa selittää että aikaa on itse asiassa varattava siihen että ehditään perehtyä vaatimusdokumentaatioon kirjattuihin lupauksiin ja olettamiin.
- Obsessive Counting Disorder. Pakonomainen tarve laskea testitapauksia, joiden laskemisella ei oikeasti ole niin suurta merkitystä. Pieni määrä ei korreloi huonon testauksen kanssa. Mutta, itse ainakin taas tänään totesin, että testitapausten laskeminen suhteessa jonkinlaiseen ideaan kattavuuskriteeristä antaa edes jonkinlaisen tuntuman siihen minkä verran lisää pitäisi vielä suunnitella / kirjata. Tarpeellista ja hyödyllistä tällä tasolla vain kun ei ole oikein vakuuttunut tekemisen otteesta muutenkaan.
- Overspecified Cases Disease. Epäjohdonmukainen pakkomielle kohdella ihmisiä automaatiorobotteina aivan liian tarkan dokumentaation myötä. Muodostuu usein sitten myös itseään toteuttavaksi ennusteeksi, suunnittelu oli jonkun muun nakki ja minä vaan kliksuttelen ja katson mitä käskettiin...

Pandemia - maailmanlaajuinen vitsaus - sinänsä ainakin minulle kolkuttelee jotain tosi tuttua...

Erinomaisia korostuksia myös siitä miksi testitapausten lukumäärään pitäisi aina suhtautua varauksella:
- eri suoritusaika muuttaa testitapausta: jos samaa asiaa katsoo kolmatta kertaa, ei varmasti tee samaa testiä, saattaa tehdä suppeampaa tai laajempaa
- testien suunnittelu on subjektiivista: vaikka sovittaisiin yhteinen muoto ja määrä, silti on vaihtelua, koska testauksen kohteet ovat erilaisia
- testaajat eivät edes noudata testitapauksia: monestihan testitapauksia kuittaillaan suoritetuksi sitten kun "tähän liittyvät vapaat tarkastelut on ehkä jo riittävässä määrin tehty". Olen joskus itsekin ihmetellyt kun viiden minuutin tarkistus kesti testaajalla kaksi viikkoa, ympärillä oli vaan aika monta asiaa jotka tähän tehtävään piti mahduttaa.
- sama testi automaation ja ihmisen suorittamana ei ole sama testi. Ihmisen päässä tapahtuu asioita joita ei voida siirtää automaatioon, mutta joskus se ei haittaa - jos se vain tiedostetaan.

Itse kirjoitan testitapauksia, periaatteella muistilistaa testattavien asioiden monipuolisuudesta. Minua vaivaa ainakin aika vahvasti tuo OCD v.2 jossa lasketaan asioita, mutta laskemisesta haen puitteita enkä absoluuttista totuutta. Ja tilanteesta riippuen tulisi laskettua vähän eri asioita, riippuen paljolti siitä mitä voi laskea puitteiden vuoksi. Testitapaukset on helpoimmasta päästä laskettavia asioita testauksessa.

Kohtuulliset odotukset testaustoimittajalle

Tehtyäni takinkäännön - edelleen uskollisena testaukselle - ohjelmistotuoteliiketoiminnasta omiin räätälöitäviin tilaustyönä hankittaviin järjestelmiin, olen jäänyt monesti pohtimaan odotuksia kohtuulliselle testaukselle.

Päivän listani on asioita jotka ovat minusta kovin kohtuullisia, mutta jättävät silti miettimään:

- Testaaminen asiakasnäkökulmasta
Tuoteliiketoiminnassa oli selvää, että järjestelmätestausporukka epäonnistuu pahasti, jos hyvin tehdyt vaatimusmäärittelyt otetaan liian kirjaimellisesti, eikä edes koiteta merkittävässä määrin huomioida asiakkaan / käyttäjän hiljaisia vaatimuksia sekä kaikkea sitä teknistä nippelinappelitietoa, joka voi jäädä vaatimusten ja määrittelyjen väliin. Räätälöitävien järjestelmien peruselementti tuntuisi olevan "vaatimusmäärittely" joka kuvaa tilatun järjestelmän, jota tarkennetaan ja jonka rivien väliin jääneet yksityiskohdat ovat aina muutospyyntöjä. Ja eivät löydy toimittajan testauksissa. Niinpä asiakkaan testaajien ja toimittajan testaajien välillä on kuilu, joka korostuu kahdenlaisessa hyväksymistestauksessa: on aivan eri asia suorittaa sopimushyväksymistestausta kuin tuotantoonhyväksymistestausta - valitettavasti.

- Näkyvyys ja raportointi projektiin testauksen kautta
Tuoteliiketoiminnassa tuntui varsin selkeältä katsoa tehtävää testausta kokonaisuutena mittarein. Työmäärän kulumisen lisäksi kiinnosti testauksella saatu lisäarvo, niin kattavuuden kuin tulostenkin osalta. Räätälöityjen maailmassa en pidä itsestään selvänä että testauksesta saisi mitään muuta raporttia kuin että budjetoidut tunnit nyt tuli käytettyä. Aiemmassa elämässä tästä minulla onkin ollut tosi ikäviä kokemuksia, ja toivon että ne kokemukset eivät päätyisi värittämään tulevaisuutta toistuvin kaavoin.

- Mallipohjan täyttäminen ajatuksella
Kun testaussuunnitelmassa pitää miettiä mallipohjan ohjauksella jotain, sitä jotenkin ajattelisi ja kuvittelisi että viime kädessä sisällöllä on merkitystä. Muoto on tärkeä kun luetaan rutiininomaisesti toistuvia suunnitelmia ja halutaan katsoa vastaavat teemat vastaavassa järjestyksessä, mutta silloinkin hyvän ja heikon suunnitelman erottaa ajattelu ja asioiden huomioiminen eikä vaan vakioliturgian kirjaaminen.

- Riskienhallinta - testauksen edellytykset voivat olla projektin tuho
Tuoteliiketoiminnan jälkeen on vaikeaa myös nähdä syitä siihen että testauksen on arvostussyistä oltava oma organisaationosansa tai että testaus pitää ehdottomasti projektoida omana kokonaisuutenaan, että saadaan kertoa realistista tilannetta kokeilluista ja ei-toimivista asioista. Minua ei henkilökohtaisesti yhtään lohduta että olin oikeassa kun sanoin että testaus voi voi tapahtua kahdessa viikossa jos testausympäristö ei toimi, jos siinä vaiheessa projekti on myöhässä eikä ole tullut edes ehdotettua vaihtoehtoista jonkinasteista lisäkustannusta toipumissuunnitelmaksi niille keskeisimmille riskeille.

Listan viimeistä pidän jo vähän edistyneempänä kamana, mutta muita ihan peruskaurana. Saas nähdä miten mieli vielä muuttuu...