Testiautomaation sudenkuopat

Automaatio ohuiksi siivuiksi

Ei voida kiistää, etteikö testiautomaatio olisi mullistanut ohjelmistotestausta. Ja juuri oikeaan aikaan! Nykymaailmassa, jossa palvelut ovat erittäin hajautettuja, kontitettuja ja jatkuvasti päivittyviä, mielekäs ohjelmistotestaus olisi mahdotonta ilman sitä.  

Meillä on onneksi käytössämme niin monia kehittyneitä automaattisen testauksen työkaluja. Ja lisäisin vielä, että myös hyvin koulutettuja laadunvarmistusinsinöörejä käyttämään niitä kaikkien hyödyksi kehitystyössä.

Jostain syystä alallemme on kuitenkin ominaista vähätellä tällaisia merkittäviä kyvykkyyden edistysaskeleita muoti-ilmiöiksi ja muuttaa nämä muoti-ilmiöt merkityksettömiksi sanahelinöiksi ja iskulauseiksi, joita ylemmät johtajat, asiantuntijat ja konsultit toistelevat konemaisesti vain keksiäkseen tekosyyn lakata ajattelemasta ongelmaa. Tai tehdäkseen nopeasti rahaa.  

Näin on käynyt myös testiautomaation läpimurroille, jotka on nopeasti valjastettu pelkistetyn kertomuksen osaksi: ”meidän tarvitsee vain automatisoida kaikki testauksemme! Heti! Ja kaikki testausongelmamme ratkeavat!”

Tämä ei ole ainoastaan kauhea ajatus, vaikka sen esittäisivät ihmiset, jotka yrittävät suhtautua ongelmaan vakavasti eivätkä vain vältellä sitä. Se on myös vahingollinen, koska kertomus sulkee pois mahdollisuuden pohtia syvällisesti automaation integroimista testaustoimiin ja varmistaa siten sen epäonnistumisen.  Tämä on epäoikeudenmukaista kaikkia niitä kohtaan (asiakkaat mukaan lukien), jotka ovat riippuvaisia sen onnistumisesta.

Tässä suhteessa testiautomaatio vain perii erityisen muodon yleisestä lähestymistavasta ohjelmistojen laadunvarmistukseen (SQA) niiltä, jotka eivät ymmärrä sitä eivätkä halua ymmärtää. Sitä kohdellaan bulkkituotteena, ei monimutkaisena asiantuntemuksena. Siksi laadunvarmistuksen parissa työskentelevät kuulevat jatkuvasti ylemmältä johdolta: ”me tarvitsemme vain lisää laadunvarmistusta!”, ikään kuin jossain olisi ohjelmistodeli, josta sitä voisi tilata kilohinnalla ohuiksi siivuiksi leikattuna.

Siksi mantra kuuluu nyt: ”me tarvitsemme vain lisää automaatiota!”, ilman että ajatellaan, mitä se todella tarkoittaisi ohjelmistokehitystyönne yhteydessä. Näin tämä puhe ruokkii organisaationne toimintahäiriöitä. Se ei korjaa niitä.  

Näiden muoti-ilmiömäisten taipumusten suora vastustaminen on kuin yrittäisi estää aurinkoa nousemasta. Tai tässä tapauksessa laskemasta. Paras tapa vastustaa on vain nyökytellä ja hymyillä varajohtajille ja konsulteille, palata työpisteillenne, selvittää oikea tapa toteuttaa automaatio ja esitellä ideat sitten esimiestenne nerokkaan mielikuvituksen tuotteina. Olette kuitenkin luultavasti oppineet tämän läksyn jo muiden asioiden yhteydessä.

Tehdään siis niin. Tässä on luetteloni testiautomaation toteuttamisen sudenkuopista ja keinoista lieventää niitä, jotta automaatio voi lunastaa huomattavan lupauksensa omissa testaustoimissanne.

Automaation laajuus

Tärkein alussa vastattava kysymys on, missä automaattinen testaus tuottaa parhaan hyödyn suhteessa testaustoimintaan käytettyihin resursseihin. Kun käytätte aikaa tämän selvittämiseen, säästätte itsenne monilta, monilta päänsäryiltä myöhemmin.

Tähän kysymykseen vastaaminen tiivistyy kysymykseen siitä, kuinka suuri osa testauksestanne on automatisoitava ja kuinka suuren osan on jäätävä manuaaliseksi. Tämä saattaa yllättää ne teistä, jotka jatkuvasti altistuvat ”automatisoi kaikki testaus!” -julistukselle. Älkää kuitenkaan kiinnittäkö huomiota tuohon hölynpölyyn; nämä ihmiset eivät tiedä, mistä puhuvat.

Kaiken testauksen automatisointi – olettaen, että se olisi edes mahdollista – olisi hirvittävä päätös, joka voisi johtaa testaustoimienne ainoastaan katastrofiin.  

Automaatio voi tehdä hämmästyttäviä asioita, joihin manuaalinen testaus ei pysty – tai ainakaan yhtä nopeasti ja toistuvasti. Mutta myös päinvastainen pitää paikkansa. On asioita, jotka vain manuaalinen testaus osaa tehdä hyvin ja joihin automaatio ei pysty. Mitä nämä asiat ovat kummassakin tapauksessa?

Manuaalisen testauksen vahvuus automaattiseen testaukseen verrattuna on yksinkertaisesti inhimillinen tekijä. Todellisen ihmisen kärsivällisesti tekemän perusteellisen tutkivan testauksen hyötyä ei yksinkertaisesti voida toisintaa automaatiolla. Enkä puhu vain virheiden löytämisestä.  

Kuka tahansa voi löytää virheitä. Asiakkaat tekevät sitä jatkuvasti ilmaiseksi. Ammattitaitoisen laadunvarmistusasiantuntijan tuoma arvo on intuitiivinen ymmärrys siitä, miten ohjelmisto rikotaan, erityisesti siitä, miten asiakkaat voivat käyttää ohjelmistoa tavoilla, joihin sitä ei koskaan suunniteltu, mutta jotka ovat silti mahdollisia – usein katastrofaalisin seurauksin. 

Toinen manuaalisen testauksen etu on, että löydettyään virheen manuaalinen testaaja voi välittömästi ryhtyä selvittämään sen laajuutta ja vakavuutta. Toisin sanoen hän voi rajata ne testauskontekstit (käyttöjärjestelmät, työnkulut, palvelujen väliset vuorovaikutukset ja riippuvuudet), joissa virhe ilmenee, sekä ne, joissa se ei ilmene. 

Automaattiset testiskriptit eivät pysty tähän läheskään yhtä hyvin, ja ohjelmistoinsinöörin näkökulmasta juuri nämä ovat ratkaisevia tietoja, joita hän tarvitsee minkä tahansa virheen diagnosointiin ja korjaamiseen. Virheraportti, jossa yksinkertaisesti todetaan ”tein tämän ja tämä paha asia tapahtui”, on heille hyödytön.

Manuaalinen testaus on itse asiassa paljon tehokkaampaa ajankäytön kannalta, kun tarvitaan näitä tietoja, ja koska se on luonnostaan vuorovaikutteista ja tapahtuu reaaliajassa yhdessä kehitystiimin kanssa, sen palaute ja juurisyyn analyysi ovat huomattavasti tietorikkaampia.  

Kyllä, Virginia, manuaalinen testaus ei aina ole tehottomin ja aikaa vievin tapa löytää, diagnosoida ja korjata virheitä sekä vahvistaa niiden korjaukset (tai todeta, etteivät ne toimineet). 

Automaation ilmeinen etu on kuitenkin jatkuvassa käytettävyyden ja vakauden testaamisessa – erityisesti hajautetuissa järjestelmissä. Tämä on nykyisessä kehitysympäristössämme entistä keskeisempää, kun jatkuva integraatio ja käyttöönotto hajautetuissa ympäristöissä tapahtuvat reaaliaikaisesti.

Automaatio on myös tehokkaampi niin sanotussa ”massatestauksessa”, jossa käsiteltävänä on valtava tuhansien järjestelmäolosuhteiden ja niiden muuttujien muodostama matriisi, jotta voidaan selvittää, onko jokin niistä täysin rikki tai aiheuttaako se järjestelmän kaatumisen.

Nyrkkisääntö, jonka tulisi ohjata suunnittelussa sitä, milloin manuaalinen tai automaattinen testaus asetetaan etusijalle, on tämä: 

Manuaalista testausta suositaan yleensä uusien ominaisuuksien ja toimintojen ensimmäisessä testauksessa. Automaattinen testaus on selvästi paras vaihtoehto jatkuvaan yleiseen regressiotestaukseen sekä kuormitus- ja suorituskykytestaukseen.

Tuotteen tai palvelun elinkaaren aikana saman toiminnon testauksen tulisi kehittyä manuaalisesta automaattiseksi. Kyseessä on toiminnon elinkaarijatkumo. Ei kiinalainen muuri, jota ei koskaan ylitetä ja jonka kummankaan puolen ei tarvitse tietää, mitä toisella puolella tapahtuu. Oletusarvoisesti tulisi ajatella, että se, mikä testataan tänään manuaalisesti, siirtyy ajan mittaan automaattiseen testaukseen.

Automaatioinsinöörin pätevyydet

Automaattisen testauksen insinöörejä palkattaessa keskeiset halutut pätevyydet ovat ehkä väistämättä ehdokkaiden (a) niiden automaatiotyökalujen käyttötaito, joita heidän odotetaan käyttävän, sekä (b) näiden työkalujen käyttämät testauskomentosarjakielet.  

Jos kuitenkin keskityt vain näihin pätevyyksiin, teet suuren virheen. Ne ovat tarpeellisia, mutta tuskin riittäviä pätevyyksiä automaatioinsinöörin tehtävään.

Miksi? Yksinkertaisesti siksi, että automaatiotyökalun käytön ja sen komentosarjakielellä laadittavien komentosarjojen luomisen tuntemus ei kerro heidän yhtään mitään ymmärryksestään laadunvarmistuksesta itsestään.

Valitettavasti tapaan harvoin automaatioinsinöörejä, joilla olisi tällainen koulutus tai tausta. Heidät palkataan yksinkertaisesti siksi, että he ovat komentosarjojen taitajia, ei siksi, että heillä olisi taitoa suunnitella tehokasta ja diagnosoivaa testiä.

Nämä pätevyydet ovat itse asiassa tärkeämpiä kuin kokemus käytettävistä automaatiotyökaluista ja -kielistä. He voivat helposti oppia nämä tarvittaessa. Mutta testien suunnittelun ja niiden tulosten tulkinnan opettaminen vie paljon aikaa ja vaivaa.  

Olisi itse asiassa parempi ottaa jo palveluksessasi oleva kokenut analyytikko ja kouluttaa hänet tarvittavien automaatiotyökalujen käyttöön. Nämä automaatiotaidot ovat loppujen lopuksi nykyään yleistä osaamista. Kokeneen testaajan intuitio ja oivalluskyky eivät ole.

Tietämättömyyden automatisointi antaa sinulle vain tietämättömyyttä nopeammin ja toistettavammin sekä heikentää automaattisella testauksella tavoittelemaasi tehokkuutta. 

Automaation suunnittelustandardit

On itsestään selvää, että jos ryhdyt laajamittaiseen testiautomaatiohankkeeseen, sinun on ensin määriteltävä yleiset standardit, joita kaiken automaation on noudatettava, jotta se hyväksytään käytettäväksi testauksessa. Kuten monien itsestäänselvyyksien kohdalla, näyttää kuitenkin siltä, että järkeä on liikkeellä vähemmän kuin voisi olettaa.

Seuraavassa kerrotaan, mitä näiden standardien tulisi kattaa.

Ymmärrettävyys

Yksi ohjelmistokehityksen turhauttavista arvoituksista on se, kuinka käsityömäistä se loppujen lopuksi on. Valitettavasti ei ole lainkaan harvinaista, että ohjelmistoinsinööri kertoo, ettei pysty korjaamaan virhettä, koska hän ei kirjoittanut koodia, jossa se ilmenee. On kuin toisen insinöörin kirjoittama koodi olisi vieraalla kielellä, jota hän ei ymmärrä.

Tämä on valitettavasti yhtä yleistä myös testiautomaatiotekniikassa. En pysty edes kertomaan, kuinka monta kertaa laadunvarmistusinsinööri on sanonut minulle, ettei hän tiedä, miten testiautomaation osa päivitetään suuren tuoteversion päivityksen yhteydessä, koska hän ei ole kirjoittanut sitä eikä siksi ymmärrä sitä – eikä voikaan ymmärtää sitä. Ja kyseisen koodin kirjoittanut insinööri lähti yrityksestä kaksi kuukautta sitten.

Tämä on vielä vähemmän hyväksyttävää automaattisten testikomentosarjojen tapauksessa kuin uuden ohjelmistokoodin kohdalla, jossa toteutetaan suunnittelulogiikkaa eikä vain saada tiettyjä vaiheita tapahtumaan. Silti se on hämmästyttävän yleistä.

Tämä tarkoittaa, että ennen kuin palkkaat tusinan verran laadunvarmistusinsinöörejä ja annat heidän tuottaa iloisesti satoja automaattisia testikomentosarjoja, varmista, että olet ensin määritellyt yleiset ymmärrettävyysstandardit ja kouluttanut henkilöstön niiden mukaisesti.  

Vaatimuksena on oltava, että kaikkien testikomentosarjojen on oltava kaikkien laadunvarmistusinsinööriesi ymmärrettävissä, jotta niiden ylläpito ei lopulta ole yhden, usein vaihtuvan resurssin varassa.  

Määrittele ja toimeenpane kaikkien automaattisten komentosarjakandidaattien tarkastus- ja hyväksymisprosessi näitä standardeja vasten, ennen kuin ne voidaan ottaa käyttöön testauksessa. 

Ylläpidettävyys

Ylläpidettävyys liittyy läheisesti ymmärrettävyyden ongelmaan, mutta nämä kaksi ovat loogisesti ja toiminnallisesti erillisiä. Testiskripti voi olla helposti ymmärrettävä testausinsinööreille, jotka eivät ole kirjoittaneet sitä, ja silti rakenteeltaan sellainen, että sen päivittäminen tai muokkaaminen on erittäin hankalaa.

Tässä on tosielämän esimerkki. 

Yhdellä työnantajistani valmistauduimme testaamaan heidän lippulaivatuotteensa keskisuuren tason päivitystä. Päivitykselle oli suunniteltu neljän viikon julkaisusykli, mikä oli tässä tapauksessa itse asiassa kohtuullista.

Suunnitellessani tarvittavia testaustoimia tajusin, että meidän pitäisi myös päivittää tärkein automatisoitu regressiotestiskripti. Kun kysyin johtavalta QA-insinööriltä, kuinka kauan päivitys kestäisi, hän vastasi ”kahdeksan viikkoa”. Kaksi kertaa koko julkaisun vaatima aika! Vaikka otettaisiin huomioon insinöörityön synti eli arvioiden paisuttelu, tämä oli äärimmäistä.  

Pyysin muutamia muita testausinsinöörejä arvioimaan skriptin ja aika-arvion. He kaikki olivat yhtä mieltä siitä, että skripti oli kirjoitettu niin kömpelöllä ja tehottomalla tavalla, että sen päivittäminen seuraavaa julkaisua varten vaatisi useiden viikkojen huolellisen koko skriptin uudelleenkirjoittamisen, vaikka itse päivitykset eivät olleet tuotteen perusteellisia uudelleenkirjoituksia.

Tilanne oli klassinen esimerkki siitä, kuinka ohjelmistosuunnittelun synti siirtyy suoraan testaussuunnitteluun. On aika lopettaa tämä hulluus.

Neuvoni tässä on täsmälleen sama kuin aiemmin ymmärrettävyyteen liittyvässä asiassa. Älä missään tapauksessa anna QA-insinööreidesi piiloutua testaussuunnittelun luoliinsa ja ilmestyä viikon tai kahden kuluttua mukanaan jokin testinä mahdollisesti toimiva ratkaisu, jonka päivittäminen ajoissa olisi kuitenkin merkityksettömän kärsimyksen painajainen.

Laadi standardit oikea-aikaiselle päivitettävyydelle ja luo tarkastus- ja hyväksymisprosessi, jolla varmistetaan niiden toteutuminen. Tämä voidaan helposti yhdistää samoihin toimiin, joilla varmistetaan ymmärrettävyys, joten kaikki voi olla osa samaa tarkastusprosessia.

QA-insinöörisi eivät ole renessanssimaalareita, etkä pyydä heitä maalaamaan Sikstuksen kappelia uudelleen. Sen ei pitäisi kestää koko elämää.

Testauksen roolit ja testiautomaatio

Yksi tehottomuuden malleista, joka estää automaation sujuvan ja hyödyllisen integroinnin koko testaustyöhön, on virheellinen oletus, jonka mukaan jokaisen automatisoidun testausprosessin vaiheen on tapahduttava itse automaatioryhmän sisällä.

Tämä on toinen virhe. Tässä tapauksessa se ei kuitenkaan ole täysin ilmeinen.

Automaatioinsinöörit ovat todennäköisesti tiimisi parhaiten palkattuja resursseja, joten heidän aikansa on arvokasta. Lisäksi kyseisen tiimin luomien ja jatkuvasti päivittämien testiskriptien määrä kasvaa ajan myötä, mutta testausinsinöörien määrää ei pystytä kasvattamaan läheskään riittävän nopeasti pysyäkseen mukana. Ei edes silloin, jos työskentelet Googlella.

Siksi on toiminnallisesti järkevää jakaa työ automaatiotiimin ja muun tiimin välillä. Tarkemmin sanottuna automaattisia skriptejä ja työkaluja luovien ja ylläpitävien resurssien sekä automaattisia testejä tosiasiallisesti suorittavien resurssien välillä.

On selvää, että ensin mainitut vastuut voi hoitaa vain automaatiotiimi itse.  Se on kuitenkin juuri se syy, jonka vuoksi heidät alun perin palkattiin. Jälkimmäinen ei kuitenkaan koske tätä.  

Ei ole mitään syytä, etteivät analyytikot voisi myös suorittaa automaattisia testejä itsenäisesti ja tulkita niiden tuloksia.  

Hyvin harvat ajattelevat asiaa näillä termeillä, mutta tämä työnjako on kaikin puolin järkevä. Ensinnäkin se vapauttaa huomattavasti aikaa, jonka ansiosta automaatioinsinöörit voivat keskittyä uuden automaation luomiseen.

Toiseksi se vahvistaa edellä määriteltyä ymmärrettävyysvaatimusta. Jos automaatio on keskeinen osa testaustyötäsi, yhtä keskeistä on, että kaikkien testitiimisi jäsenten, automaatioinsinöörien tai muiden, pitäisi pystyä ymmärtämään ja käyttämään automaattisia testejäsi. Myös manuaalisten testaajien.

Tällainen roolien määrittelyjärjestelmä lisää huomattavasti koko QA-tiimisi resurssijoustavuutta ja luo siksi myös aika- ja aikataulutehokkuutta, jota ei muuten olisi olemassa. 

Lopuksi

Edellä määritellyn vankan automatisoidun testaamisen kyvykkyyden kehittäminen on nykyään yksinkertaisesti välttämätöntä. Ammattimaisesta ja tehokkaasta laadunvarmistuksesta ei voi puhua ilman sitä.  

Silti monet loistavat seikkailut alkavat innostuneina ja iloisina, mutta päättyvät matkan lopussa tappioon. Näen tätä tapahtuvan QA:ssa testiautomaation osalta hyvin, hyvin monissa tapauksissa.

Ongelma on siinä, että automatisoituun testaukseen on suhteellisen helppo ryhtyä. Se on kallista, mutta ainakin sen teeskenteleminen, että asiaan panostetaan, on helppoa. Automatisoitu testaus voi kuitenkin myös olla jyrkänne, jolta voi Wile E. Coyoten tavoin Roadrunner-piirretyissä juosta huolettomasti alas ja pudota heti, kun vaivautuu katsomaan alas.

Alusta alkaen on ymmärrettävä, että testiautomaatiolla on elinkaari. Jokaisella testiskriptillä on kuukausien, ellei jopa vuosien, elinkaari.

Kyse ei ole vain siitä, että kirjoitetaan joukko automatisoituja testiskriptejä, jotka vastaavat kaikkiin tuotteen nykyisessä kehitysvaiheessa oleviin tarpeisiin. Kyse on siitä, miten kaikkea tätä automaatiota voidaan kehittää saumattomasti tuotteen oman elinkaaren mukana.

Jos jätät automaation laajuuteen, QA-insinöörien pätevyyteen, ymmärrettävyyteen, ylläpidettävyyteen ja roolien määrittelyyn liittyvät ongelmat huomiotta, huomaat ajan myötä, että kaikesta tuosta automaatiotyöstä on tullut valkoinen elefantti ja rahareikä, jota on mahdotonta ymmärtää tai ylläpitää.

Ja kaikki siihen käyttämäsi rahat ovat menneet hukkaan. Asia, jota pomojesi pomot eivät jätä huomaamatta.

Jos taas noudatat edellä antamiani neuvoja ja sovellat niitä tietenkin omien haasteidesi ja tilanteesi erityispiirteisiin, vältät suurelta osin tämän vanhentumiskriisin ja saat nauttia tuottavan testiautomaation hyödyistä vielä vuosien ajan.

Kuten aina, onnea matkaan.

Aiheeseen liittyvää luettavaa:

• 10 PARASTA VERKKOPALVELINTEN VALVONTATYÖKALUA
• AUTOMAATION PARHAAT KÄYTÄNNÖT DIGITAALISESSA MUUTOKSESSA

Tutustumisen arvoinen: MIKÄ ON MABL? YLEISKATSAUS JA OMINAISUUKSIIN TUTUSTUMINEN