Automaatiota arvostetaan suhteessa enemmän kuin manuaalista testausta: kun etsin manuaalisesta testauksesta kertovaa materiaalia, jokaisessa oli vähintään ohjeistus kuinka automatisoida nuo manuaaliset testit. On ilman muuta totta, että automatisoidut testit vievät vähemmän aikaa ajaa, kunhan ne on toteutettu. Onko kuitenkin jokin kuitenkin pudonnut kelkasta matkan varrella, koska manuaalinen testaus testauksena on maailman hienoin asia (puhtaasti oma mielipide eikä minulla ole tieteellistä faktaa tukemaan tätä väitettä)?
Testauksen automaation helppoutta korostetaan monessa paikassa (mm. Bhavian Turakhia esityksessään), vaikka helposti automaation toteuttaminen on huomattavasti vaikeampaa kuin manuaalinen testaaminen. Testausautomaation edut eivät siis suinkaan ole testit toteuttamisen helppoudessa, ainakaan kaikissa tapauksissa. Pentti Pohjolainen kirjoitta gradussaan:
Ennen kuin voidaan automatisoida, täytyy toimiva manuaalinen testausjärjestelmä olla olemassa. Sen täytyy sisältää vähintään seuraavat piirteet: Ensinnäkin yksityiskohtaiset testitapaukset sekä odotetut tulokset, jotka perustuvat vaatimusmäärittelyihin ja suunnitteludokumentteihin.
Tämä tarkoittaa käytännössä sitä, että sen lisäksi että pitää olla hyvä määrittely- ja suunnitteludokumentaatio, tulee tapaus pystyä testaamaan ylipäänsä. Lisäksi Pohjolainen viittaa siihen, että järjestelmän toiminta tulee olla ennustettavissa tarkkaan, että tiedetään mikä loppu tulema tulee tarkalleen olemaan. Automaatiota ei kannata tehdä ilman tarkistuksia. Manuaalisessa testauksessa tarkistuksen tulevat automaattisesti, kun tulosta tarkistetaan! (No menipähän saivarteluksi..)
Testausautomaatio on äärimmäisen kannattavaa silloin, kun samaa tapausta ajetaan useita kertoja. Jos puhutaan ketteristä menetelmistä, joissa iteraatioita on paljon, yönylitestit tuovat lisäarvoa ja ennustettavuutta, jne., testausautomaatio on tehokas työkalu. Jos verrataan manuaalisen testauksen kustannuksia iteraatiotilanteissa, ei manuaalisen testauksen kustannustehokkuus yllä lähellekään automaatiossa säästettäviä summia. Mitä tapahtuu, kun määrittely muuttuu? Mitä tapahtuu, kun muutetaan komponenttien nimeämispolitiikkaa? Mitä tapahtuu muutoksen yhteydessä? Jotain muuttuu! Kun testiautomaation kohteena oleva järjestelmä muuttuu, täytyy testi päivittää. Kun testi päivitetään, sen toiminta tulee ensin varmistaa jollakin tapaa että testi itse ei jää vialliseksi -> manuaalinen testaus. Kun tehdään automatisoitua testausta ketterissä menetelmissä, voidaan olla varmoja, että testien päivitystä tapahtuu. Kuinka suuret kustannukset aiheutuvat testien päivittämisestä, koestamisesta, uudelleenajamisesta? Kuinka "hauskaa" (lainatakseni herra Turakhiaa) testien päivittäminen on, kun koko sovelluslogiikka muuttuu?
Manuaalisen testauksen ollessa pääasiallinen lähestymistapa edellä mainitussa tapauksessa, voidaan manuaalisesti saada palaute nopeammin kuin automatisoiduissa testeissä. Automaation kannattava voimahan on sen "palautteen nopeus". Jos tämä voima katoaa, onko automaatiosta mitään hyötyä? Toki joitakin testitapauksia on vaan puhtaasti viisaampi testata automaattisesti, mutta näissäkään tapauksissa ei puhuta puhtaasta automaatiosta vaan manuaalisen testauksen tukena käytettävästä työkalusta, jossa testausta helpotetaan työkalun ominaisuuksilla. Hyvänä esimerkkinä on suorituskykytestaus, joka ei luonnistu ihan helposti manuaalisesti... vaikkakin mm. Sokoksen verkkokaupan case-esittelyssään kerrottiin koko kehittäjätiimin (noin 100 henkeä) tehneen viiden minuutin aikana pikaisen suorituskykytestin, jossa kaikki kirjautuivat verkkokauppaan, jne. Pointti on kuitenkin se, että manuaalinen testaus sitä tukevin työkaluin on usein tehokkaampaa kuin puhtaasti automaattinen testaus.
F-secure on yksi testauksen edelläkävijöitä Suomessa ja heidän automaation toteutustavat herättävät minussakin kateutta. Voiko kuitenkaan samaa mallia soveltaa kaikkialle? Onko järkevää toteuttaa automaatiota sellaisiin projekteihin, joissa kalenteriajassa on viikko testausaikaa ja määrittelyt ovat powerpoint-tasolla (onko kenellekkään tuttu malli?) tai toteutus on niin paljon myöhässä, että vesiputousmallinen projekti karsii taas testauksesta? Ei heilläkään kuitenkaan ole hylätty automaatiota vaan se tukee heidän manuaalista testaustaan ja toimii "takaporttina", jolla mahdollistetaan regression poissulkeminen mahdollisimman pian. Heidän testausprosessinsa on sen mallinen, että automaatio mahdollistaa kypsän softan pääsyn manuaaliseen testaukseen.
No, kaikki tämä puhe automaation ongelmista ei tarkoita sitä, että automaatio pitäisi karsia kokonaan pois. Ei suinkaan! Päämääränä on tuoda älykkyys takaisin testaukseen (oliko se se, mikä taannoin putosi kelkasta?). Älykkyydellä en suinkaan tarkoita teknistä tietämystä tai taitoa, vaan sellaista älykkyyttä, mikä testaajalla pitää olla: kyseenalaistava älykkyys. Voidaanko puhua älykkyydestä, jos työkalujen tarjoajat mainostavat manuaalista testausta vanhentuneeksi? Voidaanko puhua älykkyydestä, kun koko laadun pohjaksi muodostetaan yönylitestien vihreänä pitäminen? Voidaanko puhua älykkyydestä, kun mottona on testauksen automatisointi, jolloin myös testauksen suunnittelu on automaattista? Jos kaikki on automaattista, niin mihin sitä älykkyyttä itse asiassa tarvitaan edes? (Onnistuinko puhumaan itseni pussiin...)
Sivusin aiemmin manuaalisen testauksen palautteen "hitautta" verrattuna automaatioon. Minulle on itselleni tuputettu teesiä "automaatiolla palaute on sekunteja, kun manuaalisella se on päiviä". Mitä tapahtuu, kun automaattista testisettiä pitää päivittää ja kyseinen setti voidaan ajaa vasta seuraavana päivänä? Testataan se manuaalisesti, kun kerran samoilla spekseillä se automatisoidaankin. Palaute on jopa nopeampi. "Automaattiset raportit", joku sanoo. Muun muassa Quality Center, Microsoftin Test Manager ja Test Runner ovat yksi keino palautteen nopeuttamisessa. Eikös se vähän niin kuin syö automaatiolta sen pääteesin? Tokihan pitkissä iteraatioissa automaatio on kustannustehokkaampi ja se huomaa regression nopeammin. Näissä tilanteissa se tulee kuitenkin ajatella työkaluna, jolla annetaan enemmän aikaa manuaaliseen testaukseen. Manuaalinen testaus huomaa erilaisia vikoja kuin automaatio, ja yleensä automatisoidaan ne tapaukset, missä manuaalisesti vikoja huomataan.
Ei manuaalinen testaus tietenkään mikään ihmelääke ole. Se ei ole idioottivarma, mutta ei sen pidäkään olla! Jos olisi olemassa idioottivarma testausmenetelmä, niin ei asiasta kiisteltäisi! Manuaalisen testauksen kompastuskiviä on (ja tulee aina olemaan) sen kustannustehokkuus iteratiivisessa projektimallissa. Älykkäällä manuaalisella testauksella voidaan kuitenkin löytää paljon enemmän kuin automaatiolla. Ei-älykäs testaus on usein se, mitä vasten automaatiota verrataan: testitapauksissa harpotaan, testien tarkistaminen unohtuu, jne. Tilastollinen tosiasia on (en pysty löytämään tämän julkaisijaa, mutta muistaakseni löytyy James Bachin webinaarista, en kuitenkaan mene oikeuteen tästä lainauksesta ;) ), että
80% kaikista automaatiotestitapauksista on kuraa eivätkä todellisuudessa testaa mitään.
Voiko manuaalisesta testauksesta sanoa kuitenkaan samaa? Jos järjestelmä on alhaalla, niin näyttääkö manuaaliset testit vihreää, koska tarkistus puuttuu?
Jos siis saataisiin manuaaliseen testaukseen integroitua joitakin automaation peruspiirteitä (eli nopea vaste ja raportoinnin helppous), voitaisiin manuaalista testausta nostaa voimakkaammin automaation rinnalle. Ehkä tällä tavoin manuaalisen testauksen piiriin saataisiin lisää huippuosaajia, jotka kehittäisivät testaustekniikoita ja -metodeita manuaalisen testauksen piirissä. Totta kai nykyiset testingdojot ja testingweekendit ovat nostaneet profiilia, mutta miten se saadaan nostettua samalle tasolle automaation tekniikan kehityksen kanssa? Miten voidaan tehdä manuaalisesta testauksesta seuraava ISO JUTTU? Miten saadaan ihmiset ymmärtämään, että testauksen tehokkuus ja eritoten kustannustehokkuus riippuu puhtaasti testaajien älykkyydestä eikä automaatiotyökalun käytettävyydestä?
Moro Peksi,
ReplyDeleteOikein virkistävä, uusinäkökulmia tarjoava ja selkeää näkemystä edustava kirjoitus! Ajatuksiakin herätti ja tässä nyt niitä sitten…
On tärkeää tunnistaa millaisessa testauksessa automaatiota on järkevä käyttää. Yksikkö- ja regressiotestaus tulevat nyt noin alkuun mieleen ja tuottavat yleensä hyvän tuloksen vastauksena työhaastattelussakin, mutta aihe olisi hyvä laajentaa tontille tekninen vs. liiketoiminnallinen testaus, koodin laatu vs. tuotteen laatu. Automaatio on jokseenkin helpompaa valjastaa varmistamaan teknistä osaa toteutuksesta, mutta liiketoiminnallisia koukeroita koestaessa tilanne on toinen. Siinä missä automaatiota on helppo hallita eristetyissä järjestelmissä ja myös rajatuissa järjestelmäkokonaisuuksissa, ei sitä välttämättä pystytä valjastamaan, kun pyritään varmistamaan loppukokonaisuuden toimivuus päästä päähän (ks. end-to-end, E2E). Järjestelmiä voi olla kymmeniä, ne voivat levätä palvelimilla ympäri maailman, tietokannat voivat olla hujan hajan, jne. jne. ja kaikkea tätä on hallitsemassa useita eri toimittajia omine sääntöineen ja kujeineen. Asiansa osaava porukka toki pystyy hoitamaan tämänkin automatisoimalla, mutta tällaisia menestystarinoita ei kasva puissa, eikä myöskään se raha, jolla tällaisen porukan saisi nostamaan edes sormeaan…
Tästä syystä mitä kauemmas kooditasosta mennään ja mitä lähemmäs valmista tuotetta, sitä vähemmän näkisin kokonaisvaltaisen automaation olevan tarpeellista ottaa käyttöön. Toki liiketoimintavetoisessakin testauksessa voi olla automaatio apuna; Esimerkkinä selaimiin asennettavat kilkkeet, jotka voivat rummuttaa joukon syötteitä kenttiin (esim. täyttää web-lomakkeen), kun yhteenvedon tarkastaa ihmissilmä/-aivot. Tällainen hybriditoiminta on hyvin yleistä eikä vaadi kohtuuttomasti teknistä tietämystä taakseen, mikä taas pienentää kynnystä saada testaus resurssoitua.
Minulle manuaalinen testaus on aina ollut Se Juttu. Automaatio voidaan kuitenkin ottaa mukaan niin, että se poistaa ihmiseltä varmistamisen taakan. Näin testaajalle jää mahdollisuus ajatella ja miettiä sitä miten kaiken pitää loppupeleissä toimia. Älykkäästi, kuten kirjoituksessa kerrottiin. Ajatuksensa ”vapaana” pitävä manuaalinen testaaja keksii keinoja testata ja vastavuoroisesti toimittaa ne eteenpäin automaatiota rakentavalle taholle. Tämä taho pitää huolen, että myös nämä ”vapaasta ajattelusta” syntyneet ideat päätyvät robottien arsenaaliin, mahdollisuuksien ja järjen puitteissa tottakai. Näin syntyy proaktiivinen käytäntö, laatukulttuuri, jossa automaatio ja manuaalinen testaus ovat harmoniassa keskenään ja molemmat nauttivat ansaitsemaansa arvostusta.
Bonushöpinät:
Kirjoituksessa mainitaan ongelmat nopeiden aikataulujen ja jatkuvien muutosten turbulenssissa. Se, että esim. F-Secure joutuu hallitsemaan valtavaa määrää muutoksia ja niihin liittyviä lukemattomia toistoja ulkopuolisten paineiden takia (no ne virukset) ei tarkoita, että ”perinteisempien” liiketoiminta-alueiden pitäisi hyväksyä jatkuva turbulenssi toiminnassaan. Usein tälläinen viestii huonosta projektijohtamisesta, määrittelyosaamisesta tai yksinkertaisesti siitä, ettei alkuunkaan tiedetä mitä ollaan lähdetty tekemään (visiot, missiot, diipadaa). Muutoshallinta on nykykeskustelussa yksi seksikkäimmistä termeistä ja kaikki haluavat osoittaa hallitsevansa sen sekoittamalla soppaa turhaan ja sitten vaatimalla juoksuhautoja keksimään keinot päästä taas raiteille. Tämä on laajempi ongelma, jota ei testaus yksinään ratkaise, mutta joka siitä usein kärsii. Mikäli em. asiat kuitenkin hoidetaan mallikkaasti, epäkohdat saadaan pidettyä kurissa ja jää aikaa rakentaa automaatiokin testauksen tueksi, tai ainakin maltilla ajatella, josko moisesta olisi hyötyä. Joku sanoi joskus, että osaavalla ei koskaan ole kiire. Näinhän se tuppaa olemaan.
Suolsin tässä nyt sydämestä, enkä pahemmin tarkastanut toistinko vaan niitä juttuja joista kirjoitit… :)
Kollegasi,
Sami Söderblom
Terve taas,
ReplyDeleteTämä on niin kiintoisa aihe, että muutkin innostuivat... ;)
http://blogs.forbes.com/alexknapp/2011/05/18/researcher-develops-automatic-software-testing/
Siinä missä valistuneet osaavat tunnistaa tuon mielenvikaisuudeksi, moni päättäjä näkee tuossa tilaisuuden leikata kustannuksia. Ja taas meitä testaajia koetellaan...
Totta. Olen kuullut sellaisiakin kommentteja, että manuaalinen testaus on "rahasampo", jonka leikkaamisella voidaan pienentää IT-yrityksen tuotantokuluja. Lisäksi "ei tarvitse tehdä niin paljon virhekorjauksia" ja "automaattiset testit antavat palautteen vioista paljon nopeammin". Jossakin vaiheessa mennään taas metsään, niin että rytisee...
ReplyDelete