Pienistä näkökulmaeroista: ihminen, apina ja tietokone

Aikaisemmin tällä viikolla julkaistiin toisaalla blogiartikkeli Ihminen, apina ja tietokone testaamassa. Opettavaisella ja yksinkertaisella sadulla oli kaunis opetus testauksen suhteen.

Yhteistuumin kaverukset sopivat, ettei hommasta pidä enää kiistellä: jokaisella on omat vahvuutensa, ja tulevaisuudessa kannattaa keskittyä niihin.

Sadussa on kuitenkin vain pieni ongelma: siinä vertaillaan omenoita ja appelsiineja, ja tarinan opetuksen yksinkertaistuksessa saattaa mennä se lapsi pesuveden mukana.

Samaa mieltä?

Tarinan opetus on kaunis ja oikein: jokaisella (ihminen, apina ja tietokone) on omat vahvuutensa, ja tulevaisuudessa kannattaa keskittyä niihin. Tietokoneen vahvuus on toistossa. Jos on jotain minkä tietokone voi suorittaa ilman ihmisen puuttumista, se tekee sen väsymättömästi. Ihmisen vahvuus on ajattelussa ja tietokoneen ohjeistamisessa. Jos ihminen keksii mitä yksityiskohtia katsoa ja käyttää aikaa sen opettamiseen koneelle (automatisointi), automaatio katsoo mitä käskettiin ja miten käskettiin. Ja apina syö banaania, näyttää hampaitaan ja kiipeilee puissa tarjoten ihmiselle virkistystä aivoja lepuuttaessa.

Testauksessa automaatio on tärkeää ja se vapauttaa voimavaroja muuhun. Muu voi olla tutkivaa testausta, tai se voi olla nopeampaa korjaamista nopeamman palautteen myötä – nopeampi palaute kun usein johtaa nopeampaan korjaamiseen kun muutokset ovat vielä tuoreessa muistissa.

Tarvitaan monenlaista testaamista: sitä mitä voidaan automatisoida (checking) ja sitä mitä ei voida automatisoida (exploring). Ja suurikaan panostus automatisointiin ei muuta sitä että molemmat ovat tarpeen.

Eri mieltä!

Tarinan todellisuuspohjassa oli muutamia aukkoja, jotka varmasti on tarkoituksellakin jätetty tarinan suoraviivaisuuden vuoksi. Mutta tarkastellaanpaa niitä hieman.

  1. Tulokset: kierrosmäärä ja virheet
    Kun voittajia julistettiin, vertailussa oli kaksi lukua: kierrosmäärä ja virheet.

    Tietokone suoritti testinsä aina kun koodia muutettiin, ja koodia muutettiin viikossa 763 kertaa eli 152 kertaa työpäivän aikana. Ihminen suoritti testit viikossa kolmesti, eli olettaen että muutosmäärä jakaantui tasaisesti viikolle 254 muutosta jäi ajalle jolloin ihminen suoritti kiltisti samaiset testit viimeistä kertaa kuin joita tietokone hurjaan tahtiin ajeli. Koska tietokone löysi 72 virhettä enemmän kuin ihminen/apina ihan vaan toiston vuoksi, on varmaan kohtuullista olettaa että nämä virheet siis eivät jakaantuneet tasaisesti viikolle vaan syntyivät nimenomaan tuon viimeisen kierroksen kohdalla vähitellen kun ihminen tai apina ei niihin enää palaamassa ollut ehtimisensä vuoksi.

    Jos tarinassa olisi mitään todellisuuspohjaa, muutoksissa syntyvät virheet lienee jakaantuisivat tasaisesti viikolle eivätkä todellisuuden numerot olisi tässä jakaumassa tietokoneen eduksi ihan tällä tapaa.

    Tarkastellaanpa vielä näitä numeroita toiseltakin kantilta. Tietokonehan testasi aina muutettaessa eli viikossa tehtiin 763 muutosta – hurja määrä isollekin järjestelmäprojektille viimeisellä testausviikolla. Ja tietokoneen virhemäärien perusteella näistä muutoksista 72 oli selvästi syntynyt kyseisen viikon aikana kun vain toistolla niitä löysi ja vielä tosiaan sen viimeisen nelituntisen aikana, jolloin testaaja ja apina eivät toistoa tehneet. Ja jos näin olisi, numerot kertovat että viimeisen nelituntisen aikana tasaiseen tahtiin tehtiin 76 muutosta, joista siis 72 oli virheellisiä. Korjaukset näihin lienee tehtiin sitten vasta seuraavalla viikolla.

    Alkuperäinen tarinahan ei sitä kerro, mutta on lienee selvää että tietokone, ihminen ja apina kukin tekivät testausta ajan, mutta testaus ei ollut oikeasti kattavuudeltaan samaa.

    Huomasitko muuten että tietokoneella meni numeroiden perusteella 3 minuuttia testiensä suorittamisessa. Harvinaisen nopeita integraatio- ja järjestelmätestiautomaatioita, jos kierroksen kesto olisi noin lyhyt. Tai ehkä tietokone tarinan ulkopuolelta kykeni ajamaan montaa kierrosta rinnan (eli joku olisi toteuttanut vielä vähän monimutkaisemman automaatiosetupin tietokoneen eduksi).

    Suuri toistomäärä puree vain jos kattavuudessa on ero tietokoneen eduksi tai jos rikkovat muutokset sijoittuvat ajalle jolloin hitaammat eivät enää samoihin kohtiin ehdi. Näillä numeroilla järjestelmäprojektissa oli jotain pahasti vialla.

  2. Kattavuus ja osapuolten testauksen erityispiirteet
    Tarinan osapuolet olivat viehättäviä yksinkertaistuksia, joiden kuvauksissa oli suuria asiavirheitä.

    Aloitetaanpa apinasta: kuka osaa kuvitella apinan, joka tottelevaisesti kliksuttelee menemään neljän tunnin sykleissä samoja testejä kerta toisensa jälkeen? Apinan, joka ei hypi näppäimistön päällä kun ei alkujaan edes ymmärtänyt mitä ja miten voisi testata, joka ei lähinnä brute-force -tyyliin tuurilla osu joskus nappeja painellessaan toimintoihin tavoilla jotka voisivat toimia tai hajoittaa jotakin? Kun apina testaa, tottelevaisuus ja ohjeiden noudattaminen ei liene ensimmäinen ominaisuus. Niinpä tarinan apina menetti kaikki nk. apinatestauksen hyvät puolet. Apinatestauksen ideana (automaation muoto ja erinomainen sellainen) on syöttää erilaisia arvoja ja tapahtumia satunnaisesti ja huomata vain yksinkertaisin säännöin tunnistettavat ongelmat, kuten isot näkyvät virheilmoitukset. Apina-parkaa kohdeltiin tässä tarinassa erityisen huonosti, kun siltä otettiin pois kaikki sen positiiviset erityisominaisuudet. Apina olisi löytänyt virheitä, joita tietokone tai ihminen ei kykene löytämään ilman apina-testaus-automaatiota, jota en liittäisi sanaan ”Robot Framework”. Tarinan apina muistutti enemmän Aasiasta halpatyövoimana ostettua testaajaa – Commodity Testers.

    Yhtä iso mysteeri tarinan henkilöissä on myöhemmin esitelty ihminen: ohjelmistokehittäjä, joka auttoi tietokonetta automatisoiden testit Robot Frameworkilla. Millainen on ihminen, joka automatisoi hyvät testit, joilla löytyy 13 virhettä mutta jättää kertomatta niistä niin että apina, ihminen ja tietokone kaikki voivat niihin aikaansa vielä tuhlata? Jos testit kerran olivat olemassa, miksi ihmeessä tietokone saisi niistä yhtään tuloksia ilman muutosta. Testejä ei voi automatisoida ajamatta niitä samalla kun niitä kehittää. Automaatiolla löytyy eniten virheitä siinä vaiheessa kun sitä rakennetaan eli kun ihminen perehtyy ja selvittelee yksityiskohtia.

    En myöskään pysty käsittämään ihmistä, joka testauskisaan lähti mukaan ja testasi pääasiassa etukäteen suunnitelluilla testitapauksilla ja vain vähän täydensi tutkivalla testauksella. Miksi ajatteleva ihminen tekisi asioita kuten tietokone? Ihminen tuskin suorittaisi testejä kolmeen kertaan, vaan saisi viikossa aikaiseksi vain koko ajan uusia juttuja vaikka sovellus taustalla muuttuukin, eli kierrosmäärän laskemisessa ei olisi mitään järkeä. Kaikessa testauksessa olisi päällekkäisyyttä, mutta ihmisen aivot suuntaisivat energian uusien näkökulmien ottamiseen: eri aineisto, eri ympäristö, eri käyttäjä, uudet sidosryhmät ja heidän tarpeensa, eri käyttöskenaario… Usein minusta tuntuu, että vain ohjelmoijat ihmislajina ovat sellaisia, jotka eivät ole tarpeeksi luovua vaihtaakseen näkökulmaa ollakseen kyllästymättä. Ohjelmoinnin onnistumisen keskeinen osaaminen kun on löytää ne polut, jotka automatisoi mahdollisimman suoraviivaisesti ja joilla asian saa toimimaan.

  3. Ajankäytöstä ja siitä kuka on kuinka nopea
    Ihminen, joka toistaa apinaa nopeammin on myös erikoinen ajatus – tämä ihminen ei taida juurikaan pysähtyä ajattelemaan. Erityisesti ajankäytössä särähtää ajatus, että ne jotka löytävät enemmän virheitä ovat nopeampia – sehän ei ole todellisuudessa koskaan totta.Mitä enemmän virheitä löytyy, sitä hitaammin testaus etenee. Virheiden kohdalla joutuu pysähtymään raportoimaan ”+1” mittareihin, ja usein vielä selvittelemään tarkemmin mikä virhe on ja onko kyseessä oikeasti virhe.Jos ihminen löysi enemmän virheitä kuin apina, miten ihmeessä ihminen on vielä nopeampikin?

    Ja kuka auttoi tietokonetta virheiden selvittelyssä? Tietokoneet ja testiautomaatio kun ovat tunnetusti hyvinkin tyhmiä sen suhteen että vääriä hälytyksiä selviteltäväksi saattaa syntyä ja niistä tietokone ei suoriudu ilman ihmisen apuja. Kenties se selittääkin suuren virhemäärän, kun viimeisen nelituntisen virheet ovatkin kaikki vääriä hälytyksiä?

  4. Muutokset ja korjaaminen viimeisellä viikolla
    Tarinassa erikoista oli myös testausviikon muutosten suuri määrä – ja tietysti suhteessa suuri virhemäärä, kun muutoksiin liittyviä virheitä oli 10 % muutosten määrästä. Vielä toisto huomioiden viimeinen nelituntinenhan oli varsinaista rikkomisen juhlaa, eli miksi näillä numeroilla puhutaan testauksen hyvyydestä eikä siitä mitä muutos/korjauspuolella voisi tehdä jotta prosentit eivät olisi näin hurjia? Mitä yleensä tehdään: mennään hiukan hitaammin. Ajatellaan. Jutellaan kehittäjäkolleegalle ja katselmoidaan. Tai vaikka pariohjelmoidaan. Tehdään mitä vaan ammattimaisesti tehdäänkin, jotta kaikki ei hajoa käsiin jatkuvasti.Ja sitä kautta, automaatio ei löydä yhtään sen enempää kuin ihminen. Päin vastoin.

    Mutta se kuulostaisi niin hyvältä opettavaisena tarinana, eihän. Mutta voisi nostaa esiin automaation oikeat hyödyt. Ja ne tuskin näkyvät viimeisen viikon testauksessa, vaan läpi projektin.

    On myös hyvä muistaa, että muutoksissa asiat eivät hajoa ilman syytä. Siinä missä tietokone ei käy juttelemassa ohjelmistokehittäjille (tai vakoile muutoksia committien kommenteista vapaasti tulkaten), ihminen käy. Ja sitä kautta ihminen testaa muutokset kohdistetusti eikä hakkaamalla kierrosta ”samoja testitapauksia”. Ihminen ajattelee ja suuntaa voimavarojaan.

  5. Testiautomaatiopanotuksen valinnat
    Kun korjauksia tehdään, testiautomaatiolla on tässäkin turvallisen nopean palautteen näkökulmasta suuri merkitys. Mutta tarinamme automaatio oli Robot Framework -automaatiota: integraatio- ja järjestelmätasoa, kokoluokaltaan keskisuurta tai suurta testiä eli hitaampaa palautetta. Isoissa järjestelmissä isoilla testijoukoilla usein ei puhuta minuuteista vaan tunneista automaation taustalla pyörähtämiseen, jonka aikana kehittäjä on jo ehtinyt toisten tehtävien kimppuun.Itse asiassa, tarina hieman vinkkaa suuntaan jossa yksikkötestausautomaatio on jätetty Robot Frameworkin olemassaolon vuoksi kepeille kantimille – virhemäärät joita muutoksissa pääsee syntymään eivät liene ihan tyypillisiä jos yksikkötestausautomaatio (tai kehittäjien muutoksissa käyttämä harkinta) on kovemmalla tasolla.
  6. Testiautomaatiota pitää rakentaa ja ylläpitää, ei se ole ilmaista
    Tarinan lopulla tietokone paljasti että siinä missä muut olivat eläneet suuren järjestelmäprojektin testaamattomuuden reunaehdoissa, sillä olikin ohjelmistokehittäjäkumppani, joka oli ilmeisen merkittävällä työmäärällä rakentanut tietokoneelle kilpailemisen edellytyksiä.

    Mutta huomaattehan mitä tämä tarinassa kertoo: meillä on oltava sitä aikaa automaation rakentamiseen. Ja usein automatisointi vie aikaa merkittävässä määrin, joten sitä tuskin haluaa tehdä viimeisen viikon testausten vuoksi vaan tukemaan tekemistä läpi projektin.

    Ohjelmistokehittäjä oli automatisoiniut tietokoneelle erityisen hyvät ja tarkat testitapaukset, kun virhemäärät olivat raportoitua luokkaa. Monissa projekteissa todellisuus kun on että automaatio raportoi virheää kun tarkistukset eivät ole riittävän monipuolisia. Ja ohjelmistokehittäjän oli lienee pakko olla tietokoneen tukena koko sen testausviikon muutoksen läpi, sillä minun on vaikea kokemuspohjalta kuvitella viikkoa jolloin tehdään 763 muutosta ohjelmistoon ja yksikään testiautomaatiocase ei vaatisi muutoksia toimiakseen oikein. Luultavasti ohjelmistokehittäjä on viettänyt viikon aikana saman verran aikaa kuin toinenkin ihminen testauksen etenemisen parissa, vain eri tyyppisissä tehtävissä. Ja sehän voisi ollakin perusteltua numeroiden pohjalta.

Yhteenvetona

Ihmisen ja tietokoneen yhteistyö on ihanaa ja mahtavaa. Mutta ihminen voi tehdä monia muitakin valintoja kuin ”Robot Framework”. Ihminen voi valita eritasoisia ja tyyppisiä automaatioita. Ihminen voi ajatella monipuolisesti ja jättää automatisoimatta ja käsin testaamatta arvioiden riskin pieneksi. Ihminen voi automaatiolla löytää virheitä, jotka eivät liity millään tapaa toistoon, vaan esimerkiksi massoihin. Muistan itse suurella ylpeydellä XML-automaatiolla löytynyttä virhettä, jossa selvisi että huomautuskoodi, jonka pitäisi esiintyä suurissa massoissa hyvin harvoin löytyykin suuresta massasta aivan liian usein. Sitä ei käsin olisi testattu.

Ihminen käsin testatessaan löytää enemmän ja erilaisia virheitä kuin mitä automaatio ihmisen ohjaamana toiston kautta kykenee löytämään. Joidenkin virheiden löytäminen on ihmisen tekemänä mahdollista, kun taas automaatio voi kyetä siihen mutta testin luomisen työmäärä on kohtuuton.

Se että jotain ei ole testattu ei tarkoita että se ei toimisi. Rakkaat ohjelmistokehittäjät saavat aikaan toimivaa ohjelmistoa myös testaamatta – aika usein ainakin. Testaamaton voi olla hyvinkin toimiva. Se että emme tiedä, ei tarkoita että se on rikki.

Tarinamme lopussa todettiin näin:

Siitä päivästä lähtien ihminen kehitti tietokoneelle Robot Framework -testejä ja teki itse tutkivaa testausta.

Tosiasia kuitenkin on että ihmisillä on erilaisia vahvuuksia. Usein ne jotka ovat vahvoilla tutkivassa testauksessa ja hyvin monipuolisten virheiden näkemisessä eivät ole välttämättä vahvoilla etenkään helposti ylläpidettävän automaation rakentamisessa. Tutkiva testaus tarinasta huolimatta ei ole lyhyt tehtävä kaiken muun jälkeen, vaan se on lähestymistapa ohjelmiston monipuoliseen empiiriseen tarkasteluun. Ja sillä voi helposti täyttää aikaansa niin että on vaikea löytää aikaa automatisoinnille jättämättä toisen tyyppisiä virheitä löytämättä.

 

Artikkelin on kirjoittanut Maaret Pyhäjärvi. Tämä teos on lisensoitu Creative Commons Nimeä-Epäkaupallinen 4.0 Kansainvälinen -käyttöluvalla.
Creative Commons -käyttölupa

maaret.pyhajarvi