Ohjelmistorobotiikan hyödyntäminen sovelluskehyksen versionvaihdoksessa

OHJELMISTOROBOTIIKAN HYÖDYNTÄMINEN SOVELLUSKEHYKSEN VERSIONVAIHDOK-

SESSA

Teemu Laakkonen

Pro gradu –tutkielma

Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede

Joulukuu 2017

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

Tietojenkäsittelytiede

Opiskelija, Teemu Laakkonen: Ohjelmistorobotiikan hyödyntäminen sovelluskehyk- sen versionvaihdoksessa

Pro gradu –tutkielma, 63 s., 1 liite (2 s.)

Pro gradu –tutkielman ohjaaja: Markku Tukiainen Joulukuu 2017

JavaScript-sovelluskehysten ja ulkoisten kirjastojen nopea kehittyminen mahdollista- vat jatkuvasti uusien ominaisuuksien ja paremman ylläpidettävyyden hyödyntämisen sovelluskehityksessä. Sovelluskehysten ja uusien kirjastojen päivittämistä ja käyttöön- ottoa kuitenkin vaikeuttaa esimerkiksi JavaScript-kielestä puuttuva vahva tyypitys ja pakettienhallinnan puutteet. Vaikkei rikkovia muutoksia olisi tarkoitus ilmentyä kir- jastoa tai sovelluskehystä päivitettäessä, ei sovelluskehityksessä tästä voida aina kui- tenkaan olla varmoja. Tässä tutkielmassa robottitestein toteutettujen hyväksymistes- tien on tarkoitus vastata osittain tähän ongelmaan.

Testauksen kulujen hallitsemiseksi ja laadukkaampien sovellusten toteuttamiseksi au- tomaatiotestien hyödyntäminen projekteissa on yleistynyt. Automaatiotestien tarkoi- tuksena on helpottaa regressiotestauksen aiheuttamia kustannuksia, joita esimerkiksi iteratiivinen kehitysmalli synnyttää projektille. Regressiotestien toteuttaminen manu- aalisesti ei ole järkevää niiden toistuvuuden takia. Kaikkea testausta ei kuitenkaan ole mahdollista toteuttaa automaatiotestein ja esimerkiksi käytettävyyttä voidaan joutua testaamaan edelleen manuaalisesti. Molempien testaustapojen yhteiskäyttö mahdollis- taa sovelluksen laadukkaan toteuttamisen.

Tässä tutkielmassa on tutkittu, kuinka robottitestausta kyetään hyödyntämään iteratii- visessa sovelluskehyksen versionvaihdoksessa helpottamaan sovelluksen tuotantoon vientiä sekä hallitsemaan testauksen kustannuksia. Tutkielmassa esitettyä mallia on sovellettu onnistuneesti käytännön projektissa, jossa AngularJS-sovelluskehyksellä toteutettu sovellus refaktoroitiin Angular-sovelluskehyksellä toteutetuksi sovel- lukseksi.

Sovelluskehityksen mallina projektissa on mukailtu ketterän kehityksen perusteita sekä DevOpsia. Ketterän kehityksen malleista projektissa on hyödynnetty iteratiivis- inkrementaalista kehitysmallia, jonka avulla sovellusta saadaan refaktoroitua pienissä ja helposti hallittavissa kokonaisuuksissa. DevOpsin päätarkoituksena sovelluskehi- tyksessä tässä projektissa on helpottaa sovelluksen asentamista eri ympäristöihin ja auttaa§ hallitsemaan jatkuvasti luotavia uusia versioita, joita iteratiivisessa kehitys- mallissa syntyy lyhyin intervallein. Projektissa käytettävät DevOps-työkalut myös mahdollistavat automaatiotestien suorittamisen kehittäjien yhteisessä ympäristössä.

Sovelluskehyksen versionvaihdoksen hyötynäkökulmaa tutkielmassa tarkastellaan kahden eri sovelluksen näkökulmasta. Ensimmäisessä sovelluksessa tarkoituksena on selvittää sovelluskehysten erot pienessä, kontrolloidussa sovellusympäristössä, joka

ii

on toteutettu ainoastaan suorituskykytestejä varten tähän tutkielmaan. Toisessa testi- sarjassa verrataan tutkielmassa käytetyn esimerkkiprojektin toimintaa ennen sovellus- kehyksen versionvaihdosta ja sen jälkeen.

Avainsanat: testaus, robottitestaus, ohjelmistorobotiikka, Robot Framework, ketterä kehitys

ACM-luokat (ACM Computing Classification System, 1998 version

• Software and its engineering~Agile software development • Software and its engineering~Use cases • Software and its engineering~Acceptance test- ing • Software and its engineering~Maintaining software • Software and its engineering~Waterfall model

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

Computer Science

Student, Teemu Laakkonen: Using software robotics to assist switching of application frameworks

Master’s Thesis, 63 p., 1 appendix (2 p.)

Supervisor of the Master’s Thesis: Markku Tukiainen December 2017

Rapid development of JavaScript frameworks and external libraries provide new fea- tures and more advanced ways to maintain applications during software development.

Lack of strong typing and shortcomings in package management systems make updat- ing frameworks and external libraries challenging during development process. Intro- ducing new versions of external libraries or the actual framework may cause uncon- trolled bugs which are not detected in manual or automated tests. Robot tests described in this thesis are supposed to provide solution to this problem.

Automated software testing has become more popular as it helps to minimize testing costs and aids in software quality assurance to provide more reliable software. Auto- mated tests are supposed to aid in costs generated by regression testing which is heav- ily included for example in iterative development model. Executing regression tests manually is not very cost effective due to their repetitive nature. However, all testing is not possible to implement by automation tests and for example usability might have to be tested manually. Using both testing methods helps software development process to provide better quality software.

In this thesis, we have made research about how robot testing can be utilized in itera- tive development process to ease production deployment process and to aid controlling testing costs. The presented model has been successfully implemented in an actual project where an application, implemented in AngularJS framework, was refactored in to an Angular application.

The development process model in this refactoring process has adapted agile develop- ment ideologies and some parts of DevOps. From agile methodologies, iterative and incremental development model has been implemented to create small and easily con- trollable units for refactoring. Main purpose of DevOps in this development process is to aid in deployment of the application and maintain continuous new versions of the application which iterative and incremental development process produces in short in- tervals. DevOps tools also enable testing in common shared environment.

Advantages of the proposed refactoring process is being inspected in two different applications. In the first application, the aim is to find out the differences between the two frameworks in small controlled environment. This environment has been created just for this occasion. In the second test set, the software presented in the thesis is being tested before and after the refactoring process.

iv

Keywords: software testing, robot testing, software robotics, Robot Framework, agile development

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

• Software and its engineering~Agile software development • Software and its engineering~Use cases • Software and its engineering~Acceptance test- ing • Software and its engineering~Maintaining software • Software and its engineering~Waterfall model

Sisällysluettelo

1. Johdanto ... 3

2. Testaaminen ... 5

2.1 Testauksen tasot ... 5

2.1.1 Yksikkötestaus ... 6

2.1.2 Integraatiotestaus ... 7

2.1.3 Järjestelmätestaus ... 8

2.1.4 Hyväksymistestaus ... 8

2.1.5 Regressiotestaus ... 8

2.2 Manuaalinen testaus ... 9

2.3 Automaatiotestaus ... 9

2.3.1 Robottitestaus ... 13

2.4 Testausta hyödyntävät kehitysmenetelmät ... 13

2.4.1 Testivetoinen kehittäminen ... 14

2.4.2 Hyväksymistestivetoinen kehittäminen ... 14

3. Kehitysmallit ... 16

3.1 Vesiputousmalli ... 16

3.1.1 Testaajat vesiputousmallissa ... 17

3.1.2 Refaktorointi kertarysäyksellä ... 17

3.2 Ketterä kehitys ... 18

3.2.1 Iteratiivinen ja inkrementaalinen kehitystyö ... 18

3.2.2 Käyttäjätarinat ... 19

3.2.3 Käyttäjätarinoiden hyödyntäminen testauksessa ... 21

3.2.4 Jatkuva integraatio ... 21

3.2.5 Ketterän kehityksen muita piirteitä ... 23

3.3 DevOps ... 24

4. Esimerkki automatisoidusta testausympäristöstä ... 28

4.1 Testausympäristö ... 29

4.2 Testien rakenne ... 30

4.2.1 Avainsanat ... 30

4.2.2 Testien abstraktiotasot ... 31

4.2.3 Testijoukko ... 32

4.3 Testien kirjoittaminen ... 33

4.3.1 Kirjoitusmalli, käyttötapauskohtainen kehitysmalli ... 33

4.3.2 Testien tekninen toteutus ... 34

5. Sovelluskehyksen vaihto hyödyntäen ohjelmistorobotiikkaa ... 36

5.1 Alkuvaatimukset ... 37

5.2 Projektin esittely ... 38

5.3 Projektin teknologiat ... 39

5.4 Projektin koonti ... 40

5.5 Työmäärät ... 41

5.6 Testien suunnittelu ja toteutus ... 42 5.7 Versionvaihdos hyödyntäen hyväksymistestausvetoista kehitysmallia43

5.7.2 Hyväksymistestien luonti ... 45

5.7.3 Refaktorointi ... 46

5.7.4 Integrointi ... 48

6. Angular vs. AngularJS: Käytännön osa ... 51

6.1 Kontrolloidun ympäristön esimerkkisovellus ... 52

6.1.1 Testitapaus 1: Taulukon lataus ... 53

6.1.2 Testitapaus 2: Taulukon päivitys... 54

6.1.3 Testitapaus 3: Muistinkäyttö ... 54

6.2 Tutkielmassa käytetty esimerkkiprojekti ... 55

6.2.1 Testitapaus 1: Sovelluksen lataus ... 56

6.2.2 Testitapaus 2: Hakutulosten lataus ... 56

6.2.3 Testitapaus 3: Kielisyyden vaihtoa ... 58

6.2.4 Testitapaus 4: Muistinkäyttö ... 58

6.3 Johtopäätökset sovelluskehysten välillä ... 59

6.4 Vertailuiden rajoitteet ... 61

7. Johtopäätökset ... 62

Lähdeluettelo ... 1

Liitteet

Liite 1: Käsiteluettelo (2 sivua)

1. JOHDANTO

Kehitystyöhön osallistuvien toimijoiden kasvanut määrä ja projektihallinnan uudet, ketterät ke- hitysmenetelmät tuovat sovelluskehityksen budjetinhallintaan uusia haasteita. Samalla sidos- ryhmien tuottamat budjettivaatimukset vaativat kehitystiimiltä onnistunutta projektin hallintaa ja ylimääräisten kulujen minimointia. Ketterässä kehitystyössä asiakkaalle pyritään varmista- maan mahdollisimman hyvin heidän tarpeitaan vastaava lopputuote ja nimensä mukaisesti py- ritään mukautumaan projektin muuttuviin määrittelyihin, vaikka ne tapahtuisivatkin aivan pro- jektin viime hetkillä. Ketterän kehityksen mahdollistamat viime hetken muutokset on tarkoitus saada hyvin nopealla aikataululla toimivaksi kokonaisuudeksi ja valmiiksi tuotteeksi, joten to- teutukselle ja testaukselle varattu aika jää lyhyeksi. Toteutukseen vaadittavaa aikaa on hankala lyhentää, mutta testauksesta on helppo tinkiä ainakin laadun kustannuksella. Testausta voidaan kuitenkin auttaa muun muassa ohjelmistorobotiikan avulla.

Ketterän kehityksen iteratiivinen kehitysmalli muuttaa testauksen aikataulua toimimaan sa- maan aikaan itse sovelluskehityksen kanssa verrattuna vanhan vesiputousmallin tapaan, jossa testaus jätetään kehitysprosessissa viimeiseksi. Jatkuvat muutokset ja uudet ominaisuudet jo olemassa olevaan ja valmiiksi testattuun sovellukseen, tai sen osioon, aiheuttavat regressiotes- tausta. Regressiotestausta varten on kuitenkin kehitetty sovelluskehyksiä, joiden avulla tes- tausta voidaan automatisoida ennalta määrättyjä testitapauksia hyväksikäyttäen. Näin ollen reg- ressiotestauksen kuluja pystytään pitämään kurissa. Sovelluksen testaus samanaikaisesti sovel- luskehityksen kanssa tuo hyviä ominaisuuksia projektiin ja sen hallintaan, mutta muutosten vaatiman regressiotestauksen toteuttaminen manuaalisesti nostaa testauskuluja.

Ohjelmistorobotiikka-termin käyttö it-projektien ja prosessien ympärillä on selvästi yleisty- mässä ja sen hyödyntämiseksi projektin eri vaiheissa on useita mahdollisuuksia. Ohjelmistoro- botiikka (Robotic process automation, RPA), on tapa automatisoida tehtäviä (Economics, 2015). Pienten tehtävien automatisoinnin ketjuttamisella saadaan toteutettua suuria ja työläitä prosesseja automaattisesti. Työtehtävät saadaan toteutettua edullisesti, nopeasti ja ilman vir- heitä. Tässä tutkielmassa ohjelmistorobotiikasta puhuttaessa käsitellään pääasiassa sovellusten automaattista testausta, jota toteutetaan ohjelmistorobotiikan keinoin.

Tämän tutkielman tarkoituksena on selvittää, kuinka ohjelmistorobotiikkaa voidaan hyödyntää toiminnassa olevan sovelluksen refaktoroinnissa. Tarkoituksena on myös tarkastella, mitä oh- jelmistoprojektilta vaaditaan ja mitä tulee ottaa huomioon refaktoroidessa sovellusta ketterin menetelmin ja hyödyntäen ohjelmistorobotiikan tarjoamia työkaluja. Tutkielman kirjallisen osuuden ohessa tutkitaan käytännössä toteutettavaa kehitystyötä, jossa olemassa olevan sovel- luksen sovelluskehys vaihdetaan uudempaan versioon iteratiivista kehitysmallia noudattaen ja hyväksikäyttäen ohjelmistorobotiikkaa vähentämään manuaalitestauksesta aiheutuvia kuluja sekä lyhentämään testauksen vaatimaa aikaa.

2. TESTAAMINEN

Sovellusten testaustavat eroavat merkittävästi riippuen sovelluskehitysmalleista. Vesiputous- mallissa testaukselle on selvästi oma ajanjaksonsa toteutuksen jälkeen. Toisaalta taas ketterän kehityksen mallissa testausta tapahtuu jatkuvasti sovelluskehityksen rinnalla. Testauksen eri lähtökohtien takia myös regressiotestauksen määrä vaihtelee merkittävästi ja ketterässä kehi- tyksessä regressiotestausta toteutetaankin huomattavasti enemmän verrattuna vesiputousmal- liin.

Sovelluskehityksessä testauksen tarvetta eivät luo pelkästään uusien ominaisuuksien ja koko- naisuuksien luonnit, vaan sovelluksen elinkaaren aikana on myös muita tapahtumia, jotka vaa- tivat sovellukselta regressiotestausta. Pitkän elinkaaren omaavat sovellukset voivat jossain vai- heessa tarvita sovelluskehyksen uusimista joko uudempaan tai kokonaan uuteen versioon. Sa- malla myös sovellusten palvelinalustat voivat vaatia korjauksia, muutoksia tai vaihdon koko- naan uuteen ympäristöön. Kaikki nämä muutokset vaativat sovellukselta testausta, jotta sen toi- minta kyetään varmistamaan.

2.1 Testauksen tasot

Sovelluskehityksessä sovelluksen eri osa-alueiden toimintaa voidaan testata useilla eri tasoilla.

Eri tasojen on tarkoitus paljastaa sovelluskoodissa olevia virheitä eri tavoin ja eri vaiheissa so- velluskehitystä. Tiettyä tarkoitusta varten toteutetut testit helpottavat ja nopeuttavat virheiden löytymistä ja niiden korjaamista mahdollisimman aikaisessa sovelluskehityksen vaiheessa eh- käisten virheiden kertymisen. Yksittäisen komponentin toimintavirheen huomaaminen yksik- kötestin avulla ja sen korjaaminen on edullisempaa verrattuna siihen, että kyseinen virhe löy- tyisi vasta järjestelmätestauksen vaiheessa. Korkeamman tason testauksen yhteydessä löyty- neen virheen korjaus voi olla työlästä sekä hankalaa. Kuten kuvasta 1 nähdään, sovellukseen toteutettavien testien eri tasot vastaavat omalta osaltaan sovelluskehitysprosessin osa-alueita sidosryhmien tarpeista aina kehitykseen saakka.

Kuva 1. Testauksen eri vaiheiden vastaavuus sovelluskehityksen eri vaiheisiin.

2.1.1 Yksikkötestaus

Yksikkötestien on tarkoitus testata yksittäisen komponentin toimintaa matalalla tasolla (Fowler, 2017). Tällöin komponentin tai luokan tulee olla eristettynä ympäristöstään (Enzler, 2017).

Ympäristöstä eristäminen sisältää yksikkötestin riippuvuuksien ja siitä riippuvien komponent- tien eristämistä pois testattavasta yksiköstä. Eristämällä komponentti sen ympäröivistä teki- jöistä, varsinkin niistä, joista se on riippuvainen, saadaan virhetilanteet täsmennettyä helposti yksittäiseen komponenttiin. Komponentin eristäminen tehdään käyttämällä testitynkiä ja luo- malla palveluita, jotka palauttavat hallitusti tiedossa olevia arvoja testauksen helpottamiseksi.

Yksikkötestien ei ole tarkoitus olla massiivisen suuria testejä, jotka testaavat isoa kokonaisuutta sovelluksesta. Yksikkötestien on tarkoitus olla nopeasti ajettavia testejä, jotta niiden ajaminen kehityksen lomassa on mielekästä. (Fowler, 2017) Jos yksikkötestien ajamiseen kuluu liian pal- jon aikaa, jää kehittäjältä niiden suorittaminen helposti tekemättä kehitystyön ohessa. Samalla myös projektin kannalta arvokasta kehitysaikaa menee hukkaan.

Sovelluskehittäjät kirjoittavat itse yksikkötestit (Fowler, 2017). Yksikkötestien luomisajan- kohta suhteessa projektin eri vaiheisiin vaihtelee kehitysmalleittain. Testivetoisessa kehitys- mallissa kehittäjät kirjoittavat testit ennen kuin aloittavat yksittäisen toiminnon kehittämistä.

Näin yksikkötestejä voidaan hyödyntää kehityksessä. Kehittäjien itse kirjoittamat yksikkötestit mahdollistavat komponentin kattavan testauksen. Henkilö, joka on itse kehittänyt komponentin, omaa parhaan mahdollisen tuntemuksen sen toiminnasta ja mahdollisista virheherkistä koh- dista. Samalla yksikkötestejä toteutettaessa virheet huomataan yksittäistä komponenttia toteu- tettaessa jo hyvin varhaisessa vaiheessa.

Yksikkötestit ovat helposti automatisoitavia testejä, koska niiden on tarkoitus testata sovelluk- sen komponentin toimintaa yksinkertaisesti matalalla tasolla. Samalla testejä voidaan suorittaa helposti ja nopeasti ilman lisäkustannuksia varmistaen sovelluksen virheettömän toiminnan.

Automatisoidut yksikkötestit helpottavat komponentin refaktorointia, jatkokehitystä ja ylläpi- toa. Komponentin refaktoroinnin jälkeen sen kaikkia toiminnallisuuksia ei tarvitse testata erik- seen, vaan aiemmin toteutetuilla yksikkötesteillä voidaan varmistua, että sen muiden osien toi- minta on pysynyt ennallaan. Tämä mahdollistaa tehokkaamman kehitystyön, koska kehittäjien on helppo varmistua muokkaamansa komponentin virheettömästä toiminnasta.

2.1.2 Integraatiotestaus

Integraatiotestien tarkoituksena on varmistaa sovelluksen eri osien toiminta yhdessä yksittäi- senä komponenttina. Integraatiotestauksen on tarkoitus paljastaa virheitä komponenttien vä- lillä, jotka eivät ole ilmenneet yksittäistä komponenttia testatessa yksikkötestein. Jos kom- ponentit ovat läpäisseet yksikkötestit, mutta niiden välinen integraatiotestaus paljastaa virheen, voidaan olettaa virheen johtuvan komponenttien välisestä rajapinnasta (Microsoft, 2017).

Jos yksi suurempi osio koostuu useasta pienemmästä komponentista, tulisi ne testata pareittain (Microsoft, 2017). Tällöin voidaan varmistua, että testeissä ilmentyneet virheet johtuvat juuri niiden kahden komponentin välisestä toiminnasta. Näiden lisäksi komponenttien testaamiseksi integraatiotesteissä voidaan käyttää erilaisia tynkäpalveluita sekä kyseisen palvelun toimintaa simuloivia palveluita, joiden toiminta ja palauttamat arvot ovat tiedossa ja helposti hallittavissa.

2.1.3 Järjestelmätestaus

Järjestelmätestauksen tarkoituksena on testata sovelluksen toimintaa kokonaisuutena ja arvi- oida täyttääkö sovellus sille asetetut määrittelyt. Järjestelmätestausta on tarkoitus toteuttaa mustalaatikkotestauksena, jossa testaajilla ei ole pääsyä ohjelmakoodiin. Testauksen tarkoituk- sena on varmistaa sovelluksen toiminta siinä muodossaan, kuin se on tarkoitus julkaista ylei- seen käyttöön. Järjestelmätestaus on testauksen tasoista laajin. (Jyväskylän yliopisto, 2017).

2.1.4 Hyväksymistestaus

Hyväksymistestauksella pyritään varmistamaan, että sovellus toimii asetettujen vaatimusten mukaisesti. Hyväksymistesti on kuvaus sovelluksen toiminnasta skenaarion tai esimerkin avulla (Alliance, 2017). Hyväksymistestit voidaan suunnitella sovellusdokumentaation lisänä täsmentämään sovelluksen toiminnan vaatimuksia. Hyväksymistestien luonnissa voidaan käyt- tää käyttäjätarinoita, jotka toimivat siten myös sovelluksen dokumentaationa.

Sovelluksen laadunvarmistamiseksi huolellisesti sovelluskehityksen aikana sitä varten määri- tellään ja toteutetaan yleensä runsaasti hyväksymistestejä. Näiden hyväksymistestien suoritta- minen yksitellen manuaalisesti on yleensä aikaa vievää ja Stameleos ja Sfetsosin kirjoittaman kirjan mukaan ne tulisikin automatisoida (Stamelos & Sfetsos, 2007). Hyväksymistestien luonne on automatisointia varten sopiva. Sovelluksen tulee täyttää jokin vaatimus tai se ei lä- päise testiä.

Hyväksymistestit pyrkivät testaamaan sovellusta käyttäjän näkökulmasta varmistaen, että so- vellus täyttää käyttäjän sille asettamat vaatimukset. Automaattisten hyväksymistestien avulla kyetäänkin varmistamaan sovelluskokonaisuuden toiminta useasti eri sovelluskehityksen vai- heissa ilman lisäkustannuksia.

2.1.5 Regressiotestaus

Regressiotestauksella tarkoitetaan testauksen osa-aluetta, jossa sovelluksessa aikaisemmin to- teutettuja osioita testataan muutosten jälkeen, vaikka niihin ei ole kohdistunut suoranaisia muu- toksia (Homes, 2013). Tällä tavalla pystytään varmistamaan, etteivät muutokset ole rikkoneet

aiemmin toimivaksi todettuja kokonaisuuksia. Regressiotestauksen luonteen takia ne tulisi au- tomatisoida ja Paul Amman sekä Jeff Offutt esittävät julkaisussaan, ettei regressiotestauksesta voida puhua regressiotestauksena, jos testejä ei ole automatisoitu (Ammann & Offutt, 2016).

Regressiotestauksen automatisointiin liittyy vahvasti myös jatkuva integraatio ja sen työkalut, jolla testejä voidaan suorittaa.

2.2 Manuaalinen testaus

Toisin kuin automaatiotestaus, manuaalinen testaus ei vaadi projektilta alkuinvestointeja, jotta yksittäinen testi saadaan toteutettua. Manuaalinen testaus kuitenkin vaatii jokaista testiä varten henkilön toteuttamaan kyseisen testin. Näin ollen esimerkiksi regressiotestausta toteutettaessa jokainen testi maksaa aina saman verran ja useat iteraatiot projektissa kasvattavat merkittävästi testauksen osuutta budjetista.

Manuaalisessa testauksessa jokaisen testitapauksen toteutuksessa on mukana ihminen. Ihmisen mukana olo prosesseissa tuo siihen mukaansa inhimillisten erehdysten mahdollisuuden. Testiä suoritettaessa testaaja voi esimerkiksi kirjoittaa jonkin merkin väärin tai jokin virhetilanne voi jäädä häneltä huomaamatta.

Ihmisen mukanaolo testeissä tuo testaukseen myös mahdollisuuksia. Testaaja voi havaita vir- hetilanteita sovelluksessa, joita ei muuten huomattaisi esimerkiksi yksikkötestien avulla, koska näitä ei olla otettu testeissä huomioon. Sovelluksissa on myös osa-alueita, joita ei ole edes mah- dollista testata muutoin, kuin ihmisten toteuttamana tai testien toteuttaminen automaattisesti on hyvin hankalaa ja työlästä. Esimerkiksi käyttäjäkokemuksen tai sovelluksen käytettävyyden testaaminen manuaalisesti on tällä hetkellä helpompaa kuin käyttäen automaatiotestejä.

2.3 Automaatiotestaus

Manuaalitestaukseen verrattuna automaatiotestaus on hyvin erilainen kulurakenteensa perus- teella. Kun manuaalitestauksessa yksittäinen testi maksaa erikseen ja alkuinvestoinnit ovat mi- nimaaliset, robottitestien luonti vaatii alkuinvestointeja, mutta testien ajaminen jatkossa ei nosta

kustannuksia olettaen, että testien ajoympäristöstä ei aiheudu kuluja projektille. Ketterässä so- velluskehityksessä ja DevOpsia hyödyntävissä projekteissa on yleensä käytössä jatkuvan integ- raation palvelimet, joilla automaatiotestit on helppo ajaa muun sovelluskehitykseen liittyvän toiminnan ohessa. Koska testien toistuvasti uudelleen ajaminen ei kohota testauksen kuluja, sopii robottitestaus hyvin projektimalliin, joka vaatii paljon regressiotestausta, kuten esimer- kiksi ketterän kehityksen iteratiivis-inkrementaalinen kehitysmalli. Iteratiivis-inkrementaali- sessa kehitysmallissa sovelluksesta tuotetaan uusia versioita peräkkäisissä iteraatioissa (peräk- käisissä sykleissä), joissa jokaisessa versiossa sovellukseen lisätään uusia ominaisuuksia.

Kuva 2. Yksittäisen automaatiotestin ja manuaalisesti suoritetun testin yhteenlaskettu aika seitsemän tes- tin osalta. (Stamelos & Sfetsos, 2007)

Kuten kuvasta 2 voidaan havaita, ovat automaatiotestejä hyödynnettäessä yksittäisen testita- pauksen kustannukset alussa korkeammat kuin manuaalisen testauksen. Stameleos ja Sfetsos tuovat ketterän kehityksen laadunvarmistus-kirjassaan esille, kuinka yksittäisen automaatiotes- tauksen luomisajaksi voidaan olettaa keskimääräisesti noin tunti, kun taas samaan testiin voi- daan manuaalisen testauksen osalta olettaa kuluvan noin neljäsosa eli 15 minuuttia (Stamelos

& Sfetsos, 2007). Tämän olettamuksen perusteella kuvasta 2 nähdään, kuinka automaatiotes- taukseen käytetyt investoinnit alkavat olla hyödyllisiä suhteessa manuaalitestaukseen neljännen testikerran jälkeen.

0 20 40 60 80 100 120

0 1 2 3 4 5 6 7

Testauksen yhteenlaskettu aika

Automaatiotestaus Manuaalinen testaus

Yllä esitetyssä kuvassa ei huomioida eri testien vaatimuksia ympäristöltä, vaan siinä keskity- tään ainoastaan yksittäiseen testitapaukseen. Kaaviossa ei ole myöskään huomioitu automaa- tiotestin vaatimia mahdollisia muutoksia ja ylläpitoa. Manuaalitestaus ja automaatiotestaus vaa- tivat erilaiset lähtökohdat, jotta testausta voidaan lähteä suorittamaan. Manuaalisen testauksen eri testaustavat ovat tämän tutkielman ulkopuolella.

Sovelluksen testaustavan valinta riippuu testattavasta sovelluksesta ja sen sisältämistä toimin- nallisuuksista. Jotkin ominaisuudet ovat helpompia toteuttaa testattavaksi automaatiotestein, kun taas joitain ominaisuuksia ei ole mahdollista toteuttaa testattavaksi kuin ainoastaan manu- aalisesti. Tämän takia sovellukset yleensä vaativat myös manuaalista testaamista automaatio- testauksen lisäksi.

Kuten manuaalitestausta, myös automaatiotestausta voidaan toteuttaa usealla eri tavalla. Läh- tökohtaisesti automaatiotestit vaativat kuitenkin jonkin ympäristön, jossa testejä voidaan suo- rittaa. Testauksen apuna voidaan käyttää myös erillistä testaustietokantaa, jolloin tiedetään aina, kuinka sovelluksen tulisi toimia. Tällöin jokaisella testin suorituskerralla sovelluksen toimin- nan tulisi olla edellisen kaltainen. Jos sovelluksen käyttämä data muuttuu jokaista testitapausta varten, testitapausten olettamukset eivät välttämättä täsmää sovelluksen toimintaan ja testit ei- vät läpäise. Myös testien luoman datan siivous on tärkeää. Lukuisat uudelleen ajettavat testit luovat jokaisella suorituskerralla tietokantaan dataa, jolle ei ole enää käyttöä testin valmistuttua.

Tämän takia testissä käytetyt testidatat tulisi siivota pois, ettei tietokanta täyttyisi vanhojen tes- tien luomasta datasta.

Jos sovellus käyttää ulkoisia palveluita, on automaatiotesteillä hankala varmistaa niistä riippu- vien ominaisuuksien toiminta ilman, että kyseisten palveluiden palauttamia arvoja matkitaan hallitusti. Tämä voidaan toteuttaa esimerkiksi testejä varten toteutetulla palvelimella, jonka toi- mintaa voidaan säädellä testien vaatimalla tavalla. Nämä ovat asioita, jotka tulee ottaa huomi- oon automaatiotestausta ja sen budjettia suunnitellessa. On myös hyvä pyrkiä arvioimaan, mitä testausta halutaan lähteä automatisoimaan ja kuinka paljon joidenkin hankalien osuuksien au- tomatisointi vie aikaa suhteessa niiden manuaaliseen testaukseen.

Kuten ketterissä menetelmissä, ja erityisesti iteratiivis-inkrementaalisessa kehitysmallissa on tapana, sovelluksen kehityksen kaaressa syntyy useita uusia versioita, joiden toiminta täytyy varmistaa ja samalla kyseisen komponentin integrointi jo olemassa olevaan järjestelmään tulee

varmistaa. Jokaista integraatiota varten sovellus vaatii testausta. Sovellukseen tehtävien muu- tosten laajuus määrittelee, kuinka paljon sovellukseen täytyy toteuttaa regressiotestausta. Var- sinkin sovellukset, jotka eivät ole vahvasti tyypitettyjä eivätkä omaa edistynyttä kääntäjää, voi- vat kokea odottamattomia virheitä myös osa-alueilla, jotka eivät kuulu kyseisessä integraatiossa toteutetun refaktoroinnin piiriin. Näihin osa-alueisiin manuaalitestauksen resursseja ei välttä- mättä ole hyödyllistä käyttää, koska testattava kokonaisuus voi laajentua hallitsemattoman suu- reksi. Samalla myös regressiotestauksen määrä kasvaa. Automaatiotestaus ei kuitenkaan vaadi enempää resursseja, koska testit ovat toteutettu aikaisemmin ja ne kaikki ovat ajettavissa hyvin pienellä budjetilla. Näin ollen koko sovelluksen toiminnallisuuden laatu kyetään varmistamaan ja julkaistavaksi saadaan laadukkaampi ja paremmin testattu tuote.

Automaatiotestien ja manuaalitestauksen erona kulurakenteessa ovat pääasiassa manuaalites- tauksen jatkuvat kulut ja automaatiotestauksen alkuinvestoinnit. Automaatiotestien ajaminen sovelluskehityksen myöhemmässä vaiheessa ei enää lisää kustannuksia projektille, mutta so- velluksen jatkokehitys ja ylläpito vaativat muutoksia sovellukseen tehdyille automaatiotes- teille. Sovelluskehityksen ohessa tehdyt automaatiotestit eivät ole sille enää hyödyksi, jos jat- kokehitystä tehdessä testit eivät enää läpäisekään ja ne poistetaan käytöstä. Tämän takia sovel- luskehityksessä on otettava huomioon testien ylläpito sovelluksen jatkokehitystä toteutettaessa.

Tällöin voidaan varmistua, että automaatiotesteistä on hyötyä myös jatkossa.

Automaatiotestien vanhenemiseen voi olla useita eri syitä. Niihin lukeutuvat muun muassa so- velluksen vaatimusten muuttumiset, jolloin hyväksymistestien määrittelemät toiminnallisuudet eivät enää täsmää uusiin vaatimuksiin. Toinen automaatiotestien ylläpitoon liittyvä asia on so- velluksen refaktorointi. Komponenttien vaihtaminen, ulkoisten kirjastojen päivittäminen ja ni- meämiskäytäntöjen selkeyttäminen voivat vaikuttaa automaatiotestien toimintaan. Automaatio- testit eivät kykene mukautumaan muutoksiin ja vaikka sovellukseen toteutettava refaktorointi ei varsinaisesti muuttaisi sovelluksen toimintaa tai aiheuttaisi virhetilannetta sovelluksen toi- minnassa, voivat automaatiotestit kuitenkin rikkoutua sovelluksen rakenteen muutoksista joh- tuen.

Automaatiotestien vanhenemista voidaan välttää, tai ainakin vähentää, hyvällä nimeämiskäy- täntöjen suunnittelulla mahdollisimman aikaisessa vaiheessa sovelluskehitystä. Myös testien suunnittelu ja toteutustavat vaikuttavat niiden kykyyn sopeutua muutoksiin. Esimerkiksi web- kehityksessä monimutkaisten XPath-kaavojen (W3Schools, 2017) käyttäminen voi tehdä tes- tistä alttiimman rikkoutumiselle.

2.3.1 Robottitestaus

Robottitestauksella yleisesti tarkoitetaan sovelluskehityksen yhteydessä toteutettavaa testausta, jonka testitapausten suorittamisessa hyödynnetään ohjelmistorobotiikkaa. Robottitestauksessa käytetään yleensä ennalta määriteltyjä testitapauksia, jotka tulkitaan robotiikan avulla joko on- nistuneeksi tai epäonnistuneeksi.

Ohjelmistorobotiikkaa ja robottitestausta voidaan toteuttaa useilla eri tavoin. Ohjelmistorobo- tiikassa on tarkoitus mukautua käyttäjän rooliin tehtävissä, jolloin robotilla on samat mahdolli- suudet käyttää sovellusta kuin käyttäjällä. Yleensä tämä tarkoittaa sitä, että ohjelmistorobotti suorittaa tehtävänsä käyttöliittymän kautta. Tällä tavalla ohjelmistorobotiikkaa on helppo hyö- dyntää sovelluksissa, joissa ei ole pääsyä esimerkiksi tietokantaan tai tarkoituksena on vain käyttää sovellusta lukemaan tai syöttämään tietoa järjestelmään.

Sovelluskehityksessä hyödynnettävää robottitestausta voidaan suorittaa suoraan tietokantaan, jotta varmistutaan tiedon tallentuneen oikein käyttöliittymän kautta. Testausta voidaan myös suorittaa käyttäen pelkästään käyttöliittymää, joka mukailee paremmin käyttäjän toimintaa, mutta rajoittaa sovelluksen kokonaisuuden testaamista.

Robottitestausta varten on olemassa useita eri sovelluksia ja kirjastoja, joiden avulla robottites- tausta voidaan toteuttaa. Testaussovelluksista kaupallisia versioita ovat muun muassa Automa- tion Anywhere (Anywhere, 2017), Blue Prism (Prism, 2017) sekä UiPath (Path, 2017). Tässä tutkielmassa käytetty Robot Framework on alun perin Nokia Networksin kehittämä ja nykyisin Robot Framework foundationin ylläpitämä avoimen lähdekoodin testaussovelluskehys (Robot Framework, 2017).

2.4 Testausta hyödyntävät kehitysmenetelmät

Tässä tutkielmassa käsitelty tapa toteuttaa refaktorointia sovellukselle yhdistelee testivetoisen, käyttötapauskohtaisen ja hyväksymistestivetoisen kehitysmallin piirteitä. Tässä osiossa kerro- taan testivetoisesta kehitysmallista, kuinka sitä voidaan hyödyntää uusien toiminnallisuuksien kehittämiseen ja kuinka sen avulla voidaan toteuttaa refaktorointia jo olemassa olevaan sovel- lukseen. Samalla selvennetään, mitä käyttötapauskohtainen- ja hyväksymistestivetoinen kehit-

2.4.1 Testivetoinen kehittäminen

Testivetoinen kehittäminen (Acharya, 2013) on ohjelmistokehitystä ohjaava kehitysmalli. Tes- tivetoisessa kehitysmallissa sovelluskehittäjä luo ensin testin, jonka on tarkoitus epäonnistua sitä suoritettaessa. Testin suorittamisen jälkeen kehittäjän on tarkoitus kehittää toteutus vastaa- maan kyseistä testiä mahdollisimman yksinkertaisesti. Kehitetyn ohjelmakoodin jälkeen kehit- täjä refaktoroi kirjoittamansa koodin vastaamaan kehitystyön sanelemia periaatteita, jonka jäl- keen kirjoitettu sovelluskoodi yhdistetään versionhallintaan ja yhteiseen sovelluskoodiin (Stamelos & Sfetsos, 2007). Testivetoisen kehittämisen mallissa yksittäisen testin on tarkoitus vastata jonkin yksittäisen toiminnallisuuden oletettua toimintaa (Stamelos & Sfetsos, 2007).

Testien toteutuksien avulla sovellukseen lisättäviä toiminnallisuuksia saadaan ohjattua. Sa- malla saadaan myös rajattua kehittäjien toteuttaman koodin määrää sekä yksinkertaistamaan toteutuksia, koska tarkoituksena on toteuttaa ainoastaan testiä vastaavat koodit.

Kehitysvaiheessa luotavien yksikkötestien avulla sovelluskehityksessä varmistutaan siitä, että jokaista komponenttia vastaavat testit tulevat tehdyksi (Stamelos & Sfetsos, 2007). Samalla myös saadaan nopeasti palautetta sovelluskoodin toiminnasta ja laadusta ennen kuin se luovu- tetaan eteenpäin testattavaksi.

Testivetoinen kehittäminen toimii hyvin, kun sovellukseen kehitetään uusia ominaisuuksia.

Tällöin uusien toteutettujen ominaisuuksien valmistuminen voidaan havaita helposti. Vanhan jo olemassa olevan sovelluskoodin muuttaminen testivetoiseen kehitysmalliin on myös mah- dollista, joskin työlästä (Stamelos & Sfetsos, 2007). Tässä tapauksessa refaktoroitavaa sovel- luskoodia vastaavat testit tulee kirjoittaa ennen refaktoroinnin alkua, jonka jälkeen kehittäjät voivat muokata sovelluskoodia siihen saakka, että aikaisemmin toteutetut testit suoriutuvat läpi.

Tällä tavoin varmistutaan siitä, että refaktoroinnilla ei ole rikottu sovelluskoodin toimintaa ja vanhat toiminnallisuudet toimivat edelleen uudella sovelluskoodilla.

2.4.2 Hyväksymistestivetoinen kehittäminen

Testivetoiseen kehittämiseen verrattuna hyväksymistestivetoisen kehittämisen (Acceptance test driven development, ATDD) (Alliance, 2017) testausprosessiin osallistuu pelkän kehittäjän si- jasta kolmesta eri perspektiivistä projektissa mukana olevia henkilöitä. Näihin rooleihin kuulu-

vat käyttäjä, kehittäjä sekä testaaja, jotka toteuttavat hyväksymistestit yhdessä. Useamman roo- lin tuodessa oman näkökulmansa hyväksymistestien luontiin, saadaan niistä mahdollisimman kattavat ja sovelluksen vaatimukset vastaavat paremmin kaikkien sidosryhmien tarpeita. Hy- väksymistestien onkin tarkoitus varmistaa, että käyttäjä pystyy tekemään haluamansa toimen- piteet sovelluksella.

Hyväksymistestivetoisen kehittämisen yhteydessä puhutaan useasti myös käyttötapauskohtai- sen kehittämisen mallista (Behavior driven development, BDD) (Agile Alliance, 2017). Käyt- tötapauskohtaisen kehityksen mallissa sovelluksen määrittelyissä käytetään käyttötapauksia, joiden avulla sovelluksen vaatimukset saadaan määritettyä. Näitä käyttäjätarinoita voidaan edelleen käyttää apuna hyväksymistestien luonnissa.

3. KEHITYSMALLIT

Sovelluskehityksessä kehitysmallien tarkoituksena on tarjota jokin malli, jonka avulla sovel- luskehitystä voidaan suunnitella ja hallita (Services, 2005). Sovelluskehityksen eri vaiheita ovat muun muassa suunnittelu, kehitys ja testaus. Eri kehitysmallit kuitenkin pilkkovat ja jäsentävät sovelluskehityksen osa-alueet eri tavalla. Kehitysmallit eroavat toisistaan myös siinä, missä jär- jestyksessä mitäkin kehityksen osa-aluetta toteutetaan. Myös roolitukset sovelluskehityksessä mukana oleville vaihtelevat kehitysmallien välillä.

Kehitysmalleilla on erilaisia tapoja ohjata sovelluskehitystyötä eteenpäin. Ensimmäiseksi esi- teltävä vesiputousmalli on yksi tunnetuimmista ja vanhimmista sovelluskehityksen malleista ja se tarjoaa hyvin selkeät ohjeet, kuinka sovelluskehitystä tulisi tehdä. Toisena esiteltävä ketterä kehitys sen sijaan on käsitteenä hieman uudempi ja sen tarkoituksena ei ole pyrkiä rajaamaan toteutustapaa, vaan pikemminkin ohjaamaan toteutusta tiettyyn suuntaan. Hyvin useasti ohjel- mistoprojekteissa sovelluskehitys kuitenkin muovautuu omanlaisekseen ja ottaa sille sopivim- mat puolet valitsemistaan sovelluskehitysmalleista.

3.1 Vesiputousmalli

Vesiputousmalli (Balaji & Murugaiyan, 2012) on peräkkäinen sovelluskehityksen malli, jossa yksittäinen vaihe toteutetaan loppuun ennen kuin siirrytään seuraavaan vaiheeseen. Näin ollen projektin eri vaiheille ei synny päällekkäisyyksiä. Vesiputousmallissa projektin eri vaiheet on aikataulutettu, ja jokaisella vaiheella on oma päättymispäivämääränsä. Tästä johtuen sovelluk- sesta ei saada näkyvää versiota sidosryhmien tarkkailtavaksi tai testattavaksi ennen kuin pro- jekti on edennyt testausvaiheeseen, missä sitä voidaan testata. Sovellukseen tehtävät muutokset on lyöty lukkoon jo aikaisemmassa vaiheessa ja testausvaiheessa ainoastaan havaitut virheet korjataan. Tästä johtuen testatessa havaitut puutteet ja kehitystoiveet voidaan toteuttaa vasta testauksessa olevan version valmistumisen jälkeen.

Lineaarinen ja ajastettu toteutusmalli helpottaa projektin hallintaa, koska koko ajan on selvillä, milloin projektin tulisi olla valmis, sekä missä vaiheessa projektia ollaan kullakin hetkellä me- nossa. Vesiputousmallissa sovelluksen määrittelyt tulee olla valmiina ennen kuin projektissa siirrytään toteutusvaiheeseen. Tämä auttaa hallitsemaan projektin työmäärää ja sen arviointia,

koska sovelluksen ominaisuudet ovat tiedossa varhaisessa vaiheessa ennen toteutuksen aloi- tusta toisin kuin esimerkiksi ketterässä kehityksessä.

3.1.1 Testaajat vesiputousmallissa

Koska vesiputousmallissa projektin eri osa-alueet eivät limity keskenään, testaajien rooli jää sovelluskehityksen loppuvaiheeseen. Tämä aiheuttaa resurssienhallinnan kannalta ongelmati- lanteen, koska testaajilla ei ole mitään roolia projektissa ennen kuin projekti on edennyt tes- tausvaiheeseen. Testauksen toteutus vasta projektin toteutusvaiheen jälkeen voi myös paljastaa virheitä, joiden korjaus toteutusvaiheen jälkeen voi olla haastavaa, aikaa vievää, sekä kallista.

3.1.2 Refaktorointi kertarysäyksellä

Projektin refaktoroinnin kannalta sovellusintegraatio ja integraatiotestauksen loppuun jättämi- nen voivat tuottaa ongelmia. Sovelluskehykset, joita ei ole suunniteltu toimimaan yhdessä, voi- vat olla keskenään yhteensopimattomia estäen toisen sovelluskehyksen toiminnan osittain tai jopa kokonaan. Tällaisten virheiden paikallistaminen refaktorointiprosessin loppuvaiheessa voi aiheuttaa suuria ylimääräisiä kustannuksia projektille ja viivästyttää projektin valmistumista merkittävästi.

Kertarysäys toteutusmallia (Big Bang) käytettäessä sovelluksen valmius tuotantoon vientiä var- ten on hidas. Vesiputousmallissa koko sovelluskokonaisuuden toiminnasta ei voida olla var- moja kehitysvaiheessa, koska sovelluksen integraatiotestausta, järjestelmätestausta eikä hyväk- symistestausta toteuteta ennen varsinaista testausvaihetta. Ilman testausta kehitysvaiheessa ei sovelluksen toimintavalmiudesta ja toimivan version puutteista voida olla täysin varmoja. Jokin ulkoinen palvelu tai sovelluksen osio voikin vaatia refaktorointia tai päivitystä, vaikkei sitä oli- sikaan suunniteltu muutettavan refaktorointiprosessin yhteydessä.

Kertarysäyksellä toteutettavat muutostyöt pysyvät hyvin hallinnassa, eikä suunniteltuun versi- oon tulevat muutokset kasaannu liian suuriksi. Tämä tapa vaatii kuitenkin hyvää tietämystä sovelluksen toiminnasta ja huolellista suunnittelua, jotta kaikki vaaditut palvelut ja osa-alueet saadaan muutettua haluttuun muotoonsa.

3.2 Ketterä kehitys

Ketterässä kehitystyössä sovelluskehitystiimi toimii perinteisen lineaarisen mallin sijaan iteraa- tioissa. Ketterä kehitystyö ei itsessään ole kehitysmalli, jota mukaillen kehitystyötä toteutettai- siin, vaan kokoelma eri työskentelytapoja jotka ohjaavat kehitystä. Ketterän kehityksen perus- tana toimivat ”Ketterän manifestin” kuvailemat arvot, joita ketterän ohjelmistokehityksen on tarkoitus vaalia. Ketterässä kehitysmallissa pääkohtina ovat käyttäjätarinat, päivittäiset ko- koukset, inkrementaalinen kehitystyö, persoonat, tiimi ja tapahtumien läpikäynti (Alliance, 2017). Seuraavissa kappaleissa käydään läpi, mitä nämä käsitteet tarkoittavat ja kuinka ne liit- tyvät ketterään kehitystyöhön.

3.2.1 Iteratiivinen ja inkrementaalinen kehitystyö

Vesiputousmallissa tuotetta kehitetään yksittäisenä kokonaisuutena, kun taas ketterän kehityk- sen yksi pääkohdista on inkrementaalinen kehitystyö. Inkrementaalisessa kehitystyössä loppu- tuotteesta toteutetaan ensin minimalistinen versio ilman ylimääräisiä ominaisuuksia. Versioon sisällytetään ainoastaan sovelluksen toiminnan kannalta tärkeimmät ominaisuudet, jotta se ky- kenee toteuttamaan tehtävänsä. Sovelluskehityksen seuraavissa vaiheissa sovellukseen lisätään ominaisuuksia pala kerrallaan. Inkrementaalisessa kehitystyössä jokainen onnistunut versio so- velluksen koonnista on tarkoitus olla toimiva versio, johon on lisätty uusia käyttäjälle näkyviä toiminnallisuuksia (Alliance, 2017).

Inkrementaalisessa kehitystyössä sovelluksen kustannuksia kyetään tarkkailemaan helposti.

Kustannusten helpompi seuraaminen mahdollistaa budjetissa pysymisen esimerkiksi jättämällä pois valittuja ominaisuuksia sovelluksesta tarpeen mukaan.

Iteratiivinen ja inkrementaalinen kehitystyö ovat hyvin lähellä toisiaan. Iteratiivisessa kehitys- työssä tarkoituksena on kirjoittaa sovellukseen koodia, joka ei välttämättä ole siinä muodossa, kuin se tulee lopulta olemaan. Koodin toteutuksen jälkeen se käydään uudelleen läpi ja sitä parannellaan, sekä muokataan paremmin toimivaksi ja siistimmäksi kokonaisuudeksi. Esimer- kiksi sovellukseen toteutetaan yksi kokonainen toiminnallisuus, joka koostuu useammasta komponentista. Komponenttien toteutuksen jälkeen yksittäistä komponenttia ryhdytään kehit- tämään tarkemmin ja siihen mahdollisesti lisätään ominaisuuksia, tai sen rakennetta parannel- laan. Koska iteratiivinen ja inkrementaalinen kehitystyö ovat hyvin lähellä toisiaan, ovat ne

molemmat hyvin useasti käytössä yhtäaikaisesti ketteriä menetelmiä sovellettaessa. Ketterässä kehityksessä on tarkoituksena toteuttaa yksittäisen käyttäjätarinan kuvaama ominaisuus alusta loppuun. Yksittäisen käyttäjätarinan valmistuttua voidaan toteuttaa uutta käyttäjätarinaa. Tämä kuvaa hyvin inkrementaalista kehitystyötä, kun taas käyttäjätarinoiden täsmentäminen ja asiak- kaan vaatimusten muutoksiin vastaaminen kuvaa erinomaisesti iteratiivista kehitystyötä.

3.2.2 Käyttäjätarinat

Käyttäjätarina on tekstimuotoon kirjoitettu lyhyt kuvaus sovelluksen toiminnasta tai toiminnal- lisuudesta. Käyttäjätarina on kirjoitettu helposti ymmärrettävään muotoon ja sen tarkoituksena on kuvata käyttäjän näkökulmasta jotain tarvetta tai tavoitetta, jonka hän haluaa pystyä suorit- tamaan sovelluksen avulla (Stamelos & Sfetsos, 2007).

Käyttäjätarinat on tarkoitus toteuttaa yhdessä koko kehitystiimin kanssa, johon kuuluu myös asiakkaan edustajia. Asiakkaan on tarkoitus kuvata toimintaa, jonka he haluavat tehdä sovel- luksen avulla. Käyttäjätarinoiden toteutus yhdessä asiakkaan kanssa mahdollistaa paremmin haluttujen ominaisuuksien määrittelyä ja antaa kehittäjille paremman kuvan siitä, mitä asiak- kaat haluavat sovelluksen tekevän. Käyttäjätarinoiden luonti ja niiden läpikäynti kasvotusten asiakkaan kanssa vähentävät kirjoitettujen määrittelyiden aiheuttamia väärinymmärryksiä (Stamelos & Sfetsos, 2007). Yhdessä ja kasvotusten käyttäjätarinoiden kehittäminen myös avartaa molempien osapuolten näkemystä sovelluksen toiminnasta ja voi edesauttaa uusien käyttöä helpottavien ominaisuuksien kehittämistä.

Käyttäjätarinoiden avulla on tarkoitus määritellä sovelluksen toimintaa ja käyttäjien on tarkoi- tus toimia suuressa roolissa käyttäjätarinoiden suunnittelussa. Tästä syystä käyttäjätarinoiden luonteessa on otettava aluksi huomioon niiden luontiin osallisina olevien kyky hahmottaa suu- rempaa sovelluskokonaisuutta. Käyttäjien, sekä kehittäjien, voi olla haastavaa hahmottaa kaik- kia sovelluksessa tarvittavia toimintoja ja ominaisuuksia, joilla sovelluksen käytettävyyttä pys- tytään parantamaan. Tästä syystä on oleellista, että aluksi käyttäjätarinat ovat laajoja ja kuvaa- vat suurempia kokonaisuuksia. Käyttäjätarinoiden luontivaiheen jälkeen, ennen varsinaista ke- hitysvaihetta, laajat käyttäjätarinat tulee ottaa uudelleen käsittelyyn ja niitä tarkennetaan tar- peen mukaan.

Käyttäjätarinoiden tarkentamista auttaa sovelluksen kehittyminen eteenpäin ja iteratiivisen ke- hitysmallin tuottamat versiot sovelluksesta. Asiakkaat pääsevät näkemään sovelluksesta toimi- van version ja pääsevät paremmin sisälle kontekstiin ennen kuin käyttäjätarinaa ryhdytään täs- mentämään tarkemmalle tasolle. Iteratiivisen kehityksen malli mahdollistaa käyttäjätarinoihin tehtävät tarkennukset ja sitä myöten niihin tehtävät muutokset kehityksen aikana. Samalla myös jo valmiiksi toteutettujen käyttäjätarinoiden muuttaminen sekä tarkentaminen ovat mahdollista.

Valmius pystyä tekemään muutoksia jo toteutettuun sovelluskoodiin tarjoaa asiakkaalle par- haan mahdollisen lopputuloksen ja tuotteen, joka vastaa mahdollisimman paljon asiakkaan tar- peita (Stamelos & Sfetsos, 2007).

Käyttäjätarinoiden tulisi kuvata tarpeeksi pieniä osia sovelluksen toiminnasta, jotta niitä voi- daan hyödyntää mahdollisimman hyvin iteratiivisessa kehityksessä ja sitä myöten testauksessa.

Yksittäisen käyttäjätarinan työmäärän tulisi olla 1-5 työviikkoa, jotta kyseisen tarinan toteutus olisi mahdollista yhdessä iteraatiossa. Ketterässä kehitystyössä käyttäjätarinoiden ei välttämättä kuitenkaan tarvitse valmistua yhdessä iteraatiossa, vaan kesken jäänyttä tehtävää voidaan jatkaa seuraavan iteraation aikana. Jotta käyttäjätarinat on mahdollista pilkkoa pieniin palasiin ja to- teuttaa valmiiksi asti hallituissa aikajaksoissa on tärkeää, että yksittäiset käyttäjätarinat ovat riippumattomia toisistaan. Jos käyttäjätarinat ovat riippuvaisia toisistaan, niiden valmistumista on hankala seurata ja lopullista valmistumista ei voida todentaa helposti (Stamelos & Sfetsos, 2007).

Käyttäjätarinoiden ei ole tarkoitus kuvata sovelluksen teknistä toimintaa. Käyttäjätarinoiden tulee keskittyä kuvaamaan sovelluksen toimintaa siten että kuka tahansa ilman teknistä osaa- mista ymmärtää mitä käyttäjätarinalla pyritään kuvaamaan. Käyttäjätarinoiden ymmärtämistä helpottaa myös niissä käytettävän terminologian tyyli. Terminologian käytössä tulisi huomioida projektiin osallisina olevien henkilöiden osaaminen ja pyrkiä viittaamaan asioihin samoilla ter- meillä kaikkien osapuolten toimesta (Stamelos & Sfetsos, 2007).

Käyttäjätarinoiden kirjoitusta varten on määritelty kaava, jolla ne tulisi kirjoittaa. Hyvässä käyt- täjätarinassa jonkin roolin omaava käyttäjä haluaa saada tehdyksi tietyn tehtävän sovelluksen avulla (Mathias & Genaid, 2012). Esimerkkinä käyttäjätarinasta voi olla esimerkiksi ”Asiak- kaana haluan pystyä ostamaan junalipun verkosta”. Tällä käyttäjätarinalla kuvataan, kuinka tie- tyn sidosryhmän jäsen, tässä tapauksessa yrityksen asiakkaan, on mahdollista ostaa verkosta junalippu sovellusta käyttäen (Stamelos & Sfetsos, 2007).

Hyvä käyttäjätarina kuvaa sovelluksen toimintaa selkeästi tarinamuodossa (Stamelos &

Sfetsos, 2007). Näin ollen käyttäjät ilman teknistä tuntemusta sovelluksen toiminnasta saavat helposti selville, mitä sovelluksella on tarkoitus pystyä tekemään ja mitkä ovat sen käyttömah- dollisuudet. Tämä mahdollistaa eri sidosryhmien välisen kommunikoinnin ilman teknistä sa- nastoa ja perehdytystä aiheeseen sekä vähentää turhan dokumentaation luontia. Näin käyttäjä- tarinat saadaan vastaamaan paremmin käyttäjien tarpeita ja kehitystyön sekä vaatimusten välille jäävät epäselvyydet saadaan minimoitua.

3.2.3 Käyttäjätarinoiden hyödyntäminen testauksessa

Käyttäjätarinoita voidaan käyttää hyväksi myös testauksessa. Testit kuvaavat käyttäjätarinaan liittyvää toiminnallisuutta ja kuvastavat, kuinka sovelluksen tulisi toimia samalla varmistaen, että kyseisen sidosryhmän tarpeet tulevat toteutetuksi toiminnallisuuden ja toiminnan osalta (Mathias & Genaid, 2012). Yksittäinen käyttäjätarina koostuu joko yhdestä tai useasta testita- pauksesta, jotka voidaan todentaa hyväksymistestien avulla. Käyttäjätarinoita vastaavat hyväk- symistestit tulisi suunnitella samaan aikaan kuin käyttäjätarinoita suunnitellaan. Hyväksymis- testit tulisi tehdä asiakkaan toimesta siten, että testit kuvaavat kuinka käyttäjät itse testaisivat ominaisuuden ja hyväksyisivät sen tehdyksi (Stamelos & Sfetsos, 2007). Testien suunnittelussa asiakkaan edustajilla on hyvä olla apunaan joku henkilö muusta kehitystiimistä. Esimerkiksi testitapausten luonnissa testaaja voi tehdä yhteistyötä asiakkaan kanssa.

3.2.4 Jatkuva integraatio

Jatkuvassa integraatiossa kehittäjien on tarkoitus kehittää sovellusta, tuottaen lyhyin interval- lein uusia julkaistavia versioita sovelluksesta, jonka toiminnallisuudet kasvavat jokaisen integ- raation myötä (Hilton, et al., 2016). Jatkuvassa integraatiossa on tarkoituksena, että sovelluske- hittäjät yhdistävät omia tuotoksiaan versionhallinnassa sijaitsevaan päähaaraan lyhyin vä- liajoin. Fowlerin mukaan jatkuvan integraation projekteissa kehittäjien tulisi tehdä vähintään yksi integraatio jokaista työpäivää kohden (Fowler, 2017).

Jokaisen kehittäjän tehdessä vähintään yhden integraation päivässä, usean kehittäjän tiimeissä projektissa valmistuu lukuisia integraatioita päivittäin ja sen myötä useita julkaistavia versioita.

Useiden julkaistavien versioiden ansiosta projektin hallinta helpottuu, koska projektin kunkin hetkinen tilanne on helposti havaittavissa. Myöskin sidosryhmien on helpompi havaita projek- tin eteneminen ja mahdollisesti projektiin käytettyjen resurssien aikaansaannokset. Ketterässä kehityksessä yhtenä pääkohdista on sovelluskehitystiimin kyky reagoida ja mukautua muuttu- viin määrittelyihin. Kun sovelluksesta saadaan julkaistavia versioita ennen kuin sovelluksen kaikki toiminnallisuudet ovat valmiita, on sovellukseen mahdollista lisätä toivottavia toimin- nallisuuksia tai poistaa toiminnallisuuksia, jotka vaikuttavatkin turhille, kun sovelluksen toi- mintaa on päästy kokeilemaan käytännössä. Tällä tavalla sovelluksen kokonaiskustannuksia voidaan karsia, kun turhia ominaisuuksia ei tarvitse toteuttaa loppuun saakka.

Sovelluksen saaminen julkaistavaksi versioksi on hyvin nopeaa jatkuvan integraation avulla.

Jokaisen kehittäjän on tarkoitus integroida oma työnsä toimivaan sovellukseen siten, että so- velluksen koonti-tehtävä pysyy ehjänä ja kaikki sovellukseen tehdyt automaattiset hyväksymis- testit ovat menneet läpi (Fowler, 2017). Näin ollen sovelluksesta on koko ajan olemassa versio, joka on mahdollista julkaista.

Sovelluskehityksessä jatkuvan integraation mahdollistaa testien, sovelluskoontien sekä kään- nösten automatisointi (Hilton, et al., 2016). Jokaista versiota ja testikierrosta ei tarvitse toteuttaa käsin, joka veisi paljon aikaa, vaan kaikki voidaan tehdä automaattisesti ilman kehittäjien yli- määräistä työpanosta. Automaattisen sovelluskoonnin voi aloittaa esimerkiksi tehtävä, joka käynnistetään sovelluskehittäjän yhdistettyä oma sovelluskehityshaaransa muutokset valittuun sovelluskehityshaaraan projektin versionhallinnassa (Fowler, 2017). Sovelluskokonaisuuden läpäistyä kaikki hyväksymistestit sovellus on valmis julkaistavaksi.

Ilman jatkuvaa integraatiota projektin eri osien integrointi yksittäiseksi kokonaisuudeksi voi osoittautua useasti työlääksi (Stamelos & Sfetsos, 2007). Hankalasti arvioitavat työmäärät, jotka kohdistuvat projektin loppupuolella tehtävään integraatiovaiheeseen, voivat viivästyttää projektia odottamattoman paljon. Yllättävät viivästykset pitkittävät projektin kestoa ja vaativat resursseja, joita ei ole välttämättä otettu huomioon projektia budjetoitaessa.

Jatkuva integraatio helpottaa myös yksittäisen kehittäjän päivittäistä työtä, koska integraatio- prosessit eivät kasva liian suuriksi ja niissä syntyvät ongelmat ovat helposti hallittavissa. Jokai- nen yhteiseen versionhallintaan tehtävä sovellusversioiden yhdistys on kaksivaiheinen. Kehit- täjän on ensin päivitettävä oma versionsa ajan tasalle yhteisen sovelluskehityshaaran kanssa.

Tämä vaatii mahdollisesti muokkauksia sovelluskoodiin, jota kehittäjä on tehnyt viimeisimmän päivityksen jälkeen.

Sovellusversion sulauttamisen jälkeen sovelluskehittäjä suorittaa automaatiotestit. Kehittäjien tulee ylläpitää ja luoda uusia automaatiotestejä luodessaan uusia komponentteja ja toiminnalli- suuksia sovellukseen, jotta niiden toiminnallisuudet pystytään todentamaan jatkossa automaat- tisesti. Automaatiotestit osoittavat, että kehittäjän tekemät muutokset eivät ole rikkoneet mui- den kehittäjien tekemiä muutoksia ja hänen omatekemänsä muutokset toimivat yhteisessä so- vellusvedoksessa. Automaatiotestien suoriuduttua kehittäjä voi yhdistää omat tuotoksensa yh- teiseen sovelluskehityshaaraan. Usean kehittäjän projekteissa sovelluskehityksen edetessä jat- kuvasti eteenpäin, yksittäisen kehittäjän version jääminen jälkeen yhteisestä sovelluskehitys- haarasta aiheuttaa useampia konflikteja versioiden välillä ja vaikeuttaa integraatiota kehittäjän oman sekä yhteisen sovellusversion kanssa (Stamelos & Sfetsos, 2007).

3.2.5 Ketterän kehityksen muita piirteitä

Yllä esitettyjen ketterän kehityksen osa-alueiden lisäksi ketterään kehitykseen kuuluu myös muita käsitteitä ja tapoja, jotka ovat kuitenkin tämän tutkielman ulkopuolella eivätkä suoranai- sesti liity sovelluksen refaktorointiin. (Alliance, 2017)

Päivittäiset kokoukset

Päivittäisten kokousten tarkoituksena on tehdä tilannekatsaus toteutetuista tehtävistä ja varmis- taa, ettei kehitystyössä ole ilmennyt esteitä, jotka mahdollisesti estävät kehitystyön (Alliance, 2017). Päivittäisten kokousten avulla kyetään havainnoimaan ja reagoimaan nopeasti tilantei- siin, jotka mahdollisesti viivästyttäisivät projektia tai aiheuttaisivat kehittäjille turhaa odottelua.

Persoonat

Kehitystyön niin vaatiessa, esimerkiksi silloin kun käyttäjäkokemus on suuri osa sovelluksen toimintaa, persoonia voidaan käyttää käyttäjätarinoiden personoimiseen ja yksittäisen käyttäjän tarpeiden kartoitukseen. Persoonien tarkoituksena on eritellä, mitä erilaisia tarpeita eri käyttä- jillä on, kun he käyttävät sovellusta ja näin pystytään vastaamaan paremmin kaikkien sidosryh- mien tarpeisiin (Stamelos & Sfetsos, 2007).

Tiimi

Agile Alliancen (Alliance, 2017) mukaan ketterässä kehityksessä tiimi kuvastaa pientä ryhmää työntekijöitä, jotka toteuttavat samaa projektia tai kokonaisuutta. Yksittäinen suuri projekti voi sisältää useita sovelluskehitystiimejä, jotka kaikki toteuttavat omaa kokonaisuuttaan. Tällöin projektin tehtävienhallinta sekä versionhallinta ovat tärkeässä roolissa, jotta kaikki pysyvät ajan tasalla eikä päällekkäisyyksiä tai konflikteja synny. Kehitystyön tuloksien läpikäynti sekä hy- vässä, että pahassa tulisi tehdä tiimin tasolla sen sijaan, että se tehtäisiin yksilötasolla.

Tapahtumien läpikäynti

Tapahtumien läpikäynti (Alliance, 2017) on tärkeä vaihe ketterässä kehityksessä. Tapahtumien läpikäynnin ansiosta sovelluskehitystiimi kykenee parantamaan omia käytäntöjään, jotta se ky- kenee toimimaan paremmin. Tähän läpikäyntiin tulisi osallistua kaikki projektissa jatkuvasti työskentelevät henkilöt ja läpikäynti tulisi tehdä silloin, kun kehitystyö on edennyt johonkin suurempaan merkkipaaluun saakka. Kyseinen tapahtumien läpikäynti ei vastaa päivittäisiä ko- kouksia eikä sitä tulisi myöskään sekoittaa iteraatioiden välissä pidettävään kuluneen iteraation tapahtumien läpikäyntiin.

Tilaisuudessa tiimin toimintatapoja voidaan muokata sopimaan paremmin sille sopiviksi. So- velluskehityksen alussa määritellyt tavat eivät välttämättä sovikaan sille niin hyvin kuin aikai- semmin on ajateltu. Samalla voidaan tehdä muutoksia testitapausten tai sovelluskoodin toteu- tuksen käytäntöihin. Tällaisia voivat olla esimerkiksi nimeämiskäytäntöjen muutokset, jotta ne sopivat paremmin muuhun sovelluskehitykseen, esimerkiksi käyttäjätarinoista johdettuihin au- tomaattisiin testitapauksiin.

3.3 DevOps

DevOps-kehitysmallin tarkoituksena on pienentää kehityksen ja tuotannon sekä ylläpidon väli- siä kuiluja toimiakseen paremmin ja tehokkaammin ilman ylimääräisiä esteitä (Swartout, 2012). Swartout tuo kirjassaan myös esille, ettei DevOpsin ole tarkoitus siirtää tuotannon ja ylläpidon tehtäviä kehittäjien toteutettavaksi, vaan paremminkin saada eri osa-alueet toimimaan sujuvammin keskenään ilman ylimääräisiä esteitä ja aikaa vieviä odotteluita. Samoin kuten ket-

terän kehityksen malli, DevOps ei itsessään määrittele tiukkoja suuntaviivoja, kuinka kehitys- työtä tulisi tehdä, vaan sen tarkoitus on ohjata kehitystyötä tiettyyn suuntaan. DevOpsia käyt- töönotettaessa tärkeintä on ymmärtää sen eri osa-alueet ja pyrkiä poimimaan sieltä tarvittavat palaset, jotka tuovat sen käyttöön ottavalle organisaatiolle eniten lisäarvoa sovelluskehityspro- sessiin (Swartout, 2012).

DevOpsin tarkoituksena on tuoda toisiaan lähemmäksi kolme eri sovelluskehityksen osa-alu- etta: kehitystyö, laadunvarmistus ja tuotanto. Nämä osa-alueet ovat vanhassa vesiputouskehi- tysmallissa olleet toisistaan riippuvaisia, mutta erillään toimineita kokonaisuuksia. Lyhenne Dev viittaa kehittäjiin (Developers), mutta DevOpsista puhuttaessa se käsittää myös muut hen- kilöt, jotka ovat osallisina itse tuotteen kehitykseen (Mueller, 2017). Näihin kuuluvat muun muassa itse kehittäjät, suunnittelijat, määrittelijät sekä testaajat. Ops-käsite (Operations) viittaa sovelluksen tuotantoon ja ylläpitoon liittyviä henkilöitä. Näihin kuuluvat muun muassa järjes- telmän ylläpitäjät, tuotantoinsinöörit, tietokantavastaavat, tietoturva-asiantuntijat sekä verkko- yhteyksien ylläpitäjät (Mueller, 2017).

Jatkuva integraatio on vahvasti osana DevOpsia. Jatkuvan integraation tarkoituksena on tuottaa jokaisesta versionhallintaan viedystä muutoksesta versio, joka voidaan testata ja todeta toimi- vaksi kokonaisuudeksi. Samalla tämä versio voidaan viedä testausympäristöön. Sovelluksen asentaminen eri ympäristöihin on työlästä tehdä manuaalisesti. Jatkuvan integraation tuottamat lukuisat versiot on helppo viedä automaattisesti eri ympäristöihin samoin konfiguraatioin.

Tämä poistaa riippuvuudet operatiivisesta puolesta, jolle tarvittaisiin tehdä pyyntö version asen- nusta varten jokaista ympäristöä varten. Samalla myös odotteluajat näistä asennuksista saadaan poistettua.

Kuva 3. DevOps yhdistää kehityksen, tuotannon/ylläpidon ja laadunvarmistuksen (Swartout, 2012)

Amazonin on sanottu tekevän muutoksia tuotantoon keskiarvoltaan joka 11,6:des sekunti (Humble, 2017). Tällaisilla intervalleilla toteutettujen tuotantoon vientien toteuttaminen käsin ei olisi millään tavalla mahdollista. Käyttäjälle näkyvissä järjestelmissä tuotantoon viennin yh- teydessä tapahtuvat virhetilanteet voivat aiheuttaa yritykselle imagon menetyksiä tai haittoja liiketoiminnalle. Tämän takia olemassa olevaan julkiseen ympäristöön tehtävien muutosten ris- kien minimointi on tärkeää. Riskejä voidaan minimoida DevOps-työkaluilla, joiden avulla tuo- tantoon vientiä on tarkoitus saada helpommin hallittavaksi. Käytännössä tämä tarkoittaa, että sovelluksesta tehdään vedos, joka viedään testiympäristöön jatkuvan integraation työkaluilla (Gmeiner et al., 2015). Kun tuotantoversio on saatu todistetusti toimimaan testiympäristössä, voidaan se ottaa käyttöön tuotantoympäristössä napin painalluksella silloin, kun se on sopivaa ympäristön ja käyttäjien kannalta (Gmeiner et al., 2015). Tämä takaa sen, että testiympäristöön viedyt sovelluksen eri osa-alueet tulevat viedyiksi myös tuotantoympäristöön samassa järjes- tyksessä ja samalla tavalla yhtenevin konfiguraatioin.

DevOpsin on pitkälti tarkoitus automatisoida kehityksen ja sovelluksen tuotantoon viennin vä- liset vaiheet aina sovelluspaketin kasaamisesta sovelluksen testaukseen ja sovelluksen käyt- töönottoon saakka. Tästä syystä eri vaiheiden toteuttaminen vaatii eri työkaluja ja ne ovatkin

isossa roolissa DevOps sovelluskehityksessä mukana. Alla on listattuna muutamia DevOps työ- kaluja ja kerrottu lyhyesti niiden toiminnasta. Näiden työkalujen lisäksi on olemassa lukuisia eri työkaluja DevOps sovelluskehitykseen, joilla on omat roolinsa kehitystyössä.

Git

Git (Git, 2017) on laajasti käytössä oleva versionhallintajärjestelmä, joka eroaa muista version- hallintatyökalustaan omalla haarautumismallillaan. Eri haaroja (Branch) voidaan käyttää eri ominaisuuksien kehitykseen erillään muusta kehityksestä. DevOpsia hyödynnettäessä sovelluk- sen version luominen voidaan rajata ainoastaan tiettyyn haaraan tehtäviin muutoksiin. Esimer- kiksi jokaisesta päähaaraan tehdystä muutoksesta voidaan automaattisesti luoda sovellusvedos muilla DevOps-työkaluilla. Tällä tavalla keskeneräiset tuotokset voidaan eriyttää omaan haa- raansa koottavasta versiosta.

Ansible

Ansible (Ansible, 2017) pyrkii olemaan kokonaisvaltainen DevOps-työkalu, joka kattaa koko sovelluksen elinkaaren. Työkalun on tarkoitus automatisoida yksinkertaiset ja työläät tehtävät tuottavuuden parantamiseksi. Näitä ovat muun muassa sovelluksen asentaminen, sekä konfigu- raatioiden- ja työtehtävien hallinta.

Jenkins

Jenkins (Jenkins, 2017) on automaatiota varten toteutettu palvelin, joka on ajettavissa täysin itsenäisesti esimerkiksi Java-alustalla tai Docker-konttina. Jenkinsiä voidaan käyttää kasaa- maan, testaamaan ja asentamaan sovelluksia. Sille on myös toteutettu lukuisia liitännäisiä eri tehtäviä varten.

Docker

Docker on konttityökalu, jolla pyritään eliminoimaan eri ympäristöissä ajettavien sovellusten ympäristökohtaiset ongelmat. Sovellukset ja niiden riippuvuudet paketoidaan suljettuun ympä- ristöön konttiin, jonka avulla sovellukselle saadaan samat asetukset ja kirjastot kaikkiin ympä- ristöihin.

4. ESIMERKKI AUTOMATISOIDUSTA TESTAUSYMPÄRIS- TÖSTÄ

Robot Framework (Framework, 2017) on avoimen lähdekoodin sovelluskehys testauksen auto- matisointiin hyväksymistestien suorittamiseksi. Robot Framework mahdollistaa testitapausten uudelleenkäytettävyyden ja laajan liitännäisten saatavuuden, jolloin testejä voidaan toteuttaa tehokkaasti ja hyödyntää monilla eri teknologioilla toteutettuihin sovelluksiin. Robot Fra- meworkin sallimat eri tavat toteuttaa testejä mahdollistavat sen hyödyntämisen eri kehitysmal- lien mukaisesti. Esimerkkinä tästä on käyttötapauskohtaisen kehitysmallin hyödyntäminen, jonka tuottamia käyttäjätarinoita voidaan hyödyntää testitapauksia luotaessa.

Robot Framework perustuu avainsanavetoisen testauksen malliin, jossa voidaan luoda uusia avainsanoja. Tällä tavalla kyetään luomaan uudelleenkäytettäviä avainsanoja ketjutettavaksi uusia testitapauksia varten. Sovelluskehystä kyetään myös jatkamaan Java tai Python ohjel- mointikielillä toteutetuilla testikirjastoilla. Ulkoisia kirjastoja löytyy lukuisia ja kuka tahansa voi kehittää niitä myös itse. Ulkoisten kirjastojen avulla Robot Frameworkilla voidaan testata muun muassa iOS-sovelluksia sekä Javalla kirjoitettuja Swing-sovelluksia (Framework, 2017).

Itse sovelluksen testaukseen Robot Framework käyttää hyväksi eri testauskirjastoja. Tässä tut- kielmassa testauksen alla olevan web-sovelluksen testaukseen käyttämämme Robot Framework hyödyntää käyttöliittymän osalta Selenium2-sovelluskehystä.

Kuva 4. Havainnekuva Robot Frameworkin toiminnasta.

Robot Frameworkin valinnan syynä tähän tutkielmaan oli sen maksuttomuus. Myös sen käyt- tötarkoitus toteuttaa hyväksymistestausvetoista kehittämistä tukee tämän tutkielman toteutta- mismallia. Robot Framework omaa myös laajan käyttäjäkunnan ja se on dokumentoitu katta- vasti, joka helpottaa sen käyttöönottoa.

4.1 Testausympäristö

Robot Frameworkilla voidaan toteuttaa testejä usein eri tavoin. Sovelluksen toimintaa voidaan testata suoraan sellaisenaan, mutta esimerkiksi sovellukset, joissa tallennetaan tai luetaan tietoa tietokannasta vaativat omia järjestelyitä ympäristöjen asetuksia varten, jotta testit voidaan ajaa joka kerta samanlaisessa ympäristössä. Tällaista alkuvalmistelua ei välttämättä kaikissa tapauk- sissa tarvita manuaalitestauksissa, koska ihmistestaajat kykenevät sopeutumaan tilanteisiin tai muuttamaan tilanteen vastaamaan alkuperäistä tilannetta. Alkuvalmisteluita vaaditaan kuiten- kin useasti kaikkiin automaatiotestauksiin, eikä se ole sidoksissa pelkästään robottitestaukseen.

Robottitestauksella toteutetut testitapaukset vaativat jonkinlaisen tavan viitata html-elementtei- hin sovelluksessa, jota ollaan testaamassa. Toisin kuin ihmistestaajat, tietokoneet eivät itsestään kykene mukautumaan sovelluksen muutoksiin. Testitapausten ja niiden sisällä toteutettujen viittausten kykyä välttää muutoksista aiheutuvia testien rikkoutumisia voidaan kuitenkin paran- taa testitapausten huolellisella suunnittelulla ja johdonmukaisella toteutuksella. On kuitenkin hyvin todennäköistä, että jossain vaiheessa sovelluskehitystä testit rikkoutuvat refaktoroinnista tai uusista ominaisuuksista johtuen. Jotta robottitesteistä voidaan hyötyä myös jatkossa, täytyy projektissa olla valmius ylläpitää testejä läpi sovelluskehitysprosessin.

Robottitestien avulla on edullista tehdä regressiotestausta. Yksittäisen testikierroksen toteutta- minen olemassa olevilla testeillä ei kustanna projektille merkittävästi enempää ja kaikki testat- tavissa olevat osuudet tulevat testattua. Regressiotestauksen avulla sovelluksen laatua pystytään parantamaan, koska kaikki testit voidaan suorittaa jokaisella testikierroksella hallituin kustan- nuksin.

4.2 Testien rakenne

Robot Frameworkilla kirjoitettavat testit pohjautuvat tekstitiedostoihin kirjoitettuihin testita- pauksiin, joiden toteuttaminen täsmentyy lopulta varsin tekniselle tasolle. Hyvin tekniselle ta- solle toteutetut testitapaukset hankaloittavat testitapausten lukemista ja ymmärtämistä. Samalla se myös rajaa henkilöiden määrää, jotka ymmärtävät, mitä testissä testataan. Robot Framework tarjoaa kuitenkin mahdollisuuden rajata testitapauksia omiin kokonaisuuksiin ja helpottaa tes- tien ymmärtämistä abstraktiotasojen avulla.

4.2.1 Avainsanat

Robot Framework on avainsanapohjainen sovelluskehys, jonka avulla voidaan luoda uudelleen- käytettäviä avainsanoja ja avainsanakokonaisuuksia. Esimerkkikoodista 1 voidaan nähdä, kuinka testitapausta varten on luotu kaksi avustavaa avainsanaa, joita voidaan käyttää uudelleen testitapauksissa. Esimerkkikoodissa 1 esiintyvät avainsanat eivät itsessään testaa sovelluksen toimintaa, vaan toimivat apuna testitapauksissa syöttäen käyttäjänimen, sekä salasanan. Lopulta avainsanat täsmentyvät esimerkkikoodissa 1 esitettyyn malliin, jossa Selenium-sovelluskehyk- sen avulla etsitään HTML-koodista HTML-elementti. Elementille voidaan tehdä tarkistuksia tai syötetään siihen jotain tietoa.

Tässä tutkielmassa esitellyn Robot Frameworkin esimerkkikoodit ovat kirjoitettu Intellij IDEA- editorilla. Editoriin asennettavan liitännäisen ansiosta se kykenee erottelemaan syntaksin eri osat ja värittämään ne, jotta testit olisivat paremmin luettavissa. Tutkielmassa käytetyissä esi- merkeissä sininen väri kuvastaa avainsanan julistusta, vihreä väri kuvaa käytettävää avainsanaa ja punainen väri kuvaa avainsanalle annettavaa parametriä.

Esimerkkikoodi 1. Esimerkki Robot Frameworkilla toteutetuista avainsanoista.

Robot Frameworkilla toteutetut avainsanat ovat ketjutettavia. Kuten esimerkkikoodista 2 voi- daan havaita, siinä käytettävä testitapaus käyttää esimerkkikoodissa 1 esitettyjä avainsanoja.

Vastaavasti esimerkkikoodissa 2 esitettyä avainsanaa voidaan käyttää jatkossa uusissa testita- pauksissa.

Esimerkkikoodi 2. Esimerkki uudelleenkäytettävistä avainsanoista.

4.2.2 Testien abstraktiotasot

Robot Frameworkin uudelleenkäytettävät avainsanat mahdollistavat testien kirjoittamisen eri abstraktiotasoille saakka. Avainsanojen korkea abstraktiotaso mahdollistaa testien kirjoittami- sen helposti ymmärrettävään muotoon myös henkilöille, joilla on vähän teknistä osaamista. Ku- vasta 5 voidaan nähdä, kuinka Robot Frameworkilla toteutettuja avainsanoja on ketjutettu ylei- sen tason tehtävästä ”Käyttäjä voi kirjautua sovellukseen omilla tunnuksillaan” aina matalalle tasolle, jossa klikataan yksittäistä painiketta. Kuvassa 5 esitetään ainoastaan Robot Framewor- killa toteutetut avainsanat ja siitä on jätetty pois tekniset osuudet.

Kuva 5. Robot Frameworkin avainsanojen käyttö eri abstraktiotasoilla.

4.2.3 Testijoukko

Robot Frameworkin käyttöoppaan mukaan (Robot Framework, 2017) testit koostuvat testijou- koista (Test suite), joiden on tarkoitus kuvata jotain kokonaisuutta sovelluksesta. Testijoukon on tarkoitus sisältää muutamia testejä, jotka varmistavat sitä vastaavan vaatimuksen toiminnan.

Testijoukot kirjoitetaan yksittäiseen tiedostoon, josta testit lopulta ajetaan. Testijoukkoja voi- daan muodostaa korkeamman abstraktion tasolle luomalla kansioita ja alikansioita, joihin tie- dostot lopulta sijoittuvat.