Testauksen automatisointiko mullistaisi it-alan?
Tietoviikon tammikuussa julkaisemassa artikkelissa puhutaan testauksen automatisoinnista ja it-alan muuttuvasta ilmapiiristä. Avasin artikkelin kiinnostuneena, mutta aivoni jäivät lyömään tyhjää heti ensimmäisen lauseen kohdalla:
Ohjelmistotestaajan työ ja koko testaaminen ovat muuttumassa.
Testauksen perimmäisenä tarkoituksena on nostaa esille ne virhekohdat tuotteesta, jotka haittaavat loppukäyttäjän käyttökokemusta. Vaikka testaaminen saattaisi lisääntyä tuotteiden monimutkaistuessa, testauksen tarkoitus ei muutu mihinkään. Onko siis tarkoituksenmukaista ajaa ohjelmistotestaajan työtä ja koko testaamista muutoksen tielle?
Tietoviikon artikkelin lisäksi useasta lähteestä kuulee nykyään samaa raitaa missä lauletaan, että pitäisi panostaa enemmän testauksen automatisointiin. Joillekin automatisointi tuntuu olevan uuden testamentin veroinen ohjenuora työelämän pitkospuille. Sen nimeen vannotaan ja siihen panostetaan aina vain enemmän ja enemmän. Liekköhän tässä ollaan muutoksen tiellä ohituskaistalla vai ajamassa rampilta alas hitaaseen ja tukkoiseen taajamaan…
Vaikka testauksen automatisointi kannattaakin tietyissä tilanteissa, mielestäni testauksen automatisoinnin yhteydessä ei voi puhua testauksesta. Kun testaustyö automatisoidaan, kyseessä on enää vain koneellinen tarkistus. Testauksen ja koneellisen tarkistuksen välillä on hurja ero. Niin pitkään kuin tuotteiden loppukäyttäjinä ovat ihmiset, ei varsinaista testausta kannata korvata koneellisesti. Koneet löytävät pieniä ja teknisiä nippelivirheitä, kun taas ihmiset löytävät fiilispohjaisia virheitä. Väitän, että olennainen osa virheistä löytyy jälkimmäisellä tavalla. Se on osa, joka vaikuttaa merkittävästi tuotteen myyntipotentiaaliin.
Jos testaamisen lisääntyessä testaajien määrä pienenee, ollaan ohjelmistokehityksessä hyvin vaarallisella tiellä. Tuolla tiellä merkittäviä virheitä jää löytymättä sitä mukaa kun rahaa palaa automatisoinnin suitsuttamiseen ja toteuttamiseen. Silloin kannattaa pysähtyä kysymään: Onko kyseinen yhtälö todellakin taloudellisesti kannattava?
Suosittelemme myös:
Mikä on kun ei taidot riitä?
Ilma oli sakea, tunnelma tiivis ja noin 100 kilttiä koululaista nojautui kuuntelemaan väkeviä tarinoita myynnin ihmeellisestä maailmasta. Istuin...
Kun ei käynyt mielessäkään
Ei niin yksinkertaista tilannetta olekaan, etteikö sitä voisi mokata. Pieni inhmillinen virhe voi aiheuttaa ison ongelman. Viimeksi näin kävi...
Miten testausautomaatio testataan? Testausautomaatiolla?
Vaikka olen testaaja henkeen ja vereen, näen kyllä että testaustyö on muuttumassa. Kuten ko. seminaarissa puhuin, josta tuota artikkelia joku toimittaja kirjoitti, kyse ei ole siitä että testaus olisi muuttumassa automatisoitavammaksi, vaan siitä että on yhä enemmän perusteltua odottaa että testaustyö ei ole manuaalista automaation ajamista, vaan oikeasti sitä nk. tutkivaa testausta, joka tuottaa ”checking” näkökulmaa laajempaa / monipuolisempaa tietoa laadusta.
Sen lisäksi että muutosta checking-työstä tapahtuu, tapahtuu myös yhä enemmän sitä, että testaus on ”programming productivity” aktiviteettia – ja tässä automaatiolla, ja erityisesti laajentavalla, ei vain regressiotestausta tekevällä automaatiolla on roolinsa.
Testaajien määrän pieneneminen ei ehkä ole ongelma / uhka – jos kyse on erillisistä, testaukseen erikoistuneista testaajista. Kuten Cem Kaner sen joskus totesi: toteuttajilla on kyky löytää >99% virheistä, mutta aikataulun tiivistämisessä tämä malli ei ehkä meitä parhaiten palvele. Sen sijaan toivon ja uskon, että malli, jossa puutteellista laatua heitellään aidan yli perusteella että testaamista tarvitaan yhä enemmän järjestelmien monimutkaistuessa, olisi oikeasti siirtymässä nykypäivän arjesta historian havinaan.
Kyllä testausala muuttumassa on. Otan esimerkiksi peliteollisuuden joka on niin lähellä sydäntäni kuten olen joskus jossain yhteydessä tainnut mainita. Ensinnäkin peliteollisuus on eräs voimakkaiten kasvava teollisuuden ala ja nyt puhumme jopa miljardeista.
Pelin kehittämiseen voidaan käyttää useita malleja kuten esimerkiksi: Tehdään peli nopeasti ja halvalla (eli ei testausta jne.) ja pusketaan markkinoille ja katsotaan, että miten sille käy. Sitten toistetaan tämä niin monta kertaa, että saadaan jotain myytyä ja palkat maksettua.
Toinen malli on sitten se, että suunnitellaan softa hyvin ja tosissaan ja nyt nousee testaajien ammattitaito tärkeään roolii. Pelissä nimittäin tiivistyy hyvin se, että käyttäjän kokemuksen täytyy olla hyvä jotta tuote myy. Vaikka peli olisi teknisesti miten hyvä tahansa, niin ei sillä ole mitään merkitystä jos loppukäyttäjä kokee, että peli on tylsä, aihe töksähtelee, liian vaikea, liian helppo, huumorintajuton ja niin edelleen.
Peliteollisuuden testaajat ovat ammattikunnan yksi erikoisimmista joukoista. Samantapaisiin aiheisiin törmää testaajat yhä enemmän myös muiden ohjelmistojen parissa. On olemassa projekteja joissa on oma tiimi työskentelemässä kokemuksiin pohjautuvien asioiden kanssa. On olemassa myös pienempiä projekteja joiden budjetti ei aivan riitä massiiviseen miehitykseen, niin silloin pelkästään yksi testausammattilainen voi merkittävästi vaikuttaa ohjelmiston kehitykseen.
Kuten ensimmäisessä lauseessa totesin, automaatio ei osaa kertoa tunteisiin ja kokemuksiin liittyvistä asioista.
Hyviä pointteja! Vaikka hieman kyseenalaistinkin niin olen yhtä mieltä siitä, että testausala on muuttumassa. Kun koko it-ala on jatkuvassa muutostilassa, on välttämätöntä pysyä kärryissä mukana. Jos ei pysy niin jää samalta seisomalta rannalle ruikuttamaan. Se on ajan henki 🙂
Kyseenalaistan kuitenkin vahvemmin testausautomaation roolia näissä muutoksen tuulissa. Automaatiosta on pikkuhiljaa syntymässä sellainen hype, että sen kanssa juostaan hampaat hulmuten tapahtumahorisontin toiselle puolen. Ja siinä vaiheessa alkaa projektissa rytisemään ja aikataulut paukkumaan, kun ollaan kadotettu se ikiaikainen motto ”kohtuus kaikessa”. Huomataan, että ollaan tehty vääriä asioita, jotka näyttivät hyvältä vielä paperilla. Testausautomaation (ja kaiken muunkin muutoksen suhteen) tulisi pitää se paljon kuulutettu maalaisjärki mukana toiminnassa.
Testausautomaation tutkiminen ja kehittäminen on hyvä juttu, sitä en kiistä! Liian monesti on kuitenkin tullut todistettua sellaista tilannetta projekteissa, että automaatiota tehdään pelkästään automaation vuoksi. Automaatiota tulisi tehdä testauksen vuoksi. Eli kannattaa pitää se kultainen keskitie mielessä, minkä takia ylipäänsä automatisoidaan, if ju knou wot ai miin 🙂
Minusta on hauskaa huomata, että esityksessäni oli kolme trendiä, ja yksi asia, josta minun pitäisi tehdä täyskäännös nähdäkseni toisenlaista tulevaisuutta – ja minulle se tulevaisuudenkääntävä asia oli automaatio, joka oppii kuten ihminen. Tiedeleffakamaa, ei todellisuutta.
Sitä artikkelia taitaa joutua lukemaan otsikkoa ja ensimmäistä lausetta pidemmälle jos haluaa hahmottaa mistä siinä koitettiin puhua.
Jos miettii regressiovirheiden luonnetta, ovatko ne ”fiilispohjaisia virheitä” vai ”pieniä nippeleitä” – taitavat usein olla jälkimmäistä. Vauhti ja osittainen tietämättömyys naapureista (ja omankin koodin unohtaminen kun aikaa kuluu) perustelevat kyllä varsin vahvasti sitä, miksi automaatiotyyppisiä turvaverkkoja tarvitaan.
Minusta olisi mukavaa, jos automaation osalta ei aina tarvitsisi käydä näitä ehdottomasti puolesta / vastaan keskusteluja, vaan se olisi siinä roolissa kuin sen kuuluu. Trendin numero kolme mukaisesti: ”Automaation rooli välinetukena”.
Trendi numero yksi listallani oli ”oikeita testaajia” yhä vähemmän – sellaiset ammattitestaajat, jotka simuloivat koneentoimintaa käsivoimin ovat toivottavasti vähitellen poistuva luonnonvara. Checking-työn määrä kasvaa, mutta kuorma testauksesta kokonaisuutena siirtyy eriytetyltä testausroolilta useille eri osapuolille. Ei-testaajatkin osaavat testata – toiset paremmin kuin toiset. Haluttomuus ja sen salliminen / kannustaminen testausta nostaakseen pitäisi olla kiellettyä.
Minusta osut Maaret siinä hyvin asian ytimeen, että toivot keskustelua, missä asetelma ei olisi puolesta/vastaan -tyyppinen. Minusta valveutuneet testausalan asiantuntijat tietävät, että oikein rakennettuna ja sopivasti mitoitettuna automaatio ja käsityö voivat tukea toisiaan erinomaisesti. Tulokset voivat olla jäätävän hyvät.
Käyn kuitenkin tapaamassa paljon ohjelmistokehityksen ammattilaisia ja kehitysjohtajia työni puolesta ja yhä uudestaan huomaan saman asian. ”Haluamme nostaa automaatioastetta”.
Tavoite tuntuu hämmentävästi olevan juuri tuossa mustavalkoisen maailman automaatiopäässä. Kaiken automatisoinnissa. Minusta hämmentävintä on, että usein yrityksissä on kokeiltu tutkivia tai nopeita testausmenetelmiä. Niiden on todettu myös tuottavan enemmän tietoa ja bugiraportteja käytettyä aikaa kohti kuin automaation avulla. Siitä huolimatta regressionpelko on hirmuinen ja pakottaa panostamaan juurikin sen tuottamattomamman menetelmän lisäinvestointeihin.
Luin juuri Cem Kanerin viimeisintä blogiartikkelia rinnan tämän kanssa, ja se resonoi yhden kohdan osalta vahvasti (http://context-driven-testing.com/?p=23) tämän kanssa. Sinä ehkä kuulet hämmentävästi automaatiopäätä, mutta minä kuulen vielä hämmentävämmin automaatiotonta päätä, joka koittaa korostaa tutkivan testauksen merkitystä. Tätä sinäkin kai teit: ”kun testaus automatisoidaan, kyseessä on enää koneellinen tarkistus”. Kyseessä on koneellinen tarkistus, joka on eri asia kuin ihmissilmällä ja aivoilla tehty tarkistus, ja se voi sellaisena olla aidosti myös vahvempi.
Regressionpelko on osin aiheellinen ja lähtee kokemuksesta. Se, että missä määrin automaatiolla sitä pelon aiheuttajaa aidosti voidaan poistaa vaihtelee vahvasti tilanteissa. Mutta ajatus siitä että automaatioton testaus olisi jotenkin parempi yleinen vaihtoehto tuntuu vähintään yhtä väärältä. Ehkä koitan ajatella positiivisesti, mutta kun kuulen ”haluamme nostaa automaatioastetta” en kuule että halutaan vähentää manuaalista testausta – kuulen että halutaan enemmän, nopeammin, turvaverkolla.
Tuottavuus on suhteellista. Olen seurannut myös monta kertaa testaajien silmin tuottavaa testausta, joka löytää väärät ongelmat. Edelleen liian harvoin käsinkin tehtävässä testauksessa nähdään kokonaisuuksia ja sitä mistä yritys rahansa tekee luhyellä ja pitkällä tähtäimellä. Harva täydellisestä laadusta, joskin niitäkin on.
Ihan totta. Nousi oikein hymy huulille, kun ajattelen mainitsemaasi tuottavuuden suhteellisuutta. Jos testaaja löytää vääriä ongelmia, niin minusta testaaja ei ole vielä riittävällä tarkkuudella pysähtynyt ajattelemaan palkanmaksajan bisnestä.
Juuri sillä tavalla käy vaarallisen usein testaajalle, joka tehtävänannon saatuaan ei mieti eikä osaa tai uskalla esittää kysymyksiä. Sellainen testaaja vain ryhtyy töihin ja tuottaa tuloksia, joiden kuvittelee olevan maksajalle hyödyllisiä.
Minä kannustan aina ottamaan tehtävästä, tuotteesta ja bisneksestä selvää ennen hihojen käärimistä ja toimeen ryhtymistä. Ne ovat taustatietoja, jotka tarvitaan aina ensimmäisenä. Testausmenetelmillä tai työkaluilla ei oikeasti ole mitään väliä ennen tuota tärkeintä.
Vasta sen jälkeen on mahdollista tehdä päätöksiä muunmuassa automaation ja manuaalisen testauksen sopivasta suhteesta. Oikeiden taustatietojen perusteella voidaan haluta myös enemmän, nopeammin ja turvaverkolla 🙂
Testausautomaatio on milteimpäs kuumin puheenaihe ohjelmistotestausalalla. Se on kuuma aihe siksi, että se herättää voimakkaita tunteita ja mielipiteitä suuntaansa.
Seuraavassa oma näkemykseni testausautomaatiosta. Käytän kevääseen sopivaa esimerkkiä eli polkupyörän keväthuolto. Onnistuneeseen huoltoon tarvitaan joukko erinäisiä työkaluja – joka kevät et tarvitse jokaista meisseliä ja pinnan kiristintä, mutta siitä huolimatta ne on hyvä löytyä työkalupakista. Harjaantunut ja kokenut polkupyörän huoltaja tunnistaa nopeasti ne kohdat jotka huoltoa vaativat ja valitsee toimeen sopivat työkalut.
Useimmiten tarvitaan pumppua täyttämään renkaiden ilmanpaine sopivaksi. Jos renkaiden ilmanpaine on hyvä, pumppua ei tarvita. Se ei kuitenkaan tarkoita, että heittäisimme pumpun pois. Kokenut pyöränhuoltaja laittaa pumpun takaisin työkalupakkiin odottamaan sitä hetkeä jolloin pumpulle on käyttöä. Joku saattaa kiinnittää pumpun pyörään jotta se kulkee koko ajan mukana eli on heti valmiina kun sitä tarvitaan.
Joskus saattaa käydä sitten niin, että rengas on vaurioitunut ja ilma ei pysy renkaassa. Silloin ei auta juurikaan vaikka pumpulla suhuuttaisi lisää ilmaa – parhaassakin tapauksessa saavutetaan lyhytaikainen illuusio siitä, että kyllä tämä onnistuu. Kun renkaan vika on korjattu ja pumpun käytölle on perusteet, niin sitä kannattaa käyttää. Manuaalisesti puhaltamalla renkaan paine tuskin saavuttaa tavoitetasoa tahi ilmaa ei siirry renkaaseen lainkaan.
Testausautomaatio on minulle yksi tärkeä työkalu pakissa. Pakissa on myös muita työkaluja ja yhdessä nämä muodostavat työkalusarjan jonka kanssa liidän tilanteesta toiseen.
Kiitos mainiosta tarinastasi Ammattitestaaja,
Saanko julkaista sen aivan omana blogitekstinään tässä lähiviikkoina?
Terve Antti! Tarinani saa julkaista ja soveltavin osin täydentää jos sellainen on tarpeen.
Usein tutkailen ja itselleni selvitän testausmaailman asioita arkipäiväisillä askareilla. Meistä jokainen testaa joskus jotain ja useimmat joka päivä.
Kyllä testaaminen ja testaajien päivittäinen duuni muuttuu.. Ja hyvä niin. Ennen vanhaan testaajat nähtiin devaajien apumiehinä ja testi automaatioon ei panostettu. Testaajan tuli varmistaa, että ohjelmisto toimii kuten speksattu. Tän takia moni bugi (jopa puolet) aiheutuu siitä, että vaatimukset ovat puutteelliset. Tämä taas johtaa siihen, että bugit on kalliita korjata ja osa joudutaan ignoraamaan, koska aika ei riitä siihen.
Agilen myötä testauksen pitää muuttua siten, että testaaja auttaa product owneria speksaamaan vaatimukset paremmin ja auttaa scrum tiimiä testaamaan (kaikki testaa agilessa, ei vain testaajat). Samoin, testaajan on panostettava testiautomaatioon ja katettava sitä exploratory testaamisella. Täten testaajan onkin nyt varmennettava, että tuote todellakin vastaa asiakkaan haasteisiin, eikä että se toimii kuten speksattu. Totta kai, testaaja koettaa edelleenkin löytää vikoja. Se ei saa muuttua.
Tervehdys Marko! Rautaista asiaa ja sapelihampaan teräviä näkemyksiä.
Kyllähän ohjelmistotestauksen arki on muuttunut lyhyen ajan sisällä ja muutoksen kourissa olemme parhaillaankin. Itse koen, että elämme ohjelmistotestauksen maailmassa testausjaksoa jossa testaamme erilaisia ideoita, käytäntöjä ja filosofioita. Ottaa oman aikansa, ennen kuin voimme lausua yleispätevästi, että miten testaus itseasiassa tulee suorittaa missäkin tilanteessa. Toki monelle on muodostunut pitkälle viety arvaus siitä, että mikä voisi olla pätevä lähestyminen tiettyihin tilanteisiin, mutta siinäpä se suurin piirtein on.
Testaajien ja devaajien suhde on kehittynyt valtavasti. Nykyään suhde on enempi kaksisuuntainen ja ohjelmistojen kehitys on parhaimmillaan moniulotteinen versio parityöskentelystä. Klassinen esimerkki täydellisestä parityöskentelystä on poliisipartio jossa toinen on aina parempi kirjoittamaan (nykyään yhtä kuin parempi tietokoneiden kanssa) ja toinen on parempi pamputtamaan. Kahta pamputtajaa ei parane laittaa samaan partioon – se ei ole hyvä idea. Pamputtajalla on hyvä olla kirjoittaja vastapainona joka tarkistaa lähes reaaliaikaisesti pamputuksen tuloksen ja kirjaa riittävän määrän sakkoja. Palauttaa toki lisäpamputusta tarvitsevat takaisin pamputukseen.