Auvoisa automaatio
Nurmikko vihersi ensimmäisen hallayön jälkeen aamukasteesta raikkaana ja aurinko oli jo noussut pilvettömän horisontin ylle. Hörppäilin aamukahvia terassillani ja kuuntelin, kuinka linnut vielä lauloivat lähimetsässä. Rauhallisen lauantaiaamun rikkoi hento, suriseva ääni, joka vahvistui tasaisesti. Tunnistin toki äänen, sillä olinhan joutunut jo useamman kerran kuuntelemaan samaa, naapurin uudesta robottiruohonleikkurista tulevaa ääntä.
Jotain oli tällä kerralla kuitenkin pielessä. Näin kuinka leikkuri suuntasi suoraan pihan keskellä olevaan omenapuuhun. Törmäys oli välttämätön. Rimpuilustaan huolimatta, tämä puutarhatekniikan taidonnäyte jäi lopulta kiinni puun juurakkoon, eikä päässyt enää omin neuvoin irti. Naapurini oli sopivasti reissun päällä, joten kävin ystävällisesti irrottamassa robotin ja jatkoin aamukahvin parissa. Pohdin syvällisiä. Jopa filosofisia.
Entäpä jos tuo nurmikko olisi voinut edustaa testisettiä, ja jokainen heinä olisi ollut testitapaus. Automaatti niittää testitapauksia ihan rauhassa ja kaikki näyttää menevän hyvin, kunnes jotain ennalta arvaamatonta tapahtuu. Hyvin usein automaatti ei itse tokene virheestä. Se vaatii aina ihmisen väliintulon. Varsin yleinen harhakäsitys on, että automaatti voi korvata ihmisen. Siksi usein kuvitellaan, että testausautomaatio tarkoittaa myös halpaa testausta.
Mitä hyötyä automaatiotestauksesta sitten on? Toki viisi työntekijää leikkaisi saman nurmikon huomattavasti nopeammin kuin robotti. Hankkimalla robotin, voidaan kuitenkin vapauttaa nämä viisi henkilöä tekemään jotain tärkeämpää. Sillä aikaa he voivat esimerkiksi parantaa nurmikentän kattavuutta ja kitkeä rikkaruohot.
Kun ominaisuus on kerran todettu toimivaksi, komennetaan robotti huolehtimaan siitä, että se ei enää mene huomaamatta rikki.
Oikein käytettynä automaatio on erinomainen apuväline, joka vapauttaa testaajan kädet niihin todella olennaisiin töihin! Anna siis automaatin tarkistaa ja ammattilaisen testata.
Suosittelemme myös:
Oivalluksellakin on hintansa
Jos kysymys ei ole uskomattomasta munkista, mäihästä tai tuurista, niin onnistumisilla on aina hintansa. Hinta on mahdollista maksaa etukäteen ja...
Mielenterveys on työtäni
Hämmästynyt katse seuraa lähes poikkeuksetta kun vastaan siihen yhteen kysymykseen. Mitäs sinä teet Antti? Tai mitäs tuo teidän yritys...
Tämä lause on briliantti: ”Anna siis automaatin tarkistaa ja ammattilaisen testata.”. Kyllä minä tuon tiesin, mutta en ollut asiaa pukenut koskaan noin älykkääksi lauseeksi. Joka päivä sitä näköjään saa uutta perspektiiviä näihin testausasioihin. 🙂
Tässä kerrottiin, missä automaatio menee pieleen. Missä automaatio sitten onnistuu? Onko olemassa paikkoja, missä testaaja henkilönä on niin heikoilla, että automaatio tarvitaan pelastamaan henkilö pinteestä? Milloin tulee tilanne, josta *testaaja* ei tokene? Kuka irroittaa testaajan jalat juurrakosta tai mutakuopasta?
Kuten tuossa loppulauseessa sanoit, niin automaatio on maanmainiota tarkistamiseen. Eikös joissakin yrityksissä automaatiota käytetä kuitenkin myös testaamiseen? Miten se heillä toimii, jos he eivät ole sysänneet sitä syrjään?
Automaatio voi myös olla eräänlainen motivaattori. Kun me teemme automaatiota, skriptaamme, konffaamme, rakennamme semaforiratkaisujaketjuttamiseen, jne., me todellisuudessa tutkimme järjestelmää, miten se voisi helpoiten automatisoida?
Itse olen järkkymätön älykkään testauksen lipunkantaja: Testaus ja tarkistaminen pitää osata erottaa. Toki myös testaajat tarkistavat, mutta onko se ajanhukkaa, jos kone voi tarkistaa sen myös? Kyse on älykkäästä tasapainosta, jossa manuaalinen ja koneilla avustettu testaaminen suoritetaan älykkäästi, ja koneistettu tarkistaminen myös älykkäästi. Se, miten määritellään älykäs toimintamalli riippuu kontekstista ja vaatii paneutumista moniin ohjelmistotestauksen haaroihin ja kerroksiin.
Kuten tekstissä kerroin, automaatti onnistuu tarkistamisessa. Tai jos se halutaan testaukseksi kääntää, niin regressiotestauksessa. Olet Pekka oikeassa siinä, että en kattanut kaikkia mahdollisia alueita joissa automaatiotestausta voidaan käyttää, kuten esimerkiksi suorituskykytestaus. On totta, että testaaja olisi pulassa, jos meillä ei olisi apuvälineitä performassitestaukseen.
Jutun pointti oli tässä kuitenkin se, että älä korvaa älykästä tutkivaa testausta automaatiotestauksella säästöjen toivossa. Se kostautuu varmasti jossain vaiheessa laadun heikkoudella, ja se maksaa muussakin kuin vain rahassa.
Oletetaan tilanne, jossa testaajan jalat todellisuudessa ovat mutakuopassa. Anna hänelle lapio ja ei kestää kauaakaan, niin testaaja on vapaana. Mutaan juuttuneelle robotille on turha antaa lapiota, sillä tuskin se tietää mikä lapio on, mikäli sitä ei ole robottiin ohjelmoitu.
Tässä on kyse siitä, miten automaatiota käytämme. Jos suoritamme kehitysvaiheessa tapahtuvan tutkivan testauksen automaation kautta, on se huomattavasti hitaampaa, skriptejä joutuu kokoajan muokkaamaan, ja testaus on ”tunteetonta”. Toki siinä syntyy automaatioskriptit samalla, mutta mielestäni sen hinta on liian korkea. Kuvitellaan, että istun vaimoni kanssa häälounaalla ja kaikki keskustelu tapahtuu tekstiviesteillä, muistan kyllä vuosia jälkeenpäin mistä keskusteltiin, mutta aivan varmasti keskutelu oli suppea, eikä siinä ollut tunnetta mukana ollenkaan. Eikä vaimokaan siitä pitäisi.
Toistan loppukaneetin (hieman muuttaen): Anna ammattitestaajan testata softasi kuntoon tutkivalla testauksella, vasta sen jälkeen automaatti hoitaa jatkuvan tarkistamisen regression välttämiseksi. En tarkoita että softan tulee olla kokonaan valmis, voit automatisoida esimerkiksi sprinteissä testattuja, toimivaksi testattuja komponentteja tai kokonaisuuksia. Niin ja se performanssi ja muu NFT, vanhaa sananlaskua lainaten; muista että automaatti on todella hyvä renki, mutta huono isäntä.
Edelliseen kommenttiin liittyen: kun vilkuilee laajemmin testauskirjallisuutta läpi siitä että mitä regressiotestaus itse asiassa onkaan, voi olla perustellusti sitä mieltä että automaatti ei onnistu regressiotestaamisessakaan. Se onnistuu toistamaan tarkalleen samoja asioita, mutta regressiotestauksen keskeinen juju lienee kuitenkin regressioriski, ei vain se että aikaisempia nappeja juuri samalla tapaa voi painaa.
Edellisessä toimivassa ohjelmistoversiossa on voinut olla paljonkin toimintoja ketjuissa, joita ei ole testattu lainkaan. Ne toimivat, vaikkei toteuttaja eikä erillinen testaaja tullut ohjelmistoprojektia tehdessä kertaakaan niitä käyttäneeksi, eikä edes tiedostanut ettei käyttänyt. Sen sijaan käyttäjä saattoi hyvinkin osua juuri tähän kohtaan, kerta toisensa jälkeen ja se toimi – pitkään ja hartaasti. Kunnes regressioriski sivuvaikutuksesta jollekin muutokselle realisoitui.
Vaikka paljon automaatiossa hyvää onkin, yksi heikoimpia asioita joita automaation edistämiselle voi tehdä on valjastaa se niin yksipuoleiseen testaukseen kuin yleisin regressiotestauksen tulkinta samoista askeleista kerta toisensa jälkeen voi tuottaa.
Automaatiolla tuettu tutkiva testaus XML-rajapinnassa on täysipäisenä pysyvän testaajan perusedellytyksiä. Automaatio ja tutkiva testaus kuuluvat samaan lauseeseen.
No kyllä. Eräässä projektissa käytimme automaatiota juurikin siten, että automaatti hinkkasi samoja yksinkertaisia tapauksia läpi yötä päivää ja tällä varmistimme sen, että tuotteen perusta pysyy kunnossa. Tässä työssä automaatti oli loistava. Se ei valittanut (joskus tosin vaati säätöä), se ei pitänyt taukoa ja se ilmoitti viiveettä jos jokin perustoimista oli mennyt rikki. Tämän voi mieltää yhdeksi regressiotestaamisen osaksi, mutta me emme sitä sillä nimellä kutsuneet. Regressiotestit tehtiin aina käsin tutkivalla menetelmällä ammattitestaajien toimesta.
Automaatiojärjestelmän rakentaminen ja ylläpito työllistävät helposti yhden henkilön täysipäiväisesti ja jopa enemmänkin. Mainitsemassani projektissa tilanne oli juurikin tämä. Automaatin tuoma jatkuva informaatio tuotteen peruskunnosta koettiin kuitenkin siihen käytetyn rahan arvoiseksi.