Ohjelmistotestaus työnä

Moni lienee kuullut vitsin testi-insinöörin baarikeikasta:

Tulee baariin, tilaa 1 oluen, tilaa miljoona olutta, tilaa 0 olutta, tilaa -1 olutta, tilaa liskon, tilaa "ബിയർ":n, tilaa " ":n

Vitsissä on totuuden siemen, testaushan on laadunvarmistusta. Varmistetaan, että ohjelma tai vaikka laite täyttää sille asetetut vaatimukset. Jos lähdetään purkamaan vitsin tilannetta, vaatimus todennäköisesti olisi "Baarimikolta pitää voida tilata yksi olut.". Testaaminen aloitetaan kokeilemalla täyttyykö vaatimus, sitten kokeillaan raja-arvot ja lopuksi kokeillaan, mitä kaikkea syöte voi pitää sisällään. Vaatimuksen tarkennuksista riippuu se, mitkä poikkeustapauksista menevät läpi.

Wikipediasta tai vastaavasta lähteestä voi katsoa, mitä kaikkea ohjelmistotestaus pitää sisällään, mutta tämän blogikirjoituksen tarkoituksena on ehkä kertoa enemmän siitä, että miten olen päätynyt alalle, miten teen tätä ja näyttää esimerkkinä testitapaus ja bugiraportti, koska testitapausten läpi käynti ja bugiraporttien kirjoitus on kuitenkin pääosa tätä työtä.

Valmistumisen jälkeen jouduin osittain tyhjän päälle, diplomityöpaikasta ei irronnut jatkoa, joten alkoi työttömyys ansiosidonnaisella ja töiden enemmän tai vähemmän ankara haku johtuen siitä, että totesin hyvin nopeasti toimettomuuden olevan aika tylsää. Jostain syystä päädyin hakemaan kouluttavaan harjoitteluohjelmaan, jossa työttömyyskorvauksella + pienellä koulutuslisällä tehdään jossain firmassa ohjelmistotestaustöitä 7kk ja välillä käydään jotain työtä tukevia kursseja Tieturilla. Itselle tämä oli hyvä kokemus ja sain työpaikan sitä kautta, mutta olen kuullut että monesti tällainen koulutus on orjahommaa eikä töitä irtoa koulutuksen jälkeen.

Omalla kohdalla työ on projektiluontoista, perustapaus on, että mennään jollekin asiakkaalle projektiin, joka on alkanut ohjelmoinnin ja muiden juttujen osalta aiemmin, lyödään käteen läjä vaatimusmäärittelyitä, kirjoitetaan niihin testitapaukset, ajetaan tapaukset tapaus tapaukselta läpi ja kirjataan löytyneet bugit. Joissakin projekteissa kirjoitetaan vielä joko projektin lopuksi tai testikierroksen lopuksi testiraportti, johon kirjataan löydetyt ja korjatut bugit ja lisäksi tiedossa olevat bugit, joita ei projektin puitteissa korjata. Olen tämän muutaman vuoden testausurani aikana testannut ohjelmistoja perus Windows-työpöytä- tai web-ympäristön lisäksi myös Android- ja iOS-ympäristössä sekä eksoottisemmilla Palm-kämmentietokoneilla ja Windows Mobile -kännyköillä.

Kokemukseni mukaan suurinta osaa bugeista ei löydetä testitapauksia ajettaessa, vaan yleensä, jos toiminto on jo toteutettu, tapausta suunnitellessa tai tapausta ajaessa keksii kokeilla jotain sellaista, mitä ei testitapauksella suoraan testata. Voikin sanoa, että tässä työssä on hyötyä kekseliäisyydestä ja mielikuvituksesta. Esimerkiksi alun vitsin tapauksessa mieleen voisi tulla kokeilla, jos tilaisi tuotteen, jonka nimi on 500 merkkiä pitkä tai jos se on vielä mahdollista katsottaisiin, missä vaiheessa raja tulee vastaan. Joku voisi mainita että ilkeä luonnekin on hyvästä tässä työssä, mutta vaikka testaajat usein väärinkäyttävät ohjelmaa, ei kyse ole kiusanteosta, vaan halusta tehdä ohjelmasta parempi. Mitä vähemmän bugeja päätyy loppukäyttäjälle, sitä parempi. Mistään vähänkään monimutkaisemmasta tuotteesta ei kuitenkaan saa koskaan bugitonta, mutta jos eniten käyttöä häiritsevät bugit löytyisivät tuotekehitysvaiheessa, sitä varmemmin tuote ei aiheuta harmaita hiuksia tavalliselle käyttäjälle.

Vaikka nykyään trendinä on yhä enemmän testiautomaatio Robot Frameworkilla tai vastaavilla työkaluilla, oma työni on enimmäkseen manuaalista testaamista. Testiautomaatio vaatii yleensä omat kirjastonsa työpöytäsovelluksissa, joten ne pitää kirjoittaa ensin ja testiskriptien kirjoittaminen ja kokeilu voi viedä aikaa enemmän kuin testaisi asiat manuaalisesti. Regressiotestaamisessa eli vanhojen testien uudelleen ajamisessa siinä vaiheessa, kun jokin on muuttunut, kuitenkin testiautomaatio on yleensä nopeampaa, koska moni testitapaus on aika tylsä. Esimerkiksi jos pitää täyttää käsin monia kenttiä lomakkeelta, on testiautomaatioskripti satunnaisgeneroituine syötteineen huomattavasti nopeampi tapa.

Kaikkea testaamista ei toki voi automatisoida, esimerkiksi jos web-sivulla on CAPTCHA (https://en.wikipedia.org/wiki/CAPTCHA) niin siihen syötettävistä merkeistä voi kyllä testata automaattitesteillä tyhjän, varmasti liian lyhyen, varmasti liian pitkän ja varmasti väärän mutta oikeaa ei voi. Nimittäin jos voi, se todistaa että käytetty CAPTCHA ei ole hirveän hyvä. Vaikka tekoäly onkin nykyään yhä parempi, testiautomaatio tekee vain sen, mitä skriptin kirjoittaja on halunnut sen tekevän, kun taas kekseliäät käyttäjät voivat saada systeemin rikki vahingossa, vaikka testiautomaatioskriptit menisivät kaikki läpi.

Itse olen kerran saanut testatessani erään pilvipalvelun jumiin niin, että kukaan ei siihen päässyt enää käsiksi ilman pääkäyttäjän suorittamaa palvelun uudelleenkäynnistämistä. Systeemi koostui lomakkeista, joihin sai itse määritellä uusia kenttiä esimerkiksi numeroille, tekstille, päivämäärille tai viitteitä toisiin lomakkeisiin. Kentän saattoi määritellä pakolliseksi ja/tai nimikentäksi, jolla lomaketta sitten etsittäisiin palvelun hausta. Tein lomakemallin, jossa nimikenttä oli joku tekstikenttä. Sitten loin käyttäen tätä mallia yhden lomakkeen (lomake1). Tämän jälkeen muokkasin lomakemallia niin, että nimikenttä olikin viite samanmalliseen lomakkeeseen ja tämän jälkeen muokkasin lomake1:stä niin että pistin nimikenttään viittauksen siihen itseensä. Tallentamisen jälkeen menin hakuun ja yritin hakea lomaketta, jolloin systeemi etsi vähän aikaa, kunnes ei enää reagoinut mihinkään niin, ettei kukaan muukaan päässyt kirjautumaan järjestelmään.  Palvelu sittemmin kuopattiin, syynä ei ollut tuo löydetty ja sittemmin osittain korjattu bugi vaan ihan perinteiset kaupalliset syyt.

Testitapausesimerkki

Koska oikeita työtapauksia en voi käyttää, otetaan esimerkiksi hypoteettinen vaatimus: "As a member of AS-alumnit I want to see pictures from past events."

Tästä sitten ruvettaisiin työstämään testitapausta. Seuraavissa kuvissa näkyy miten testitapaus näkyisi MS Test Managerilla.

MS Test Manager - uusi testitapaus

Sitten testitapaus otettaisiin testiin

ja ajon jälkeen voi katsoa raporttia.

Koska tämä esimerkki oli jokseenkin simppeli, saman testin voisi tehdä testiautomaatiolla ja seuraavassa on Robot Frameworkilla tehtynä sama. Skripti on kirjoitettu hyvin nopealla aikataululla, eikä se testaa esimerkiksi testaa täydellisesti virheilmoituksia kirjautuessa.

Näitä skriptejä voi kirjoittaa millä tahansa tekstieditorilla ja ajaa sitten suoraan pythonilla, mutta apuun on tehty myös RIDE-niminen ohjelma josta seuraavat kuvakaappaukset ovat. Ensimmäiset 2 kuvaa näyttävät vähän RIDE:n käyttöliittymää.

Seuraavat 2 kuvaa näyttävät testit tekstinä, ensimmäinen on itse testit ja toinen on resurssifilu missä on jotain tarvittavia avainsanoja ja vakioita.

Testin voi myös ajaa RIDE:ssä ja toimiessaan oikein se näyttää väreillä menikö testit läpi ja lisäksi login.

Testin jälkeen raportin voi avata selaimessa ja jo tästä perusraportista näkee taustan väristä menikö testi läpi (vihreä) vai ei (punainen).

Kun vertaa ajoaikoja manuaalitestin ja automaattitestin välillä, voidaan huomata että automaattitesti oli huomattavasti nopeampi ajaa (6 minuuttia vs 20 sekuntia). Manuaalitesti tosin olisi mennyt nopeammin läpi, jos olisin muistanut salasanani heti enkä vasta noin 10 yrityksen jälkeen ja jos en olisi ottanut screenshottia testin aikana, koska MS Test Manager on hieman tunnettu siitä, että se jumittaa konetta tuntemattomista syistä, mutta silti se tuskin olisi ollut yhtä nopea kuin automaattitesti, jossa eniten aikaa taisi kulua selaimen käynnistymiseen.

Bugiraporttiesimerkki

Samoin kun testitapausten kanssa, oikeita tapauksia en voi hirveästi käyttää, joten alla on raportti yhteen bugiin, joka ainakin tätä kirjoittaessa löytyy vielä alumniyhdistyksen sivuilta. Omat bugiraporttini ovat yleensä tätä muotoa, jos selkeä polku ongelmaan on löydettävissä.

  1. Go to AS-Alumnit web site
  2. Click link "Jäseneksi"
  3. Look for member fee for year 2016

Excepted result:

"Vuoden 2016 jäsenmaksun suuruus on ## euroa ja eräpäivä on ##.##.2016."

Actual result:

"Vuoden 2016 jäsenmaksun suuruus ja eräpäivä päätetään yhdistyksen vuosikokouksessa su 13.3.2016."

Workaround:

Doesn’t exist

Teksti: Erkki-Juhani Lämsä