Automaatiotestauksen kehittäminen eBusiness Suite- alustalle
Erica Kytösaho
2021 Laurea
Laurea-ammattikorkeakoulu
Automaatiotestauksen kehittäminen eBusiness Suite- alustalle
Erica Kytösaho
Tietojenkäsittelyn koulutusohjelma Opinnäytetyö
toukokuu, 2021
Laurea-ammattikorkeakoulu Tiivistelmä Tietojenkäsittelyn koulutus
(AMK)
Erica Kytösaho
Automaatiotestauksen kehittäminen eBusiness Suite- alustalle
Vuosi 2021 Sivumäärä 38
Tämän opinnäytetyön tavoitteena oli kehittää edelleen automaatiotestausta Visma Consulting Oy:n eBusiness Suite- alustan asioinnin ja käsittelyn käyttöliittymien regressiotestauksen tar- peisiin. Tavoitteena oli automatisoida julkaisutestausta, jotta testaajien resursseja voitaisiin hyödyntää muussa testaamisessa.
Koska julkaisujen yhteydessä suoritettavien regressiotestitapausten määrä on niin laaja, tällä opinnäytetyöllä ei tavoiteltu niiden kaikkien automatisointia, vaan tarkoituksena oli selvittää, miten automaatiotestausvälineitä voidaan hyödyntää parhaiten ylläpidettävyyden ja helppo- käyttöisyyden näkökulmasta.
Tämä opinnäytetyö on kehittämistyö, jonka tarkoituksena oli tuottaa käytäntöön soveltuvia automatisoituja regressiotestitapauksia sekä tuottaa vertailua valittujen testaustyökalujen välillä. Aluksi opinnäytetyössä käsiteltiin ohjelmistotestausta ja sen teoriaa yleisellä tasolla, jonka jälkeen syvennyttiin tarkemmin kohdeyrityksen lähtökohtiin automaatiotestauksen osalta sekä millaisia haasteita automaatiotestaukseen liittyy yleisellä tasolla. Lopuksi vielä keskityttiin kehittämistyön toteutukseen ja sen aikana saavutettuihin tuloksiin sekä niihin haasteisiin, jotka tulivat esille kehittämistyön aikana.
Kehittämistyön tarkoituksena oli erityisesti selvittää millä tavoin testitapauksia voidaan luoda Selenium-kirjastoja hyödyntäen kehitysympäristössä, Selenium IDE:llä sekä Katalon Studiolla.
Testitapauksia luotiin Java- ohjelmointikielellä Eclipse IDE-kehitysympäristössä hyödyntäen Seleniumin kirjastoja sekä tutkittiin millä tavoin testitapauksia voitiin luoda Selenium IDE:llä ja Katalon Studiolla.
Asiasanat: automaatiotestaus, BrowserStack, Selenium, regressiotestaus, Katalon Studio
Laurea University of Applied Sciences Abstract Degree Programme in Business Information Technology
Bachelor’s Thesis
Erica Kytösaho
Test Automation Development for eBusiness Suite Platform
Year 2021 Pages 38
The aim of this thesis was to develop further automation testing for the regression testing needs of Visma Consulting LTD’s eBusiness Suite platform for transaction and processing user interfaces. The goal was to automate release testing so that testers’ resources could be utilized in other testing.
Because the number of regression test cases performed in release testing is so large, the aim of this thesis was not to automate all of them, but to find out how automation testing tools can be best utilized from the point of view of maintainability and ease of use.
This thesis is a development work, which purpose was to produce automated regression test cases suitable for practice and to provide a comparison between the selected automation testing tools. Initially, the thesis focused on software testing and its theory at a generel level, after which focus was set to deeper level on target company’s base-line position for
automation testing and what kind of challenges are associated with automation testing at a general level. Finally, the focus was on the implementation of the development work and the results achieved during it, as well as on the challenges that emerged during the development work.
The purpose of the development work was especially to find out how automation test cases can be created using Selenium libraries in the development environment, with the Selenium IDE and the Katalon Studio. Test cases were created in the Java programming language in the Eclipse IDE development environment using Selenium libraries and it was also analyzed how test cases could be created with Selenium IDE and Katalon Studio.
Keywords: test automation, BrowserStack, Selenium, regression testing, Katalon Studio
Sisällys
1 Johdanto ... 7
2 Työn lähtökohdat ... 7
2.1 Toimeksiantaja ... 8
2.2 Kehitystyön tavoite ... 8
2.3 Aihealueen rajaus ... 8
2.4 Keskeiset käsitteet ... 9
3 Ohjelmistotestaus ... 10
3.1 Ohjelmistotestauksen tavoitteet ... 12
3.2 Ohjelmistotestauksen tasot ... 12
3.2.1 Yksikkötestaus ... 12
3.2.2 Integraatiotestaus ... 13
3.2.3 Järjestelmätestaus ... 13
3.2.4 Hyväksymistestaus ... 14
3.3 Ohjelmistotestauksen tyypit ... 15
3.3.1 Toiminnallinen testaus ... 15
3.3.2 Ei-toiminnallinen testaus ... 15
3.3.3 Lasilaatikkotestaus ... 15
3.3.4 Muutokseen pohjautuva testaus ... 16
3.4 Ohjelmistotestauksen tekniikat ... 16
3.4.1 Musta laatikko- testaus ... 16
3.4.2 Lasilaatikkotekniikat ... 17
3.4.3 Harmaa laatikko- testaus ... 17
3.4.4 Staattinen ja dynaaminen testaus ... 18
3.4.5 Regressiotestaus ... 18
3.5 Ketterä testaus ... 19
3.5.1 Scrum ... 19
3.5.2 Kanban ... 19
3.6 Automaatiotestaus ... 20
4 Automaatiotestaus asiakasyrityksessä ... 20
4.1 Lähtötilanne ... 20
4.2 Saavutettavat hyödyt ... 21
4.3 Automaatiotestauksen yleiset haasteet ... 21
4.4 Automatisoitavat regressiotestitapaukset ... 21
4.5 Automaatiotestaukseen käytettävät työkalut ... 22
4.5.1 BrowserStack ... 22
4.5.2 Selenium ... 23
4.5.3 Katalon Studio ... 23
5 Kehittämistyön toteutus ... 24
5.1 Automatisoitavien regressiotestitapausten valitseminen ... 24
5.2 eBusiness Suite ... 24
5.3 Testitapausten luonti Eclipse IDE- kehitysympäristössä Selenium- kirjastoa hyödyntäen ... 26
5.4 Testitapausten luonti Selenium IDE:llä ... 27
5.5 Testitapausten luonti Katalon Studiolla ... 28
5.6 Automaatiotestaustyökalujen valinta ja vertailu ... 30
6 Kehittämistyön tulokset ... 31
6.1 Automatisoidut regressiotestitapaukset ... 31
6.2 Havaitut ongelmat ... 32
7 Yhteenveto ... 34
8 Oman oppimisen arviointi ... 35
Lähteet ... 36
Kuviot ... 38
1 Johdanto
Tämän opinnäytetyön tavoitteena on selvittää millä tavoin sekä millä Seleniumiin pohjautu- valla automaatiotestaustyökalulla regressiotestausta voidaan kehittää edelleen toimeksianta- jana toimivan Visma Consulting Oy:n Digital Services- liiketoimintayksikön tarpeisiin.
Tarkoituksena on myös tuottaa automatisoituja regressiotestitapauksia toimeksiantajan käyt- töön valitulla automaatiotestaustyökalulla sekä selvittää automaatiotestaukseen liittyvien työkalujen hyödynnettävyyttä ylläpidettävyyden ja helppokäyttöisyyden näkökulmasta sekä tuottaa vertailua näiden välillä.
Automaatiotestauksen tarkoituksena on hyödyntää automaatiotestaustyövälineitä toistuvasti suoritettavien testitapausten testauksien yhteydessä. Automaatiotestaustyökalut voivat olla organisaation itsensä kehittämiä tai vaihtoehtoisesti valmiita työkaluja. Automaatiotestauk- sen tarkoituksena on nopeuttaa testausprosessia sekä mahdollistaa resurssien kohdentamisen muuhun testaukseen.
Opinnäytetyön alussa käsitellään työn lähtökohtia sekä ohjelmistotestausta ja sen teoriaa yleisellä tasolla. Tämän jälkeen paneudutaan tarkemmin kohdeyrityksen lähtökohtiin auto- maatiotestauksen osalta sekä sen yleisiin haasteisiin ja lopuksi vielä syvennytään kehittämis- työn toteutukseen, sen tuloksiin sekä havaittuihin ongelmakohtiin.
2 Työn lähtökohdat
Tämän opinnäytetyön aihe on syntynyt Visma Consulting Oy:n Digital Services- liiketoimin- tayksikön testaustiimin käytännön tarpeesta. Automaatiotestauksen kehittäminen edelleen on osa laajempaa automaatiotestauksen jatkokehitysprosessia, ja lähiaikoina sen tärkeys on muodostunut ajankohtaiseksi asiaksi monesta syystä, jonka vuoksi mahdollisuuksia lisäkehityk- seen haluttiin lähteä tutkimaan vielä enemmän.
Visma Consulting Oy:llä on BrowserStack- lisenssi käytettävänään ja ajatus sen hyödyntämi- sestä automaatiotestauksessa tuli esille tämän työn aihealuetta tarkastellessa. Tarkoituksena oli kuitenkin myös teettää vertailua erilaisten, Seleniumiin pohjautuvien automaatiotestaus- työkalujen välillä sillä tavoitteella, että niiden avulla tuotetut testitapaukset voidaan yhdis- tää BrowserStackiin.
Opinnäytetyön aikana tarkoituksena oli arvioida Selenium- pohjaisten automaatiotestaustyö- kalujen sopivuutta sekä toimivuutta helppouden ja ylläpidettävyyden näkökulmasta sekä tuot- taa käyttökelpoisia automatisoituja regressiotestitapauksia edelleen hyödynnettäväksi.
2.1 Toimeksiantaja
Visma Consulting Oy on IT- konsultointiin ja ohjelmistoratkaisuihin keskittyvä palveluyritys, joka on osa pohjoismaista Visma- konsernia. Visma Consulting Oy:n osaamisaluetta ovat mm.
digitaaliset palvelut, palvelumuotoilu, räätälöidyt IT- ratkaisut sekä tiedolla johtaminen.
(Visma Consulting Oy 2021a.)
Opinnäytetyö toteutetaan Visman Digital Services- yksikön sähköisen asioinnin alustan eli Visma eBusiness Suiten tarpeisiin, erityisesti testaustiimin käyttöön. Sähköisen asioinnin alusta perustuu avoimen lähdekoodin lisenssiin, joka mahdollistaa kustannustehokkaan ja joustavan järjestelmän, joka on helposti räätälöitävissä asiakkaan liiketoimintaprosessin mu- kaiseksi (Visma Consulting Oy 2021b).
2.2 Kehitystyön tavoite
Tämän kehitystyön tavoitteena on pyrkiä kehittämään automaatiotestausta edelleen erityi- sesti eBusiness Suite- alustan regressiotestauksen tarpeisiin. eBusiness Suite- eli eBS- alustaa käytetään pääasiallisesti dedikoiduissa SaaS- ympäristöissä. Alustan SaaS- ympäristöihin jul- kaistaan uusia versioita tasaisin väliajoin, ja tällä hetkellä jokainen versio testataan regressio- testauksella testiympäristössä ennen kuin versio julkaistaan asiakkaiden tuotantoympäris- töissä. Automaatiotestausta on tarkoitus kehittää nimenomaan regressiotestauksen tarpeisiin versioiden julkaisuvaiheessa, jotta testaajien työaikaa vapautuisi lisää muuhun testaamiseen.
Automaatiotestauksella ei kuitenkaan ole tarkoitus korvata manuaalitestausta kokonaisuudes- saan.
Erityisiä kysymyksiä kehittämistyössä ovat mm. se millä tavalla BrowserStack- lisenssiä kye- tään hyödyntämään automaatiotestauksen kehittämisessä, millaisia regressiotestitapauksia on parasta automatisoida sekä millä tavalla ja millä Seleniumiin pohjautuvalla automaatiotes- taustyökalulla testitapaukset saadaan mahdollisimman helpoksi ylläpidettävyydeltään ja käy- tettävyydeltään.
2.3 Aihealueen rajaus
Opinnäytetyö rajoittui nimenomaan automaatiotestauksen kehittämiseen regressiotestauksen yhteyteen eBS- alustalle. Automatisoitavat testitapaukset rajoittuivat vain regressiotestita- pauksiin, joista rajattiin erikseen pois sellaiset testitapaukset, jotka vaativat käyttöliittymän visuaalisen ilmeen tarkistusta sekä esimerkiksi liitteen lisäämistä lokaalilta tietokoneelta käyttöliittymään. Tarkoituksena ei ollut tuottaa suurta määrää automatisoituja
regressiotestitapauksia, vaan joitakin helposti muokattavissa olevia ja monikäyttöisiä testita- pauksia. Opinnäytetyössä ei käsitelty myöskään tarkemmin eBS- alustaan liittyviä teknologisia ratkaisuja.
2.4 Keskeiset käsitteet Automaatiotestaus
Automaatiotestauksen tai testausautomaation käsitteillä tarkoitetaan testausta, jossa tarkoi- tuksena on suorittaa toistuvassa käytössä olevia testitapauksia jollakin automaatiotestaukseen tarkoitetulla työvälineellä, joka automatiikkaan perustuen etsii korjattavia virheitä järjestel- mästä tai sovelluksesta.
Manuaalitestaus
Manuaalitestauksella tarkoitetaan testaajan käsin suorittamaa, eri menetelmillä tehtyä tes- tausta virheiden löytämiseksi järjestelmästä tai sovelluksesta. Manuaalitestauksessa ei käy- tetä automaatiotestauksen työvälineitä.
Regressiotestaus
Regressiotestaus on kaikentyyppistä testausta, jonka tarkoituksena on varmistaa, että minkä tahansa muutoksen jälkeen, ohjelmisto tai sovellus toimii edelleen kuten pitääkin. Regressio- testaus on yleistermi, joka tarkoittaa lähinnä uudelleentestausta. Regressiotestauksen tärkein tavoite on varmistaa, että kertaalleen korjatut ongelmat eivät esiinny enää komponenttiin tehtyjen muutosten jälkeen, ja että mitään uutta ei ole mennyt rikki. (Kasurinen 2013, 68- 69.)
Visma eBusiness Suite
eBusiness Suite on Visma Consulting Oy:n sähköiseen asiointiin tarkoitettu alusta, jota voidaan räätälöidä asiakkaan tarpeen mukaiseksi. Alusta käsittää pääasiallisesti asiointi- ja käsittely- portaalin, mutta tämäkin riippuu asiakkuudesta. Asiakkaalle tarjottavaa käyttöliittymää nimi- tetään asianhallinnan käyttöliittymäksi.
Eclipse IDE
Eclipse IDE on avoimen lähdekoodin kehitysympäristö, joka tukee erityisesti Java- ohjelmoin- tikieltä, mutta myös muita ohjelmointikieliä kuten C:tä, C++:a sekä PHP:tä.
Selenium
Selenium on avoimen lähdekoodin web-pohjaisten sovellusten automaatiotestaukseen käytet- tävä työkalu.
BrowserStack
BrowserStack on web-pohjaisten sovellusten ja mobiilisovellusten testaamiseen tarkoitettu alusta.
Katalon Studio
Katalon Studio on Seleniumiin pohjautuva IDE, joka soveltuu web-pohjaisten sovellusten tes- taukseen. Katalon Studio sisältää käyttöliittymän sekä tekstieditorin.
Ketterät menetelmät
Ketteriä menetelmiä käytetään pääasiassa vaihtoehtona perinteiselle vesiputousmallille ohjel- mistokehityksessä. Yleisesti menetelmiä, joissa korostetaan yksilöidenvälistä kommunikointia, asiakasyhteistyötä ja ohjelmiston toiminnallisuuksia enemmän kuin kattavaa ennakkosuunnit- telua ja sopimuspohjaisia määrittelyjä, voidaan pitää ketterinä menetelminä (Kasurinen 2013, 27-28). Ketteristä menetelmistä mainittakoon mm. Scrum, Kanban ja Extreme Programming (XP).
3 Ohjelmistotestaus
Ohjelmistotestaus on yksi ohjelmistotuotannon piiriin kuuluva kokonaisuus. Sillä tarkoitetaan työtä, jolla varmistetaan, että ohjelmistotuotteesta tulee toivotun kaltainen sekä kaikki sii- hen liitetyt ominaisuudet toimivat kuten pitääkin. Ohjelmistotestaus on laaja käsite ja tes- tauksen työtehtävät voivat vaihdella suurestikin eri työvaiheen mukaan. Testaajan ammatin- kuva voikin vaihdella suuresti eri ohjelmistotalojen mukaan, sillä peliyritys voi olla kiinnostu- nut täysin eri asioista testauksen näkökulmasta kuin vaikkapa valtion viraston verkkopalvelua rakentava yritys. (Kasurinen 2013, 10.)
Ohjelmistotuotannossa on perinteisesti käytetty niin sanottua vesiputousmallia, jossa kehitys- tehtävät tehdään valmiiksi yksi toisensa jälkeen ja testaaminen tehdään vasta, kun kaikki muut vaiheet ovat valmiita (Kuvio 1).
Kuvio 1: Vesiputousmalli
Perinteisen vesiputousmallin rinnalle on kuitenkin kehittynyt muitakin ohjelmistotuotannon kehitysmalleja, kuten esimerkiksi V- malli, jossa testaus on osa ohjelmistotuotantoa koko sen toteutusprosessin ajan (Kuvio 2).
Kuvio 2: V-malli
Ohjelmistotuotannon muita kehitysmalleja ovat mm. inkrementaalinen sekä iteratiivinen malli. Inkrementaalisessa kehitysmallissa vaatimusten määrittely sekä ohjelmiston suunnittelu, toteutus ja testaus tehdään osissa, jolloin ohjelmiston osat laajenevat osa kerrallaan. Osien koko voi vaihdella ja jotkut ominaisuudet koostuvat isommista ja osa pienemmistä osista. Iteratiivisessa kehitysmallissa taasen joukko ominaisuuksia määritellään, suunnitellaan, toteutetaan ja testataan sovitun mittaisen kierroksen aikana. Näihin
menetelmiin kuuluvat esimerkiksi RUP- malli (Rational Unified Process), Scrum ja Kanban.
(ISTQB 2018, 25-26.)
Vaatimusmäärittely Suunnittelu
Toteutus Testaus
Käyttöönotto
3.1 Ohjelmistotestauksen tavoitteet
Ohjelmistotestauksen tavoitteita ovat mm. vikojen ennaltaehkäisy, häiriöiden ja vikojen löy- täminen, kuvattujen vaatimusten todentaminen, eri tuotosten arviointi, luottamuksen kasvat- taminen testauksen kohteen laadun tasoon, tiedon tuottaminen sidosryhmille päätöksenteon tueksi, testauksen kohteen valmiuden ja toimivuuden kelpuuttaminen käyttäjien ja muiden sidosryhmien odotusten mukaisesti, ohjelmiston laatuun liittyvien riskien tason vähentäminen sekä sopimuksiin, lakeihin tai muuhun sääntelyyn perustuvien vaatimusten täyttäminen.
(ISTQB 2018, 12.)
Ohjelmistotestauksella tavoitellaan eri asioita ohjelmiston tai sovelluksen kehityskaaren ai- kana. Ohjelmiston tai sovelluksen ohjelmointivaiheessa yksikkötestauksella, joka tunnetaan myös komponenttitestauksena, voidaan varmistaa esimerkiksi koodin toimivuus ja vikojen löy- tyminen komponentista. Integraatiotestauksella taas voidaan varmistaa komponenttien tai järjestelmien yhteensopivuus ja vuorovaikutus. Järjestelmätestauksen tarkoituksena on tutkia koko järjestelmän, ohjelmiston tai sovelluksen käyttäytymistä ja ominaisuuksia sekä usein sen tutkimuskohteena ovat sen suorittamat kokonaiset toimintoketjut alusta loppuun saakka. Hy- väksymistestauksessa arvioidaan myös järjestelmän, ohjelmiston tai sovelluksen käyttäyty- mistä ja ominaisuuksia kokonaisuutena ja sen lopputulemana pyritään saamaan tietoa, jonka avulla voidaan arvioida, onko järjestelmä, ohjelmisto tai sovellus valmis julkaistavaksi asiak- kaan eli loppukäyttäjän käyttöön. (ISTQB 2018,12.)
3.2 Ohjelmistotestauksen tasot
Ohjelmistotestauksen tasot ovat testaustehtäviä, joita organisoidaan yhdessä. Jokainen tes- taustaso on testausprosessin ilmentymä, joka koostuu tehtävistä, jotka suoritetaan ohjelmis- ton kehitysvaiheen tilan mukaisesti. Testaustasot liittyvät toisiin tehtäviin ohjelmistokehityk- sen elinkaaressa. Jokaiselle testaustasolle käytetään erilaista testausympäristöä, esimerkiksi yksikkötestauksessa kehittäjät käyttävät omaa kehitysympäristöään, kun taas hyväksymistes- tauksessa ympäristön olisi hyvä olla mahdollisimman lähellä tuotantoympäristöä. (ISTQB 2018, 27.)
3.2.1 Yksikkötestaus
Yksikkötestauksella tarkoitetaan sellaista testausta, jossa yksittäisen moduulin, funktion tai olion toimintaa tarkastellaan heti toteutuksen yhteydessä. Yksikkötestaus toteutetaan usein itse kehittäjän tai ohjelmoijan toimesta ja sen tarkoituksena on varmistaa, että juuri toteu- tettu muutos tai uusi toiminto olemassa olevaan järjestelmään toimii ainakin periaatetasolla.
Tarkastelun tarkoituksen on todeta esimerkiksi, että juuri tehty muutos kääntyy virheettä, sekä toteuttaa funktion toiminnalliset ominaisuudet. (Kasurinen 2013, 51.)
Yksikkötestauksen avuksi voidaan rakentaa esimerkiksi joukko funktio- tai oliokutsuja, joihin testattavan komponentin pitää osata vastata oikein tai toteuttaa oikeanlainen toiminto (Kasu- rinen 2013, 51-52). Yksikkötestauksen tekniikoina käytetään usein lasilaatikkotestausta, kun testitapauksia johdetaan ohjelmiston rakenteesta tai mustalaatikkotestausta, kun testaus pe- rustuu vaatimuksiin. Pääosin yksikkötestauksessa testitapaukset suoritetaan siten, että tes- taajalla on pääsy lähdekoodiin. (Homès 2012, 60.)
3.2.2 Integraatiotestaus
Integraatiotestaus keskittyy komponenttien tai järjestelmien väliseen vuorovaikutukseen (ISTQB 2018, 28). Sen tarkoituksena on käytännön tasolla kokeilla, että järjestelmän osat toi- mivat myös yhteen sekä saavuttaa lopulta yhtenäisyys ohjelmiston eri komponenttien kanssa.
Integraatiotestauksessa uusi komponentti kiinnitetään osaksi aiemmin toimivaksi testattua ko- konaisuutta ja tämän jälkeen testataan, että kokonaisuus toimii myös lisäyksen jälkeenkin.
(Kasurinen 2013, 54.)
Integraatiotestauksessa moduulien integrointijärjestys voidaan toteuttaa kolmella erilaisella tavalla eli alhaalta ylöspäin- testauksena (bottom up testing), ylhäältä alaspäin- testauksena (top down testing) tai voileipätestauksena (sandwich testing). Alhaalta ylöspäin- testauksessa ensimmäisenä järjestelmään tuodaan matalimman tason moduuleja, jotka kommunikoivat suoraan raudan tai käyttöjärjestelmän kanssa. Tästä eteenpäin järjestelmään tuodaan lisää moduuleja, jotka käyttävät edellisiä, aiemmin integrointitestattuja osia kunnes kaikki osat on tuotu järjestelmään. Ylhäältä alaspäin- testauksessa ajatus on sama kuin alhaalta ylöspäin- menetelmässä, mutta järjestys on käänteinen eli testaus aloitetaan järjestelmähierarkian hui- pulta edeten alaspäin kohti rautatasoa lähellä olevia toimintoja. Voileipätestauksessa hyödyn- netään molempia aiemmin mainittuja menetelmiä eli integraatiota lähestytään molemmista suunnista, alhaalta ja ylhäältä, samanaikaisesti. (Kasurinen 2013, 55.)
3.2.3 Järjestelmätestaus
Järjestelmätestauksessa tarkoituksena on keskittyä koko järjestelmän, ohjelmiston tai tuot- teen ominaisuuksiin ja käyttäytymiseen. Testauksessa tutkitaan usein järjestelmän suoritta- mia toimintoketjuja päästä päähän sekä järjestelmän osoittamia ei- toiminnallisia käyttäyty- misiä, kun se suorittaa kyseisiä toimintoketjuja. (ISTQB 2018, 31.)
Tämän testausvaiheen tarkoituksena on varmistaa, että järjestelmä toteuttaa sille määritellyt tavoitteet sekä toimii kokonaisuutena. Menetelminä tässä vaiheessa käytetään usein lasilaa- tikko- tai mustalaatikkotestausta. (Kasurinen 2013, 56-57.) Testausympäristönä käytetään usein mahdollisimman lähellä tuotantoympäristöä olevaa testausympäristöä, jotta myöhem- min tehtävä hyväksymistestaus helpottuisi (Homès 2012, 63).
3.2.4 Hyväksymistestaus
Hyväksymistestauksen päätavoitteena on osoittaa ohjelmiston tai järjestelmän olevan riittä- vän laadukas ja kyvykäs täyttämään ne vaatimukset, mitkä sille on vaatimusmäärittelyssä ase- tettu. Tässä vaiheessa järjestelmä tai ohjelmisto tarkastetaan ja hyväksytään virallisesti, joka tarkoittaa sitä, että asiakas hyväksyy tuotteen valmistumisen ja onnistuneen hyväksymistes- tauksen jälkeen, ohjelmisto tai järjestelmä siirtyy lakiteknisesti asiakkaan omaisuudeksi. (Ka- surinen 2013, 57.)
Testausmuotoina tässä vaiheessa käytetään yleisimmin käyttäjän hyväksymistestausta, käyt- töön soveltuvuuden testausta, sopimusten ja sääntelyiden perusteella tehtävää hyväksymis- testausta sekä alfa- ja betatestausta (ISTQB 2018, 32).
Käyttäjän hyväksymistestauksella pyritään todentamaan, että ohjelmisto tai järjestelmä so- veltuu sen tarkoitettujen käyttäjien käytettäväksi oikeassa tai simuloidussa käyttöympäris- tössä. Tavoitteena on lisätä luottamusta siihen, että käyttäjät todella voivat käyttää ohjel- mistoa tai järjestelmää ja se vastaa heidän tarpeitaan sekä täyttää käyttäjien asettamat vaa- timukset sille. (ISTQB 2018, 32.)
Käyttöön soveltuvuuden testauksen tarkoituksena on varmistaa, että toiminnan- ja järjestel- mänvalvojat voivat pitää järjestelmän tai ohjelmiston toiminnassa käyttäjiä varten tuotanto- ympäristössä myös poikkeuksellisissa tai hankalissa olosuhteissa. (ISTQB 2018, 32-33.) Sopimusten ja säännösten perusteella tehtävän hyväksymistestauksen tarkoituksena on var- mistaa, että toteutus on tehty sopimusten tai sääntelyiden kanssa yhdenmukaiseksi. Sopimus- pohjainen hyväksymistestaus suoritetaan sopimusvaiheessa määriteltyjä hyväksymiskriteerejä vastaan, kun taas sääntelypohjainen hyväksymistestaus tehdään kaikkia sellaisia sääntelyitä vastaan, joita tulee noudattaa. (ISTQB 2018, 33.)
Alfa- ja betatestausta käytetään usein kaupallisten ohjelmistojen kehittämisprosessissa ja nii- den eräänä tarkoituksena on saada palautetta potentiaalisilta ja nykyisiltä käyttäjiltä, asiak- kailta ja/tai operaattoreilta, ennen kuin ohjelmistotuote julkaistaan virallisesti markkinoille (ISTQB 2018, 33). Alfatestauksen katsotaan olevan niin sanotusti sisäinen hyväksymistestaus, jolla tarkistetaan, että ohjelmisto tai järjestelmä on riittävän toimiva ja sen kanssa voi edetä suuremman testiyleisön kokeiltavaksi betatestausvaiheeseen. Betatestauksessa ohjelmisto- tuotteen toimivuutta testataan normaaliolosuhteissa ja sen suorittavat yleensä olemassa ole- vat tai potentiaaliset asiakkaat. Betatestauksen havaintojen perusteella ohjelmistoon tai jär- jestelmään voidaan tehdä vielä muutoksia, sillä tuote ei ole vielä virallisesti julkaistu. (Kasu- rinen 2013, 73.)
3.3 Ohjelmistotestauksen tyypit
Ohjelmistotestauksen tyypeillä tarkoitetaan testaustehtäviä, joiden tarkoituksena on testata tietyn ohjelmiston tai järjestelmän tai niiden osien määrättyjä ominaisuuksia määriteltyjen tavoitteiden perusteella. Näitä tavoitteita voivat olla esimerkiksi toiminnallisten laatuominai- suuksien arviointi, ei-toiminnallisten laatuominaisuuksien arviointi, komponentin tai järjestel- män rakenteen tai arkkitehtuurin arvioiminen sekä muutosten vaikutusten arviointi. (ISTQB 2018, 35.)
3.3.1 Toiminnallinen testaus
Toiminnallisessa testauksessa arvioidaan toimintoja, jotka järjestelmän tai ohjelmiston tulisi suorittaa. Toiminnalliset vaatimukset kuvataan yleensä vaatimusten määrittelyissä, käyttäjä- tarinoissa, eepoksissa, käyttötapauksissa tai toiminnallisissa määrityksissä. Toiminnallinen testaus soveltuu käytettäväksi kaikilla testaustasoilla. (ISTQB 2018, 35).
Toiminnallinen testaus keskittyy tutkimaan nimenomaan järjestelmän käyttäytymistä, jonka vuoksi musta laatikko- menetelmä soveltuu hyvin komponentin tai järjestelmän toiminnalli- suuden testaamiseksi. Toiminnallisen testauksen perusteellisuuden mittarina käytetään toi- minnallista kattavuutta. Toiminnallisella kattavuudella tarkoitetaan sitä, kuinka perusteelli- sesti testit ovat käyneet läpi jonkin toiminnallisen osan ja tämä osuus ilmaistaan katettujen osien prosenttiosuutena. (ISTQB 2018, 35.)
3.3.2 Ei-toiminnallinen testaus
Ei- toiminnallinen testaus arvioi järjestelmien ja ohjelmistojen ominaisuuksia kuten esimer- kiksi käytettävyyttä, suorituskykyä tai tietoturvaa. Ei- toiminnallista testausta voidaan ja sitä pitäisikin tehdä kaikilla testaustasoilla. (ISTQB 2018, 35.)
Ei- toiminnallisessa testauksessa voidaan hyödyntää musta laatikko- menetelmää sekä esimer- kiksi raja-arvoanalyysiä. Ei- toiminnallisen testauksen tulosten ja perusteellisuuden mittaa- miseksi voidaan käyttää ei- toiminnallista kattavuutta. Ei- toiminnallisella kattavuudella tar- koitetaan sitä, kuinka perusteellisesti testit ovat käyneet läpi jonkin ei- toiminnallisen osan ja tämä osuus ilmaistaan katettujen osien prosenttiosuutena. (ISTQB 2018, 35.)
3.3.3 Lasilaatikkotestaus
Lasilaatikkotestauksessa testitapaukset luodaan järjestelmän tai ohjelmiston sisäisen raken- teen tai toteutuksen pohjalta. Sisäistä rakennetta ovat mm. koodi, työnkulut ja tietovirrat.
Lasilaatikkotestauksen perusteellisuus on mitattavissa rakenteellisen kattavuuden perus- teella. Rakenteellisella kattavuudella tarkoitetaan sitä, että kuinka perusteellisesti testit ovat käyneet läpi jonkin rakenteellisen osan ja tämä osuus ilmaistaan katettujen osien
prosenttiosuutena. (ISTQB 2018, 36.) Lasilaatikkotestauksessa testaajalla on pääsy ohjelmis- ton lähdekoodiin saakka ja täten pystyy jäljittämään kooditasolle asti, mistä virhe aiheutui.
Lasilaatikkotestauksessa testaajalla tulisi olla myös kattava ymmärrys ohjelmiston tai järjes- telmän toiminnasta sekä ymmärrystä ohjelmoinnista, jotta tämä pystyy arvioimaan järjestel- män tai ohjelmiston toimivuutta lähdekooditasolla. (Kasurinen 2013, 67.)
3.3.4 Muutokseen pohjautuva testaus
Muutokseen pohjautuvan testauksen lähtökohtana on testata järjestelmän tai ohjelmiston toi- minnallisuutta vian korjauksen tai uuden toiminnallisuuden lisäämisen jälkeen. Testauksen tarkoituksena on tällöin varmistaa, että muutokset ovat korjanneet vian tai uusi toiminnalli- suus toimii kuten pitääkin eivätkä muutokset ole aiheuttaneet haitallisia seurauksia. (ISTQB 2018, 36.)
Muutoksen pohjautuvan testauksen menetelminä ovat varmistustestaus sekä regressiotestaus.
Varmistustestauksen tarkoituksena on testata niitä testitapauksia uudelleen, joiden suoritta- minen epäonnistui aiemmassa ohjelmistoversiossa vian vuoksi. Tarkoituksena on varmistaa, että alkuperäinen vika on korjautunut onnistuneesti. Regressiotestauksessa varmistetaan, että ohjelmiston yhteen osaan tehty muutos ei ole vaikuttanut muiden osien käyttäytymiseen. Tar- koituksena on suorittaa testit mahdollisten tahattomien sivuvaikutusten havainnoimiseksi.
(ISTQB 2018, 36.)
3.4 Ohjelmistotestauksen tekniikat
Testaustekniikoiden tarkoituksena on auttaa testattavien tilanteiden, testitapausten ja testi- aineiston tunnistamisessa. Tekniikan valinta riippuu monesta eri tekijästä ja osa tekniikoista soveltuu paremmin tiettyihin tilanteisiin ja testitasoille, kun taas osa soveltuu kaikille testita- soille. (ISTQB 2018, 50.)
3.4.1 Musta laatikko- testaus
Musta laatikko- testauksessa (black box testing) ohjelmistoa testataan antamalla sille syöt- teitä ja tarkastellaan mitä ohjelma tekee. Annettavat syötteet tai tehtäväsarjat määritellään testitapauksissa, joissa on kuvattu miten ohjelmiston tai järjestelmän tulisi tehtäväsarjaan reagoida. Musta laatikko- testausta voidaan käyttää kaikissa testauksen työvaiheissa ja sen testeillä voidaan testata erilaisia käyttötapauksia. (Kasurinen 2013, 66.)
Musta laatikko- testauksen tekniikoista mainittakoon ekvivalenssiositus, raja-arvonalyysi, pää- töstaulutestaus, tilasiirtymätestaus sekä käyttötapaustestaus. Ekvivalenssiosituksessa tieto jaetaan luokkiin, jossa samaan luokkaan kuuluvia tietoja tulisi käsitellä samalla tavalla. Ekvi- valenssiluokkia on sekä kelvollisille että epäkelvoille arvoille, joka tarkoittaa sitä, että kom- ponentin tai järjestelmän tulisi hyväksyä kelvolliset arvot ja puolestaan hylätä epäkelvot
arvot. Raja-arvoanalyysi toimii samalla idealla kuin ekvivalenssiosituskin, mutta sitä käyte- tään vain silloin, kun luokka on järjestetty eli se koostuu numeerisista tai peräkkäisistä ar- voista. Luokan pienin ja suurin arvo ovat sen raja-arvoja. Päätöstaulutestauksessa testaaja tunnistaa ehdot ja niistä seuraavat järjestelmän toimenpiteet, jotka muodostavat taulukon rivit. Taulukon jokainen sarake vastaa päätössääntöä, joka määrittelee ehtoyhdistelmän sään- töön liittyvien toimenpiteiden suorittamiseksi. Tilasiirtymätestaus perustuu usein tilasiirtymä- kaavion hyödyntämiseen, joka kuvaa ohjelmiston tilat sekä sen, miten ohjelmiston siirtymät eri tilojen välillä tapahtuvat jonkin tapahtuman, esimerkiksi syötteen annon, perusteella.
Testaus voidaan suunnitella kattamaan esimerkiksi jokin tyypillinen tilasiirtymäketju. Käyttö- tapaustestauksessa testitapaukset johdetaan käyttötapauksista, jotka kuvaavat ohjelmiston vuorovaikutusta eri osien välillä toimijoiden, joita voivat olla käyttäjät, ulkoiset laitteet tai muut järjestelmät, sekä kohteiden, joita ovat käyttötapauksessa tarkoitetut järjestelmät tai ohjelmistot, suorituksen perusteella. Toimijoiden ja kohteen väliset vuorovaikutukset voivat johtaa muutoksiin kohteen tilassa, joita pyritään löytämään käyttötapaustestauksella. (ISTQB 2018, 51-53.)
3.4.2 Lasilaatikkotekniikat
Lasilaatikkotestaus perustuu järjestelmän tai ohjelmiston sisäiseen rakenteeseen, jonka vuoksi siihen liittyviä tekniikoita käytetään useimmiten yksikkötestaustasolla, vaikkakin lasi- laatikkotekniikoita voidaan käyttää kaikilla testaustasoilla. Lausetestauksessa testataan ohjel- makoodin suoritettavia lauseita, joiden kattavuus lasketaan testien suorittamien lauseiden lu- kumäärällä sekä jakamalla se kaikkien testauksen kohteen sisältämien suoritettavien lausei- den lukumäärällä ja kertomalla sadalla, josta saadaan kattavuus prosentteina. Päätöstestauk- sessa puolestaan suoritetaan koodin sisältämiä päätöksiä ja testataan koodi, joka suoritetaan päätösten tulosten perusteella. Kattavuus saadaan laskemalla testien suorittamien päätös- vaihtoehtojen määrä sekä jakamalla se kaikkien kohteen sisältämien päätösvaihtoehtojen määrällä ja kertomalla sadalla, josta saadaan kattavuus prosentteina. (ISTQB 2018, 54.) 3.4.3 Harmaa laatikko- testaus
Harmaa laatikko- testaus yhdistelee musta laatikko- ja lasilaatikkotestausta ja sen tarkoituk- sena onkin hyödyntää musta laatikko- testauksen vaatimusmäärittelyistä tehtyjä testitapauk- sia kuin lasilaatikkotestauksen sisäisen rakenteen tarkasteluunkin tehtyjä testitapauksia. Tä- ten tavoitteena on käydä yhtäaikaisesti läpi sekä mallikattavuutta että koodikattavuutta. Har- maa laatikko- testaus soveltuu parhaiten tilanteisiin, jossa järjestelmää tai ohjelmistoa ei voida testata kokonaan lasilaatikkotestien tasolla, mutta sen paikallisiin komponentteihin päästään käsiksi. (Kasurinen 2013, 68.)
3.4.4 Staattinen ja dynaaminen testaus
Staattisessa testauksessa tarkoitus on tutkia tuotoksia tai koodia manuaalisen tarkastuksen tai työkalujen avulla. Manuaalista tarkastusta kutsutaan katselmoinniksi ja staattisen testauksen työkalujen käyttöä staattiseksi analyysiksi. (ISTQB 2018, 41.) Staattisen testauksen päätavoit- teena on löytää vikoja testikohteesta ja antaa siten tietoja tuotetun ohjelmiston tai järjestel- män laadusta. Staattisen testauksen kohteina voivat olla esimerkiksi määritykset, tuote- ja testausmateriaali, vaatimusmäärittelyt, tuote-, projekti- ja testaussuunnitelmat, käyttöop- paat sekä itse järjestelmä tai ohjelmisto, kuten sen koodi, tiedot, laitteistot ja asennusoh- jeet. (Hass 2014, 168.)
Dynaaminen testaus taas puolestaan vaatii ohjelmiston tai järjestelmän suoraa käyttämistä ja sen tarkoituksena on tarkastella miten järjestelmä tai ohjelmisto reagoi sille annettuihin syöt- teisiin. Testausmenetelmistä esimerkiksi yksikkötestaus ja integraatiotestaus ovat dynaamista testausta, sillä niissä tarkastellaan ohjelman tai sen osan reaktioita käytännössä. (Kasurinen 2013, 65.) Dynaamisen testauksen kohteina voivat olla esimerkiksi koodi, komponentit, koko ohjelmisto tai järjestelmä sekä käyttöliittymä (Hass 2014, 212-213).
3.4.5 Regressiotestaus
Regressiotestausta käytetään tilanteissa, joissa toimivan järjestelmän tai ohjelmiston jotakin osaa on muutettu ja muutoksen jälkeen tulee varmistaa, että ohjelmisto tai järjestelmä toi- mii edelleen kuten pitääkin. Sitä voidaan hyödyntää myös tilanteissa, joissa kehitettävässä järjestelmässä tai ohjelmistossa on saavutettu jokin tavoite ja kyseisestä versiosta halutaan varmentaa toimintojen oikeellisuus. (Kasurinen 2013, 68-69.) Regressiotestauksessa ilmi tul- leita sivuvaikutuksia, jossa jokin muutos on vaikuttanut toimivaan järjestelmään, nimitetään taantumiseksi (regressioksi) ja testien tarkoituksena on löytää kyseisenlaiset tahattomat sivu- vaikutukset (ISTQB 2018, 36).
Regressiotestit ovat tyypillisesti yhä uudelleen suoritettavia testitapauksia, jotka on luotu esi- merkiksi ohjelmiston kehitysvaiheessa tai vastaamaan hyväksymistestauksen tarpeisiin. Reg- ressiotestitapauksista voidaan myös johtaa alajoukko aiemmin luoduista testitapauksista, joi- den tarkoituksena on varmistaa mahdollisimman korkea kattavuus, jotta aukkoja ei jäisi tai päällekkäisyyksiä ei tapahtuisi. Regressiotestien automatisointi sopii erityisen hyvin, mikäli suoritettavien testien joukko on laaja. On kuitenkin huomattava, että automatisoituja testita- pauksia tulee ylläpitää ja päivittää sitä mukaa, mitä ohjelmistosta tai järjestelmästä julkais- taan uusia versioita. (Homès 2012, 78.)
3.5 Ketterä testaus
Ketterän testauksen käyttö perustuu ketteriin menetelmiin eli testausta toteutetaan saman- laisissa lyhyissä iteraatioissa kuin ohjelmistokehitystäkin. Tärkeimpiä eroavaisuuksia perinteis- ten ja ketterien elinkaarimallien välillä on se, että toimiva ohjelmisto on tarkoitus saada tuo- tettua jokaisen iteraation päätyttyä. Projekti alkaa ketterien elinkaarimallien mukaisesti suunnittelujaksosta, jota seuraavat peräkkäiset iteraatiot. Jokainen iteraatio alkaa suunnitte- luvaiheella, jossa valitaan toteutettavat käyttäjätarinat ja iteraation aikana nämä toteute- taan ja integroidaan ohjelmistoon tai järjestelmään. Toteutus-, integraatio- ja testaustehtä- vät tapahtuvat läpi iteraatiojakson ja niissä on rinnakkaisuutta tai päällekkäisyyksiä. Testauk- sen kannalta tärkein huomio on, että sen tehtäviä suoritetaan koko iteraatiojakson ajan eikä vasta sen loputtua. (ISTQB 2015, 19.)
3.5.1 Scrum
Scrum- mallissa iteraatiot jakautuvat muutaman viikon mittaisesta ajanjaksosta noin kuukau- den jaksoon. Iteraatioita kutsutaan Scrum- mallissa sprinteiksi ja jokaisen sprintin tarkoituk- sena on tuottaa ohjelmistoon joukko uusia ominaisuuksia tai toimintoja vaatimusmäärittely- jen perusteella ja testata niiden toimivuus kyseisen sprintin aikana. (Kasurinen 2013, 27.) Scrum- mallissa kehitystiimin sisäinen kommunikaatio on tärkeää ja malliin kuuluukin päivit- täin järjestettävät lyhyet palaverit, sprinttien katselmoinnit sekä retrospektiivit. Katselmoin- nin tarkoituksena on tarkastella sprintin tuotoksia ja selvittää muutostarpeita. Retrospektiivin tarkoituksena taas on suunnitella keinoja laadun ja tehokkuuden parantamiseksi ja siinä tiimi tarkastelee, miten kulunut sprintti on sujunut ja mitä ongelmia kohdattiin sekä mikä meni hy- vin. (Schwaber & Sutherland 2020, 9-10.)
Scrum- tiimi koostuu yleensä enintään kymmenestä jäsenestä, jonka jäsenillä on kaikki ne tai- dot, joita tarvitaan sprintin tuotosten onnistuneeseen läpiviemiseen. Scrumissa määritellään kuitenkin kolme erityistä vastuualuetta eli kehittäjät, tuoteomistaja ja Scrum Master. Kehit- täjien tehtävänä on kehittää sprintin aikana siinä määritellyt käyttökelpoiset tuotokset, tuo- teomistajan tarkoituksena on vastata siitä, että Scrum- tiimin työ tuottaa tavoitellun arvon sekä vastata kehitysjonon hallinnasta ja Scrum Masterin tehtävänä on auttaa Scrum- tiimiä sekä ympäröivää organisaatiota ymmärtämään Scrumin teoria ja käytännöt. (Schwaber & Sut- herland 2020, 5-6.)
3.5.2 Kanban
Kanbanin tavoitteena on visualisoida työn kulku Kanban- taululla. Kanbanissa hyödynnetään kolmea välinettä eli Kanban- taulua, Work-In-Progress Limit:iä (WIP) sekä läpimenoaikaa.
Kanban- taululla kuvataan hallinnoitavaa arvoketjua, jossa jokaisessa sarakkeessa on
sijoituspaikka, jonka sisälle on määritelty siihen liittyvät tehtävät. Sijoituspaikka kuvaa esi- merkiksi sitä, mitä tehtäviä on tehty, mitkä ovat työn alla ja mitkä tekemättä. WIP puoles- taan määrittelee rinnakkaisten aktiivisten tehtävien enimmäismäärän ja läpimenoajan avulla pyritään määrittelemään jatkuvan tehtävävirran optimointi minimoimalla läpimenoaikaa arvo- virrassa. (ISTQB 2015, 12.)
Kanbanissa iteraatiot ja sprintit ovat valinnaisia, sillä Kanban- prosessi mahdollistaa tuotosten julkaisun yksi kerrallaan sen sijaan, että niitä julkaistaan osana julkaisua. Myös kehitysjonossa olevia aikatauluttomia tehtäviä voidaan siirtää Kanban- taululle heti, kun sille tulee tilaa eikä tehtävien siirto vaadi odottamista tulevaan iteraatioon. (ISTQB 2015, 12.)
3.6 Automaatiotestaus
Automaatiotestaus on testauksen muoto, jossa ohjelmiston tai järjestelmän testaukseen hyö- dynnetään automaatiotestausvälineitä. Automaatiotestauksen tavoitteena on valita joukko toistuvasti suoritettavia testitapauksia ja kehittää niiden nopeaa suorittamista varten erilli- nen laite tai ohjelma sekä näin vapauttaa testaajien työaikaa muihin tehtäviin. Automaatio- testaukselle sopivia kohteita ovat esimerkiksi moduulien rajapinnat, yksittäisten moduulien yksikkötestauksessa tehtävät tarkastukset sekä käyttöliittymän tarkastukset. (Kasurinen 2013, 76.)
Käytännössä automaatiotestaukseen sopivia työkaluja voidaan kehittää organisaatiossa itse tai siihen voidaan hyödyntää valmiita työkaluja. Valmiista työkaluista mainittakoon Selenium, Ka- talon Studio, Robot Framework ja TestComplete. Tässä opinnäytetyössä tarkemmassa esitte- lyssä ovat Selenium sekä Katalon Studio.
4 Automaatiotestaus asiakasyrityksessä
Visma Consulting Oy:n Digital Services- liiketoimintayksikössä automaatiotestauksen edelleen kehittäminen on muodostunut ajankohtaiseksi asiaksi asiakasmäärän jatkuvasti laajentuessa ja testaustarpeen kasvaessa. Asiakasyrityksessä on käytössä BrowserStack, joka soveltuu eri- tyisen hyvin web- pohjaisten sovellusten automaatiotestaukseen ja jonka hyödyntämisen nä- kökulmasta kehittämistyötä lähdettiin edistämään.
4.1 Lähtötilanne
Kehittämistyö aloitettiin tutkimalla lisää automaatiotestaustyökalujen hyödynnettävyyttä ni- menomaisesti regressiotestauksen tarpeeseen. Tutkimus aloitettiin tarkastelemalla Brow- serStackin tukemia välineitä. Tutkimuksen perusteella BrowserStackin voi yhdistää mm. Sele- niumiin, Cypress:iin, JS Testing:iin ja Percy:yn (BrowserStack 2021a). BrowserStack tarjoaa
myös Live- palvelun, jossa testitapauksia voi nauhoittaa eri selaimilla tai mobiililaitteella.
Tässä tapauksessa päädyttiin kuitenkin tutkimaan ensisijaisesti Seleniumia sekä sen tarjoamia vaihtoehtoja testien luomiseen, jotta työ saataisiin paremmin rajattua sekä sen aikana voitai- siin tuottaa enemmän kuin vain muutamia konkreettisia automatisoituja testitapauksia.
4.2 Saavutettavat hyödyt
Versioiden julkaisujen yhteydessä tehtävien regressiotestitapausten automatisoinnilla voidaan saavuttaa merkittävää hyötyä resurssien säästymisen myötä, kun ne voidaan kohdistaa esi- merkiksi uusien ominaisuuksien manuaalitestaamiseen. Koska regressiotestitapauksia on yh- teensä satoja SaaS- alustoilla oleville eri asiakkuuksille, ajan säästön ja selkeyden vuoksi tar- kasteluun valittiin yksi asiakkuus, jonka regressiotestitapauksia lähdettiin automatisoimaan.
4.3 Automaatiotestauksen yleiset haasteet
Vaikka automaatiotestauksella odotetaan saavutettavan useita hyötyjä, voi siitä aiheutua myös haasteita, erityisesti mikäli automaatiotestaukselle kohdistetaan suuret odotukset. Fi- resmith (2014, 225-227) mainitsee teoksessaan regressiotestauksen automatisoinnin haasteiksi esimerkiksi sen, että automaatiotestauksen työkalujen tuki on puutteellinen tai liian epäkäy- tännöllinen hyödynnettäväksi, aiemmin kehitettyjä automaatiotestitapauksia ei ylläpidetä eikä aiemmin kehitettyjä automaatiotestitapauksia ole hyödynnetty järjestelmän tai ohjel- miston testaamisessa.
Muita mahdollisia haasteita automaatiotestauksessa ovat epärealistiset odotukset siitä, että vain yksi testaustyökalu riittäisi tukemaan kaikkia käyttöjärjestelmiä tai laitteita, oletus välit- tömästä testauksen tarpeen vähenemisestä, oletus mahdollisuudesta automatisoida kaikenlai- set testitapaukset, oletus täydellisestä testikattavuudesta sekä oletus siitä, että pelkkä tes- tien nauhoittaminen yksistään riittäisi tuottamaan toimivan automaatioskriptin. (Dustin, Gar- ret & Gauf 2009, 75-80.)
Kuten manuaalitestauksessakin, myös automaatiotestauksenkin osalta tulee huolehtia riittä- vän dokumentaation ylläpidosta sekä testaajien perehdyttämisestä käytettäviksi valittuihin automaatiotestaustyökaluihin. Tärkeää on myös, että automaatiotestaukseen annetaan riit- tävä tuki ja aika organisaatiotasolta.
4.4 Automatisoitavat regressiotestitapaukset
Automatisoitavien regressiotestitapauksien kohteeksi valittiin asiakkuus, jolla on uusin versio asianhallinnan käyttöliittymästä sekä stabiili tilanne eli alustaan ei olla tekemässä merkittäviä muutoksia eikä sen käytössä ole havaittu ongelmia. Kyseisellä asiakkuudella on käytössään sähköisen asioinnin alustassa sekä asiointi- että käsittelyportaali, joka käytännössä tarkoittaa sitä, että heidän asiakkaansa lähettävät yhteydenoton tai tekevät muita toimintoja asioinnin
käyttöliittymässä, kun taas käsittelyn käyttöliittymässä asiakkuuden omat työntekijät käsitte- levät asiakkaiden lähettämiä yhteydenottoja.
Releasetestauksen yhteydessä asiakkuudelle suoritetaan kymmeniä regressiotestitapauksia.
Tämä vaikutti myös valintaan, sillä mikäli osa asiakkuuden regressiotestitapauksista saadaan automatisoitua, vapauttaisi tämä merkittävästi testaajien työaikaa muuhun testaamiseen. Tä- män opinnäytetyön puitteissa ei ollut tarkoitus saada automatisoitua kaikkia asiakkuuden reg- ressiotestitapauksia, vaan tarkoitus oli automatisoida osa näistä regressiotestitapauksista.
Regressiotestitapaukset suoritetaan releasetestauksen yhteydessä aina testiympäristössä, jo- hon automaatiotestitapauksiakin kehitettiin.
4.5 Automaatiotestaukseen käytettävät työkalut
Seuraavissa kappaleissa esiteltäväksi valikoituivat ne automaatiotestaustyökalut, joilla kehit- tämistyötä lähdettiin edistämään tai joita toivottiin hyödynnettäväksi lisää tulevaisuudessa automaatiotestauksen kehittämisessä. Automaatiotestaustyökaluja löytyy myös lukuisia mui- takin, mutta niitä on välttämätöntä rajata, jotta konkreettinen kehittämistyö sai paremmin alkunsa eikä automaatiotestauksesta tulisi vain yksittäisten henkilöiden kokeiluja eri työka- luilla.
4.5.1 BrowserStack
Ritesh Arora ja Nakul Aggarwal perustivat BrowserStackin vuonna 2011 Mumbaissa ja tällä het- kellä yrityksellä on asiakkaita yli 25 000 ympäri maailman ja toimipisteet Mumbaissa, Dubli- nissa ja San Franciscossa. BrowserStack on pilvi- ja mobiilitestausalusta, joka mahdollistaa käyttäjilleen mobiili- ja verkkosovellusten testauksen eri mobiililaitteiden ja tietokoneiden verkkoselaimissa. (BrowserStack 2021b.)
BrowserStackin tuotteita ovat Live, Automate, Percy, App Live ja App Automate. App Live ja App Automate ovat tarkoitettu mobiilitestaukseen. Liven avulla käyttäjät pystyvät nauhoitta- maan testejä verkkosivuistaan eri selaimille, kun taas Automaten avulla voidaan ajaa auto- maatiotestejä, jotka hyödyntävät Selenium Web Driveria. Percyn avulla taas voidaan automa- tisoida visuaalista testausta, sillä se pystyy paikantamaan visuaalisia muutoksia sivustoilla tai alustoissa (BrowserStack 2021c).
Tässä opinnäytetyössä keskityttiin tutkimaan nimenomaisesti Automaten tarjoamia mahdolli- suuksia. Testausta ei tehty mobiililaitteilla, jolloin App Livea sekä App Automatea ei käsitelty tarkemmin eikä tarkoitus ollut tehdä visuaalista testausta, jolloin myöskään Percyn tarjoamia mahdollisuuksia ei tutkittu enempää.
4.5.2 Selenium
Selenium on avoimen lähdekoodin työkalu, jonka avulla voidaan automatisoida verkkosivus- toille tehtäviä testejä. Seleniumia voi käyttää ilman koodaustaitoja selaimiin ladattavan Sele- nium IDE- laajennuksen avulla tai hyödyntäen esimerkiksi Selenium WebDriveria, jolla voi luoda automatisoituja testitapauksia eri selaimille hyödyntäen erilaisia ohjelmointikieliä, mm. Javaa, Pythonia, Rubya tai C#:a. (Guru99 2021.) Seleniumia voi käyttää eri kehitysympä- ristöissä, esimerkiksi Eclipsessa, lisäämällä projektille tarvittavat kirjastot.
Selenium WebDriver suorittaa testejä selainkohtaisten ohjainten kautta, joita ovat esimer- kiksi Chromelle ChromeDriver, Firefoxille Mozilla GeckoDriver ja Safarille SafariDriver. Sele- nium WebDriver tukee monia käyttöliittymiä, mm. Windowsia, Mac:ia, Linuxia sekä Unixia.
(BrowserStack 2021d.)
Selenium IDE eli Selenium Integrated Development Environment on helppokäyttöinen testaus- työkalu, joka ei vaadi erityisiä asetuksia muita kuin laajennuksen lisäämisen selaimeen. Sele- nium IDE tarjoaa graafisen käyttöliittymän, jolla testitapauksia voi helposti nauhoittaa ja suo- rittaa joko yksitellen tai testijoukkona. (Unadkat 2021.)
Selenium tarjoaa myös Selenium Grid- tuotteen, jonka tarkoituksena on suorittaa useita tes- tejä samanaikaisesti eri selainten, käyttöliittymien ja koneiden välillä (Guru99 2021). Sen avulla voidaan suorittaa WebDriver- skriptejä etäkoneissa reitittämällä kutsuvan sovelluksen lähettämät komennot etäkoneissa oleville selaininstansseille, tarkoituksenaan tarjota helpon tavan suorittaa testejä rinnakkain useilla koneilla (Selenium 2021).
4.5.3 Katalon Studio
Katalon Studio kuuluu Katalonin tuoteperheeseen, johon kuuluvat lisäksi Katalon Recorder, Katalon TestOps ja Katalium. Katalon Recorder on Chrome-, Edge- ja Firefox- selaimiin asen- nettava IDE, jolla voidaan nauhoittaa testitapauksia samaan tapaan kuin Selenium IDE:llä. Ka- talon TestOps puolestaan on testauksen hallintaan ja suunnitteluun soveltuva työkalu. Kata- lium puolestaan on pääasiassa Visual Studio- kehitysympäristöön ladattava kehys, jonka tar- koituksena on helpottaa testijoukkojen ja testitapausten luontia sisäänrakennettujen ominai- suuksien avulla. (Katalon 2020.)
Katalon Studio on automaatiotestaukseen soveltuva avoimen lähdekoodin työkalu, joka laa- jentaa Seleniumin ja Appiumin ominaisuuksia. Sitä voidaan hyödyntää verkkosivujen, sovellus- liittymien (API) sekä mobiililaitteiden testaukseen. Katalon Studio tarjoaa selkeän käyttöliit- tymän sekä kaikki tarvittavat kehykset ja kirjastot eli se ei vaadi käyttäjältään erityisiä lisä- asennuksia. (Software Testing Genius 2021.) Käyttöliittymä mahdollistaa testitapausten manu- aalisen nauhoituksen sekä näkymän koodiin, jossa testitapausta voi muokata syntaksin
korostuksella ja lähdekoodin automaattisella täydennyksellä. Käyttöliittymän avulla voi myös luoda testijoukkoja tai luoda yksittäisiä testitapauksia. Katalon Studio tukee Google Chro- men, Firefoxin, Internet Explorerin, Microsoft Edgen, Operan sekä Safarin selaimia sekä Win- dowsin uusimpia käyttöjärjestelmiä (7,8,10), macOS 10.11+ -käyttöjärjestelmiä sekä Ubuntu- pohjaista Linuxia.
5 Kehittämistyön toteutus
Kehittämistyötä lähdettiin työstämään ajatuksella, että automaatiotestauksen toteutus olisi hyvä saada keskitettyä BrowserStackin ympärille. Ensimmäisenä tarkoitus oli tutkia millä työ- kalulla testitapauksia olisi parasta alkaa kehittämään sekä mikä palvelisi parhaiten yksinker- taisen ylläpidettävyyden ja helppokäyttöisyyden ajatusta.
BrowserStack tukee muitakin automaatiotestaukseen soveltuvia työkaluja kuin Seleniumia, mutta ajankäytön tehostamiseksi työkaluksi valittiin Selenium ja lähdettiin tutkimaan sen mahdollisuuksia testitapausten luomiseen, sillä jokaisen työkalun opettelu ja käytön vertailu olisi vienyt liikaa aikaa pois itse kehittämistyöltä. Tähän tarkasteluun valittuja, Seleniumin tukemia automaatiotestaustyökaluja ei ollut käytetty aiemmin yrityksessä.
5.1 Automatisoitavien regressiotestitapausten valitseminen
Releasetestauksen yhteydessä asiakkuudelle suoritetaan tietty joukko, yleensä vähintään kymmeniä, regressiotestitapauksia, jonka vuoksi niitä ei tarvinnut lähteä erikseen suunnitte- lemaan, koska ne olivat jo valmiina. Regressiotestitapausten valintaan vaikuttivat paljolti se, millaisia rajoitteita ne mahdollisesti sisälsivät teknisesti sekä niiden laajuus. Aluksi automati- soitaviksi valittiin testitapauksia, jotka sisälsivät vain muutamia yksinkertaisempia testis- teppejä, jotta voitiin havainnoida työkalujen toiminnallisuutta ja käytettävyyttä paremmin.
Lopuksi automatisoitaviksi valittiin myös laajempia testitapauksia. Itse toteutuksen aikana oli havaittavissa, että tiettyjä testitapauksia ei ole mielekästä lähteä automatisoimaan. Tällaisia testitapauksia olivat mm. sellaiset regressiotestitapaukset, jotka vaativat selkeästi käyttäjän havainnointia esimerkiksi käyttöliittymän visuaalisesta ilmeestä. Myös sellaiset testitapaukset, jotka vaativat jonkin liitteen lisäämistä käyttöliittymälle lokaalilta tietokoneelta, jätettiin tä- män opinnäytetyön puitteissa toteuttamatta.
5.2 eBusiness Suite
eBusiness Suite muodostuu asiakkuudelle kahdesta erillisestä portaalista; asioinnin käyttöliit- tymästä, joka on tarkoitettu nimenomaisesti kyseisen asiakkuuden omien asiakkaiden käyt- töön (Kuvio 3) sekä käsittelyn käyttöliittymästä, joka on tarkoitettu asiakkuuden työntekijöi- den käyttöön. Käytännössä sähköisen asioinnin kiertokulku toimii siten, että henkilöasiakas
lähettää yhteydenoton oman asiointiportaalinsa kautta, jonka asiakkaan työntekijät käsittele- vät käsittelyn portaalissa. Käsittely tarkoittaa tässä tapauksessa usein henkilöasiakkaiden viesteihin vastaamista portaalin kautta. Myös henkilöasiakas voi vastata takaisin viesteihin oman portaalinsa kautta.
Kuvio 3: Näkymä asioinnin portaalin etusivulta
Käsittelyportaalin etusivulle aukeavat käsittelijän omat, keskeneräiset asiat (Kuvio 4). Asiak- kuudessa henkilöasiakkailta tulevat yhteydenotot ovat jaettu työjonoihin sen mukaan, mitä asia koskee. Käsittelijä pääsee näkemään etusivun kautta erillisillä hakutoiminnoilla myös kaikki mahdolliset yhteydenotot; myös ne, jotka ovat uusia, käsittelyssä jollakin toisella tai mahdollisesti jo käsitelty.
Kuvio 4: Käsittelyportaalin etusivun näkymä
Käsittelijän valitessa jonkin asian, avautuu kyseinen asia selaimen uudelle välilehdelle avaten valikon toimenpiteistä, joita asialle voi tehdä. Toimenpiteistä voi mm. lähettää viestejä tai tarkastella asiaan liitettyjä kommentteja.
5.3 Testitapausten luonti Eclipse IDE- kehitysympäristössä Selenium- kirjastoa hyödyntäen Ensimmäinen tarkasteltava vaihtoehto oli Seleniumin hyödyntäminen Eclipse IDE- kehitysym- päristössä. Jotta testitapauksia on mahdollista luoda kehitysympäristössä, vaaditaan ensim- mäisenä Java SE Development Kit:in sekä Eclipsen IDE:n asennukset koneelle. Eclipse IDE-ke- hitysympäristö on erityisesti käytössä Java- ohjelmoinnissa, mutta se tukee myös muita ohjel- mointikieliä, kuten C:tä, C#:a, C++:a sekä Pythonia. Java- ohjelmistokehityspaketin ja Eclipse IDE- kehitysympäristön asennuksen jälkeen, Eclipseen tulee asentaa myös Selenium WebDri- ver- kirjastot, jotta sen tarjoamat ominaisuudet on mahdollista saada kehitysympäristössä käyttöön. Jotta WebDriver pystyisi hyödyntämään esimerkiksi yleisimpiä Google Chrome- se- lainta tai Firefox- selainta, tulee asentaa vielä erikseen ChromeDriver sekä GeckoDriver.
Testitapausten luonti Eclipsellä Seleniumin kirjastoja hyödyntäen, on suoraviivainen prosessi, joka käytännössä tarkoittaa vain koodin kirjoittamista. Tässä tapauksessa toteutettiin yksi yk- sinkertainen testitapaus, jolla testattiin sivuston sisään- ja uloskirjautumista (Kuvio 5).
Kuvio 5: Eclipse IDE- koodinäkymä
Testitapausten toteuttaminen jollakin ohjelmointikielellä on selkeimpiä vaihtoehtoja toteu- tustavaksi, mikäli ilmenee tarvetta muuttaa esimerkiksi elementtien hakemisen tapaa sivus- tolta. Elementtejä voi hakea eri parametreilla, joita ovat esimerkiksi elementtitunniste (HTML-elementin id-attribuutti), nimi (HTML-elementin name-attribuutti), xpath tai arvo (HTML-elementin value-attribuutti). Testitapausten ohjelmoinnilla voidaan saavuttaa myös parempaa testikattavuutta sekä luoda monipuolisia testitapauksia. Testitapausten toteuttami- nen suoraan ohjelmoimalla soveltuu erittäin hyvin, mikäli testaajalla on aiempaa taustaa tai kiinnostusta ohjelmointia kohtaan. Jos kuitenkin testaustiimin sisällä on henkilöitä, jotka ei- vät ole orientoituneita ohjelmointiin tai omaa siitä kokemusta, voi testitapauksien luominen
vain ohjelmoimalla muodostua ongelmaksi ylläpidettävyyden ja ymmärrettävyyden näkökul- masta.
5.4 Testitapausten luonti Selenium IDE:llä
Toisena tarkasteltavana vaihtoehtona oli testitapausten nauhoittaminen Selenium IDE:llä. Se- lenium IDE on selaimeen asennettava laajennus, joka mahdollistaa testitapauksien nauhoitta- misen. Itse asentaminen on hyvinkin helppoa ja vaatii vain laajennuksen lataamisen Google Chrome- tai Firefox- selaimiin, mikäli käytössä ovat nämä selaimet.
Testitapaukset nauhoitetaan Selenium IDE:llä, joka tarkoittaa sitä, että IDE sisältää kohdan, johon syötetään verkkosivuston osoite ja tämän jälkeen testitapauksen tallennus aloitetaan nauhoitus- painikkeesta. Nauhoitetun testitapauksen voi tallentaa ja suorittaa uudelleen. Se- lenium IDE:llä toteutettiin jälleen yksi yksinkertainen sisään- ja uloskirjautumistesti (Kuvio 6).
Kuvio 6: Selenium IDE- näkymä
Selenium IDE on erityisen helppokäyttöinen eikä se vaadi ohjelmointitaitoja. Sen asennus vaa- tii myös hyvin vähän aikaa ja on erittäin yksinkertaista. Selenium IDE tukee monia ominai- suuksia kuten mm. debuggausta, visuaalista testausta sekä koodin muokkausta. Mikäli kuiten- kin itse koodia haluaa muokata, Selenium IDE:llä se vaatii hieman enemmän vaivannäköä, sillä Selenium IDE tallentaa testien koodit JSON- tiedostoiksi, jotka tulee avata jossakin tekstiedi- torissa ja vasta tämän jälkeen muokata. Koodia ei siis pääse laajennuksesta näkemään ja muokkaamaan suoraan.
5.5 Testitapausten luonti Katalon Studiolla
Kolmantena tarkasteltavana vaihtoehtona oli Katalon Studio. Katalon Studio on erikseen ko- neelle asennettava IDE, joka tarjoaa kaiken tarvittavan käyttäjälleen eli selkeän ja helppo- käyttöisen käyttöliittymän sekä kaikki tarvittavat kirjastot.
Katalon mahdollistaa käyttöliittymässä testien nauhoituksen joko verkkosivuille tai mobiilille sekä myös helpon koodin muokkauksen. Manual- näkymä näyttää nauhoitetun testitapauksen askeleet selkeästi tehdyn nauhoituksen mukaisesti (Kuvio 7) ja Script- osio taas avaa näkymän suoraan koodiin (Kuvio 8).
Kuvio 7: Manual- näkymä Katalon Studiossa
Kuvio 8: Script- näkymä Katalon Studiossa
Katalon Studiossa testitapausten luonti onnistuu yläpalkin nauhoitus- kuvakkeesta (maapalloi- koni punaisella nauhoitus- kuvakkeella), jonka jälkeen valitaan haluttu selain sekä verkkosi- vun osoite, jossa testi nauhoitetaan. Nauhoitetun testitapauksen voi tallentaa haluttuun si- jaintiin ja toistaa uudelleen. Katalon Studio mahdollistaa myös testijoukkojen tallentamisen sekä erikseen mahdollisuuden katsella ja muokata oliovarastoa (Object Repository), joka tal- lentaa sivustolla käytettyjen elementtien kohdistintiedot (Kuvio 9).
Kuvio 9: Näkymä oliovarastoon Katalon Studiossa
Suurin osa automatisoitavista regressiotestitapauksista nauhoitettiin Katalon Studiolla, sillä se tarjoaa helpon ja monipuolisen käyttöliittymän. Katalon Studion asennus ei vaadi käyttäjäl- tään monimutkaisia toimenpiteitä eikä sen käyttöönotto ole vaikeaa. Käyttöliittymässä oleva mahdollisuus päästä suoraan muokkaamaan testitapauksen koodia on hyvä ominaisuus. Kata- lon Studio tarjoaa kuitenkin vain rajoitetut ominaisuudet ilmaisella versiolla ja esimerkiksi debuggaus ei onnistu kuin maksullisella lisenssillä. Mikäli automaatiotestauksessa on tarvetta monipuoliselle määrälle ohjelmointikieliä, Katalon Studio ei ole siihen optimaalisin vaihto- ehto, sillä se tukee vain Javaa ja Groovya.
5.6 Automaatiotestaustyökalujen valinta ja vertailu
Automaatiotestaustyökaluja löytyy runsaasti muitakin, mutta tässä tapauksessa niiden testaus oli rajattava vain muutamaan käyttökelpoiseen kohteeseen, jotta testitapauksia on myös mahdollista luoda aikarajoitusten puitteissa. Lähtökohtana oli, että työkaluilla luodut
testitapaukset on mahdollista yhdistää BrowserStackiin. Vaikka BrowserStack tukee muitakin automaatiotestaustyökaluja, päätettiin tässä tapauksessa ottaa tarkasteluun sellaiset työka- lut, jotka pohjautuvat Seleniumiin.
Vertailuun otettiin testitapausten luominen Eclipse IDE- kehitysympäristössä Selenium- kirjas- toja hyödyntäen, Selenium IDE sekä Katalon Studio. Ensimmäisenä ongelmana havaittiin, että testitapausten luominen ohjelmointikielellä kehitysympäristössä voisi olla liian työlästä ja hankalaa ylläpitää. Tämän vuoksi testitapauksia ei lähdetty kehittämään edelleen puhtaasti ohjelmoimalla.
Toisena testattiin testitapausten nauhoittamista selaimiin lisättävällä Selenium IDE- laajen- nuksella. Itse testitapausten nauhoittaminen onnistui hyvin, mutta muutaman havaitun ongel- man vuoksi, jotka vaativat helpompaa ja nopeampaa pääsyä testitapaukseen koodiin, päätet- tiin, että testitapauksia ei luoda tällä välineellä.
Lopulta testitapauksien nauhoittamiseen valittiin Katalon Studio, joka tarjoaa selkeän käyttö- liittymän, nauhoittamisen helppouden sekä nopean pääsyn muokkaamaan itse koodia. Katalon Studio tarjoaa ne mahdollisuudet, jotka puuttuvat työkaluista, jotka pohjautuvat pelkästään koodin luomiseen tai toimivat vain nauhoitustyökaluina.
6 Kehittämistyön tulokset
Alun perin kehittämistyön tarkoituksena oli hyödyntää nimenomaisesti Visma Consulting Oy:llä käytössä olevaa BrowserStack- lisenssiä. Ongelmaksi kuitenkin muodostui automatisoitavien testitapausten julkinen näkyvyys, sillä lähtökohtaisesti luodut testitapaukset näkyvät koko or- ganisaatiolle, joka ei ole haluttu tila. Testitapausten näkyvyyttä halutaan rajoittaa nimen- omaisesti liiketoimintayksikkötasolle jo asiakkaiden yksityisyyden ja tietoturvallisuuden tur- vaamiseksi sekä sen estämiseksi, että kukaan organisaation sisällä ei vahingossa muuttaisi au- tomatisoituja testitapauksia.
BrowserStack kuitenkin mahdollistaa näkyvyyden vain rajatulle käyttäjäryhmälle, mutta asian toteuttaminen vaatii sisäisiä toimenpiteitä sekä lisätarkasteluja, jonka vuoksi nyt automati- soituja testitapauksia ei tämän opinnäytetyön puitteissa pystytty lisäämään ja hyödyntämään BrowserStackissa.
6.1 Automatisoidut regressiotestitapaukset
Katalon Studiolla automatisoitiin kaikkiaan kyseiseltä asiakkuudelta muutamia kymmeniä reg- ressiotestitapauksia, mutta kaikkia asiakkuuden regressiotestitapauksia ei kuitenkaan voitu automatisoida. Muilla automaatiotestaustyökaluilla tehtiin lähinnä vain yksinkertaisia
kokeiluja sisään- ja uloskirjautumisesta, mutta muutoin automaatiotestitapausten luontiin käytettiin Katalon Studiota, jolla automatisoitiin sisään- ja uloskirjautumisen lisäksi myös laa- jempia testitapauksia.
Automatisoinnin piiristä jäivät toistaiseksi pois sellaiset testitapaukset, joissa vaaditaan visu- aalisen ilmeen tarkistusta sekä sellaiset, joissa portaaliin lisätään liite esimerkiksi omalta ko- neelta. Myös luotuja testitapauksia yksinkertaistettiin niiden alkuperäisestä muodosta sen vuoksi, että osa testitapauksista sisälsi sellaisia teknisiä haasteita, joita ei saatu ratkaistua ajan puitteissa.
6.2 Havaitut ongelmat
Automatisoitavien regressiotestien luomisen aikana havaittiin muutamia ongelmia, jotka esti- vät joidenkin ominaisuuksien testauksen osittain tai kokonaan. Ensimmäiseksi havaittu on- gelma esiintyi sisäänkirjautumisen yhteydessä, kun Katalon Studio pyrki hyödyntämään ele- menttitunnistetta (HTML-elementin id-attribuutti) kohdistintietona. Sisäänkirjautumisen yh- teydessä oleva elementtitunniste on dynaaminen, joka vaikutti siten, että sisäänkirjautumi- nen onnistui vain muutamalla kerralla, mutta ei kaikkina suorituskertoina. Ongelman ratkai- suksi testitapausten koodeihin annettiin kohdistintiedoksi elementtitunnisteen sijaan arvo (HTML-elementin value-attribuutti) ’Kirjaudu sisään’.
Toiseksi havaittu ongelma esiintyi sellaisilla sivuilla, joissa oli useasti samanniminen painike.
Tässä tapauksessa ongelma ilmeni Tallenna- nimisen painikkeen kohdalla, sillä Katalon Studio tallentaa painikkeen sen nimen perusteella (Kuvio 10).
Kuvio 10: Tallenna- painike Katalon Studiossa
Tilanne muodostui ongelmalliseksi, mikäli Tallenna- painike oli samalla sivulla monta kertaa, vaikkakin joka kerta eri elementtitunnisteella. Katalon Studio ei tehnyt automaattisesti jokai- sesta esiintyneestä Tallenna- painikkeesta uuden nimistä versiota oliovarastoon, vaan se asetti ensimmäisenä nauhoitetun Tallenna- painikkeen elementtitunnisteen jokaisen Tallenna- painikkeen kohdalle, jolloin testitapauksen suoritus epäonnistui. Ongelman ratkaisuksi jokai- nen Tallenna- niminen painike tuli nimetä uudelleen uniikilla arvolla ja elementtitunnisteella sekä sijoittaa oikean niminen painike vastaamaan sivulla olevan Tallenna- painikkeen ele- menttitunnistetta (Kuvio 11).
Kuvio 11: Tallenna- painikkeen uudelleen nimeäminen
Muutos oli helpointa tehdä suoraan testitapauksen koodiin (Kuvio 12).
Kuvio 12: Tallenna- painikkeen nimeäminen koodiin
Testauksen edetessä havaittiin myös, että järjestelmän lähettämän viestin teksti sisälsi yli- määräisiä HTML- tageja, kuten seuraavassa esimerkissä: <p style="">testiviestiä</p><p style=""><br></p>. Asia jätettiin toistaiseksi tarkempaan selvittelyyn, jonka vuoksi siihen ei saatu ratkaisua tämän kehittämistyön puitteissa.
Erään testitapauksen nauhoituksen osalta havaittiin toiminnallinen ongelma eikä testitapausta saatu suoritettua lainkaan, mikäli selainikkunaa ei asetettu kokonäyttöön. Ongelman ratkaise- miseksi testitapauksen koodiin tuli lisätä metodi WebUI.maximizeWindow().
Huomioitavaa on myös se, että tällä hetkellä käytössä olevat testikäyttäjätunnukset portaa- leihin ovat käytössä myös itse asiakkaalla, kehitystiimillä sekä muilla testaajilla. Tästä voi muodostua automatisoitujen testitapausten osalta ongelma, sillä mikäli joku muu henkilö muuttaa automatisoidun testitapausten osalta niiden lähtökohtia tai jotakin osaa, joka vaikut- taa niiden toiminnallisuuteen, tällöin testitapauksen suorittaminen epäonnistuu. Ongelma voi- daan ratkaista luomalla erilliset testikäyttäjätunnukset portaaleihin, jotka ovat vain automaa- tiotestauksen käytössä. Myös sillä on merkitystä, mikäli testiaineistoon tehdään muutoksia jonkun muun kuin automaatiotestaustyökalun toimesta.
7 Yhteenveto
Kehittämistyön tarkoituksena oli automatisoida osa asiakkuuden regressiotestauksessa käytet- tävissä testitapauksista ja tämä tavoite onnistuttiin saavuttamaan. Alkuperäinen ajatus Brow- serStackin hyödyntämisestä automaatiotestauksessa ei tässä tapauksessa onnistunut suunni- tellusti, mutta se kuitenkin antoi alkusysäyksen siihen suuntaan, miten automaatiotestausta mahdollisesti halutaan kehittää lisää. Itse testitapausten luonti paljasti seikkoja, jotka vaati- vat lisää tutkimista sekä yhteistyön tarvetta eri tiimien välillä.
Automaatiotestauksen käyttöönotossa on monta vaihetta ja asiaa, jotka tulee ratkaista ennen kuin sitä voidaan alkaa täysimittaisesti hyödyntämään. Aluksi on tärkeää arvioida mitä halu- taan automatisoida ja sen jälkeen pohtia onnistuuko kyseisten testitapausten automatisoimi- nen ja onko se mielekästä sekä tarpeellista. Automaatiotestauksen kehittäminen vaatii aluksi resurssien hyödyntämistä laajamittaisesti sekä yhteistyötä eri tiimien välillä. Näiden edellä mainittujen lisäksi se vaatii myös motivoituneita tekijöitä, suunnitelmallisuutta sekä taitoa hyödyntää erilaisia automaatiotestaustyökaluja. Automaatiotestauksen systemaattiseen lisä- kehittämiseen on realistista varata myös runsaasti aikaa epärealististen aikaodotusten ja no- pean hyödyn tavoittelun välttämiseksi. Mikäli automaatiotestaukselle asetetaan liian suuret odotukset ja oletetaan, että manuaalisen testauksen tarve häviäisi sen myötä kokonaan, ol- laan menossa väärään suuntaan. Parhaimmillaan kuitenkin automaatiotestaus säästää resurs- seja tarpeettomalta manuaaliselta testaukselta ja sen myötä resurssit voidaan kohdentaa vielä tehokkaammin esimerkiksi uusien ominaisuuksien testaukseen.
Yrityksen sisällä tämän opinnäytetyön puitteissa tehty kehittämistyö lisäsi tietoutta Sele- niumiin pohjautuvien automaatiotestaustyökalujen hyödynnettävyydestä. Se vahvisti myös ajatusta mihin suuntaan automaatiotestausta voidaan lähteä kehittämään lisää, millaisia
rajoitteita ja millaisia mahdollisuuksia siihen sisältyy sekä miten paljon resursseja se vaatii myös jatkossa. Kehittämistyö antoi lisää vertailupohjaa sen suhteen, millaisia työkaluja tes- tauksen automatisointiin Selenium tarjoaa ja mikä niistä palvelisi parhaiten helpon ylläpidet- tävyyden ja käytettävyyden tavoitetta. Automaatiotestauksen käyttöönottoon vaikuttavat kui- tenkin eniten resurssit, olivatpa ne henkilöresursseja tai rahallisia. Harva automaatiotestaus- työkalu on kuitenkaan täysin ilmainen, joten pohdittavaksi jää kuinka paljon automaatiotes- tauksen kehittämiseen halutaan sijoittaa rahallisia resursseja sekä henkilöresursseja, sillä ly- hyellä tähtäimellä automaatiotestauksen kehitystyö on pois laskutettavasta projektityöstä, mutta pitkällä tähtäimellä se on kuitenkin panostus, joka maksaa itsensä takaisin.
8 Oman oppimisen arviointi
Automaatiotestauksen jatkokehitys oli mielenkiintoinen ja erittäin opettavainen projekti, sillä ohjelmistotestaajana kehittyminen vaatii tänä päivänä lähes poikkeuksetta myös yhden tai useamman automaatiotestaustyökalun hallintaa. Manuaalitestaukselle tulee olemaan varmasti aina tarvetta, mutta monen yrityksen tavoitteena on pyrkiä lisäämään automaatiota koko oh- jelmiston kehityskaaren osalta, jonka vuoksi automaatiotyövälineitä hallitseville tekijöille on aina kysyntää.
Automaatiotestauksessa hyödynnettävät työkalut eivät olleet entuudestaan tuttuja, jonka vuoksi niihin tutustuminen vaati myös enemmän aikaa. Työkalujen optimoitu käyttö vaatii myös jonkin verran kykyä ohjelmoimiseen tai edes kykyä lukea sujuvasti koodia. Automaatio- testaustyökaluihin perehtyminen avarsi kuitenkin näkymiä siihen, millaisia työkaluja markki- noilla on käytettävissä ja mitä niiden kanssa voi tehdä. Työkaluihin tutustuminen ei kuiten- kaan yksistään riitä, vaan tarvitaan myös oikeaa käytännön kokemusta sekä laaja-alaisempaa teknistä osaamista ohjelmistokehityksestä ja ymmärrystä liiketoiminnan prosesseista. Tämän vuoksi itsensä kehittämistä ei voi lopettaa opinnäytetyöhön tai yhteen projektiin työelämässä, mikäli haluaa kehittyä oman alansa ammattilaiseksi.
Kehittämistyön myötä vahvistui näkemys siitä, mihin omaa osaamistaan haluaa vielä kehittää.
Käytännössä tämä tarkoittaa jo opeteltuun työkaluun paremmin perehtymistä sekä mahdolli- sesti uuden työkalun, esimerkiksi Robot Frameworkin, käytön opettelua ja toivottavasti myös mahdollisuutta hyödyntää oppimaansa käytännön työelämässä. Luonnollisesti tämä tarkoittaa myös ohjelmoinnissa opittujen taitojen ylläpitämistä ja kehittämistä, sillä useat automaatio- testaustyökalut vaativat jonkin ohjelmointikielen hyvää hallintaa.
