Graafisten käyttöliittymien automaattinen testaus

(1)

Graafisten käyttöliittymien automaattinen testaus

Ville Puoskari

Pro gradu –tutkielma

Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede

Toukokuu 2021

(2)

i

ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Joensuu Tietojenkäsittelytieteen laitos

Tietojenkäsittelytiede

Opiskelija, Ville Puoskari: Graafisten käyttöliittymien automaattinen testaus Pro gradu –tutkielma, 57 s.

Pro gradu –tutkielman ohjaaja: Markku Tukiainen

Tiivistelmä: Tutkielman tavoitteena on tutkia ja selvittää mitä graafisten käyttöliitty- mien automaattinen testaus on, mitkä ovat sen pääpiirteet ja kuinka sitä voidaan toteuttaa. Lisäksi tuodaan esille, minkä vuoksi graafisten käyttöliittymien testaus on hyvin tärkeä osa ohjelmistotestausta nykypäivänä. Tutkielma toteutettiin kuvailevana kirjallisuuskatsauksena, jossa perehdyttiin aiheeseen liittyvään kirjallisuuteen, jonka avulla pystyttiin vastaamaan tutkimuskysymyksiin. Graafiset käyttöliittymät ovat osa jokapäiväistä elämäämme, ja niitä esiintyy useissa eri käyttöpaikoissa, kuten mobiili tai websovelluksissa. Nykypäivänä pääasiallinen tapa ohjata ohjelmistoja on graafisten käyttöliittymien kautta. Tämän vuoksi graafisten käyttöliittymien oikeellisuuden ja eheyden varmistaminen testauksen avulla on tärkeässä roolissa ohjelmistotestauksessa. Tarve graafisten käyttöliittymien testaamiselle kasvaa entisestään, sillä ohjelmistot ja niiden graafiset käyttöliittymät kasvavat jatkuvasti ja muuttuvat yhä moni- mutkaisemmiksi. Manuaalinen testaaminen on hidasta ja kallista sekä yhä haastavampaa mitä suuremmaksi graafinen käyttöliittymä kasvaa. Näiden ongelmien ratkaisuksi ehdotetaan automaattisen testauksen käyttöönottoa. Graafisten käyttöliittymien automaattisessa testauksessa automatisoidaan graafisten käyttöliittymien testauksen vaiheita. Automaation merkittävimpiä etuja ovat testauksen suorittamisen nopeus, testien toistettavuus ja mahdollisuus testauksen suorittamiseen ilman ihmisen läsnäoloa. Tes- tiautomaation toteuttaminen vaatii alkuun investointeja eikä testiautomaatiosta saada välttämättä hyötyjä suoraan, vaan hyödyt ja säästöt tulevat esille testien toistettavuu- den avulla pidemmällä aikavälillä. Graafisten käyttöliittymien automaattinen testaus ei kuitenkaan yksin ratkaise kaikkia graafisten käyttöliittymien testaukseen liittyviä ongelmia. Paras mahdollinen testauksen kattavuus ja käytännöllisyys voidaan saavuttaa, kun manuaalista ja automaattista käyttöliittymätestausta hyödynnetään yhdessä graafisten käyttöliittymien testaamiseen.

Avainsanat: Graafinen käyttöliittymä; Graafisten käyttöliittymien testaus; Testiauto- maatio; Automatisoitu graafisten käyttöliittymien testaus; ohjelmistotuotanto

ACM-luokat (ACM Computing Classification System, 2012 version):

•Software and its engineering → Software creation and management → Software ver- ification and validation → Software defect analysis → Software testing and debugging

(3)

ii

UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Joensuu School of Computing

Computer Science

Student, Ville Puoskari: Automatic testing of graphical user interfaces Master’s Thesis, 57 p.

Supervisors of the Master’s Thesis: Markku Tukiainen May 2012

Abstract: The aim of this Master’s Thesis is to research and study what automatic testing of graphical user interfaces is and what are its main features and how it can be implemented. It is also highlighted why graphical user interface testing is a very im- portant part of software testing today. The study was carried out as a descriptive literature review, in which the related literature was examined, which was used to answer the research questions. Graphical user interfaces are a part of our daily lives and occur in many different places of use, such as mobile or web applications. Today, the main way to control software is through graphical user interfaces. Therefore, ensuring the correctness and integrity of graphical user interfaces through testing plays and im- portant role in software testing. The need to test graphical user interfaces is growing as software and their graphical user interfaces continue to grow and become more complex. Manual testing is slow and expensive, and increasingly challenging as the graphical user interface grows. To solve these problems, it is proposed to introduce the use of automatic testing. In automatic testing of graphical user interfaces steps of graphical user interface testing is automated. The most significant advantages of automation are the speed of testing, the repeatability of tests and the possibility to perform testing without human presence. Implementing test automation requires initial invest- ment and it does not necessarily give benefits straight away, but the benefits and sav- ings come from the repeatability of the test in the longer time frame. However, automatic testing of graphical user interfaces alone does not solve all the problems of graphical user interface testing. The best possible testing coverage and practicality can be achieved when manual and automatic user interface testing are utilized together for graphical user interface testing.

Keywords: Graphical User Interface, Graphical User Interface Testing, Test Automa- tion, Automated Graphical User Interface Testing, Software Engineering

CR Categories (ACM Computing Classification System, 2012 version):

•Software and its engineering → Software creation and management → Software ver- ification and validation → Software defect analysis → Software testing and debugging

(4)

iii

Esipuhe

Tämä tutkielma on tehty Itä-Suomen yliopiston Tietojenkäsittelytieteen laitokselle ke- väällä 2021.

Ennen tutkielman aiheen valitsemista olin ollut työharjoittelussa paikallisessa ohjel- mistoyrityksessä ja siellä päädyin perehtymään graafisten käyttöliittymien testaukseen ja pääsin kirjoittamaan automaatiotestejä websovellusten graafisille käyttöliittymille.

Tämän harjoittelun aikana mielenkiintoni ohjelmistotestausta ja erityisesti graafisten käyttöliittymien testiautomaatiota kohtaan nousi suuresti ja harjoittelun jälkeen toi- voin, että voisin perehtymään aiheeseen jollakin tavoin lisää. Tämän mielenkiinnon kasvamisen seurauksena halusin tutkia Pro Gradu tutkielmassani tarkemmin graafisten käyttöliittymien testauksen automatisointia. Lisäksi aiheen valintaan vaikutti se, että minulla saattaisi olla mahdollisuus palata samoihin työtehtäviin työntekijänä yrityk- seen, jossa olin ollut harjoittelussa, joten halusin osoittaa myös tällä tavalla erityistä kiinnostusta aihealuetta kohtaan.

Minua kiinnosti erityisesti tutkia ja selvittää laajemmin graafisten käyttöliittymien testiautomaatiota, sillä olin nähnyt siitä vain yhden puolen, websovellusten käyttöliitty- mien testauksen kannalta. Lisäksi olin tehnyt harjoittelussani jonkin verran manuaalista graafisen käyttöliittymän testausta, joten halusin myös löytää tieteellistä tietoa vahvistamaan omia harjoittelun aikaisia havaintoja manuaalisen ja automaatiotestaa- misen eroista. Koen, että tutkielman tekeminen on vahvistanut tietojani ja ymmärrys- täni tästä testauksen osa-alueesta huomattavasti.

Koen myös tutkielmani hyödylliseksi siltä näkökannalta, että en itse löytänyt kovin- kaan montaa saman tapaista tieteellistä tutkimusta, jossa perehdytään laajemmalta per- spektiiviltä graafisten käyttöliittymien testauksen automatisoinnin aiheeseen. Usea teksti sivusi tai käsitteli aihealuetta muilta näkökannoilta. Lisäksi moni löytämistäni tieteellisistä teksteistä keskittyi yleensä johonkin tiettyyn tekniikkaan tai uuden kehi- tetyn tavan tai työkalun luomiseen. Mielestäni on ollut hyödyllistä toteuttaa tutkielma, jossa tuodaan esille graafisten käyttöliittymien testiautomaation erilaisia toteutustapoja ja eroja sekä että aihealuetta on käsitelty laajemmalta näkökannalta.

(5)

iv

Käsiteluettelo

BITTIKARTTA Kuvan esitystapa digitaalisessa muodossa

GRAAFINEN KÄYTTÖLIITTYMÄ Graafisiin elementteihin perustuva tapa käyttää ohjelmistoa

SOFTWARE AS A SERVICE (SaaS) Ohjelmiston jakelumalli, jossa kolmas osa- puoli tarjoaa palvelun internetin kautta.

TESTIAUTOMAATIO Ohjelmistotestaus työn automatisointia TESTISKRIPTI Ohjelmoimalla kirjoitettu testi, jonka avulla

suoritetaan testaus toimi automaattisesti TESTITAPAUS Yksittäisen testin määrittely ja kuvaus testin

suorittamisesta ja odotetusta lopputuloksesta

(6)

v

Sisällysluettelo

1 Johdanto ... 1

2 Ohjelmistotuotanto ja testaus ... 4

2.1 Ohjelmistotestaus ... 4

2.2 Testauksen toteutus ja tavat ... 6

2.3 Testauksen haasteet ... 7

3 Automaattinen testaus ... 10

3.1 Automatisoinnin edut ... 11

3.2 Automatisoinnin toteutus ... 13

3.3 Jatkuva integraatio ... 14

3.4 Automatisoinnin haasteet ... 14

3.5 Automatisoinnin suunnittelu ja mitä automaatiolla saavutetaan ... 16

4 Graafiset käyttöliittymät ... 19

4.1 Graafinen käyttöliittymä ... 19

4.2 Erilaiset graafiset käyttöliittymät ... 20

5 Graafisten käyttöliittymien testaus ... 24

5.1 Graafisten käyttöliittymien testauksen toteutus ... 24

5.2 Graafisten käyttöliittymien testauksen prosessi ... 25

5.3 Erilaisten graafisten käyttöliittymien testaus ... 26

6 Graafisten käyttöliittymien automaattinen testaus ... 29

6.1 Graafisten käyttöliittymien automaattisen testauksen piirteet ... 30

6.2 Graafisten käyttöliittymien automaattisen testauksen suunnittelu .... 33

6.3 Graafisten käyttöliittymien testauksen automatisoinnin tavat ... 34

6.3.1 Mallipohjainen testaus ... 35

6.3.2 Tallenna/toista -testaus ... 35

6.3.3 Automaattiset testiskriptit ... 36

6.3.4 Kuvakaappaus testaus ... 37

6.3.5 Visuaalinen graafisten käyttöliittymien testaus ... 38

7 Graafisten käyttöliittymien testiautomaation työkalut ... 39

7.1 Testiautomaation sukupolvet ... 39

7.2 Testiautomaation työkalut ... 42

7.2.1 TestComplete ... 42

7.2.2 Selenium ... 43

7.2.3 Appium ... 43

7.2.4 Ranorex ... 44

7.3 Pilvipohjaiset ratkaisut ... 44

7.3.1 Jenkins ... 45

7.3.2 Azure DevOps ... 45 8 Graafisten käyttöliittymien testaus osana ohjelmistotuotantoa ja testausta47

(7)

vi

9 Yhteenveto ... 50 Viitteet ... 53

(8)

1 Johdanto

Graafiset käyttöliittymät ovat osa jokapäiväistä elämäämme nykyaikana. Nykypäivänä pääasiallinen tapa ohjata ohjelmistoja on graafisten käyttöliittymien kautta. Tämän tutkielma tarkoituksena on käsitellä graafisten käyttöliittymien automaattista testausta.

Tutkielmassa pyritään tuomaan esille graafisten käyttöliittymien testauksen pääpiir- teitä ja tutkimus kohdistuu graafisten käyttöliittymien testiautomaatioon. Tutkielma toteutetaan kuvailevana kirjallisuuskatsauksena ja tutkielman tavoitteena on selvittää graafisten käyttöliittymien testiautomaation ominaisuuksia, tärkeyttä ohjelmistotestauksessa ja kuinka sitä toteutetaan. Lisäksi tutkielmassa pyritään luomaan katsaus graafisten käyttöliittymien testauksen rooliin ohjelmistotuotannossa ja tarkastelemaan graafisten käyttöliittymien testiautomaation työkaluja. Tutkimuskysymyksiä tutkielmassa ovat: Mitä on graafisten käyttöliittymien automaattinen testaus, miten graafisten käyttöliittymien automaattista testausta toteutetaan ja mitä graafisten käyttöliittymien testiautomaatiolla saavutetaan.

Testauksen automatisointi on jatkuvasti kehittyvä ala ja varhaisista graafisten käyttö- liittymien automaation tavoista, kuten tallennettujen käyttöliittymä toimintojen toista- misesta, on edetty jo tekoälyä hyödyntäviin testaustapoihin. Graafiset käyttöliittymät kehittyvät nopealla tahdilla ja muuttuvat koko ajan laajemmiksi ja monimutkaisem- miksi, graafisten käyttöliittymien koodi voi olla jopa puolet koko ohjelmiston koodista. Suuriosa graafisen käyttöliittymän testaamisesta toteutetaan nykyäänkin yhä ma- nuaalisin keinoin, mutta se on hyvin aikaa vievää ja virheherkkää työtä sekä yhä laa- jemmaksi kasvavat graafiset käyttöliittymät hankaloittavat tätä prosessia entisestään.

Tämän vuoksi on tärkeää perehtyä graafisten käyttöliittymien testiautomaatioon ja sen toteutukseen, jotta voidaan pyrkiä ratkaisemaan manuaalisesta testaamisesta koituva rajoitteita ja ongelmia. Lisäksi testiautomaatiolla voidaan mahdollisuuksien mukaan pystyä kattamaan testattavan alustan graafisen käyttöliittymän testaus laajemmin kuin manuaalisella testaamisella, koska testiautomaatio on huomattavasti nopeampi tapa suorittaa testausta. Testiautomaatiota koskevat haasteet liittyvät siihen tarvittaviin in- vestointeihin, tietotaitoon ja osaamiseen sekä testien suunnittelun ja toteutuksen vaa- tivuuteen.

(9)

Graafisten käyttöliittymien testausta ja automaattista testausta on tutkittu useissa muis- sakin tutkimuksissa. Muun muassa Garousi et al. (2013) tutki tapaustutkimuksessa sitä, millaisia hyötyjä voidaan saavuttaa, kun automaattinen graafisten käyttöliittymien testaus otetaan käyttöön lakihallinto ohjelmiston testauksessa. Toisaalta joissakin aiheeseen liittyvissä tutkimuksissa kehitettiin uusia työkaluja tai tekniikoita graafisten käyttöliittymien testauksen automatisointiin. Esimerkiksi Nguyen et al. (2014) kehit- tivät uuden innovatiivisen montaa erilaista tekniikkaa hyödyntävän työkalun, GUI- TAR, automaattiseen graafisen käyttöliittymän testaukseen. Tämän tutkielman kanssa samankaltaisia kirjoituksia eli aihetta laajemmin käsitteleviä tutkimuksia ei juurikaan löytynyt, usein tutkimuksissa keskityttiin johonkin tiettyyn tapaan, tekniikkaan tai alustaan graafisen käyttöliittymän automatisoinnin kannalta. Kuten Sztipanovits et al.

(2008) käsitteli kirjoituksessaan automaattista testausta websovellusten kontekstissa tai Kropp ja Morales (2010) automaattista graafisen käyttöliittymän testausta Android alustalla. Aihetta on selvästi käsitelty tieteellisessä kirjallisuudessa laajasti, mutta hyvin monilta eri näkökulmilta. Tieteellinen kirjallisuus graafisten käyttöliittymien automaattiseen testaukseen liittyen vaikuttaa keskittyneen useasti yksittäisen tekniikan, tavan tai käyttötarkoituksen tutkimiseen. Tässä tutkielmassa on esitetty laajempia ko- konaisuuksia yhdistämällä yksittäisten lähteiden tietoja, joiden perusteella on voitu koostaa laajemman perspektiivin kuvauksia.

Tutkielman luvussa 2 käsitellään ohjelmistotestausta ja luodaan tätä kautta leikkaus testauksen osa-alueeseen. Tarkoituksena on esitellä ohjelmistotestauksen yleispiirteitä ja kuinka tutkielmassa tutkittava alue liittyy ohjelmistotestaukseen. Tällä tavoin pyri- tään antamaan kuvaus siitä, mitä testaus on yleisellä tasolla, ennen kuin perehdytään tarkemmin sen yksittäisiin osa-alueisiin. Luvussa 3 esitellään automaattista testausta ja kuvataan mitä testauksen automatisoinnilla saavutetaan ja millaisia asioita automaation toteutuksessa tulisi ottaa huomioon. Näin luodaan kuva siitä, mitä testiautomaatiolla tarkoitetaan. Luku 4 käsittelee lyhyesti erilaiset graafiset käyttöliittymät ja kuinka ne eroavat toisistaan, sillä tämä vaikuttaa myös siihen, kuinka graafisten käyttöliitty- mien testausta ja sen automatisointia toteutetaan. Luvussa 5 esitellään graafisten käyt- töliittymien testausta, testauksen prosessia ja toteutusta. Päätutkimusalueena tutkielmassa on graafisten käyttöliittymien automaattinen testaus ja luvussa 6 esitetään mitä graafisten käyttöliittymien automaattinen testaus tarkoittaa, kuinka sitä toteutetaan ja mitä tällä automaatiolla voidaan saavuttaa graafisten käyttöliittymien testauksen

(10)

kontekstissa. Tämän jälkeen luvussa 7 luodaan katsaus muutamiin tutkielman kirjoit- tajan mielestä relevantteihin työkaluihin, joita käytetään graafisten käyttöliittymien automaattiseen testaukseen. Luku 8 käsittelee graafisten käyttöliittymien testauksen roolia ohjelmistotuotannon ja testauksen kokonaisuudessa. Lopuksi luvussa 9 käydään läpi pohdintaa ja esitellään tutkielman johtopäätökset.

(11)

2 Ohjelmistotuotanto ja testaus

Ohjelmistotuotannolla tarkoitetaan kaikkia niitä käytäntöjä ja menetelmiä, joita liittyy erilaisten ohjelmistojen tuottamiseen. Nämä eri prosessit yhdessä luovat kokonaisuu- den ohjelmistojen kehittämiselle ja tästä kokonaisuudesta käytetään nimitystä ohjelmistotuotanto. Ohjelmistotuotanto käsittää niin ohjelmiston suunnittelun, kehityksen kuin testauksen ja ylläpidon vaiheet.

Tässä luvussa tarkastellaan testausta osana ohjelmistotuotannon kokonaisuutta ja esi- tellään testaamisen osa-aluetta ohjelmistotuotannon näkökulmasta. Yleisemmin tätä osa-aluetta voidaan kutsua ohjelmistotestaukseksi. Termillä ohjelmistotestaus voidaan viitata mihin tahansa suunniteltuun toimintaan, jonka tavoitteena on vähentää riskejä muun muassa ohjelmiston kehityksessä, sen toiminnassa tai ylläpidossa (DeMillo, 2003). Ohjelmistotestaus on olennainen osa ohjelmiston laadun varmistamista. Sitä toteutetaankin jokaisessa ohjelmistokehityksen vaiheessa (Pan, 1999). Tämä tekee ohjelmistotestauksesta tärkeän osan ohjelmistotuotannon kokonaisuutta. Luku 2.1 esitte- lee ohjelmistotestausta yleisesti antaen kuvan siitä, mitä ohjelmistotestaus on osana ohjelmistotuotantoa, luvussa 2.2 käsitellään ohjelmistotestauksen toteutusta ja sen tapoja, luvussa 2.3 kuvataan ohjelmistotestauksen kohtaamia haasteita ohjelmistotuotannossa.

2.1 Ohjelmistotestaus

Yleisin käytetty tekniikka ohjelmiston laadun varmistamiseen ja vahvistamiseen on ohjelmistotestaus (Shao et al., 2007). Ohjelmistotestauksella tarkoitetaan niitä toimia ja tapoja, joilla voidaan selvittää, toimiiko ohjelmisto tai sen osa oikein ja suunnitel- lusti. Pääasiassa ohjelmistotestausta tehdään jotta voidaan arvioida testattavan ohjelmiston laatua, löytää ongelmia siitä tai varmistaa ohjelmiston hyväksyttävyyttä (Jor- gensen, 2014). Testauksella pyritään ennaltaehkäisemään ongelmia jo ohjelmiston kehityksen aikana kuin myös varmistamaan ja kehittämään tuotteen laatua sekä takaamaan, että valmis tuote on suunnitellun mukainen. Testaus edustaakin näin perinpoh- jaista määrittelyn, suunnittelun ja ohjelmoinnin varmentamista (Ahamed, 2009).

(12)

Ohjelmistotestauksen yksi päätavoitteista on löytää virheitä ja ongelmia ohjelmistosta mahdollisimman aikaisessa vaiheessa sen kehitystä (Gojare et al., 2015). Kun virheet voidaan havaita jo ohjelmiston aikaisessa kehitysvaiheessa, hyödytään tästä useassa- kin näkökulmassa. Ajoissa huomattu virhe voidaan korjata ennen kuin tuotteen kehitys on edennyt pidemmälle, virheen korjaaminen myöhäisessä ohjelmiston kehityksen vaiheessa voi olla huomattavasti haastavampaa ja kalliimpaa kuin kehityksen alkuvaiheessa. Lisäksi, kun ongelmat huomataan ja voidaan ratkaista jo aikaisessa vaiheessa, luodaan alusta saakka laadukkaampaa ohjelmointikoodia. Ohjelmiston virheet ja ongelmat voidaan löytää tekemällä testejä, jossa itse ohjelmistoa suoritetaan (Nidhra &

Dondeti, 2012).

Kehittäjien tavoite on mahdollisimman virhevapaa ja hyvin testattu ohjelmisto, joka on myös kuluttajien odotus (Mohanty et al., 2017). On kuitenkin huomioitava, että on lähes mahdotonta toteuttaa ohjelmistoa, joka on täysin vapaa virheistä tai ongelmista.

Syynä tälle on ohjelmistojen monimutkaisuus. Nykyaikana suuri osa ohjelmistoista on kooltaan ja ominaisuuksiltaan jo niin isoja, että ne kehittyvät erittäin monimutkaisiksi.

Tällä monimutkaisuudella tarkoitetaan siis sitä, että ohjelmistot ovat niin laajoja, että sen eri osien välillä on niin paljon erilaisia interaktioita, että niiden kaikkien ylläpito on haastavaa. Pan (1999) kuvasikin, että ihmisillä on vain rajoitettu taito ylläpitää monimutkaisuutta. Monimutkaisuus on yksi testauksen haasteista, mutta huolellisella suunnittelulla voidaan lieventää sen tuomia haasteita. Monimutkaisuus on kuitenkin todellisuudessa luonnollinen osa jokaista ohjelmistoa ja ohjelmistoprojektia (Axelrod, 2018).

Ohjelmiston testaaminen on tärkeää ja sitä täytyy tehdä, jotta voidaan luottavaisesti pystyä sanomaan, että ohjelmisto toimii niin kuin sen pitäisikin sille suunnitellussa ympäristössä (Fewster & Graham, 1999). Kattavan testauksen avulla voidaan varmistua ohjelmiston toimivuudesta ja sen laadusta, usein kattavan testauksen saavuttami- nen vie kuitenkin paljon aikaa (Mohanty et al., 2017). Pienessäkin ohjelmassa voi olla erittäin suuri määrä erilaisia kombinaatioita, jota testata ja näin mahdollisten testitapausten määrä voi olla hyvin korkea, ei olekaan käytännöllistä tai järkevää testata kaikkia mahdollisia asioita ohjelmistossa. Mutkikkaan ohjelmiston täysi testaus, eli kaiken testaaminen veisi liikaa aikaa ja liikaa ihmisresursseja, jotta se olisi taloudelli- sesti kannattavaa (Myers et al., 2012). Laadukkaasti ja kattavasti toteutetussa

(13)

testauksessa kulut ovat yleensä korkeat, DeMillon (2003) mukaan testaus hallitseekin usein ohjelmiston kehityskuluja. Onkin tärkeää, että ohjelmistotestauksen suunnitteluun käytetään tarpeeksi resursseja ja aikaa, jotta ohjelmistoa voidaan testata mahdollisimman tehokkaasti ja edullisesti, mutta samalla pystytään kuitenkin takaamaan laadukas ja kattava testaus.

2.2 Testauksen toteutus ja tavat

Ohjelmistotestausta ei tehdä vain yhdessä vaiheessa ohjelmiston elinkaarta. Testausta toteutetaankin ohjelmiston koko elinkaaren ajan ja testausta tehdään ohjelmiston yk- sittäisille osille kuin myös koko ohjelmiston tasolle (Naik & Tripathy, 2008). Kuiten- kin ennen kuin testausta voidaan aloittaa, on aloitettava testattavan ohjelmiston testitapausten määrittelystä. Jorgensen (2014) kuvaakin, että ohjelmistotestauksen ydin on määrittää testitapaukset, joita ohjelmistosta halutaan testata. Testitapaus tarkoittaa ku- vausta siitä, mitä testataan ja miten se toteutetaan. Testitapaus sisältää kuvauksen testattavan tapauksen ennakkoehdoista, itse testissä tehtävistä toiminnoista, oletetuista lopputuloksista ja testin loppuehdoista (Jorgensen, 2014). Tämän kuvaelman on tarkoitus ohjata testaajaa, jotta hän voi toteuttaa testin määritysten mukaisesti ja tarkistaa, että testitapauksen kohde täyttää oikeat kriteerit. Yksittäisistä testitapauksista muodos- tuu testisuunnitelman kokonaisuus, jonka pohjalta testausta voidaan alkaa toteuttamaan.

Ohjelmistotestaus voidaan jakaa karkeasti kahteen, manuaaliseen tai automattiseen testaamiseen. Manuaalinen testaus tarkoittaa sitä, että ihminen vastaa testauksen toteutuksesta ja testauksen tulosten tulkinnasta. Tämä voi olla esimerkiksi käyttöliitty- män eri toimintojen läpi käymistä manuaalisesti. Testiautomaatiossa on taas kyse siitä, että testaus tapahtuu automatisoidusti koneen tai ohjelman tekemänä ilman ihmisen manuaalista osallistumista itse varsinaiseen testaus aktiviteettiin. Testiautomaatiossa siis käytetään toista ohjelmistoa testauksen toteutuksen apuna (Axelrod, 2018).

Automaattisella testauksella voidaan korvata manuaalisesti toteutettuja testejä ja näin nopeuttaa testausprosessia, kuitenkaan manuaalista testaamista ei voida korvata täysin automaattisella testauksella. Molemmille tavoille testata on omat käyttökohteensa ja hyötynsä ohjelmistotestauksen toteutuksessa. Manuaalinen ja automaattinen testaus

(14)

ovatkin oleellisesti erilaisia (Axelrod, 2018). Luvussa 3 kerrotaan tarkemmin auto- maattisesta testauksesta, sen hyödyistä ja eroavaisuuksista manuaaliseen testaamiseen liittyen.

Ohjelmistotestauksen toteutukseen on useita erilaisia tekniikoita, nämä tekniikat voidaan pääpiirteittäin jakaa kuitenkin kahteen tapaan toteuttaa testausta. Perinteisesti ohjelmistotestaukseen on kaksi pääasiallista lähestymistapaa: Black box -testaus ja White box -testaus (Ahamed, 2009). Black box -testauksesta puhuttaessa tarkoitetaan niin sanotusti funktionaalista testaamista. Se perustuu toiminnallisten testien toteutukseen määritysten perusteella ja sitä käytetään todentamaan ohjelmiston kokonaisvaltaisia toiminnallisuuksia (Nidhra & Dondeti, 2012). Tällaisessa testaamisessa testaajan ei oleteta tietävän tai pääsevän itse lähdekoodiin käsiksi vaan testaamista suoritetaan kuin testattavaa ohjelmistoa pidettäisiin ”mustana laatikkona”, josta nimikin tulee.

Tämä tarkoittaa siis sitä, että testaaja voi testatessa syöttää tietoa ohjelmistoon ja saada palautetta ohjelmistolta ja näin testata ohjelmiston toiminnallisuuksia, mutta hän ei mene syvemmälle ohjelmiston sisäisiin mekanismeihin (Nidhra & Dondeti, 2012).

Testausta suoritetaan siis ikään kuin ulkopuolelta testaten ohjelmiston toimintaa lop- pukäyttäjän perspektiivistä. White box -testaus on taas päinvastainen testauksen lähes- tymistapa, usein Suomessa puhutaan myös lasilaatikkotestauksesta. Se on niin sanot- tua rakenteellista testaamista. Lasilaatikkotestausta käytetään pääsääntöisesti löytä- mään koodista loogisia virheitä, virheenkorjaukseen ja kirjoitusvirheiden sekä virheel- listen ohjelmointi olettamusten korjaamiseen (Nidhra & Dondeti, 2012). Lasilaatikko- testauksessa testaajan oletetaan tuntevan ohjelmointikoodi ja tietävän kuinka se toimii.

Lasilaatikkotestauksen pääideana on varmistaa ohjelmiston sisäisten mekaniikkojen toimivuus (Nidhra & Dondeti, 2012).

2.3 Testauksen haasteet

Ohjelmistotestaus kohtaa useita erilaisia haasteita liittyen niin kustannuksiin, organi- saatioon kuin jatkuvasti kasvavaan tarpeeseen vastata asiakkaiden toiveisiin. Yksi ohjelmistotestauksen haasteista onkin se, että asiakkaat haluavat nykyään lisää toiminnallisuuksia ja ominaisuuksia yhä nopeammin ja mahdollisimman halvalla, mutta samalla toivotaan ohjelmiston laadun täyttävän heidän toiveensa tai jopa ylittävän ne (Al-Zain et al., 2012). Tämä voi asettaa epärealistisia tavoitteita testauksen

(15)

toteuttamiselle, sillä mitä enemmän ohjelmistoon lisätään erilaisia ominaisuuksia, sitä monimutkaisemmaksi se kasvaa. Ohjelmiston monimutkaisuuden kasvaessa, vie yhä enemmän aikaa testata ohjelmistoa ja löytää mahdollisia virheitä siitä (Axelrod, 2018).

Testauksen kontekstissa on tärkeää myös ymmärtää ero virheenkorjauksen (engl. debugging) ja testauksen välillä. Molemmat tähtäävät ohjelmiston laadun parantamiseen (Kurokawa & Shinagawa, 2008), mutta ne eivät kuitenkaan tarkoita samaa asiaa vaan ovat fundamentaalisesti erilaisia tarkoituksiltaan. Testauksen tarkoitus on tunnistaa vi- koja ja virheitä koko ohjelmiston laajuudelta ja virheenkorjauksen tarkoitus on taas puolestaan korjata ja ratkaista ohjelmistosta löytyneitä ongelmia (Kurokawa & Shi- nagawa, 2008). Nämä kuitenkin saatetaan sekoittaa ja ohjelmoijia voidaan asettaa toteuttamaan testausta, koska ohjelmoijat vastaavat jo virheenkorjauksesta, tämä on kuitenkin huono käytäntö sillä se voi johtaa lopulta suurempaan riskiin virheiden huo- maamatta jäämiselle (Kurokawa & Shinagawa, 2008). Järkevämpi tapa olisi, että ohjelmistotestauksesta vastaa sille tarkoitettu henkilö tai tiimi, jolloin testauksen toteut- tajat voivat keskittyä täysin ohjelmistotestauksen prosessiin. Kurokawan ja Shinaga- wan (2008) mukaan, joissakin yrityksissä laitetaan aloittelijat testaustyöhön, sillä ajatellaan, että testausta voi tehdä ilman erityisiä taitoja, vaikka tämä ei pidä paikkaansa.

Ensimmäinen ajatus ohjelmistotestauksen kustannuksista voi olla, että se olisi suhteellisen edullista toteuttaa, ohjelmistotestaus on kuitenkin kallis ja aikaa vievä toimi (Méndez-Porras et al., 2015). Todellisuudessa ohjelmistotestauksen kustannukset voivat olla hyvinkin korkeat, kun verrataan kustannuksia koko ohjelmiston kustannuksiin.

Ohjelmistotestaus voi viedä noin 30–60 % kaikista ohjelmiston elinkaaren kustannuksista, riippuen kyseisen ohjelmiston tärkeydestä ja monimutkaisuudesta (Gojare et al., 2015). Ohjelmistotestauksen korkeita kustannuksia perustelee se, että testausta toteutetaan koko ohjelmiston elinkaaren ajan ja että testaus on paljon aikaa vievää. Kustan- nuksien lisäksi aika on haasteita tuova asia ohjelmistotestauksessa, ohjelmistokehittä- jät yleensä joutuvat kiirehtimään aikaa vastaan ohjelmiston toimittamiseksi (Mohanty et al., 2017), tämä asettaa myös ohjelmistotestauksen osa-alueen aikarajoitteiden tuo- mien haasteiden kohteeksi. Ohjelmistotuotannossa voidaan myös joutua ottamaan oi- koteitä eri osa-alueilta, jotta tavoitteisiin voidaan päästä. Usein näiden eri oikoteiden ottamisen kohteeksi joutuu ohjelmistotestauksen alue (Mohanty et al., 2017). Monista haasteista huolimatta ohjelmistotestaus on iso osa ohjelmistotuotantoa eikä sitä tulisi

(16)

sivuuttaa. Testaus on elintärkeässä roolissa, jotta ohjelmistotuotteiden laadukkuutta voidaan nostaa korkeammalle tasolle (Gojare et al., 2015).

(17)

3 Automaattinen testaus

Automaattinen testaus (tai testiautomaatio) on tapa toteuttaa ohjelmistotestausta tai sen vaiheita automatisoidusti ohjelmiston avulla. Automatisointi tässä kontekstissa tarkoittaa sitä, että tietokone suorittaa ohjelmiston testausta ihmisen puolesta, eikä ihmisen tarvitse osallistua varsinaiseen testaustoimeen. Testiautomaatioksi kutsutaan siis sitä, että käytetään ohjelmistoa testaamaan jotakin toista ohjelmistoa (Al-Zain et al., 2012). Automaattisessa testaamisessa ihmisen tehtävä on luoda automaattiset testit ja havainnoida sekä tulkita testien antamia tuloksia. Ihmisen kuuluu myös pitää yllä luo- tuja automaatio testejä. Testauksen automatisoinnin tarkoituksena on se, että testausta voitaisiin tehdä jollakin tavalla paremmin (Hoffman, 1999).

Ohjelmistojen kasvaessa ja monimutkaistuessa testiautomaation tarve on kasvanut huomattavasti. Nykypäivänä sovelluksiin ja ohjelmistoihin tuodaan uusia ominaisuuksia ja päivityksiä nopealla tahdilla, joka luo varsinkin manuaaliselle testaamiselle suu- ren haasteen, sillä uudet päivitykset täytyisi pystyä testaamaan, mutta monesti aikara- joitteet hankaloittavat asiaa. Yksi syy testiautomaation yleistymiselle ja sen tarpeen kasvamiselle onkin ollut siirtyminen ketterien kehitysmenetelmien käyttöön perintei- sen vesiputousmallin sijaan (Axelrod, 2018).

Yleisesti testiautomaatio yhdistetään tuotteen laadun parantamiseen, kuten virheiden etsimiseen ja tuotteen toimivuuden varmistamiseen. Nämä eivät kuitenkaan ole ainoita alueita, jota testiautomaation koskettaa ohjelmistotuotannossa. Testiautomaatio liit- tyykin joiltakin osin myös tuottavuuteen, tuotteen arkkitehtuuriin, liiketoimintaproses- seihin ja organisaation rakenteisiin sekä kulttuuriin (Axelrod, 2018). Testiautomaati- olla on siis laaja osuus ohjelmistotuotannon kokonaisuudessa, nämä eri osa-alueet vaikuttavat tai saavat vaikutteita testiautomaatioon ja sen prosesseihin.

Tässä luvussa käsitellään testiautomaatiota ja mitä se tarkoittaa ohjelmistotestauksen kontekstissa. Tarkoituksena on luoda katsaus testiautomaatioon ja automatisoinnin etuihin sekä tarkastella millaisia haasteita testiautomaatiolle löytyy. Luvussa 3.1 esi- tetään, millaisia etuja voidaan saavuttaa, kun testausta automatisoidaan. Lisäksi luvussa käsitellään testiautomaation eroa manuaaliseen testaamiseen. Luvussa 3.2 käy- dään läpi, kuinka testiautomaatiota toteutetaan osana ohjelmistotestausta ja

(18)

ohjelmistotuotantoa. Automatisoinnin toteutukseen liittyen esitetään, myös jatkuvan integraation periaatteita luvussa 3.3. Testiautomaation kohtaamia haasteita käsitellään luvussa 3.4, jossa tuodaan esille yleisimpiä testiautomaatioon haastavuuteen vaikuttavia tekijöitä. Luku 3.5 käsittelee lopuksi, mitä testiautomaatiolla voidaan saavuttaa ohjelmistotuotannossa ja mitä asioita testiautomaation suunnittelussa ja sen toteutuksessa tulisi ottaa huomioon.

3.1 Automatisoinnin edut

Ohjelmistotestauksen automatisoinnin pääasialliset edut liittyvät toistettavuuteen, uudelleen käytettävyyteen ja testien suorittamisen vaativuuden helpottumiseen. (Rafi et al., 2012). Testiautomaation hyötynä on se, että kun testit ovat valmiita, on niitä help- poa ja nopeaa käyttää uudelleen, jolloin kerran luodusta testistä saadaan paljon hyötyä pidemmällä aikavälillä. Saman testin toteuttaminen manuaalisesti vie aina lähes saman verran aikaa tehdä, mutta kerran luotu automaattinen testi nopeuttaa jatkossa saman asian testaamista. Vaikka automatisoinnin alkukustannukset ovat kalliimmat, kuin manuaalisen testauksen niin perustelut automatisoinnille pohjautuvat yleensä siihen, että automaattisia testejä voidaan suorittaa hyvin edullisesti ja kun testejä voidaan toistaa useampia kertoja, saavutetaan säästöjä (Groder, 1998). Mahdollisuus toistaa testejä uudelleen vapauttaa resursseja ohjelmistotestauksesta, näiden resurssien vapautuessa pystytään panostamaan uusien testien luomiseen sen sijaan, että keskityttäisiin toista- maan samoja testejä yhä uudelleen (Groder, 1998).

Testiautomaatiota käytetään usein korvaamaan manuaalisia testejä. Suuriosa manuaalisesta testaustyöstä onkin toistuvien regressiotestien tekemistä (Axelrod, 2018). Reg- ressiotestit ovat erittäin toistuvaa testaamista. Regressiotestien tarkoituksena on varmistaa, että aiemmin kehitetty ja toimivaksi todettu ohjelmisto toimii vielä päivitys- tenkin jälkeen. Tämän vuoksi uusien päivitysten myötä samoja tai samankaltaisia tes- tejä on tehtävä uudestaan, joka tekee tästä testaamisen osasta hyvin toistuvaa. Toistuva samojen testien tekeminen manuaalisesti on hyvin hidasta ja luo mahdollisuuden ih- misvirheelle testauksen aikana. Testiautomaatio onkin oiva tapa ratkaista nämä ongelmat, varsinkin kun kyseessä on toistuvan laatuinen testaus kuten regressiotestaus. Ko- neen avulla saavutetaan tilanne, jossa samat toistuvat testit voidaan suorittaa nopeammin kuin manuaalisesti eikä ole huolta ihmisvirheen tapahtumiselle kesken testauksen.

(19)

Testiautomaatiosta saatavien hyötyjen vuoksi ei ole syytä, miksei mikä tahansa toistuva työ ole automatisoitu nykypäivänä (Axelrod, 2018). DeMillo (2003) myös arvioi, että regressio testauksen kulut voivat olla jopa 70 % tai enemmän testauksen koko- naiskuluista ohjelmiston ylläpitovaiheessa. On siis nähtävissä, että jos tätä työtä voidaan automatisoida, pystytään sen avulla hyödyttämään niin liiketoimintaa kuin edis- tämään työntekijöiden tuottavuutta, vapauttamalla työntekijän resursseja muihin teh- täviin. Automaatio onkin hyvä tapa vähentää testauksesta syntyviä kuluja ja vähentää siihen kuluvaa aikaa (Pan, 1999).

Testiautomaation hyöty nousee myös esille jatkuvan integraation konseptissa. Jatku- vassa integraatiossa automatisoidaan lähdekoodimuutokset usealta kehittäjältä yhteen ohjelmistoprojektiin, tämän avulla kehittäjät voivat yhdistää koodin keskeiseen lähde- koodiarkistoon. (Atlassian, 2021). Tästä saatava hyöty näkyy, kun jokaisen lähdekoo- dimuutoksen kohdalla voidaan ajaa testejä, jotka varmistavat koodin oikeellisuutta ennen kuin ne yhdistetään projektiin. Tällä tavoin voidaan varmistua, että kaikki koodi mitä pääprojektin lähdekoodiarkistossa sijaitsee, on läpäissyt kaikki tarvittavat testit oikeellisuuden kannalta (Axelrod, 2018). Luvussa 3.3 esitetään jatkuvan integraation periaatteita tarkemmin automaattisen testauksen näkökulmasta.

Manuaalisen testauksen suorittamiseen vaadittava aika on huomattavasti korkeampi kuin automaattiseen testaamisen. Yksi selvimmistä testiautomaation hyödyistä onkin testausajan nopeuttaminen. Manuaaliset testit, jotka voivat pisimmillään viedä jopa useita tunteja, voidaan suorittaa testiautomaation avulla minuuteissa (Fewster & Gra- ham, 1999). Manuaalisen testin hitauteen vaikuttaa se, että työn tekee ihminen. Ihmi- sen täytyy havainnoida, suorittaa ja tulkita testin kulkua ja palautetta, tämä vie luonnollisesti huomattavasti enemmän aikaan kuin koneella, joka suorittaa annetun koodin mukaiset toiminnot ilman tarvetta ajattelulle tai miettimiselle. Automaation etuna on myös se, että se ei altistu samanlaisille inhimillisen virheen mahdollisuuksille, kuin manuaalisessa testauksessa voidaan altistua. Axelrodin (2018) mukaan manuaalinen testaaminen on paljon virhe alttiimpaa kuin automaattinen testaaminen. Tälle on yksi- selitteinen syy, kaikessa ihmisen tekemässä työssä on mahdollisuus inhimilliselle vir- heelle ja pitkäkestoisissa tai toistuvissa manuaalisissa testauksissa inhimillisen virheen riski kasvaa.

(20)

3.2 Automatisoinnin toteutus

Todennäköisesti yleisin tapa automaation toteutukselle ohjelmistotuotannossa on se, että automaatiosta vastaa sille suunnattu tiimi (Axelrod, 2018). Tiimi voi keskittyä täysin automaation tai kokonaisuutta voidaan ajatella laadunvalvonnasta vastaavan tii- min toteuttamana, jolloin samassa tiimissä työskentelevät sekä automaatio että manuaaliset testaajat ja muu laadun valvontaan liittyvä henkilöstö. Automaatiotiimin jäsenet kirjoittavat yleensä testikoodin ja vastaavat myös testien toteutuksesta ja niiden yllä- pidosta (Axelrod, 2018). Tämä ei kuitenkaan ole ainut tapa toteuttaa automatisointia ohjelmistotuotannossa, mutta on yksi yleisimmistä tavoista.

Automaatiota toteutettaessa on järkevää ottaa käyttöön sellaisia ohjelmointikieliä kuin ohjelmiston kehityksessä käytetään (Axelrod, 2018). Tämä helpottaa sekä testien te- kemistä ja koodin jakamista ohjelmistoprojektissa. Samaa ohjelmointikieltä käytettä- essä voidaan jakaa esimerkiksi kehittäjien koodia testaajien hyödyksi. Testien suunnittelu ja ymmärtäminen on myös helpompaa, kun itse ohjelmisto on kehitetty samalla ohjelmointikielellä. Tällaisen järjestelyn avulla voidaan myös hyötyä siitä, että pysty- tään jakamaan tietoa ja tekemään yhteistyötä läheisemmin kehittäjien ja testaajien vä- lillä (Axelrod, 2018).

Automatisoitujen testien suorittamista voidaan toteuttaa käytännössä monella tavalla.

Voidaan ajatella, että automaatiotestien kehittäjä ja testaaja suorittavat testejä omalta työkoneeltaan, joka on toimiva tapa esimerkiksi pienemmissä projekteissa, jos testaus- tiimi on pieni. Tällöin tietysti täytyy muistaa, että testien suoriutumisen aikana ei testaaja voi välttämättä tehdä muuta kuin odottaa testien suoriutumisen loppuvan, jonka jälkeen hän voi tulkita testien tuloksia. Automaatiotestien ajaminen omalta koneelta kerran päivässä on hyvä tapa, mutta se on kuitenkin altis erilaisille riskeille (Axelrod, 2018). Tällainen riski voi olla esimerkiksi se, että automaatiotestit täytyy muistaa lait- taa säännöllisesti suoriutumaan omalta työkoneelta (Axelrod, 2018). Testien suorittamisen prosessi voidaan myös automatisoida, jolloin vältytään unohduksen riskiltä suorittamisen muistamisen kannalta ja ei tarvita testihenkilön tietokonetta testin suorittamista varten. Testien suorittamisen prosessi olisikin hyvä automatisoida (Axelrod, 2018). Yksi mahdollinen ja yleisesti käytetty tapa toteuttaa tätä on automatisoida testien ajaminen yön yli jonkin automaattisen rakennusprosessin avulla (Axelrod, 2018).

(21)

Tähän voidaan käyttää jotakin ulkoista palvelua, jonka palvelimien kautta testejä voidaan suorittaa automaattisesti niin ettei testaamiseen tarvita testaajan omaa tietokonetta. Tällaisia palveluita tarjoavat muun muassa Jenkins ja Azure DevOps. Tällaiset palvelut mahdollistavat jatkuvan integraation ja automaatiotestauksen suorittamisen automatisoinnin toteuttamisen. Luvussa 7.3 käsitellään tarkemmin Jenkinsin ja Azure DevOpsin tuomia mahdollisuuksia graafisten käyttöliittymien automaattisen testauksen toteuttamiseen liittyen.

3.3 Jatkuva integraatio

Jatkuva integraatio on prosessi ohjelmistotuotannossa, jonka tarkoituksena on helpottaa useiden eri koodilähteiden yhdistämistä projektin kokonaisuuteen yhteisessä läh- dekoodissa. Samalla pyritään varmentamaan säännöllisesti koodin toimivuutta. Stol- bergin (2009) mukaan, jatkuvaa integraatiota pidetään yhtenä ketterien kehitysmenetelmien ja erilaisten testiympäristöjen perusedellytyksistä. Se koostuu ohjelmistokehityksen erilaisista käytännöistä, joiden tarkoituksena on lyhentää aikaa, joka kuluu ohjelmiston integraatioiden tekemiseen (Stolberg, 2009). Yleisesti jatkuvan integraation toteutuksessa on automatisoitu prosesseja ja testejä lähdekooditietovaraston muutos- ten havaitsemiseen ja tarkastamiseen. Kun muutokset havaitaan, aloitetaan integraation erilaiset prosessit. Nämä prosessit koostuvat rakentamisen ja testaamisen tehtä- vistä, joilla varmistutaan siitä, että uudet muutokset lähdekoodiin eivät aiheuta uusia virheitä ja että ne läpäisevät erilaiset testit, joilla varmennetaan koodin ja integraation toimivuutta ja yhteensopivuutta (Stolberg, 2009). Jatkuvassa integraatiossa testataan kaikki uusi eri ohjelmistotestein ja näin pidetään koodin laatu hyvänä jokaisen integraation yhteydessä. Automaatio testaukseen liittyen jatkuvaa integraatiota voidaan käyttää esimerkiksi varmentamaan automaatiotestien päivitysten oikeellisuutta, kun testien päivityksiä lisätään projektin lähdekooditietovarastoon.

3.4 Automatisoinnin haasteet

Testauksen automatisoinnin ensi-investoinnit ovat yleensä kalliita, sillä testiympäris- tön suunnitteluun ja toteuttamiseen kuluu aikaa ja rahaa. Kun puhutaan yksittäisistäkin automaatiotesteistä, on hyvä ottaa huomioon, että yhden manuaalisen testin

(22)

muuttaminen automatisoiduksi vie huomattavasti enemmän aikaa kuin sen suorittaminen manuaalisesti. Arvioidessa testien muuttamiseen kuluvaa aikaa on hyvä ottaa läh- tökohdaksi, että testin automatisointi vie todennäköisesti ainakin viisi kertaa kauem- min kuin testin läpi käyminen manuaalisesti (Fewster & Graham, 1999). Nykypäivän nopean kehitystahdin vuoksi on automatisoinnin pystyttävät vastaamaan tähän tahtiin, mutta se luo haasteita testien tekemiselle ja ylläpitämiselle, koska jatkuvasti kehitetään uusia ominaisuuksia. Nopeaan kehitystahtiin vaikuttaa olennaisesti myös se, että ny- kyään pyritään vastaamaan mahdollisimman nopeasti asiakkaan palautteeseen ja toiveisiin (Axelrod, 2018). Tällöin on myös pystyttävä nopeaan testauksen tahtiin, jotta uudetkin ominaisuudet tai korjaukset voidaan testata ja näin varmentaa niiden toimivuus ja oikeellisuus.

Nykypäivän ohjelmistot ovat hyvin laajoja, josta seuraa luonnollisesti monimutkaisuutta ohjelmistoon. Monimutkaisuutta on ohjelmistoissa, vaikka kaikki olisi suunniteltu tarkkaan ennakkoon. Monimutkaisuus kuuluu luonnostaan ohjelmistoihin eikä sitä voi täysin välttää (Axelrod, 2018). Mitä laajempi ja monimutkaisempi ohjelmisto on, sitä enemmän potentiaalisia testitapauksia ja testattavia ominaisuuksia testiautomaatiolle on. Tämä lisää sekä vaadittavan automaation suunnittelun määrää kuin to- teutettavien automaatiotestien määrää. Automaatiotestausta suunnitellessa saatetaan- kin joutua tekemään valintoja siitä, mitä testataan ja mitä jätetään testaamatta eri prio- riteettien mukaan, kuten ominaisuuden kriittisyys ohjelmiston toiminnan kannalta.

Mitä enemmän erilaisia ominaisuuksia lisätään, sitä helpommin ohjelmistosta tulee monimutkainen. Suurimmaksi osaksi ajasta ohjelmiston monimutkaisuus johtuu siitä, että ohjelmistoon on lisätty ominaisuuksia liian nopeasti, tieto ei ole liikkunut tarpeeksi hyvin ja kommunikaatiossa on ollut puutteita tai jostakin muusta syystä kuten esimerkiksi ohjelmiston kehitykseen käytettävien teknologioiden aiheuttamien syiden takia (Axelrod, 2018).

Automaattisen testauksen suurimmat kustannukset tulevat sen ylläpidosta. Vaikkakin alkuinvestointi yleensä automaatioon on kallis ja testien toteutus halpaa niin suurin alue, johon testiautomaatio keskittyy alun jälkeen, on testien ylläpito. Testien ylläpi- don kulut ovat suurin yksittäinen tekijä automaatiotestauksen kustannuksiin liittyen (Groder, 1998). Onnistuneen automaatio strategian tavoitteena tulisi olla se, että kes- kitytään ylläpitokustannusten minimointiin (Groder, 1998). Tämä tarkoittaa sitä, että

(23)

suunnitteluun ja testien toteutukseen täytyy panostaa vahvasti, jotta testit olisivat mahdollisimman uudelleen käytettäviä, mukautuvia ja helppoja ylläpitää. Näin voidaan optimoida testien ylläpitoa ja mahdollisesti jälkeenpäin testeihin tehtävät muutokset eivät aiheuta suuria kuluja ylläpitoon.

Automaatiotestauksen toteutuksessa on myös huomioitava aikarajoitteiden luomat haasteet. Tähän syynä on se, että automaattisten testien toteuttaminen voi viedä pal- jonkin aikaa (Hoffman, 1999). Ajan viemiseen vaikuttavat suunnitteluun kuin myös itse testien rakentamiseen kuluva aika. Testien tekemisen kannalta on ensin löydettävä ja valittava sopivat työkalut, joita käytetään, sen jälkeen ne on asennettava ja otettava käyttöön ja työkaluun on perehdyttävä. Vasta tämän jälkeen voidaan alkaa rakenta- maan automaatiotestejä. Kuten manuaalinenkin testaus, automaatiotestaus vaatii li- säksi tarkat suunnitelmat ja testitapauskuvaukset, automaatiotestaus voi vaatia jopa tarkemman suunnitelman kuin manuaalinen testaus. Automaatiotestien toteuttaminen ja rakentaminen on huomattavasti haastavampaa kuin manuaalisten testien testaus ja siihen vaaditaankin enemmän tietämystä ja kokemusta (Hoffman, 1999). Haasteena testiautomaation käyttöönotolle voikin olla se, että organisaatiosta ei löydy valmiiksi osaavaa henkilökuntaa toteuttamaan automatisointia.

Yksi automatisoinnin haasteista ja ongelmista on, että siitä saatavat hyödyt eivät näy suoraan ja tämän vuoksi organisaation hallinnon puolesta voi olla hankalaa nähdä miksi automatisointiin kannattaisi investoida niin paljon. Yleensä automatisoinnin hyödyt näkyvät vasta myöhemmissä projekteissa, jolloin sitä voidaan hyödyntää alusta saakka (Hoffman, 1999). Automaattisten testien toteutus on kallista ja aikaa vievää, tämän vuoksi niiden toteuttamisen hyötyjä voi olla haastava nähdä tai saavuttaa en- simmäisessä projektissa, jossa automatisointi otetaan käyttöön. Automaattisten toimien käyttöönoton hyödyt löytyvät juuri niiden toistettavuudesta ja uudelleen käytet- tävyydestä, kun automaatiota voidaan käyttää hyödyksi uudelleen ja uudelleen (Hoff- man, 1999).

3.5 Automatisoinnin suunnittelu ja mitä automaatiolla saavutetaan

Yleinen ajatus sille mitä automaatiolla ajatellaan saavutettavan, on se, että pystyttäisiin vähentämään aikaa, joka kuluu ohjelmiston testaamiseen ennen sen julkaisua

(24)

(Axelrod, 2018). Tämä ei kuitenkaan ole kaikki mitä automaatiolla voidaan saavuttaa, vaikka se onkin yksi testiautomaation tarkoituksista ja hyödyistä. Useasti saatetaan ajatella automatisoinnin olevan ”hopea luoti”, joka ratkaisee kaikki ongelmat testaukseen liittyen, kuten aikataulut, kustannukset tai virheiden löytäminen (Hoffman, 1999).

Tämä kuitenkaan ei ole koko totuus, sillä ei voida ajatella, että automatisoinnin käyt- töönotto missä vain tilanteessa antaisi suoran ratkaisun kaikkiin testaukseen liittyviin ongelmiin. Automatisoinnilla voidaan saavuttaa huomattavia säästöjä ajassa, vaivassa ja kustannuksissa sekä työntekijöiden tuottavuudessa, tätä ei voida kuitenkaan pitää itsestäänselvyytenä. Hoffmanin (1999) mukaan testauksen automatisoinnin suunnittelussa on otettava huomioon monia tekijöitä, jotta siitä voitaisiin saavuttaa selviä hyö- tyjä.

Sen lisäksi, että automatisoinnilla voidaan korvata manuaalisia testejä, automatisoinnilla voidaan myös toteuttaa sellaisia testejä, jotka eivät olisi välttämättä mahdollisia tai järkeviä toteuttaa manuaalisesti. Testiautomaation avulla voidaan testata asioita, jotka olisivat haastavaa toteuttaa manuaalisesti, tällaisia asioita ovat muun muassa ohjelmiston sisäisten toimien ja tilojen testaaminen ja ohjelmiston sisäisten kutsujen tar- kastaminen (Hoffman, 1999). Lisäksi Hoffman (1999) toteaa, että ohjelmiston kuor- mittamisen testaaminen manuaalisesti on epäkäytännöllistä, jos haluttaisiin testata esimerkiksi tuhansien samanaikaisten käyttäjien aiheuttamaa kuormaa ohjelmistolle, se olisi käytännöllistä vain automaation avulla (Hoffman, 1999).

Testiautomaation toteuttamista suunnitellessa tulisi pohtia, miksi testiautomaatiota halutaan toteuttaa ja voidaanko siitä saada oikeasti hyötyjä. Testiautomaation toteuttaminen ei aina olekaan järkevää kustannuksien kannalta tai se ei välttämättä muuten ole tarvittavaa tai sopivaa toteuttaa (Hoffman, 1999). Tämän vuoksi automaation suunnitteluun ja kustannusten hyötysuhteiden selvittämiseen on hyvä käyttää aikaa ja tehdä selvitystä miltä testauksen osa-alueilta oikeastaan hyötyjä voidaan saavuttaa, ennen kuin lähdetään toteuttamaan testauksen automatisointia. Hyötyjä arvioitaessa olisi hyvä vertailla samoissa testitapauksissa manuaalisen ja automaattisen testauksen to- teutuksia ja selvittää voidaanko automaatiolla saavuttaa todellisuudessa konkreettisia hyötyjä (Hoffman, 1999).

(25)

Testiautomaation käyttöönotto yleensä voi nostaa testauksen kattavuutta ja nopeuttaa testausprosesseja, testiautomaatiolla saavutetaankin ammattimaisuutta organisaatiossa (Hoffman, 1999). Kuitenkaan, jos testiautomaatiota ei toteuteta kunnollisesti, automaatiotestaus voi aiheuttaa vaivaa ja lisäkuluja tai se voi olla jopa vähemmän hyödyl- linen virheiden löytämisen kannalta kuin manuaalinen testaus (Garousi & Yildirim, 2018)

Laadukkaan testiautomaation toteuttamiseen tarvittavat taidot eivät ole samoja taitoja kuin ne taidot, joita vaaditaan manuaalisen testauksen tekemiseen (Fewster & Graham, 1999). Testiautomaatio vaatii siis omat taitonsa ja osaamisen, jotta sitä voidaan toteuttaa ammattimaisesti. Jotkin osaamisenalueet hyödyttävät tietenkin kummassakin ta- vassa testata, mutta usein testiautomaatiota toteutettaessa vaaditaan lisäksi sellaista ohjelmointiosaamista, jota välttämättä manuaalisella testaajalla ei ole.

(26)

4 Graafiset käyttöliittymät

Nykyaikana graafiset käyttöliittymät ovat osa jokapäiväistä arkielämäämme. Hyvin suuri osa tämän päivän sovelluksista ja ohjelmistoista käyttääkin graafista käyttöliit- tymää (Nguyen et al., 2014). Varhaiset ohjelmistot olivat komentorivikehotteisia ja ohjelmistoa ohjatakseen käyttäjät syöttivät komentoja komentoriville. Nykyään kuitenkin ohjelmistoala on siirtynyt ikkunointijärjestelmä aikaan ja käytännössä lähes jokaista sovellusta ohjataan graafisen käyttöliittymän avulla (Li, Wu, 2004).

Tässä luvussa esitetään graafisen käyttöliittymän yleisimmät periaatteet ja mitä graafinen käyttöliittymä tarkoittaa. Luvussa 4.1 luodaan yleiskuvaus graafiseen käyttöliit- tymään, sen toimintaa ja kuvataan, mistä asioista graafinen käyttöliittymä koostuu.

Luvussa 4.2 luodaan katsaus erilaisiin graafisiin käyttöliittymiin.

4.1 Graafinen käyttöliittymä

Graafisella käyttöliittymällä tarkoitetaan graafisista komponenteista muodostuvaa ohjelmiston osaa, jonka avulla voidaan ohjata ja käyttää ohjelmistoa. Graafisen käyttö- liittymän komponenteiksi mielletään muun muassa ikkunat, painikkeet, kuvakkeet, va- likot, osoittimet ja muut graafiset käyttöliittymän osat. Ohjaaminen perinteisesti tällai- sessa käyttöliittymässä tapahtuu hiirtä liikuttamalla, painikkeita painamalla ja syöttä- mällä erilaisia komentoja näppäimistöllä. Nykyään graafiset käyttöliittymät mahdollistavat myös ohjelmiston ohjauksen muun muassa kosketuksen avulla esimerkiksi mobiililaitteissa olevissa graafisissa käyttöliittymissä.

Graafinen käyttöliittymä esiintyy ohjelmistosta loppukäyttäjän näkökulmaan eli graafinen käyttöliittymä on käyttäjälle esitetty näkyvä ”kosketuspinta” ohjelmistoon ja sen käyttämiseen. Yleensä graafinen käyttöliittymä esitetään käyttäjälle jonkinlaisen näy- tön tai päätteen kautta. Graafisen käyttöliittymän omaavassa sovelluksessa graafinen käyttöliittymä on pääasiallinen tapa ohjelmiston käyttöön ja sen kanssa vuorovaikut- tamiseen (Nguyen et al., 2014). Graafisten käyttöliittymien voidaan ajatella olevan ta- pahtumapohjaisia tai reaktiivisia ohjelmiston osia (Nguyen et al., 2014). Tämä tarkoittaa sitä, että erilaiset käyttöliittymälle annetut komennot aktivoivat toimintoja ja

(27)

tapahtumia graafisessa käyttöliittymässä muuttaen sen tilaa. Tilanmuutoksen seurauksena graafinen käyttöliittymä voi antaa erilaista tietoa käyttäjälle tai reagoida muulla tavalla annettuun komentoon, kuten avaamalla kuvan tai siirtymällä uudelle sivulle hiirellä painetun linkin kautta. Käyttöliittymälle annetun komennon seurauksena tapahtuva käyttöliittymän tilanvaihdos voi olla näkyvä tai näkymätön käyttäjälle (Ngu- yen et al., 2014).

4.2 Erilaiset graafiset käyttöliittymät

Graafisia käyttöliittymiä on monenlaisia eivätkä ne rajoitukaan pelkästään erilaisiin työpöytäsovelluksiin ja tietokoneohjelmiin. Graafisia käyttöliittymiä voidaan jakaa esimerkiksi web-pohjaisten sovellusten käyttöliittymiin, mobiilikäyttöliittymiin ja työpöytäsovellusten käyttöliittymiin. Jokaisessa näistä käyttöliittymätyypeistä pätevät samat graafisen käyttöliittymän perusperiaatteet, jossa ohjelmistoa ohjataan tämän graafisen näkymän kautta. Kuitenkin jokaisella eri käyttöliittymätyypillä on omia eri- koisuuksiaan ja ominaisuuksia, jotka vaikuttavat niiden toimintaan ja ohjaamiseen.

Web-sovellukset käsittävät internetin kautta käytettäviä sovelluksia ja niitä ohjataan web-käyttöliittymän kautta. Web-sovellukset ja niiden käyttöliittymät eroavat muista sovelluksista siinä, että ne koostuvat erilaisesta rakenteesta ja arkkitehtuurista. Web- sovellukset rakentuvat asiakaspalvelin arkkitehtuurista, jossa asiakaspuolelta tehdään eri pyyntöjä palvelimelle ja palvelimelta annetaan vastauksia asiakkaan päähän (Doğan et al., 2014). Web-sovellusta käytetään jonkin internet selaimen kautta, kuvassa 1 esitetään esimerkki Google Maps web-sovelluksen graafisesta käyttöliitty- mästä Google Chrome selaimessa.

(28)

Kuva 1: Esimerkki web-käyttöliittymästä

Web-sovellusten erilainen arkkitehtuuri vaikuttaa siihen, kuinka web-pohjaiset sovellukset toimivat ja olennaisesti tämä vaikuttaa web-käyttöliittymienkin toimintaan.

Web-sovellusten graafinen käyttöliittymä esitetään tyypillisesti HTML-koodin pohjalta (Sztipanovits et al., 2008). Web-käyttöliittymiä voidaan kehittää erilaisin koodi- kielin tai tavoin, tässä on kyse web-ohjelmoinnista. Erilaisen arkkitehtuurin ja toiminnan vuoksi on web-käyttöliittymien testaaminen myös erilaista kuin muiden käyttöliit- tymätyyppien. Tarkemmin erilaisten käyttöliittymätyyppien testausta käsitellään luvussa 5.3 erilaisten graafisten käyttöliittymien testaus.

Työpöytäsovellus eroaa web-sovelluksesta siinä, että se käsittää sovellukset, joita voidaan asentaa tietokoneelle ja asennuksen jälkeen sovellus pystyy toimimaan itsenäi- sesti tietokoneella ja sitä voidaan käyttää sovelluksen suunniteltuihin käyttötarkoituk- siin sille tarkoitetussa ympäristössä. Työpöytäsovellus pystytään käynnistämään suoraan tietokoneelta, eikä sen avaamiseen tarvita selainta. Kuvassa 2 on esitetty esimerkki työpöytäsovelluksen graafisesta käyttöliittymästä langattomien kuulokkeiden hallintaohjelmalle.

(29)

Kuva 2: Esimerkki työpöytäsovelluksen käyttöliittymästä

Mobiilikäyttöliittymät tarkoittavat käyttöliittymiä, joita käytetään erilaisilla mobiili- laitteilla, yleensä nämä laitteet tarkoittavat erilaisia puhelimia ja tabletteja. Fundamen- taalisesti mobiilikäyttöliittymät eroavat muista graafisista käyttöliittymistä sillä, että niitä ohjataan usein kosketuksen avulla. Kosketusnäytöt ovatkin pääasiallinen tapa antaa syötettä mobiilisovelluksille (Muccini et al., 2012). Kuva 3 esittää esimerkin mo- biilikäyttöliittymästä samalle Google Maps sovellukselle, kuin kuvassa 1, mutta tässä esimerkissä on kyse sovelluksen mobiiliversiosta ja sen graafisesta käyttöliittymästä.

(30)

Kuva 3: Esimerkki mobiilikäyttöliittymästä

Mobiilikäyttöliittymien testauksen erilaisuuteen vaikuttaa se, että testauksessa on otettava huomioon käyttöliittymän pääasiallinen ohjaustapa eli kosketus, jonka avulla mo- biilikäyttöliittymiä käytetään. Mobiilikäyttöliittymien on myös pystyttävä toimimaan mahdollisimman monella erilaisella näytön koolla, sillä mobiililaitteiden näytön koot voivat vaihdella merkittävästi laitteesta toiseen.

(31)

5 GRAAFISTEN KÄYTTÖLIITTYMIEN TESTAUS

Graafisilla käyttöliittymillä on suora yhteys ohjelmiston käytettävyyteen ja sen toimi- vuuteen, se on yksi ohjelmiston tärkeimmistä osista. Hyvin suunniteltu ja toteutettu graafinen käyttöliittymä parantaa ohjelmiston käytettävyyttä huomattavasti, kun taas erilaiset virheet graafisessa käyttöliittymässä vaikuttavat suoraan, kuinka ohjelmistoa voidaan käyttää ja ne voivat jopa estää ohjelmiston käytön kokonaan. Ilman toimivaa käyttöliittymää on haastavaa käyttää ohjelmistoa niin kuin se on tarkoitettu. Tämän vuoksi onkin tärkeää varmistaa graafisen käyttöliittymän toimivuutta ja laatua, tapa tämän toteuttamiseen on tehdä graafisen käyttöliittymän testausta. Graafisen käyttö- liittymän testaus on elintärkeää, sillä ohjelmiston toiminnallisuuksia kutsutaan graafisen käyttöliittymän kautta ja sen testaus suoritetaan loppukäyttäjän näkökulmasta (Li

& Wu, 2004). Graafisen käyttöliittymän toimivuudella on merkittävä vaikutus siihen, kuinka loppukäyttäjä voi vuorovaikuttaa ohjelmiston kanssa. Al-Zain et al. (2012) huomauttaa myös, että graafisten käyttöliittymien testaus on hyvin tärkeää, sillä monet ohjelmiston ongelmista ilmenevät vasta graafisessa käyttöliittymässä.

Tässä luvussa käsitellään graafisen käyttöliittymän testaamista yleisellä tasolla. Lu- vussa 5.1 tarkastellaan perusteita siitä, kuinka graafisten käyttöliittymien testausta toteutetaan. Luvussa 5.2 esitetään graafisten käyttöliittymien testaamisen toteutuksen prosessia ja tämän jälkeen luvussa 5.3 käsitellään erilaisten käyttöliittymätyyppien testaamista ja esitetään eroja ja huomioitavia asioita eri käyttöliittymätyyppien testaukseen liittyen.

5.1 Graafisten käyttöliittymien testauksen toteutus

Graafisten käyttöliittymien testausta voidaan toteuttaa manuaalisesti tai automatisoidusti. Manuaalinen graafisten käyttöliittymien testaaminen on usein hidasta ja toistuvaa työtä, automatisoidulla graafisten käyttöliittymien testauksella on pyritty ratkaise- maa manuaaliseen testaamiseen liittyviä hitauden ja toistuvuuden ongelmia. Auto- maattista graafisten käyttöliittymien testausta esitetään tarkemmin luvussa 6. graafisten käyttöliittymien automaattinen testaus.

(32)

Graafisen käyttöliittymän testauksessa suoritetaan erilaisia komentoja, jotka kuuluvat käyttöliittymän komponenteille ja seurataan käyttöliittymän tilan muutoksia (Nguyen et al., 2014). Tällä tavalla voidaan varmentaa, että eri komentojen ja toimintojen seurauksena graafinen käyttöliittymä käyttäytyy oikein ja käyttöliittymässä tapahtuvat muutokset vastaavat oletettuja lopputuloksia sen toiminnan kannalta. Käyttöliittymän käyttäytyessä oletetun tavan vastaisesti, voidaan todeta käyttöliittymän toiminnassa olevan ongelma. Tämä on yksi tapa, jolla voidaan löytää virheitä ohjelmistosta ja käyt- töliittymästä testauksen avulla. Graafisten käyttöliittymien testeissä syötteenä on jokin tapahtumasarja, joka sisältää komentoja ja toimintoja, lisäksi ulostulona testeistä saadaan jokin tieto ohjelman tilasta, kuten virhe tai oletettu lopputulema. (Xie & Memon, 2007)

Graafisten käyttöliittymien testaus on järjestelmätasolla tapahtuva toimi. Tällä tasolla toteutettu testaus vaatii sitä, että ohjelmiston eri toimintoja testataan käyttäen sen käyt- töliittymää, jotta voidaan varmistua ohjelmiston oikeellisuudesta ja funktionaalisesta toimivuudesta (Mariani et al., 2018). Graafisten käyttöliittymien testauksen testitapausten ja testisuunnitelmien luonti on tärkeää, mutta haastavaa työtä. Haastavuuteen vaikuttaa se, että järjestelmätasolla tapahtuvat testit ovat monimutkaisia ja erilaisten kokonaisuuksien määrä on suuri (Mariani et al., 2018). Xie ja Memon (2007) kuvaa- vatkin, että nykypäivänä graafiseen käyttöliittymään vaadittava koodi voi olla noin 45–60 % koko ohjelmiston koodista. Tyypillisesti graafisen käyttöliittymän testauksessa testaajat eivät testaakaan jokaista käyttöliittymän toimintoa, vaan perustuen testaajien omaan kokemukseen, testauksessa keskitytään testaamaan kriittisimmät osat, joissa voi tulla virheitä (Dinh et al., 2018). Toteutettujen testien valintaan vaikuttaa monimutkaisuuden lisäksi aika, resurssi ja budjetti rajoitteet. Ohjelmiston graafisen käyttöliittymän testaaminen on monimutkainen ja kallis prosessi (Mariani et al., 2018).

5.2 Graafisten käyttöliittymien testauksen prosessi

Graafisten käyttöliittymien testauksen prosessi koostuu tyypillisesti neljästä eri osasta.

Ensimmäinen osa on testitapausten generointi, toinen osa on oletettujen lopputulosten generointi, kolmantena on testitapausten suorittaminen ja lopputulosten varmistaminen ja viimeinen osa on testien kattavuusanalyysi (Xie, 2006).

(33)

Testitapausten generointi toimii samoilla periaatteilla kuin muukin ohjelmoinnin testaus. Testitapausten generoinnissa siis määritellään ne testattavat osat ja toiminnot graafisesta käyttöliittymästä, jotka halutaan testata ja varmentaa niiden toimivuus ja oikeellisuus. Graafisen käyttöliittymän testitapaus on tapahtumasarja eri toimintoja, kuten painikkeiden painamista tai tekstin syöttämistä (Xie, 2006). Testitapauksessa kuvataan testin suorittamiseen vaadittavat tapahtumat vaihe vaiheelta. Odotettujen ulostulojen generoinnissa on kyse siitä, että varmistetaan graafisen käyttöliittymän oikeellisuus testitapauksessa (Xie, 2006). Jokaiselle testille on jokin oletettu oikeellinen lopputulos eli ulostulo, jos testi antaa tämän saman tuloksen, voidaan katsoa käyttö- liittymän toimineen oikeellisesti. Esimerkiksi voidaan ajatella, että päävalikon eri link- kien kautta ohjaudutaan juuri oikeille sivuille.

Testitapausten toteuttaminen ja lopputulosten vahvistaminen on vaihe, jossa jokainen testitapaus käydään läpi graafisessa käyttöliittymässä eli toteutetaan itse testaustoimi.

Jokainen testitapaus käydään yksitellen läpi ja tehdään kaikki määritetyt vaiheet ja toi- met ja lopuksi verrataan testistä saatua ulostuloa aiemmin määritettyyn ulostuloon, jos ne eroavat toisistaan, luetaan tämä virheeksi (Xie, 2006). Odotetun ja oikeellisen tes- tilopputuloksen vastatessa toisiaan voidaan katsoa, että testitapaus on läpäissyt testin ja käyttöliittymän testattu osa toimii oikeellisesti ja että sen oikeellinen toiminta on varmennettu. Viimeisessä vaiheessa analysoidaan testien kattavuutta. Tämä vaihe toteutetaan, kun kaikki testitapaukset on testattu. Tässä vaiheessa voidaan tarkastella kuinka kattavasti testitapaukset ovat kattaneet koko graafisen käyttöliittymän (Xie, 2006).

5.3 Erilaisten graafisten käyttöliittymien testaus

Kuten luvussa 4 kuvattiin, graafiset käyttöliittymät voidaan jakaa eri käyttöliittymä- tyyppeihin: työpöytäsovellusten käyttöliittymiin, web-pohjaisiin käyttöliittymiin ja mobiilikäyttöliittymiin. Samanlaiset testaustavat eivät välttämättä aina suoraan sovellu jokaiseen käyttöliittymätyyppiin, vaan käyttöliittymätyyppejä voidaan testata erilaisin tavoin tai työkaluin.

Mobiilikäyttöliittymät keskittyvät jopa työpöytäsovelluksia enemmän hyvään käyttä- jäkokemukseen ja ne tarjoavatkin yhä enemmän erilaisia mahdollisuuksia käyttäjälle

(34)

vuorovaikuttaa (Kropp & Morales, 2010). Tämä kuitenkin tarkoittaa sitä, että testattavaa on entistä enemmän ja käyttäjällä on erilaisia tapoja toimia käyttöliittymässä.

Graafisen käyttöliittymän oikea toiminnallisuus on yksi suurimmista hyväksymiskri- teereistä graafisen käyttöliittymän omaaville sovelluksille ja tämä on entistä tärkeäm- pää mobiilisovellusten kohdalla (Kropp & Morales, 2010). Syitä tälle on, että graafisia mobiilikäyttöliittymää voidaan ohjata monella tapaa, kuten kosketuksella, kosketus- laitteilla tai pienillä näppäimistöillä, lisäksi tähän vaikuttaa se, että mobiilikäyttöliitty- miä rajoittaa näyttöjen koot. Kroppin ja Moralesin (2010) mukaan tarve mobiilikäyt- töliittymien automaattiselle testaamiselle on erittäin suuri. Vaikuttavia tekijöitä tälle automaation tarpeelle on juuri mobiilikäyttöliittymien erilaisuus muihin graafisiin käyttöliittymiin ja monenlaiset vuorovaikutuksen tavat, joita mobiilikäyttöliittymässä käyttäjä voi tehdä. Mobiilikäyttöliittymien automaatiotestaus on kuitenkin suhteellisen uutta ja se on vielä alkuvaiheessa (Kropp & Morales, 2010). Mobiilikäyttöliittymien testaaminen nostaa esiin erityisiä haasteita, joita ei välttämättä kohdata muita graafisia käyttöliittymiä testatessa. Olennainen ero muihin testauksiin mobiilikäyttöliittymissä on se, että niitä ohjataan pääsääntöisesti kosketuksella, testaustekniikkojen täytyy pys- tyä testaamaan kosketusta ja kosketusnäytön toimintaa erilaisissa tilanteissa (Muccini et al., 2012). Haasteita aiheuttaa myös se, että yleensä kehitysalusta mobiilikäyttöliit- tymille on eri kuin itse kohdealusta, jolla käyttöliittymää käytetään (Kropp & Morales, 2010). On myös otettava huomioon, että erilaiset mobiililaitteet voivat reagoida eri tavoin samaan ohjelmistoon ja nämä erilaiset skenaariot eri alustoilla täytyy testata (Muccini et al., 2012).

Web-käyttöliittymien testaaminen asettaa omat haasteensa ja erilaisuutensa testauksen toteutukselle, sillä arkkitehtuuri jolle web-käyttöliittymät rakentuvat eroaa työpöy- täsovelluksista, kuten luvussa 4 kuvattiin. Web-käyttöliittymien testaukseen vaikuttaa myös se, että web-teknologiat muuttuvat ja päivittyvät hyvin nopeasti nykypäivänä (Alshahwan & Harman, 2011), tämä asettaa haasteen web-käyttöliittymien oikeellisuuden ja toimivuuden ylläpidolle. Onkin siis tärkeää, että web-käyttöliittymien testaus pystytään toteuttamaan pienellä vaivalla ja nopeasti. Web-sovellusten nopea ke- hitystahti ja vaatimukset jatkuvasta saatavuudesta saattavat web-testauksen tiukkaan aikatauluun (Alshahwan & Harman, 2011). Yksi web-sovellusten selvistä hyödyistä on se, että ne ovat jatkuvasti saatavilla (Alshahwan & Harman, 2011), mutta tämä aiheuttaa sen, että web-sovellusten käyttöliittymien täytyy olla jatkuvasti toimivassa

(35)

tilassa ja tämän vuoksi on erityisen tärkeää, että käyttöliittymän toimivuus voidaan varmistaa tehokkaasti. Web-käyttöliittymän testauksessa testiohjelmiston tai työkalun täytyy pystyä tunnistamaan eri web-elementtejä, jotta testi voi suorittaa eri interaktioita web-käyttöliittymässä. Nämä web-elementit esitetään yleensä HTML-koodin mukaan (Sztipanovits, 2008). Nykyään tällaiset web-elementit omaavat jonkinlaisen meta-arvon, kuten tagin tai muun arvon (Sztipanovits, 2008), joiden avulla web-ele- menttejä voidaan tunnistaa. Tapa toteuttaa näitä on nykyään hyvin standardoitu (Szti- panovits, 2008). Elementtien tunnistamisen avulla testi voidaan kohdistaa juuri oikei- siin osiin web-käyttöliittymää. Testiautomaatiota voikin olla järkevä pohjata näihin standardoituihin tapoihin toteuttaa web-elementtien tunnistusta (Sztipanovits, 2008).

Webpohjaiset sovellukset sijaitsevat, jollakin palvelimella, johon voidaan yhdistää internetin välityksellä, mutta työpöytäsovellukset taas asennetaan yksittäisille tietoko- neille ja tämä vaikuttaa testauksen toteutukseen, työpöytäsovelluksien käyttöliittymiä ei välttämättä voida testata suoraan samoin kuin web-käyttöliittymiä. Työpöytäsovel- lusten käyttöliittymätestauksessa on hyödyllistä ottaa huomioon ohjelmiston ohjelmointikieli, jotta voidaan esimerkiksi testiskriptejä kirjoittaessa käyttää hyväksi jo valmiiksi luotua koodia ja luoda käyttöliittymätestejä samalla ohjelmointikielellä. Työ- pöytäsovellusten testaaminen on siinä mielessä yksinkertaisempaa, että sen tarvitsee toimia vain sille määrätyillä alustoilla, kun taas web-sovellusten täytyisi pyrkiä tarjoa- maan sovelluksen yhteensopivuutta useille eri selaimille ja käyttöjärjestelmille (Kata- lon, 2021).

(36)

6 Graafisten käyttöliittymien automaattinen testaus

Graafisen käyttöliittymän automaattinen testaus tarkoittaa testauksen automatisointia eri tavoin niin, että graafisen käyttöliittymän testaustoimea ei tarvitse toteuttaa manu- aalisin keinoin. Graafisen käyttöliittymän testiautomaatio on tärkeä osa ohjelmistotestausta ja se tarjoaa ohjelmistotestaajille jo aikaisessa vaiheessa arvokasta tietoa siitä, jos ohjelmistossa jokin on muuttunut tai mennyt rikki (Al-Zain et al., 2012). Kuten muussakin automaatiotestauksessa, katsotaan graafisten käyttöliittymien testiautomaation suureksi hyödyksi se, että testaukseen kuluva aika pienenee huomattavasti verrattuna manuaaliseen testaamiseen. Aikaa säästetään, koska automaattiset testit suoriutuvat nopeammin kuin ihmisen toimesta tehdyt testit ja lisäksi automaation etuna on se, että testit voidaan suorittaa myös ilman ihmisen läsnäoloa, esimerkiksi yön aikana (Al-Zain et al., 2012).

Graafisen käyttöliittymän testaus on korkean tason testausta. Korkean tason testauksessa järjestelmää ja sen toimivuutta testataan laajemmalta näkökannalta, menemättä liian syvälle toiminnallisuuteen. Graafisen käyttöliittymän testeillä voidaan kattaa ohjelmisto sen koko laajuudelta (Li & Wu, 2004). Testit tapahtuvat siis järjestelmä tasolla ja sillä testataan koko järjestelmän laajuista toimivuutta. Nykypäivän ohjelmistotestauksessa korkean tason testejä, kuten graafisen käyttöliittymän testejä, tehdään vieläkin suurimmaksi osaksi manuaalisesti (Alégroth et al., 2015). Kuten luvussa 2 kuvattiin, manuaalisen testaamisen ongelmia ovat sen virheherkkyys, hinta ja aika, joka sen toteuttamiseen kuluu. Nämä ongelmat pätevät myös graafisten käyttöliitty- mien kohdalla. Graafisen käyttöliittymän testiautomaation on ehdotettu poistavan manuaaliseen graafisen käyttöliittymän testaukseen liittyviä ongelmia (Alégroth et al., 2015).

Tässä luvussa käsitellään graafisen käyttöliittymän automaattista testaamista, sen periaatteita ja toteutustapoja. Luvussa 6.1 esitetään automatisoitua graafisten käyttöliit- tymien testausta yleisesti ja luodaan katsaus graafisten käyttöliittymien testiautomaation piirteisiin. Luvussa 6.2 tarkastellaan graafisten käyttöliittymien automaattisen testauksen suunnittelua, lisäksi tutkitaan mitä asioita tulisi ottaa huomioon, kun graafisten käyttöliittymien testiautomaatiota aletaan suunnittelemaan ja toteuttamaan. Luvussa