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