Skip to content
🇺🇦 Auta ukrainalaisia tekemällä lahjoitus UNICEFin tai Suomen Punaisen Ristin kautta. 🇺🇦

Ohjelmistotestauksen lyhyt oppimäärä devaajan näkökulmasta

Aiemmin eräässä asiakashankkeessani sain kuulla, että backendin kehitystä tullaan vähentämään ja tämän myötä pitäisi saada enään vain testit kuntoon. Sain mahdollisuuden siis lähteä opiskelemaan ja tekemään Robot Frameworkkia & Pythonia vielä ennen sen hankkeen päättymistä.

Näin Microsoftin toteutuksiin koko kouluaikani sekä muuten urani pohjaten ja kaiken tekemisen pääpainon ollessa aina backendiä, oli mukavaa vaihtelua päästä oppimaan jotain hyvin erilaista. Osaamispohjana minun Python-osaamiseen oli vain kotona terrassa olevan kuningaspytonin hoitaminen ja testaamisestakin ylipäänsä hyvin minimaalinen kokemus. 

Lähdin liikkeelle kuten mihin tahansa muuhunkin projektiin, asiakkaan koodipohjan haltuunotolla. Robot framework hyödyntää paljon selkokielle kirjoitettuja keywordeja, joista pystyy (hyvin toteutettuna) todella helposti päättelemään, mitä yritetään tehdä ja miksi.

Testeissä tuntui toistuvan hyvin selkeä runko - toki pienillä variaatoilla: given/when/then eli kun jokin esiasetus on tehty, sitten tehdään jotakin, jonka jälkeen tuloksen pitäisi olla x ja tästä joko tulee PASS tai FAIL lopussa tai jos jokin testissä on rikki niin jo kesken suorituksen.

Avainasioiksi testauksen opiskelussa tässä hankkeessa tuli SeleniumLibrary sekä BuiltIn kirjasto. Lähestulkoon mitään ei tarvinnut lähteä rakentamaan itse, vaan kaikkeen oli jo olemassa omat valmiit hyödynnettävät palaset.

Robot Frameworkkia opiskellessa suosikki hakusanani olivat melkolailla “Best practises in X” sekä “Common pitfalls in x”. Näillä saa suhteellisen nopeasti ymmärryksen, miten pitäisi tehdä asioita sekä mitä kannattaa välttää.

Dokumentaatiota ja blogeja oli todella paljon aiheen parissa ja ne auttoivat merkittävästi liikkeellelähdössä. Olisin ilman näitä varmasti sortunut hyvin äkkiä käyttämään Sleep -komentoa silloin kun odotan, että jokin tausta-ajo valmistuu ja tieto tulee näkyviin. Tämä kuitenkaan ei ole suositeltu käytäntö, vaan näissä tulisi hyödyntää esimerkiksi BuiltInistä löytyvää “Wait Until Keyword Succeeds”-komentoa.

Näin koodarina oppi kyllä hyvin nopeasti huomaamaan, miten UI-elementteihin on todellakin lisättävä omia test automation id:tä, jotta niihin pystyy helposti tarraamaan testeissä kiinni. Devatessa kun ei välttämättä edes ajattele, että miten jokin ominaisuus on testattavissa myöhemmin.

Web-sivujen kanssa on toki suhteellisen helppo etsiä oikea elementti HTML:n seasta, mutta sitten kun hypätään vaikka mobiilisovellukseen, niin vaikka ihmissilmä näkisikin jonkun lohkon selvästi, niin testaus framework ei välttämättä sitä löydä.

Joissain erilaisia arvoja laskevissa tilanteissa (esim. pvm laskenta, kellonajat, api kutsut yms.) saatetaan tarvita muita keinoja kuin Robot Framework oikeiden arvojen varmistamiseen. Tässä projektissa apuna oli Python. 

Käärme-1

Uuden kielen opiskelu ja käyttäminen tuotantoympäristössä jännitti alkuunsa, mutta sitä pääsi tosiaan yllättymään, miten nopeasti sitä voikaan omaksua tietoa. Mitään python-mestaria minusta ei silti kuudessa viikossa tullut, mutta jo parissa viikossa tuli tehtyä ensimmäisiä python committeja vahvalla luottamuksella omaan koodiin. Testaus osoittautui todella kiehtovaksi osaksi IT-alaa, tätä ennen mielikuvani siitä ei ollut kovin hohdokkaat, mutta siinähän pääsee todella käyttämään luovuuttaan ja pitää olla vahva tieto siitä, miten järjestelmän oikeasti pitäisi toimia.