Automatisoidun regressiotes- tauksen kehittäminen tervey- denhuoltojärjestelmälle
Sara Kopsa
OPINNÄYTETYÖ Marraskuu 2021
Tieto- ja viestintätekniikan tutkinto-ohjelma Ohjelmistotekniikka
TIIVISTELMÄ
Tampereen ammattikorkeakoulu
Tieto- ja viestintätekniikan tutkinto-ohjelma Ohjelmistotekniikka
KOPSA, SARA:
Automatisoidun regressiotestauksen kehittäminen terveydenhuoltojärjestelmälle Opinnäytetyö 27 sivua, joista liitteitä 1 sivu
Marraskuu 2021
Opinnäytetyön tarkoituksena oli kehittää Fimlab Laboratoriot Oy:lle automaatio- testejä seuraamaan järjestelmien regressiota. Automaatiotestit luotiin Robot Fra- meworkilla kolmelle olemassa olevalle terveydenhuoltoalan järjestelmälle. Ne ajettiin öisin automaatiopalvelinympäristössä virtuaalikoneella. Opinnäytetyön tuotoksen tavoitteena oli antaa järjestelmien kehittäjille nopeaa palautetta järjes- telmien toiminnasta.
Opinnäytetyöprosessin aikana huomattiin ongelmaksi sanomaliikenteen hitaus ja tästä johtuvat virhetilanteet automaatiotesteissä. Myös Linux-virtuaalikone suo- ritti osan testeistä eri tavalla kuin lokaalisti Windowsilla ajettuna. Tästä johtuen automaatiotestien ajojen tulokset olivat ristiriitaisia. Automaatiotestit löysivät ha- vaituista ongelmista huolimatta järjestelmien kehityksestä tulleita virheitä ja nii- den raporttien informaatio auttoi järjestelmien ylläpidossa sekä kehityksessä.
Työlle määritelty päätavoite toteutui ja automaatiotesteistä oli hyötyä kehittäjille.
Automaatiotestejä on syytä tulevaisuudessa parantaa luomalla pitkäaikainen rat- kaisu sanomaliikenteen viivästyksille, jotta testien ajoajat olisivat joustavia ei- vätkä ne vaikuttaisi negatiivisesti testien tuloksiin. Testien ajaminen eri selaimilla on myös helppo keino lisätä järjestelmän luotettavuutta. Luottamuksellinen si- sältö terveydenhuoltoalan järjestelmistä on poistettu julkisesta raportista.
Asiasanat: automaatiotestaus, ohjelmistotestaus, robot framework
ABSTRACT
Tampereen ammattikorkeakoulu
Tampere University of Applied Sciences Degree Programme in ICT Engineering Software Engineering
KOPSA, SARA:
Development of Automated Regression Testing for the Healthcare System Bachelor's thesis 27 pages, appendices 1 page
November 2021
The purpose of the thesis was to develop automated tests for Fimlab Laboratories Ltd to monitor the regression of systems. Automated tests were created with Ro- bot Framework for three existing healthcare systems and were run at night in an automation server environment on a virtual machine. The output of the thesis aimed to give developers quick feedback on the operation of the systems.
During the thesis process, the speed of the message traffic and the resulting error situations in the automated tests were problems that required attention. In addi- tion, the Linux virtual machine performed some of the tests differently than on a locally run Windows, so the results of the automated test runs were conflicting.
Despite the problems, the automated tests found errors in the development, and the information in their reports helped in the maintenance and development of the systems.
The main goal defined in the thesis was achieved and the automated tests were useful for the developers. Automated tests should be improved in the future by creating a long-term solution to message traffic delays so that test run times are flexible and do not adversely affect test results. Running tests in different brows- ers is also an easy way to increase system reliability. The confidential content from the healthcare systems has been removed from the public report.
Key words: test automation, software testing, robot framework
SISÄLLYS
1 JOHDANTO ... 5
2 OHJELMISTOTESTAUS ... 6
2.1 Ohjelmiston laadun arviointi ... 6
2.2 Testaustasot ... 7
2.3 Testaustyypit ja -menetelmät ... 9
2.4 Testien kattavuus ... 10
3 AUTOMAATIOTESTAUS ... 12
3.1 Automaatiotestauksen hyödyt ... 12
3.2 Testausprosessi ... 13
3.3 Agile-testaus ... 14
4 TEKNOLOGIAT ... 17
4.1 Robot Framework ... 17
4.2 Kirjastot ... 18
4.2.1 QWeb ... 18
4.2.2 SeleniumLibrary ... 19
4.3 Jenkins ... 19
5 TESTAUKSEN TOTEUTTAMINEN ─ CASE FIMLAB ... 20
5.1 Testaus terveydenhuoltoalalla ... 20
5.2 Testausroolit ... 20
5.3 Teknologioiden valitseminen ... 21
5.4 E2E-regressiotestien kuvaus ... 21
5.5 Testien tuomat hyödyt ja löydetyt ongelmat ... 23
6 POHDINTA ... 24
LÄHTEET ... 25
LIITTEET... 27
Liite 1. Fimlabin palveluväylän kuvaus ... 27
1 JOHDANTO
Ohjelmistokehityksen tehokkuuden maksimointi on tuonut uusia tarpeita kehityk- sen automatisointiin, ja tämän vuoksi esimerkiksi ohjelmistotestaus ja julkaisu on automatisoitu. Järjestelmien testaukseen on löytynyt helpotusta automaatiotes- tauksesta, joka antaa nopeaa palautetta järjestelmän toiminnasta ohjelmistoke- hittäjille sekä vapauttaa resursseja ohjelmistotestaajilta muun muassa tutkivaan testaukseen.
Työn toimeksiantaja, Fimlab Laboratoriot Oy, on Suomen suurin laboratorioalan yritys ja he tuottavat laboratoriopalveluita sekä laboratorioalan koulutusta ja tut- kimusta. Sen omistaa Pirkanmaan, Keski-Suomen, Kanta-Hämeen ja Vaasan sairaanhoitopiirin kuntayhtymät sekä Päijät-Hämeen hyvinvointikuntayhtymä.
Sillä on yli 110 toimipistettä ympäri Suomea, joissa otetaan yli 3,3 miljoonaa näy- tettä vuosittain. (Fimlab n.d.)
Fimlabilla on useita massiivisia järjestelmiä, joiden perustana toimii vanha merk- kipohjainen järjestelmä. Tätä järjestelmää ollaan korvaamassa uudella moder- nilla järjestelmällä vaiheittain. Opinnäytetyön tarkoituksena on tehdä regressio- testausta automaatiotestein uuteen järjestelmään tukemaan ohjelmistokehitystä sekä manuaalitestausta. Tavoitteena on luoda vähäistä ylläpitoa vaativia pit- käikäisiä automaatiotestejä.
2 OHJELMISTOTESTAUS
Ohjelmistotestaus on ohjelmistotekniikan osa-alue, jossa etsitään virheitä ohjel- mistosta ja varmistetaan, että tuote vastaa suunnitelmaa. Testausta hyödynne- tään jatkuvasti kehityksen aikana havaitsemaan ongelmia ja puutteita.
(Chowdhury 2021.) On hyvin tärkeää olla tietoinen ohjelmiston virheistä ja puut- teista jo aikaisessa vaiheessa, sillä mitä aikaisemmin virhe huomataan, sitä vai- vattomampaa se on korjata.
2.1 Ohjelmiston laadun arviointi
Laatumalli (kuvio 1) on laadun arviointijärjestelmän kulmakivi. Se määrittää, mitkä laatuominaisuudet otetaan huomioon ohjelmistotuotteen ominaisuuksia arvioita- essa. Vuonna 2011 julkaistu ISO 25010-standardi sisältää kahdeksan laatuomi- naisuutta: toiminnallisuus, suorituskyvyn tehokkuus, yhteensopivuus, käytettä- vyys, luotettavuus, turvallisuus, ylläpidettävyys ja siirrettävyys. (ISO 25010 n.d.)
KUVIO 1. ISO 25010 -standardin laatumalli (ISO 25010 n.d.)
Toiminnallisuudella mitataan, kuinka hyvin järjestelmä tarjoaa toimintoja, jotka vastaavat suunniteltuja ominaisuuksia. Toiminnallisuudella on kolme alaominai- suutta: toiminnallinen täydellisyys, toiminnallinen oikeellisuus ja toiminnallinen soveltuvuus. Suorituskyvyn tehokkuus edustaa suorituskyvyn suhdetta käytetty- jen resurssien määrään tietyissä olosuhteissa. Suorituskyvyn tehokkuudella on kolme alaominaisuutta: aikakäyttäytyminen, resurssien käyttöaste ja kapasiteetti.
(ISO 25010 n.d.)
Yhteensopivuudella mitataan, missä määrin järjestelmä voi vaihtaa tietoja mui- den järjestelmien kanssa ja suorittaa vaadittuja toimintoja jakaessaan saman lait- teisto- tai ohjelmistoympäristön. Tämä ominaisuus koostuu kahdesta alaominai- suudesta: rinnakkaiselo ja yhteentoimivuus. Käytettävyydellä mitataan, kuinka te- hokkaasti ja tyytyväisesti käyttäjät voivat käyttää tuotetta tiettyjen tavoitteiden saavuttamiseksi tietyssä käyttöympäristössä. Käytettävyydellä on kuusi alaomi- naisuutta: sopivuuden tunnistettavuus, opittavuus, toimivuus, käyttäjän virhesuo- jaus, käyttöliittymän esteettisyys ja saavutettavuus. (ISO 25010 n.d.)
Luotettavuudella mitataan, kuinka hyvin järjestelmä suorittaa määrättyjä toimin- toja tietyssä ajassa ja tietyissä olosuhteissa. Se koostuu neljästä alaominaisuu- desta: kypsyys, saatavuus, viansietokyvykkyys ja palautettavuus. Turvallisuu- della tarkoitetaan sitä, että oikeilla henkilöillä ja järjestelmillä on niiden valtuusta- sojen mukainen pääsy tietoihin. Tällä ominaisuudella on viisi alaominaisuutta:
luottamuksellisuus, eheys, kiistämättömyys, vastuullisuus ja aitous. (ISO 25010 n.d.)
Seitsemäs laatuominaisuus on ylläpidettävyys. Ylläpidettävyys edustaa tehok- kuutta, jolla järjestelmää voidaan muokata sen parantamiseksi, korjaamiseksi tai mukauttamiseksi ympäristön ja vaatimusten muutoksiin. Sillä on viisi alaominai- suutta: modulaarisuus, uudelleenkäytettävyys, analysoitavuus, muokattavuus ja testattavuus. Siirrettävyys on viimeinen kahdeksasta laatuominaisuudesta ja sillä mitataan tehokkuutta, jolla järjestelmä voidaan siirtää laitteistosta, ohjelmistosta tai muusta käyttöympäristöstä toiseen. Sillä on kolme alaominaisuutta: sopeutu- vuus, asennettavuus ja vaihdettavuus. (ISO 25010 n.d.)
2.2 Testaustasot
Ohjelmistotestaus voidaan jakaa neljään päätasoon (kuvio 2), yksikkö-, integraa- tio-, järjestelmä- ja hyväksymistestaukseen. Ennen kuin ohjelmisto voidaan jul- kaista, se käy läpi perusteellisen testausprosessin varmistaen, että järjestelmä toimii tarkoitetulla tavalla. Ohjelmisto testataan jokaisella neljällä päätasolla, jotta mahdollisimman moni ohjelmistovirhe löydettäisiin. (Pearson 2015.)
KUVIO 2. Ohjelmistotestauksen tasot (Levels of Testing n.d., muokattu)
Yksikkötestauksessa keskitytään testaamaan ohjelman pienimpien testattavien kokonaisuuksien toimivuutta ja tarkastellaan, että ne vastaavat suunnitelmaa. Tä- män usein suorittaa ohjelmistokehittäjä esimerkiksi testaamalla yksittäisten funk- tioiden toimintaa. (Pearson 2015.)
Integraatiotestauksen tarkoitus on varmistaa, että ohjelman eri moduulit ja palve- lut toimivat yhdessä (The different types… n.d.). Ideana on käyttää yksikkötes- tauksen testejä ja tehdä niistä kokonaisuus, joka vastaa ohjelmiston suunnitel- maa. Integraatiotestauksen voi jakaa eri osa-alueisiin. Tällaisia osa-alueita ovat esimerkiksi mustalaatikkotestaus, mistä selviää ulostulot, sekä valkolaatikkotes- taus, mistä selviää, miten tulokseen päästiin. Ohjelmistotestaajat suorittavat in- tegraatiotestauksen. (Kritka 2020.)
Järjestelmätestaus on ensimmäinen testaustaso, jossa ohjelma testataan koko- naisena tuotteena. Siinä varmistetaan, että ohjelmisto vastaa asiakkaan asetta- miin laadullisiin, teknisiin, funktionaalisiin sekä liiketoiminnallisiin vaatimuksiin.
(Pearson 2015.)
Neljäs ja ylin testaustaso on hyväksymistestaus, jonka suorittavat loppukäyttäjät.
Testaajat tarkistavat, täyttääkö ohjelmisto heidän tarpeensa ja voiko sen jul- kaista. (Pearson 2015.) Hyväksyntätestien edellytyksenä on koko ohjelmiston jul- kaisukuntoon saattaminen, ja testeissä pyritään imitoimaan loppukäyttäjien käy- töstä aidossa ympäristössä (The different types… n.d.).
2.3 Testaustyypit ja -menetelmät
Ohjelmistotestaus voidaan jakaa funktionaaliseen ja ei-funktionaaliseen testauk- seen testauksen kohteen mukaan. Funktionaalisessa testauksessa tarkastellaan järjestelmän toimintaa ja ei-funktionaalisessa testauksessa testataan ohjelmiston toimintakykyä. (Software Testing Methodologies n.d.)
Funktionaalista testausta ovat esimerkiksi regressiotestaus, savutestaus ja yksikkötestaus (Functional Testing vs Non-Functional Testing n.d.). Regressio- testaus tarkoittaa aiemmin toimivaksi todetun toiminnallisuuden uudelleen tes- tausta muutoksen jälkeen (Ohjelmistotestaus parantaa laatua 2018). Savutes- taus on yksinkertainen testi, jolla testataan järjestelmän perustoiminnallisuutta.
Niiden tarkoitus ei ole testata koko järjestelmän toimivuutta, vaan vain sen verran, että voidaan todeta, onko järjestelmä jollain tasolla käytettävissä vai onko se täy- sin käyttökelvoton. (Koskela 2018, 12.)
Ei-funktionaalista testausta on esimerkiksi tietoturva-, kuormitus-, stressi- ja käy- tettävyystestaus. Tietoturvatestauksen tavoitteena on estää tavallista tai pahan- tahtoista käyttäjää tekemästä haittaa järjestelmälle, testaamalla sitä haavoittu- vuuksien varalta. Kuormitustestauksen tarkoitus on testata, että järjestelmä voi toimia vaaditulla vasteajalla kuormituksen alla. Stressitestaus puolestaan selvit- tää, millä kuormituksella järjestelmä kaatuu. Käytettävyystesteillä testataan jär- jestelmää loppukäyttäjien näkökulmasta. Sen avulla pyritään varmistamaan, onko järjestelmä selkeä käyttää ja helppo oppia. (Software Testing Methodolo- gies n.d.)
Tutkiva testaus on yleensä vähemmän suunniteltua ja siihen voi kuulua sekä funktionaalista että ei-funktionaalista testausta (VALA Group n.d.). Tutkiva tes- taus on samanaikaisesti oppimista sekä testien suunnittelua ja suoritusta. Sen testitapauksia ei suunnitella kattavasti etukäteen, mutta testaus ei myöskään etene täysin sattumanvaraisesti. Tutkivaa testausta kannattaa ensisijaisesti to- teuttaa sprintin yhteydessä testaamaan monipuolisesti uusia lisättyjä ominai- suuksia ennalta määrättyjen testitapausten ulkopuolelta. (Testaus ketterissä me- netelmissä n.d., 5–6.)
2.4 Testien kattavuus
Testikattavuus on mittari, jota käytetään ilmoittamaan, kuinka iso osa järjestel- mästä on katettu testein. Se on hyvin hyödyllinen ja tärkeä, sillä sen avulla arvi- oidaan testauksen laatua. (An introduction to code coverage n.d.) Testikattavuu- den laskemiseen on valmiita työkaluja (kuva 1), jotka laskevat suoraan koodista testien kattavuusprosentin. Työkalu antaa normaalisti raportin testikattavuu- desta, josta käy ilmi testatut osiot, koodista löydetyt osiot ja kattavuusprosentti.
Kattavuusprosentti lasketaan testattujen ja löydettyjen osioiden suhteesta. (An introduction to code coverage n.d.)
KUVA 1. JetBrains dotCover-yksikkötestaustyökalun raportti (JetBrains n.d.)
Kuvassa 1 on esimerkkinä JetBrainsin yksikkötestaustyökalun raportti. Siinä näy- tetään vasemmalla projektin sisältö ja samalla rivillä oikealla niitä vastaavat yk- sikkötestien kattavuudet. Raportista on hyötyä määritettäessä prioriteetit ohjel- mistokehityksessä ja laadunvarmistuksessa (JetBrains n.d.).
Riittävä testaus on hyvin järjestelmäkohtaista. Korkea testikattavuusprosentti ei aina tarkoita, etteikö virheitä olisi, jos järjestelmän kriittiset osat on jätetty täysin testaamatta. Yleisesti kuitenkin 80 % testikattavuutta pidetään hyväksyttävänä tavoitteena ja sitä suuremman testikattavuuden tavoitteleminen saattaa tulla kal- liiksi ja suhde hyötyihin laskea. (An introduction to code coverage n.d.)
Ohjelmistojen yksikkötestauksessa on yksinkertaista laskea testien kattavuus- prosentti, mutta automaatiotestauksessa se on hieman monimutkaisempaa. Yksi tapa on tehdä käyttöliittymäsuunnittelukaavio, joka sisältää navigoinnin näkymien välillä sekä käyttöliittymäkomponentit. Näiden avulla voisi laskea suuntaa anta- van testikattavuusprosentin.
3 AUTOMAATIOTESTAUS
Automaatiotestaus on ohjelmistotestausta, jossa testit ajetaan automaatiotyöka- luja käyttäen (Kinsbruner 2020). Sen tarkoituksena ei ole korvata manuaalisesti tapahtuvaa testausta, vaan tukea eri testaustyyppejä ja -vaiheita. Hyvin toteutettu automaatiotestaus vähentää manuaalisen regressiotestauksen tarvetta ja va- pauttaa testaajien resursseja tutkivaan testaukseen. (Murtosalo 2015, 17.) Auto- maatiotestausta on suositeltavaa hyödyntää laajoissa ohjelmistoissa ja niissä, joissa on odotettavissa lisäkehitystyötä tulevaisuutta ajatellen (Testausautomaa- tio tehostaa laadunvarmistusta 2018).
3.1 Automaatiotestauksen hyödyt
Automaatiotestauksella on useita käyttökohteita ja hyötyjä tukemaan ohjelmisto- kehitystä. Ohjelmistotekniikan alalla suosioon on viimevuosina noussut tehokas CI/CD-prosessi, joka tarkoittaa suoraan käännettynä jatkuvaa integraatiota ja jat- kuvaa julkaisemista. Automaatiotestaus on tässä tärkeässä roolissa. (Kinsbruner 2020.) Automaatiotestit suoriutuvat tehtävästä nopeammin kuin ihminen, joten myös testitulosten saaminen on nopeampaa.
Testien tulokset ovat tärkeää informaatiota kehittäjille. Kehittäjä reagoi testitulok- siin, tekee tarvittavat korjaukset ja palauttaa koodin takaisin testaajille, jonka jäl- keen prosessi alkaa alusta. Kun tämän prosessin suorittaa pitkällä aikavälillä usein, se nopeuttaa tuotteen julkaisemista. (Kinsbruner 2019.) Kun ohjelmistossa oleva virhe havaitaan ajoissa ja se korjataan mahdollisimman aikaisessa vai- heessa, ei virhe pääse julkistetulle tuotteelle. Näin ei pelkästään säästetä rahaa, vaan tehdään myös sujuvaa, siistiä ja helpommin skaalautuvaa koodia. (Kinsbru- ner 2019.)
Manuaalitestauksessa on aina inhimillisen virheen mahdollisuus, jota ei auto- maatiotestauksessa ole. Automaatio kykenee toistamaan eri variaatioita samasta testistä muuttumattomana ja pitkäkestoisesti. (Kinsbruner 2019.) Yksi automaa- tiotestauksen hyödyistä on korkeampi testikattavuus. Automaatio mahdollistaa
testien ajon rinnakkain ja usealla eri laitteella ja käyttöjärjestelmällä. Tämä tuo yrityksille ison edun säästämällä huomattavasti aikaa. Automaatio lisää testikat- tavuutta myös ajamalla enemmän testejä ja erilaisia testaustyyppejä kuin manu- aalisesti testaaminen. (Kinsbruner 2019.)
Vaikka automaatiotestauksessa on paljon hyötyjä, on testituloksien isossa mitta- kaavassa läpikäyminen aikaa vievää. Automatisoituja testejä tulee myös ylläpi- tää, mikä on raskasta ohjelmiston muuttuessa usein. Näistä huolimatta automaa- tiotestaukseen investoiminen kannattaa. Kun automaatiotestaus on kunnossa, testaajille vapautuu resursseja ja he voivat keskittyä muun muassa tutkivaan tes- taukseen. (Kinsbruner 2019.)
3.2 Testausprosessi
Automaatiotestaus on hyvin kustomoitava prosessi, jossa on määritellyt vaiheet (kuvio 3). Ennen kuin testejä voidaan alkaa kehittämään, testaukselle pitää mää- ritellä laajuus, valita työkalut ja teknologiat sekä ottaa käyttöön ja konfiguroida ympäristö. (Tishchenko 2019.)
KUVIO 3. Automaatiotestausprosessin kuvaus (Tishchenko 2019)
Mikä tahansa prosessi alkaa määritelmästä. Testaukselle on syytä valita laajuus, sillä kaikkea ei ole kannattavaa automatisoida. (Tishchenko 2019.) Laajuutta määriteltäessä on otettava huomioon resurssit sekä se, mitkä moduulit ja testit voidaan automatisoida (Intellipaat 2021). Tishchenkon (2019) mukaan automaa- tiotestit tulisi ajaa järjestelmän vakaimmasta osasta, sekä niistä toiminnoista, joita käytetään usein.
Kun testien laajuus on määritelty, valitaan automaatiotyökalut. Erityyppiset raja- pinnat edellyttävät erilaisia työkaluja ja ne määrittelevät pitkälti työkaluryhmän.
Myös tekniikka, jolle järjestelmä on rakennettu, vaikuttaa työkalujen valintaan.
Työkalujen valinnan jälkeen voidaan alkaa toteuttaa ohjelmistokehystä tai valita valmis ohjelmistokehys. Se on pohjana automatisoitujen testien jatkokehittämi- selle ja tarjoaa mahdollisuuden optimoida testikehitystyötä uudelleenkäyttämällä koodia. (Tishchenko 2019.)
Kaikki testit tulee suorittaa automaatioympäristössä, joka on hyvin konfiguroitu.
Ympäristöä käytetään testien suorittamiseen ja tulosten tallentamiseen. Testeihin on myös syytä käyttää testidataa, jolloin testeille valmistellaan oma käyttäjätili ja testitiedostot. (Tishchenko 2019.)
Kun alustavat valmistelut on tehty, testaajat voivat alkaa kehittää automaatiotes- tejä. Uusien testien kehittäminen aloitetaan testitapauksen valinnasta prioriteetin mukaan. Varsinaisen testien luomisen jälkeen ajetaan ja monitoroidaan ajoja, sekä analysoidaan tuloksia. On suositeltavaa asettaa testit käynnistymään vir- heenkorjausajon ja uusien koontiversioiden testisuorituksen yhteydessä. Kun testattavaan järjestelmään tulee päivityksiä tai korjauksia, on testit myös syytä päivittää. (Tishchenko 2019.)
3.3 Agile-testaus
Laadun varmistamiseksi tarvitaan monenlaisia testejä laajassa mittakaavassa.
Tällaisia testejä ovat esimerkiksi koodin, rajapintojen, tietoturvan ja suurempien työnkulkujen testit. Kuvion 4 agile-testausmatriisin vaaka-akseli sisältää liiketoi- mintaan ja teknologiaan kohdistuvia testejä. Vasemmalla pystyakseli ohjaa kehi- tystä antamalla kehitystiimille vaihtoehtoja, kuinka testata tuotosta ennen sen kir- joittamista. Oikealla puoliskolla on testejä vikojen tai puuttuvien ominaisuuksien löytämiseksi. Niiden tehtävänä on arvioida järjestelmän toimintaa käyttäjien vaa- timuksia vasten. (Scaled Agile, Inc. 2021.)
KUVIO 4. Agile-testausmatriisi (Scaled Agile, Inc 2021)
Testien luominen neljälle kvadrantille edistää kattavaa strategiaa, joka auttaa laa- dunvarmistuksessa. Jokaisessa kvadrantissa voidaan suorittaa automaatiotes- tausta. Kvadrantissa Q1 sijaitsee yksikkö-, komponentti- ja yhteystestaus, jotka ovat kaikki automatisoituja. Q2 sisältää funktionaalisen testauksen, jolla varmis- tetaan, että järjestelmä toimii tuotteen omistajan tarkoittamalla tavalla. Resurs- sien salliessa Q2-testit automatisoidaan ja manuaalitestaus suoritetaan, mikäli muuta vaihtoehtoa ei ole. (Scaled Agile, Inc. 2021.)
Kvadrantti Q3 sisältää järjestelmätason hyväksyntätestejä, joilla varmistetaan, että koko järjestelmän toiminta täyttää käytettävyys- ja toiminnallisuusvaatimuk- set. Näihin testeihin luetaan mukaan myös tapaukset, joita kohdataan usein jär- jestelmän käytön aikana. Tällaisia testityyppejä ovat tutkivat testit, hyväksyntä- testit, tapauspohjaiset testit ja käytettävyystestit. Koska edellä mainittuihin testi- tyyppeihin osallistuu käyttäjiä ja testaajia, jotka ovat mukana todellisissa tai simu-
loiduissa käyttöskenaarioissa, ovat testit usein manuaalisia. Ne ovat usein järjes- telmän viimeinen validointi ennen järjestelmän toimittamista loppukäyttäjälle. Osa testeistä voidaan kuitenkin automatisoida. (Scaled Agile, Inc. 2021.)
Kvadrantti Q4 sisältää järjestelmän laatutestauksen, jolla varmistetaan, että jär- jestelmä täyttää ei-toiminnalliset vaatimukset. Tyypillisesti niitä tukee joukko au- tomaattisia testaustyökaluja, jotka on suunniteltu erityisesti tähän tarkoitukseen.
(Scaled Agile, Inc. 2021.)
4 TEKNOLOGIAT
Käyttöliittymien automaatiotestaukseen on olemassa monia ohjelmistokehyksiä eri kohderyhmille. Robot Framework on yksi suosituimmista testaajille suunna- tuista ohjelmistokehyksistä sen vaivattomuuden ja kattavien kirjastojen ansiosta.
(Colantonio 2019.) Robot Frameworkille löytyy neljä erityisesti verkkosivuille suunnattua kirjastoa. Kirjastot ovat SeleniumLibrary, Browser Library, Puppeteer- Library ja QWeb. Näistä QWeb erottuu joukosta korkean tason avainsanojen vuoksi. (Robot Framework n.d.)
4.1 Robot Framework
Robot Framework on Python-pohjainen, avoimen lähdekoodin ohjelmistokehys, joka soveltuu automaatiotestaukseen ja ohjelmistorobotiikkaan. Sen syntaksi koostuu selkokielisistä avainsanoista, mikä tekee siitä helposti luettavan. Sitä voi- daan helposti laajentaa Pythonilla tai Javalla ohjelmoiduilla kirjastoilla. Robot Fra- meworkissa on modulaarinen arkkitehtuuri (kuvio 5), jonka moduulit kommunikoi- vat keskenään rajapintojen kautta. (Robot Framework n.d.)
KUVIO 5. Robot Frameworkin arkkitehtuuritasot (Robot Framework n.d.)
Robot Frameworkin ohjelmistokehyksen tehtävänä on lukea ja käsitellä tietoa, suorittaa testitapauksia sekä luoda raportteja ja lokeja. Kehyksen ydin ei ole tie- toinen testattavasta järjestelmästä, vaan eri kirjastot hoitavat testattavan järjes- telmän varsinaiset vuorovaikutukset. Kirjastot luottavat sovellusrajapintoihin tai matalan tason testityökaluihin ollakseen vuorovaikutuksessa testattavan järjes- telmän kanssa. (Padmanabhan 2019.)
4.2 Kirjastot
Robot Frameworkilla on vakiokirjastojen lisäksi tarjolla useita erilaisia kirjastoja, joissa on valmiita avainsanoja testaukseen. Nämä kirjastot on luotu tukemaan testausta. Robot Frameworkille voi myös kehittää omia kirjastoja Pythonilla ja Ja- valla. (Robot Framework n.d.) Omaa mukautettua kirjastoa ei tarvitse koodata alusta alkaen, vaan kirjastoon voidaan sisällyttää olemassa olevia kirjastoja sekä Python-paketteja. Nämä voidaan integroida oman koodin sekaan. (How to write and… 2021.)
4.2.1 QWeb
QWeb on moderni Robot Frameworkin kirjasto, joka helpottaa verkkosivujen tes- tausta sisäänrakennetuilla avainsanoilla (Robot Framework n.d.). Se on kehitetty automaatiotestaajille tarjoamaan vähäistä huoltoa tarvitsevia ja erittäin luettavia testejä (Qentinel n.d.).
Avainsanat ovat korkean tason avainsanoja, joilla on mahdollista tavoittaa jokai- nen verkkosivun elementti. QWeb mahdollistaa tekstimuotoisten sijaintien pai- kantimien käytön, mutta tukee myös muita paikantimia, kuten XPathia ja CSS- valitsimia. Se osaa käsitellä viivästyksiä ja odottamattomia varoituksia. Nämä kaikki ominaisuudet tekevät automaatiotestauksesta helppoa ja ylläpidettävää.
(QWeb 2021.)
4.2.2 SeleniumLibrary
Selenium on kattoprojekti useille eri työkaluille ja kirjastoille, jotka mahdollistavat selaimen automaattisen ohjaamisen. Seleniumin kirjastoista yksi on Selenium- Library, joka hyödyntää Seleniumin verkkosivujen testaustyökaluja sekä avain- sanoja. Se käyttää Selenium WebDriver -moduuleja sisäisesti selaimen ohjaami- seen. (Robot Framework n.d.)
SeleniumLibraryn tarjoamat avainsanat ovat melko matalan tason avainsanoja ja vaativat usein toteutuskohtaisten argumenttien välittämistä argumenttina. Tästä syystä on tyypillistä käyttää Robot Frameworkin korkeamman tason avainsanoja, sillä ne käyttävät sisäisesti SeleniumLibraryn avainsanoja. (SeleniumLibrary 2021.)
4.3 Jenkins
Jenkins on avoimen lähdekoodin automaatiopalvelin, jonka avulla on mahdollista automatisoida ohjelmistojen ajaminen, testaaminen ja julkaiseminen. Se on tehty tukemaan erityisesti CI/CD-prosessia. Jenkins voi toimia pilvipalveluissa ja käyt- tää niitä hyödyntäviä teknologioita. Tämä antaa Jenkinsille lisää joustavuutta, no- peutta ja luotettavuutta vastaamaan nykypäivän modernien pilvi- ja mikropalve- lupohjaisten järjestelmien vaatimuksiin. (Munetsi 2020.) Myös Robot Framework testien ajo voidaan integroida osaksi Jenkinsillä toteutettua CI/CD-prosessia.
Jenkinsillä on kattava valikoima erilaisia laajennuksia ja siitä on tehty helposti laajennettava mahdollistamalla lisäosien asentaminen. Sillä voi myös jakaa työn useille koneille, mikä auttaa nopeuttamaan ajoja, testejä sekä ohjelmistojen käyt- töönottoja uusille alustoille. (Jenkins n.d.)
5 TESTAUKSEN TOTEUTTAMINEN ─ CASE FIMLAB
Terveydenhuoltoalalla ei ole varaa vakaviin virheisiin ja virheet järjestelmissä voi- vat pahimmassa tapauksessa vaarantaa asiakkaan terveyden. Tämän takia jär- jestelmien testaus on erityisen tärkeää, eikä kaikkea testausta kannata tai voi automatisoida.
5.1 Testaus terveydenhuoltoalalla
Terveydenhuoltoalan järjestelmien testaus eroaa muiden alojen järjestelmien tes- tauksesta erityisen perusteellisella testaamisella. On hyvin tärkeää, että testaus on laadukasta, monipuolista sekä mahdollisimman lähellä tosielämän tilanteita.
Testausta on myös syytä toistaa kohtalaisen usein.
Testeihin käytetään testidataa, sekä jokaisessa vaiheessa tarkistetaan sanoma- tasolla, mitä toimintoja tapahtuu. Testauksen aikana tarkistetaan, että oikeat asiat ovat päätyneet jokaiseen järjestelmään, mihin niiden kuuluu saapua. Tämä tar- koittaa, että monitahoisen järjestelmän toiminnan varmistamiseksi tarvitaan useita eri järjestelmäasiantuntijoita varmistamaan, että järjestelmä toimii toivo- tulla tavalla.
5.2 Testausroolit
Fimlabilla on useita massiivisia järjestelmäkokonaisuuksia, joita kehitetään sekä ylläpidetään jatkuvasti. Jotta järjestelmäkokonaisuuksien toiminta pysyisi mah- dollisimman laadukkaana, eri järjestelmien osat ovat jaettu eri tiimeille. Tiimeissä on tuoteomistaja, tiiminvetäjä, järjestelmäasiantuntijoita sekä useita kehittäjiä.
Osa Fimlabin järjestelmäasiantuntijoista on siirtynyt laboratorion puolelta tietohal- lintoon töihin kehittämään, testaamaan ja ylläpitämään järjestelmiä, joita he ovat käyttäneet aikaisemmissa työtehtävissään. Järjestelmäasiantuntijat päättävät mitä testataan ja laativat testaussuunnitelmat julkaisuille. Tämän jälkeen testaajat toteuttavat manuaalitestauksen järjestelmälle. Järjestelmäasiantuntijat testaavat
myös integraatiot muihin terveydenhuoltoalan järjestelmiin, joihin yhteys on muo- dostettu.
Ohjelmistokehittäjät tekevät yksikkötestausta, jossa he testaavat yksittäisiä pie- niä kokonaisuuksia, kuten funktioita. Järjestelmäasiantuntijat ovat vastuussa jär- jestelmä- ja hyväksymistestauksesta. Automaatiotestit on luotu tukemaan järjes- telmätestausta ja vähentämään järjestelmäasiantuntijoiden taakkaa.
5.3 Teknologioiden valitseminen
Automaatiotestaustyökaluksi Fimlabille on valittu Robot Framework, joka on suunnattu pääasiassa testaajille. Se on Suomessa alkunsa saanut ohjelmistoke- hys, jolle on kattavat kirjastot muun muassa verkkosivujen käyttöliittymien tes- taukseen. Robot Frameworkin testien syntaksi on helppolukuista, mikä auttaa testien kehittämisessä. Myöskin testiajojen raportit ovat selkeitä, mikä auttaa kaikkia raportin lukijoita ymmärtämään niiden sisältöä.
Kirjastoksi valikoitui QWeb, sillä se on suunnattu verkkosivujen testaamiseen ja sisältää kattavasti siihen sopivia avainsanoja. Tämän lisäksi testeihin tarvitaan paikoittain SeleniumLibrary- ja Collections-kirjaston avainsanoja. Jotta testejä voitaisiin helposti ajaa ajastetusti, tarvitaan automaatiopalvelin. Jenkins on ollut jo aiemmin käytössä Fimlabilla muihin ylläpidollisiin tarkoituksiin, joten automaa- tiotestit oli helppo sijoittaa palveluun.
5.4 E2E-regressiotestien kuvaus
Yksi opinnäytetyön tavoitteista oli kehittää Fimlabille automatisoituja regressio- testejä järjestelmille. Järjestelmien komponenttien ja tapahtumaketjujen testaus eivät eroa toisistaan testien tasolla, mutta niille on omanlaisensa tarkoitus. Kom- ponenttien testaus on kohdennettu järjestelmän yhden osan toimintaan, jotka aje- taan erillään muista testeistä. E2E-testeissä (koko järjestelmän testaus päästä päähän) testataan tapahtumaketjua usean järjestelmän ja niiden komponenttien läpi. Yksi testein katettu tapahtumaketju on esimerkiksi näytteen elinkaari (liite 1),
joka alkaa tutkimuksen tilaamisesta ja loppuu vastausten antamiseen ja tulosten tarkastelemiseen (kuvio 6).
KUVIO 6. BPMN-kaavio E2E-testauksesta
Kyseisessä E2E-testissä käydään läpi kolme eri järjestelmää: A, B ja C. Järjes- telmässä A voidaan tehdä tutkimusten tilaus ja näytteenotto. Näytteenotossa on tärkeää saada näytenumero, jolla tunnistetaan näyte. Järjestelmässä B voidaan tarkastella potilaan tutkimusten tilauksia, päivittää näytteen kuljetustietoja, sekä erikoisalasta riippuen katsoa erilaisia kuvia, jotka liittyvät diagnosointiin. Järjes- telmässä C voidaan muun muassa tarkastella ja antaa tutkimustuloksia.
E2E-testi alkaa järjestelmä A:sta, jossa tilataan erilaisesti paketoituvia tutkimuk- sia testipotilaalle. Sanoma kulkee järjestelmien välillä HL7-standardin (terveys- palvelualan kansainvälinen standardi informaation lähettämiseen) muodossa.
Näytteenotto tapahtuu myös järjestelmä A:ssa, josta saadaan tulostettua näyt- teelle näytenumero.
Näytteenoton jälkeen tutkitaan järjestelmistä A ja B, että näyte on otettu. Tämän jälkeen näyte kuitataan matkalle laboratorioon tutkittavaksi järjestelmä B:ssä.
Kun näytekuljetus on saapunut laboratorioon, näyte siirtyy tutkittavaksi. Testita-
pauksessa näytteelle annetaan tutkimustulos järjestelmässä C. Tutkimustulok- sen antamisen jälkeen näytettä voidaan tarkastella kaikista kolmesta järjestel- mästä.
5.5 Testien tuomat hyödyt ja löydetyt ongelmat
Jos testit eivät mene läpi muutoksien jälkeen, ne tarkastetaan manuaalisesti. Jos kyseessä on virhe järjestelmässä, siitä tehdään korjauspyyntö sekä raportoidaan kehitystiimille. Fimlabille tehdyt testit ovat havainneet regressiota järjestelmien komponenttien testauksessa. E2E-testissä käytetään samoja komponentteja, jo- ten komponenttien testeissä ilmenneet ongelmat heijastuvat myös E2E-testeihin.
Tämä johtaa E2E-testin epäonnistumiseen, mutta itse tapahtumaketjussa ei ole ilmennyt ongelmia ja näytteiden elinkaari on toiminut virheittä.
Testien lisääminen Jenkinsiin ajoon Linux-virtuaalikoneelle aiheutti alussa ongel- mia, kun testit käyttäytyivät hieman eri tavalla kuin lokaalisti Windowsilla ajetta- essa. Tämä korjattiin käyttämällä tiettyihin kohtiin, kuten selaimen avaamiseen, SeleniumLibrary-avainsanoja. Testien ajot ovat epäonnistuneet satunnaisesti sa- nomaliikenteen hitauden vuoksi ja tätä on korjattu lisäämällä viiveitä ja odotusai- koja testeihin.
Automaatiotestit on suoritettu järjestelmän testiympäristössä, jonka kriittiset osat ovat toimineet hyvin. On kuitenkin huomioitava, että testiympäristö on jatkuvasti kehitysvaiheessa ja virheitä on osattu odottaa. Automaatiotestit ovat hyödyttä- neet kehittäjiä luomalla turvaa järjestelmän kehittämiselle. Myös testaajat ovat hyötyneet automaatiotesteistä, sillä se on vähentänyt manuaalitestauksen tar- vetta.
6 POHDINTA
Opinnäytetyöprosessi alkoi teknologioiden opettelusta, sillä tekijällä ei ollut aiem- paa kokemusta Robot Frameworkista. Fimlabilla automaatiotestaus oli opinnäy- tetyöprosessin alussa hyvin alkutekijöissä. Työn lopussa automaatiotestausre- sursseja on kasvatettu ja iso osa järjestelmistä on saatu katettua testein. Käytet- tävät teknologiat oli valittu ennen työn alkua, ja ne sopivatkin erinomaisesti tähän käyttötarkoitukseen. Robot Framework on hyvin suoraviivainen käyttää testien kehittämiseen ja sen kirjastot ovat hyvin kattavia. Luoduista automaatiotesteistä on ollut hyötyä kehittäjille, sekä ne ovat tuoneet helpotusta järjestelmien testaa- jille.
Ongelmia ilmeni, kun testit laitettiin ensimmäistä kertaa Linux-virtuaalikoneelle ajoon. Se suoritti osan testeistä eri tavalla, mikä johtui Chromen avaamisesta.
Ongelma kierrettiin vaihtamalla QWebin selaimen avaamiseen käytettävä avain- sana vastaavaan SeleniumLibraryn avainsanaan. Toinen ongelma, sanomalii- kenteen viive, on ilmennyt läpi kehityksen. Tämä on kierretty testeissä pidentä- mällä odotusaikoja. Aika ajoin sanomaliikenteessä on kuitenkin ruuhkaa, eikä pi- dennetty odotusaika ole aina tarpeeksi pitkä. Tälle pitäisi kehittää tulevaisuu- dessa mahdollisimman pitkäikäinen korjaus. Muita kehitysehdotuksia testeille olisi testikattavuuden lisääminen ajamalla testit eri selaimilla, joilla järjestelmiä käytetään.
Haasteita työstä löytyi, mutta myös ratkaisut niihin löytyivät helposti. Automaatio- testien kehittämisessä hyödynnettiin valittuja kirjastoja monipuolisesti. Kokonai- suudessaan opinnäytetyöprosessi oli opettavainen ja toimeksiantajalle hyödylli- nen. Automaatiotestauksen kehitys jatkuu Fimlabilla ja siitä on tullut luonnollinen osa kehitystoimintaa.
LÄHTEET
An introduction to code coverage. n.d. Pittet, S. Verkkosivu. Viitattu 14.10.2021.
https://www.atlassian.com/continuous-delivery/software-testing/code-coverage Chowdhury, A. 2021. What Is Software Testing? Testim-blogi 29.6.2021. Viitattu 12.9.2021. https://www.testim.io/blog/software-testing-basics/
Colantonio, J. 2019. 11 top open-source test automation frameworks: How to choose. Techbeacon-blogi 2019. Viitattu 11.11.2021. https://tech-
beacon.com/app-dev-testing/top-11-open-source-testing-automation-fra- meworks-how-choose
Fimlab. n.d. Verkkosivu. Viitattu 21.11.2021. https://fimlab.fi/media
Functional Testing vs Non-Functional Testing. n.d. Pedamkar, P. Educba-blogi n.d. Viitattu 8.11.2021. https://www.educba.com/functional-testing-vs-non-func- tional-testing
How to write and use custom Robot Framework Python RPA libraries. 2021.
Verkkosivu. Viitattu 11.11.2021. https://robocorp.com/docs/development- guide/robot-framework/how-to-use-custom-python-libraries-in-your-robots Intellipaat. 2021. What is Automation Testing? Definition, Types, Tools, Scope and Benefits. IntelliPaat-blogi 20.10.2021. Viitattu 18.11.2021. https://intelli- paat.com/blog/what-is-automation-testing/
ISO 25010. n.d. System and software quality models. International Standards Organization. Viitattu 7.11.2021. https://iso25000.com/index.php/en/iso-25000- standards/iso-25010
Jenkins. n.d. Verkkosivu. Viitattu 11.11.2021. https://www.jenkins.io/
JetBrains. n.d. Verkkosivu. Viitattu 14.10.2021. https://www.jet- brains.com/resharper/features/unit_testing.html
Kinsbruner, E. 2019. Top 7 Test Automation Benefits. Verkkosivu. Viitattu 26.8.2021. https://www.perfecto.io/blog/7-test-automation-benefits
Kinsbruner, E. 2020. What Is Test Automation?. Verkkosivu. Viitattu 26.8.2021.
https://www.perfecto.io/blog/what-is-test-automation
Koskela, L. 2018. Automaattinen ohjelmistotestaus mikropalveluarkkitehtuu- rissa. Tietotekniikan tutkinto-ohjelma. Tampereen teknillinen yliopisto. Kandi- daatintutkielma.
Kritka. 2020. Types of Software Testing. GeeksforGeeks-blogi 23.12.2020. Vii- tattu 10.9.2021. https://www.geeksforgeeks.org/types-software-testing/
Levels of Testing. n.d. Verkkosivu. Viitattu 10.9.2021. https://www.ja- vatpoint.com/levels-of-testing
Munetsi, T. 2020. What Is Jenkins Used For?. OpenLogic-blogi 6.3.2020. Vii- tattu 24.9.2021. https://www.openlogic.com/blog/what-is-jenkins-used-for Murtosalo, J. 2015. Automaatiotestaus. Tietojenkäsittelyn koulutusohjelma. Lau- rea-ammattikorkeakoulu. Opinnäytetyö.
Ohjelmistotestaus parantaa laatua. 2018. ATR Soft Oy. Verkkosivu. Viitattu 8.11.2021. https://www.atrsoft.com/2018/01/04/ohjelmistotestaus-parantaa-laa- tua/
Padmanabhan, A. 2019. Robot Framework. Devopedia-blogi 1.8.2019. Viitattu 11.11.2021. https://devopedia.org/robot-framework
Pearson, L. 2015. The Four Levels of Software Testing. Verkkosivu. Viitattu 10.9.2021. https://www.seguetech.com/the-four-levels-of-software-testing/
Qentinel. n.d. Verkkosivu. Viitattu 11.11.2021. https://qentinel.com/qweb-open- source-automation-library/
QWeb. 2021. Verkkosivu. Viitattu 11.11.2021. https://github.com/qenti- nelqi/qweb
Robot Framework. n.d. Robot Framework Foundation. Verkkosivu. Viitattu 24.9.2021. https://robotframework.org/
Scaled Agile, Inc. Päivitetty 10.2.2021. Agile Testing. Verkkosivu. Viitattu 18.11.2021. https://www.scaledagileframework.com/agile-testing/
SeleniumLibrary. 2021. Verkkosivu. Viitattu 11.11.2021. https://github.com/ro- botframework/SeleniumLibrary
Software Testing Methodologies. n.d. Pedamkar, P. Educba-blogi n.d. Viitattu 8.11.2021. https://www.educba.com/software-testing-methodologies/
Testaus ketterissä menetelmissä. n.d. Pdf-dokumentti. Viitattu 9.11.2021.
https://www.cs.helsinki.fi/u/mluukkai/ohtu2016/luento7.pdf
Testausautomaatio tehostaa laadunvarmistusta. 2018. ATR Soft Oy. Verk- kosivu. Viitattu 26.8.2021. https://www.atrsoft.com/2018/02/12/testausau- tomaatio-tehostaa-laadunvarmistusta/
The different types of software testing. n.d. Pittet, S. Verkkosivu. Viitattu 12.9.2021. https://www.atlassian.com/continuous-delivery/software-testing/ty- pes-of-software-testing
Tishchenko, D. 2019. Verkkosivu. Viitattu 18.11.2021.
https://www.a1qa.com/blog/test-automation-process-overview/
VALA Group. n.d. Laadunvarmistus ja ohjelmistotestaus. Ite wiki -blogi n.d. Vii- tattu 9.11.2021. https://www.itewiki.fi/opas/laadunvarmistus-ja-ohjelmistotes- taus/
LIITTEET
Liite 1. Fimlabin palveluväylän kuvaus (Fimlab Laboratoriot Oy 2021)
