OHJELMISTOROBOTIIKAN HYÖDYNTÄMINEN SOVELLUSKEHYKSEN VERSIONVAIHDOK- SESSA

Transkriptio

1 OHJELMISTOROBOTIIKAN HYÖDYNTÄMINEN SOVELLUSKEHYKSEN VERSIONVAIHDOK- SESSA Teemu Laakkonen Pro gradu tutkielma Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Joulukuu 2017

2 ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Joensuu Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede Opiskelija, Teemu Laakkonen: Ohjelmistorobotiikan hyödyntäminen sovelluskehyksen 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 mahdollistavat jatkuvasti uusien ominaisuuksien ja paremman ylläpidettävyyden hyödyntämisen sovelluskehityksessä. Sovelluskehysten ja uusien kirjastojen päivittämistä ja käyttöönottoa kuitenkin vaikeuttaa esimerkiksi JavaScript-kielestä puuttuva vahva tyypitys ja pakettienhallinnan puutteet. Vaikkei rikkovia muutoksia olisi tarkoitus ilmentyä kirjastoa tai sovelluskehystä päivitettäessä, ei sovelluskehityksessä tästä voida aina kuitenkaan olla varmoja. Tässä tutkielmassa robottitestein toteutettujen hyväksymistestien on tarkoitus vastata osittain tähän ongelmaan. Testauksen kulujen hallitsemiseksi ja laadukkaampien sovellusten toteuttamiseksi automaatiotestien hyödyntäminen projekteissa on yleistynyt. Automaatiotestien tarkoituksena on helpottaa regressiotestauksen aiheuttamia kustannuksia, joita esimerkiksi iteratiivinen kehitysmalli synnyttää projektille. Regressiotestien toteuttaminen manuaalisesti 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ö mahdollistaa sovelluksen laadukkaan toteuttamisen. Tässä tutkielmassa on tutkittu, kuinka robottitestausta kyetään hyödyntämään iteratiivisessa 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 sovellukseksi. Sovelluskehityksen mallina projektissa on mukailtu ketterän kehityksen perusteita sekä DevOpsia. Ketterän kehityksen malleista projektissa on hyödynnetty iteratiivisinkrementaalista kehitysmallia, jonka avulla sovellusta saadaan refaktoroitua pienissä ja helposti hallittavissa kokonaisuuksissa. DevOpsin päätarkoituksena sovelluskehityksessä tässä projektissa on helpottaa sovelluksen asentamista eri ympäristöihin ja auttaa hallitsemaan jatkuvasti luotavia uusia versioita, joita iteratiivisessa kehitysmallissa 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 i

3 on toteutettu ainoastaan suorituskykytestejä varten tähän tutkielmaan. Toisessa testisarjassa verrataan tutkielmassa käytetyn esimerkkiprojektin toimintaa ennen sovelluskehyksen 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 testing Software and its engineering~maintaining software Software and its engineering~waterfall model ii

4 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 features and more advanced ways to maintain applications during software development. Lack of strong typing and shortcomings in package management systems make updating frameworks and external libraries challenging during development process. Introducing new versions of external libraries or the actual framework may cause uncontrolled 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. Automated tests are supposed to aid in costs generated by regression testing which is heavily 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 iterative 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 development ideologies and some parts of DevOps. From agile methodologies, iterative and incremental development model has been implemented to create small and easily controllable 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 intervals. 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. iii

5 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 testing Software and its engineering~maintaining software Software and its engineering~waterfall model iv

6 Sisällysluettelo 1. Johdanto Testaaminen Testauksen tasot Yksikkötestaus Integraatiotestaus Järjestelmätestaus Hyväksymistestaus Regressiotestaus Manuaalinen testaus Automaatiotestaus Robottitestaus Testausta hyödyntävät kehitysmenetelmät Testivetoinen kehittäminen Hyväksymistestivetoinen kehittäminen Kehitysmallit Vesiputousmalli Testaajat vesiputousmallissa Refaktorointi kertarysäyksellä Ketterä kehitys Iteratiivinen ja inkrementaalinen kehitystyö Käyttäjätarinat Käyttäjätarinoiden hyödyntäminen testauksessa Jatkuva integraatio Ketterän kehityksen muita piirteitä DevOps Esimerkki automatisoidusta testausympäristöstä Testausympäristö Testien rakenne Avainsanat Testien abstraktiotasot Testijoukko Testien kirjoittaminen Kirjoitusmalli, käyttötapauskohtainen kehitysmalli Testien tekninen toteutus Sovelluskehyksen vaihto hyödyntäen ohjelmistorobotiikkaa Alkuvaatimukset Projektin esittely Projektin teknologiat Projektin koonti Työmäärät Testien suunnittelu ja toteutus Versionvaihdos hyödyntäen hyväksymistestausvetoista kehitysmallia Refaktoroitavan komponentin valinta

7 5.7.2 Hyväksymistestien luonti Refaktorointi Integrointi Angular vs. AngularJS: Käytännön osa Kontrolloidun ympäristön esimerkkisovellus Testitapaus 1: Taulukon lataus Testitapaus 2: Taulukon päivitys Testitapaus 3: Muistinkäyttö Tutkielmassa käytetty esimerkkiprojekti Testitapaus 1: Sovelluksen lataus Testitapaus 2: Hakutulosten lataus Testitapaus 3: Kielisyyden vaihtoa Testitapaus 4: Muistinkäyttö Johtopäätökset sovelluskehysten välillä Vertailuiden rajoitteet Johtopäätökset Lähdeluettelo... 1 Liitteet Liite 1: Käsiteluettelo (2 sivua) 2

8 1. JOHDANTO Kehitystyöhön osallistuvien toimijoiden kasvanut määrä ja projektihallinnan uudet, ketterät kehitysmenetelmät tuovat sovelluskehityksen budjetinhallintaan uusia haasteita. Samalla sidosryhmien tuottamat budjettivaatimukset vaativat kehitystiimiltä onnistunutta projektin hallintaa ja ylimääräisten kulujen minimointia. Ketterässä kehitystyössä asiakkaalle pyritään varmistamaan mahdollisimman hyvin heidän tarpeitaan vastaava lopputuote ja nimensä mukaisesti pyritään mukautumaan projektin muuttuviin määrittelyihin, vaikka ne tapahtuisivatkin aivan projektin viime hetkillä. Ketterän kehityksen mahdollistamat viime hetken muutokset on tarkoitus saada hyvin nopealla aikataululla toimivaksi kokonaisuudeksi ja valmiiksi tuotteeksi, joten toteutukselle 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 samaan 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 regressiotestausta. Regressiotestausta varten on kuitenkin kehitetty sovelluskehyksiä, joiden avulla testausta voidaan automatisoida ennalta määrättyjä testitapauksia hyväksikäyttäen. Näin ollen regressiotestauksen kuluja pystytään pitämään kurissa. Sovelluksen testaus samanaikaisesti sovelluskehityksen 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 yleistymässä ja sen hyödyntämiseksi projektin eri vaiheissa on useita mahdollisuuksia. Ohjelmistorobotiikka (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 virheitä. Tässä tutkielmassa ohjelmistorobotiikasta puhuttaessa käsitellään pääasiassa sovellusten automaattista testausta, jota toteutetaan ohjelmistorobotiikan keinoin. 3

9 Tämän tutkielman tarkoituksena on selvittää, kuinka ohjelmistorobotiikkaa voidaan hyödyntää toiminnassa olevan sovelluksen refaktoroinnissa. Tarkoituksena on myös tarkastella, mitä ohjelmistoprojektilta 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 sovelluksen 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. 4

10 2. TESTAAMINEN Sovellusten testaustavat eroavat merkittävästi riippuen sovelluskehitysmalleista. Vesiputousmallissa 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ä kehityksessä regressiotestausta toteutetaankin huomattavasti enemmän verrattuna vesiputousmalliin. Sovelluskehityksessä testauksen tarvetta eivät luo pelkästään uusien ominaisuuksien ja kokonaisuuksien luonnit, vaan sovelluksen elinkaaren aikana on myös muita tapahtumia, jotka vaativat sovellukselta regressiotestausta. Pitkän elinkaaren omaavat sovellukset voivat jossain vaiheessa tarvita sovelluskehyksen uusimista joko uudempaan tai kokonaan uuteen versioon. Samalla myös sovellusten palvelinalustat voivat vaatia korjauksia, muutoksia tai vaihdon kokonaan uuteen ympäristöön. Kaikki nämä muutokset vaativat sovellukselta testausta, jotta sen toiminta 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 sovelluskehitystä. Tiettyä tarkoitusta varten toteutetut testit helpottavat ja nopeuttavat virheiden löytymistä ja niiden korjaamista mahdollisimman aikaisessa sovelluskehityksen vaiheessa ehkäisten virheiden kertymisen. Yksittäisen komponentin toimintavirheen huomaaminen yksikkötestin avulla ja sen korjaaminen on edullisempaa verrattuna siihen, että kyseinen virhe löytyisi vasta järjestelmätestauksen vaiheessa. Korkeamman tason testauksen yhteydessä löytyneen 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. 5

11 Kuva 1. Testauksen eri vaiheiden vastaavuus sovelluskehityksen eri vaiheisiin 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 komponenttien eristämistä pois testattavasta yksiköstä. Eristämällä komponentti sen ympäröivistä tekijö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 luomalla 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 paljon aikaa, jää kehittäjältä niiden suorittaminen helposti tekemättä kehitystyön ohessa. Samalla myös projektin kannalta arvokasta kehitysaikaa menee hukkaan. 6

12 Sovelluskehittäjät kirjoittavat itse yksikkötestit (Fowler, 2017). Yksikkötestien luomisajankohta suhteessa projektin eri vaiheisiin vaihtelee kehitysmalleittain. Testivetoisessa kehitysmallissa 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ä kohdista. Samalla yksikkötestejä toteutettaessa virheet huomataan yksittäistä komponenttia toteutettaessa jo hyvin varhaisessa vaiheessa. Yksikkötestit ovat helposti automatisoitavia testejä, koska niiden on tarkoitus testata sovelluksen 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äpitoa. Komponentin refaktoroinnin jälkeen sen kaikkia toiminnallisuuksia ei tarvitse testata erikseen, vaan aiemmin toteutetuilla yksikkötesteillä voidaan varmistua, että sen muiden osien toiminta on pysynyt ennallaan. Tämä mahdollistaa tehokkaamman kehitystyön, koska kehittäjien on helppo varmistua muokkaamansa komponentin virheettömästä toiminnasta Integraatiotestaus Integraatiotestien tarkoituksena on varmistaa sovelluksen eri osien toiminta yhdessä yksittäisenä komponenttina. Integraatiotestauksen on tarkoitus paljastaa virheitä komponenttien välillä, jotka eivät ole ilmenneet yksittäistä komponenttia testatessa yksikkötestein. Jos komponentit 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. 7

13 2.1.3 Järjestelmätestaus Järjestelmätestauksen tarkoituksena on testata sovelluksen toimintaa kokonaisuutena ja arvioida täyttääkö sovellus sille asetetut määrittelyt. Järjestelmätestausta on tarkoitus toteuttaa mustalaatikkotestauksena, jossa testaajilla ei ole pääsyä ohjelmakoodiin. Testauksen tarkoituksena on varmistaa sovelluksen toiminta siinä muodossaan, kuin se on tarkoitus julkaista yleiseen käyttöön. Järjestelmätestaus on testauksen tasoista laajin. (Jyväskylän yliopisto, 2017) 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äyttää käyttäjätarinoita, jotka toimivat siten myös sovelluksen dokumentaationa. Sovelluksen laadunvarmistamiseksi huolellisesti sovelluskehityksen aikana sitä varten määritellään ja toteutetaan yleensä runsaasti hyväksymistestejä. Näiden hyväksymistestien suorittaminen 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ä sovellus täyttää käyttäjän sille asettamat vaatimukset. Automaattisten hyväksymistestien avulla kyetäänkin varmistamaan sovelluskokonaisuuden toiminta useasti eri sovelluskehityksen vaiheissa ilman lisäkustannuksia Regressiotestaus Regressiotestauksella tarkoitetaan testauksen osa-aluetta, jossa sovelluksessa aikaisemmin toteutettuja osioita testataan muutosten jälkeen, vaikka niihin ei ole kohdistunut suoranaisia muutoksia (Homes, 2013). Tällä tavalla pystytään varmistamaan, etteivät muutokset ole rikkoneet 8

14 aiemmin toimivaksi todettuja kokonaisuuksia. Regressiotestauksen luonteen takia ne tulisi automatisoida 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 virhetilanteita 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 mahdollista 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 perusteella. Kun manuaalitestauksessa yksittäinen testi maksaa erikseen ja alkuinvestoinnit ovat minimaaliset, robottitestien luonti vaatii alkuinvestointeja, mutta testien ajaminen jatkossa ei nosta 9

15 kustannuksia olettaen, että testien ajoympäristöstä ei aiheudu kuluja projektille. Ketterässä sovelluskehityksessä ja DevOpsia hyödyntävissä projekteissa on yleensä käytössä jatkuvan integraation 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 esimerkiksi ketterän kehityksen iteratiivis-inkrementaalinen kehitysmalli. Iteratiivis-inkrementaalisessa kehitysmallissa sovelluksesta tuotetaan uusia versioita peräkkäisissä iteraatioissa (peräkkäisissä sykleissä), joissa jokaisessa versiossa sovellukseen lisätään uusia ominaisuuksia Testauksen yhteenlaskettu aika Automaatiotestaus Manuaalinen testaus Kuva 2. Yksittäisen automaatiotestin ja manuaalisesti suoritetun testin yhteenlaskettu aika seitsemän testin osalta. (Stamelos & Sfetsos, 2007) Kuten kuvasta 2 voidaan havaita, ovat automaatiotestejä hyödynnettäessä yksittäisen testitapauksen kustannukset alussa korkeammat kuin manuaalisen testauksen. Stameleos ja Sfetsos tuovat ketterän kehityksen laadunvarmistus-kirjassaan esille, kuinka yksittäisen automaatiotestauksen luomisajaksi voidaan olettaa keskimääräisesti noin tunti, kun taas samaan testiin voidaan 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 automaatiotestaukseen käytetyt investoinnit alkavat olla hyödyllisiä suhteessa manuaalitestaukseen neljännen testikerran jälkeen. 10

16 Yllä esitetyssä kuvassa ei huomioida eri testien vaatimuksia ympäristöltä, vaan siinä keskitytään ainoastaan yksittäiseen testitapaukseen. Kaaviossa ei ole myöskään huomioitu automaatiotestin vaatimia mahdollisia muutoksia ja ylläpitoa. Manuaalitestaus ja automaatiotestaus vaativat 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ä toiminnallisuuksista. Jotkin ominaisuudet ovat helpompia toteuttaa testattavaksi automaatiotestein, kun taas joitain ominaisuuksia ei ole mahdollista toteuttaa testattavaksi kuin ainoastaan manuaalisesti. Tämän takia sovellukset yleensä vaativat myös manuaalista testaamista automaatiotestauksen lisäksi. Kuten manuaalitestausta, myös automaatiotestausta voidaan toteuttaa usealla eri tavalla. Lähtökohtaisesti automaatiotestit vaativat kuitenkin jonkin ympäristön, jossa testejä voidaan suorittaa. Testauksen apuna voidaan käyttää myös erillistä testaustietokantaa, jolloin tiedetään aina, kuinka sovelluksen tulisi toimia. Tällöin jokaisella testin suorituskerralla sovelluksen toiminnan 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 eivä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 testien luomasta datasta. Jos sovellus käyttää ulkoisia palveluita, on automaatiotesteillä hankala varmistaa niistä riippuvien ominaisuuksien toiminta ilman, että kyseisten palveluiden palauttamia arvoja matkitaan hallitusti. Tämä voidaan toteuttaa esimerkiksi testejä varten toteutetulla palvelimella, jonka toimintaa voidaan säädellä testien vaatimalla tavalla. Nämä ovat asioita, jotka tulee ottaa huomioon automaatiotestausta ja sen budjettia suunnitellessa. On myös hyvä pyrkiä arvioimaan, mitä testausta halutaan lähteä automatisoimaan ja kuinka paljon joidenkin hankalien osuuksien automatisointi 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 11

17 varmistaa. Jokaista integraatiota varten sovellus vaatii testausta. Sovellukseen tehtävien muutosten laajuus määrittelee, kuinka paljon sovellukseen täytyy toteuttaa regressiotestausta. Varsinkin sovellukset, jotka eivät ole vahvasti tyypitettyjä eivätkä omaa edistynyttä kääntäjää, voivat 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 suureksi. 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 manuaalitestauksen jatkuvat kulut ja automaatiotestauksen alkuinvestoinnit. Automaatiotestien ajaminen sovelluskehityksen myöhemmässä vaiheessa ei enää lisää kustannuksia projektille, mutta sovelluksen jatkokehitys ja ylläpito vaativat muutoksia sovellukseen tehdyille automaatiotesteille. Sovelluskehityksen ohessa tehdyt automaatiotestit eivät ole sille enää hyödyksi, jos jatkokehitystä tehdessä testit eivät enää läpäisekään ja ne poistetaan käytöstä. Tämän takia sovelluskehityksessä 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 sovelluksen vaatimusten muuttumiset, jolloin hyväksymistestien määrittelemät toiminnallisuudet eivät enää täsmää uusiin vaatimuksiin. Toinen automaatiotestien ylläpitoon liittyvä asia on sovelluksen refaktorointi. Komponenttien vaihtaminen, ulkoisten kirjastojen päivittäminen ja nimeämiskäytäntöjen selkeyttäminen voivat vaikuttaa automaatiotestien toimintaan. Automaatiotestit eivät kykene mukautumaan muutoksiin ja vaikka sovellukseen toteutettava refaktorointi ei varsinaisesti muuttaisi sovelluksen toimintaa tai aiheuttaisi virhetilannetta sovelluksen toiminnassa, voivat automaatiotestit kuitenkin rikkoutua sovelluksen rakenteen muutoksista johtuen. Automaatiotestien vanhenemista voidaan välttää, tai ainakin vähentää, hyvällä nimeämiskäytäntöjen suunnittelulla mahdollisimman aikaisessa vaiheessa sovelluskehitystä. Myös testien suunnittelu ja toteutustavat vaikuttavat niiden kykyyn sopeutua muutoksiin. Esimerkiksi webkehityksessä monimutkaisten XPath-kaavojen (W3Schools, 2017) käyttäminen voi tehdä testistä alttiimman rikkoutumiselle. 12

18 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 onnistuneeksi tai epäonnistuneeksi. Ohjelmistorobotiikkaa ja robottitestausta voidaan toteuttaa useilla eri tavoin. Ohjelmistorobotiikassa on tarkoitus mukautua käyttäjän rooliin tehtävissä, jolloin robotilla on samat mahdollisuudet 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 robottitestausta voidaan toteuttaa. Testaussovelluksista kaupallisia versioita ovat muun muassa Automation 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 kerrotaan testivetoisesta kehitysmallista, kuinka sitä voidaan hyödyntää uusien toiminnallisuuksien kehittämiseen ja kuinka sen avulla voidaan toteuttaa refaktorointia jo olemassa olevaan sovellukseen. Samalla selvennetään, mitä käyttötapauskohtainen- ja hyväksymistestivetoinen kehittäminen tarkoittavat termeinä. 13

19 2.4.1 Testivetoinen kehittäminen Testivetoinen kehittäminen (Acharya, 2013) on ohjelmistokehitystä ohjaava kehitysmalli. Testivetoisessa kehitysmallissa sovelluskehittäjä luo ensin testin, jonka on tarkoitus epäonnistua sitä suoritettaessa. Testin suorittamisen jälkeen kehittäjän on tarkoitus kehittää toteutus vastaamaan kyseistä testiä mahdollisimman yksinkertaisesti. Kehitetyn ohjelmakoodin jälkeen kehittäjä refaktoroi kirjoittamansa koodin vastaamaan kehitystyön sanelemia periaatteita, jonka jälkeen 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. Samalla 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 luovutetaan 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 mahdollista, joskin työlästä (Stamelos & Sfetsos, 2007). Tässä tapauksessa refaktoroitavaa sovelluskoodia 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 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 sijasta kolmesta eri perspektiivistä projektissa mukana olevia henkilöitä. Näihin rooleihin kuulu- 14

20 vat käyttäjä, kehittäjä sekä testaaja, jotka toteuttavat hyväksymistestit yhdessä. Useamman roolin tuodessa oman näkökulmansa hyväksymistestien luontiin, saadaan niistä mahdollisimman kattavat ja sovelluksen vaatimukset vastaavat paremmin kaikkien sidosryhmien tarpeita. Hyväksymistestien onkin tarkoitus varmistaa, että käyttäjä pystyy tekemään haluamansa toimenpiteet sovelluksella. Hyväksymistestivetoisen kehittämisen yhteydessä puhutaan useasti myös käyttötapauskohtaisen kehittämisen mallista (Behavior driven development, BDD) (Agile Alliance, 2017). Käyttö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. 15

21 3. KEHITYSMALLIT Sovelluskehityksessä kehitysmallien tarkoituksena on tarjota jokin malli, jonka avulla sovelluskehitystä 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ärjestyksessä 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 esiteltä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 ohjelmistoprojekteissa sovelluskehitys kuitenkin muovautuu omanlaisekseen ja ottaa sille sopivimmat 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 sovelluksesta ei saada näkyvää versiota sidosryhmien tarkkailtavaksi tai testattavaksi ennen kuin projekti 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ä menossa. Vesiputousmallissa sovelluksen määrittelyt tulee olla valmiina ennen kuin projektissa siirrytään toteutusvaiheeseen. Tämä auttaa hallitsemaan projektin työmäärää ja sen arviointia, 16

22 koska sovelluksen ominaisuudet ovat tiedossa varhaisessa vaiheessa ennen toteutuksen aloitusta toisin kuin esimerkiksi ketterässä kehityksessä Testaajat vesiputousmallissa Koska vesiputousmallissa projektin eri osa-alueet eivät limity keskenään, testaajien rooli jää sovelluskehityksen loppuvaiheeseen. Tämä aiheuttaa resurssienhallinnan kannalta ongelmatilanteen, koska testaajilla ei ole mitään roolia projektissa ennen kuin projekti on edennyt testausvaiheeseen. Testauksen toteutus vasta projektin toteutusvaiheen jälkeen voi myös paljastaa virheitä, joiden korjaus toteutusvaiheen jälkeen voi olla haastavaa, aikaa vievää, sekä kallista Refaktorointi kertarysäyksellä Projektin refaktoroinnin kannalta sovellusintegraatio ja integraatiotestauksen loppuun jättäminen voivat tuottaa ongelmia. Sovelluskehykset, joita ei ole suunniteltu toimimaan yhdessä, voivat 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ä varten on hidas. Vesiputousmallissa koko sovelluskokonaisuuden toiminnasta ei voida olla varmoja kehitysvaiheessa, koska sovelluksen integraatiotestausta, järjestelmätestausta eikä hyväksymistestausta 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ä olisikaan suunniteltu muutettavan refaktorointiprosessin yhteydessä. Kertarysäyksellä toteutettavat muutostyöt pysyvät hyvin hallinnassa, eikä suunniteltuun versioon 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. 17

23 3.2 Ketterä kehitys Ketterässä kehitystyössä sovelluskehitystiimi toimii perinteisen lineaarisen mallin sijaan iteraatioissa. Ketterä kehitystyö ei itsessään ole kehitysmalli, jota mukaillen kehitystyötä toteutettaisiin, vaan kokoelma eri työskentelytapoja jotka ohjaavat kehitystä. Ketterän kehityksen perustana 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 kokoukset, 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 liittyvät ketterään kehitystyöhön Iteratiivinen ja inkrementaalinen kehitystyö Vesiputousmallissa tuotetta kehitetään yksittäisenä kokonaisuutena, kun taas ketterän kehityksen yksi pääkohdista on inkrementaalinen kehitystyö. Inkrementaalisessa kehitystyössä lopputuotteesta toteutetaan ensin minimalistinen versio ilman ylimääräisiä ominaisuuksia. Versioon sisällytetään ainoastaan sovelluksen toiminnan kannalta tärkeimmät ominaisuudet, jotta se kykenee toteuttamaan tehtävänsä. Sovelluskehityksen seuraavissa vaiheissa sovellukseen lisätään ominaisuuksia pala kerrallaan. Inkrementaalisessa kehitystyössä jokainen onnistunut versio sovelluksen 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 kehitystyö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. Esimerkiksi sovellukseen toteutetaan yksi kokonainen toiminnallisuus, joka koostuu useammasta komponentista. Komponenttien toteutuksen jälkeen yksittäistä komponenttia ryhdytään kehittämään tarkemmin ja siihen mahdollisesti lisätään ominaisuuksia, tai sen rakennetta parannellaan. Koska iteratiivinen ja inkrementaalinen kehitystyö ovat hyvin lähellä toisiaan, ovat ne 18

24 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 asiakkaan vaatimusten muutoksiin vastaaminen kuvaa erinomaisesti iteratiivista kehitystyötä Käyttäjätarinat Käyttäjätarina on tekstimuotoon kirjoitettu lyhyt kuvaus sovelluksen toiminnasta tai toiminnallisuudesta. 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ä suorittamaan 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ä sovelluksen avulla. Käyttäjätarinoiden toteutus yhdessä asiakkaan kanssa mahdollistaa paremmin haluttujen ominaisuuksien määrittelyä ja antaa kehittäjille paremman kuvan siitä, mitä asiakkaat 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 tarkoitus 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 suurempaa sovelluskokonaisuutta. Käyttäjien, sekä kehittäjien, voi olla haastavaa hahmottaa kaikkia sovelluksessa tarvittavia toimintoja ja ominaisuuksia, joilla sovelluksen käytettävyyttä pystytään parantamaan. Tästä syystä on oleellista, että aluksi käyttäjätarinat ovat laajoja ja kuvaavat suurempia kokonaisuuksia. Käyttäjätarinoiden luontivaiheen jälkeen, ennen varsinaista kehitysvaihetta, laajat käyttäjätarinat tulee ottaa uudelleen käsittelyyn ja niitä tarkennetaan tarpeen mukaan. 19

25 Käyttäjätarinoiden tarkentamista auttaa sovelluksen kehittyminen eteenpäin ja iteratiivisen kehitysmallin tuottamat versiot sovelluksesta. Asiakkaat pääsevät näkemään sovelluksesta toimivan version ja pääsevät paremmin sisälle kontekstiin ennen kuin käyttäjätarinaa ryhdytään täsmentä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 parhaan mahdollisen lopputuloksen ja tuotteen, joka vastaa mahdollisimman paljon asiakkaan tarpeita (Stamelos & Sfetsos, 2007). Käyttäjätarinoiden tulisi kuvata tarpeeksi pieniä osia sovelluksen toiminnasta, jotta niitä voidaan 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 toteuttaa 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ä osaamista 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 termeillä kaikkien osapuolten toimesta (Stamelos & Sfetsos, 2007). Käyttäjätarinoiden kirjoitusta varten on määritelty kaava, jolla ne tulisi kirjoittaa. Hyvässä käyttä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 Asiakkaana haluan pystyä ostamaan junalipun verkosta. Tällä käyttäjätarinalla kuvataan, kuinka tietyn sidosryhmän jäsen, tässä tapauksessa yrityksen asiakkaan, on mahdollista ostaa verkosta junalippu sovellusta käyttäen (Stamelos & Sfetsos, 2007). 20

26 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ömahdollisuudet. Tämä mahdollistaa eri sidosryhmien välisen kommunikoinnin ilman teknistä sanastoa 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 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 testitapauksesta, jotka voidaan todentaa hyväksymistestien avulla. Käyttäjätarinoita vastaavat hyväksymistestit tulisi suunnitella samaan aikaan kuin käyttäjätarinoita suunnitellaan. Hyväksymistestit 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 Jatkuva integraatio Jatkuvassa integraatiossa kehittäjien on tarkoitus kehittää sovellusta, tuottaen lyhyin intervallein uusia julkaistavia versioita sovelluksesta, jonka toiminnallisuudet kasvavat jokaisen integraation myötä (Hilton, et al., 2016). Jatkuvassa integraatiossa on tarkoituksena, että sovelluskehittä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. 21

27 Useiden julkaistavien versioiden ansiosta projektin hallinta helpottuu, koska projektin kunkin hetkinen tilanne on helposti havaittavissa. Myöskin sidosryhmien on helpompi havaita projektin eteneminen ja mahdollisesti projektiin käytettyjen resurssien aikaansaannokset. Ketterässä kehityksessä yhtenä pääkohdista on sovelluskehitystiimin kyky reagoida ja mukautua muuttuviin määrittelyihin. Kun sovelluksesta saadaan julkaistavia versioita ennen kuin sovelluksen kaikki toiminnallisuudet ovat valmiita, on sovellukseen mahdollista lisätä toivottavia toiminnallisuuksia tai poistaa toiminnallisuuksia, jotka vaikuttavatkin turhille, kun sovelluksen toimintaa 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ä sovelluksen koonti-tehtävä pysyy ehjänä ja kaikki sovellukseen tehdyt automaattiset hyväksymistestit 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äännö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 ylimää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 integraatioprosessit eivät kasva liian suuriksi ja niissä syntyvät ongelmat ovat helposti hallittavissa. Jokainen yhteiseen versionhallintaan tehtävä sovellusversioiden yhdistys on kaksivaiheinen. Kehittäjän on ensin päivitettävä oma versionsa ajan tasalle yhteisen sovelluskehityshaaran kanssa. 22

28 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 toiminnallisuuksia sovellukseen, jotta niiden toiminnallisuudet pystytään todentamaan jatkossa automaattisesti. Automaatiotestit osoittavat, että kehittäjän tekemät muutokset eivät ole rikkoneet muiden kehittäjien tekemiä muutoksia ja hänen omatekemänsä muutokset toimivat yhteisessä sovellusvedoksessa. Automaatiotestien suoriuduttua kehittäjä voi yhdistää omat tuotoksensa yhteiseen sovelluskehityshaaraan. Usean kehittäjän projekteissa sovelluskehityksen edetessä jatkuvasti eteenpäin, yksittäisen kehittäjän version jääminen jälkeen yhteisestä sovelluskehityshaarasta aiheuttaa useampia konflikteja versioiden välillä ja vaikeuttaa integraatiota kehittäjän oman sekä yhteisen sovellusversion kanssa (Stamelos & Sfetsos, 2007) 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ä suoranaisesti liity sovelluksen refaktorointiin. (Alliance, 2017) Päivittäiset kokoukset Päivittäisten kokousten tarkoituksena on tehdä tilannekatsaus toteutetuista tehtävistä ja varmistaa, 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 tilanteisiin, 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 sidosryhmien tarpeisiin (Stamelos & Sfetsos, 2007). 23

29 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ä hyvä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 kykenee 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ä kokouksia 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. Sovelluskehityksen alussa määritellyt tavat eivät välttämättä sovikaan sille niin hyvin kuin aikaisemmin on ajateltu. Samalla voidaan tehdä muutoksia testitapausten tai sovelluskoodin toteutuksen 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 automaattisiin testitapauksiin. 3.3 DevOps DevOps-kehitysmallin tarkoituksena on pienentää kehityksen ja tuotannon sekä ylläpidon välisiä 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- 24

30 terän kehityksen malli, DevOps ei itsessään määrittele tiukkoja suuntaviivoja, kuinka kehitystyötä tulisi tehdä, vaan sen tarkoitus on ohjata kehitystyötä tiettyyn suuntaan. DevOpsia käyttöö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 sovelluskehitysprosessiin (Swartout, 2012). DevOpsin tarkoituksena on tuoda toisiaan lähemmäksi kolme eri sovelluskehityksen osa-aluetta: kehitystyö, laadunvarmistus ja tuotanto. Nämä osa-alueet ovat vanhassa vesiputouskehitysmallissa olleet toisistaan riippuvaisia, mutta erillään toimineita kokonaisuuksia. Lyhenne Dev viittaa kehittäjiin (Developers), mutta DevOpsista puhuttaessa se käsittää myös muut henkilö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ärjestelmän ylläpitäjät, tuotantoinsinöörit, tietokantavastaavat, tietoturva-asiantuntijat sekä verkkoyhteyksien 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 toimivaksi 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 asennusta varten jokaista ympäristöä varten. Samalla myös odotteluajat näistä asennuksista saadaan poistettua. 25

31 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 yhteydessä tapahtuvat virhetilanteet voivat aiheuttaa yritykselle imagon menetyksiä tai haittoja liiketoiminnalle. Tämän takia olemassa olevaan julkiseen ympäristöön tehtävien muutosten riskien minimointi on tärkeää. Riskejä voidaan minimoida DevOps-työkaluilla, joiden avulla tuotantoon 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ärjestyksessä 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äyttöönottoon saakka. Tästä syystä eri vaiheiden toteuttaminen vaatii eri työkaluja ja ne ovatkin 26

32 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 versionhallintatyökalustaan omalla haarautumismallillaan. Eri haaroja (Branch) voidaan käyttää eri ominaisuuksien kehitykseen erillään muusta kehityksestä. DevOpsia hyödynnettäessä sovelluksen version luominen voidaan rajata ainoastaan tiettyyn haaraan tehtäviin muutoksiin. Esimerkiksi jokaisesta päähaaraan tehdystä muutoksesta voidaan automaattisesti luoda sovellusvedos muilla DevOps-työkaluilla. Tällä tavalla keskeneräiset tuotokset voidaan eriyttää omaan haaraansa 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ä konfiguraatioiden- 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ää kasaamaan, 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. 27

33 4. ESIMERKKI AUTOMATISOIDUSTA TESTAUSYMPÄRIS- TÖSTÄ Robot Framework (Framework, 2017) on avoimen lähdekoodin sovelluskehys testauksen automatisointiin 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 Frameworkin sallimat eri tavat toteuttaa testejä mahdollistavat sen hyödyntämisen eri kehitysmallien 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 ohjelmointikielillä 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ä tutkielmassa 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. 28

34 Robot Frameworkin valinnan syynä tähän tutkielmaan oli sen maksuttomuus. Myös sen käyttötarkoitus toteuttaa hyväksymistestausvetoista kehittämistä tukee tämän tutkielman toteuttamismallia. Robot Framework omaa myös laajan käyttäjäkunnan ja se on dokumentoitu kattavasti, 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 tapauksissa tarvita manuaalitestauksissa, koska ihmistestaajat kykenevät sopeutumaan tilanteisiin tai muuttamaan tilanteen vastaamaan alkuperäistä tilannetta. Alkuvalmisteluita vaaditaan kuitenkin useasti kaikkiin automaatiotestauksiin, eikä se ole sidoksissa pelkästään robottitestaukseen. Robottitestauksella toteutetut testitapaukset vaativat jonkinlaisen tavan viitata html-elementteihin 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 parantaa 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 toteuttaminen olemassa olevilla testeillä ei kustanna projektille merkittävästi enempää ja kaikki testattavissa olevat osuudet tulevat testattua. Regressiotestauksen avulla sovelluksen laatua pystytään parantamaan, koska kaikki testit voidaan suorittaa jokaisella testikierroksella hallituin kustannuksin. 29

35 4.2 Testien rakenne Robot Frameworkilla kirjoitettavat testit pohjautuvat tekstitiedostoihin kirjoitettuihin testitapauksiin, joiden toteuttaminen täsmentyy lopulta varsin tekniselle tasolle. Hyvin tekniselle tasolle 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 testien ymmärtämistä abstraktiotasojen avulla Avainsanat Robot Framework on avainsanapohjainen sovelluskehys, jonka avulla voidaan luoda uudelleenkä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-sovelluskehyksen 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 IDEAeditorilla. 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ä esimerkeissä 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. 30

36 Robot Frameworkilla toteutetut avainsanat ovat ketjutettavia. Kuten esimerkkikoodista 2 voidaan havaita, siinä käytettävä testitapaus käyttää esimerkkikoodissa 1 esitettyjä avainsanoja. Vastaavasti esimerkkikoodissa 2 esitettyä avainsanaa voidaan käyttää jatkossa uusissa testitapauksissa. Esimerkkikoodi 2. Esimerkki uudelleenkäytettävistä avainsanoista Testien abstraktiotasot Robot Frameworkin uudelleenkäytettävät avainsanat mahdollistavat testien kirjoittamisen eri abstraktiotasoille saakka. Avainsanojen korkea abstraktiotaso mahdollistaa testien kirjoittamisen helposti ymmärrettävään muotoon myös henkilöille, joilla on vähän teknistä osaamista. Kuvasta 5 voidaan nähdä, kuinka Robot Frameworkilla toteutettuja avainsanoja on ketjutettu yleisen 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 Frameworkilla toteutetut avainsanat ja siitä on jätetty pois tekniset osuudet. 31

37 Kuva 5. Robot Frameworkin avainsanojen käyttö eri abstraktiotasoilla Testijoukko Robot Frameworkin käyttöoppaan mukaan (Robot Framework, 2017) testit koostuvat testijoukoista (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 voidaan muodostaa korkeamman abstraktion tasolle luomalla kansioita ja alikansioita, joihin tiedostot lopulta sijoittuvat. 32

38 Esimerkkikoodi 3. Esimerkki Robot Frameworkilla toteutetusta testijoukosta. Esimerkkikoodista 3 voidaan nähdä esimerkki Robot Frameworkin testijoukosta. Tässä kyseisessä testijoukossa on käytetty käyttötapauskohtaista kehitysmallia testin kirjoittamiseen. Testijoukko voi myös sisältää useampia korkeamman abstraktiotason avainsanoja, jotka liittyvät samaan kokonaisuuteen. 4.3 Testien kirjoittaminen Robot Frameworkilla kirjoitettavia testejä on mahdollista toteuttaa lukuisin eri tavoin, koska lopulta yksittäinen testi testaa yksinkertaista toimintaa, esimerkiksi tekstin ilmentymistä sivulla. Tästä johtuen testien tulisi kuitenkin mukailla yhtenäistä mallia, jotta testien ylläpito, luettavuus ja toteutus olisivat helpompaa. Testien ylläpitokustannuksiin vaikuttaa niiden huolellinen suunnittelu ja toteutus. Hyvin toteutetut testit ovat helppoja ylläpitää, eivätkä ne hajoa niin helposti sovellusta refaktoroitaessa. Testien kirjoittamiseen vaikuttaa myös sovelluksen toteutustapa, jonka takia sovelluksen suunnittelussa tulisi ottaa huomioon robottitestien toteutukset Kirjoitusmalli, käyttötapauskohtainen kehitysmalli Käyttäjätarinoita mukaillen käyttötapauskohtaisella kehitysmallilla toteutetut testitapaukset on tarkoitus kirjoittaa muotoon (Robot Framework, 2017): 1. Olettaen, että (Given), 2. Silloin, kun (When) 3. Niin (Then) 33

39 Myös avainsanoja ja (and), sekä mutta (but) voidaan käyttää testitapauksia kirjoitettaessa, joiden avulla voidaan jatkaa testiä lisäämällä siihen ylimääräisiä avainsanoja. Avainsanojen tarkoituksena on toteuttaa testitapaukset luettavaan muotoon. Esimerkkikoodista 3 voidaan nähdä esimerkki yllä esitettyä mallia mukaillen kirjoitetusta testistä. Käyttötapauskohtaisen kehitysmallin hyödyntäminen testitapauksia kirjoitettaessa helpottaa testitapausten ymmärtämistä myös projektiin osallistuville henkilöille, joiden tekninen osaaminen ei välttämättä ole kovin vahvaa. Käyttötapauskohtaista kehitysmallia käytettäessä testitapauksien kirjoituksessa voidaan hyödyntää sovelluskehityksen aikaisemmassa vaiheessa toteutettuja käyttäjätarinoita, joita testit lopulta vastaavat. Tällöin käyttäjätarinoita ei varsinaisesti tarvitse kirjoittaa erikseen, vaan ne voidaan kirjoittaa suoraan testitapausmuotoon, jolloin vältytään ylimääräiseltä dokumentaatiolta. Samalla myös muutokset testitapauksiin ja käyttäjätarinoihin eivät ole keskenään ristiriidassa, vaan molemmat pysyvät samalla vaivalla ajan tasalla. Tämä kehityksen malli vaatii kaikilta projektin sidosryhmiltä käsitystä kehitysmallin toimintatavoista ja siitä, kuinka sovelluskehitystä tukevia käyttäjätarinoita tulisi kirjoittaa. Koska käyttötapausten on tarkoitus toimia myös sovelluksen määrittelyinä, on käyttötapausten kirjoittamisessa hyvä olla mukana ainakin käyttäjien edustaja. Yleensä tähän tarvitaan myös testaajien tai kehittäjien apua, jotta käyttötapauksista saadaan kehitysmallille sopivat Testien tekninen toteutus HTML-elementteihin voidaan viitata eri tavoin Robot Frameworkin testitapauksissa hyödyntäen Selenium-sovelluskehystä. Esimerkkikoodissa 4 on kaksi eri span-elementtiä, joihin voidaan viitata Robot Frameworkin avulla. Elementtiin, joka sisältää tekstin Test text1, voidaan viitata suoraan sen HTML-elementin sisältämän id:n perusteella, kuten esimerkkikoodista 5 voidaan huomata. Vastaavasti Test text 2 -tekstin sisältämään elementtiin viittaaminen ei ole yhtä yksinkertaista, koska sillä ei ole omaa yksilöllistä id:tä. Tästä syystä testiä kirjoitettaessa siihen on viitattava XPathin avulla. XPathin avulla voidaan navigoida xml-dokumentissa elementtien ja niiden attribuuttien avulla (W3Schools, 2017). XPath on kätevä työkalu, koska se ei vaadi viitattavalta elementiltä muutoksia, kuten esimerkiksi id:tä, vaan kyseiseen elementtiin viittaus voidaan tehdä suhteessa sitä ympäröiviin elementteihin. Testauksen kohteena olevalle elementille ei aina kyetä antamaan testitapausta varten haluttua id:tä, koska testiin liittyvä komponentti voi olla ulkoisesta kirjastosta. 34

40 Esimerkkikoodi 4. HTML-koodi, jossa toinen span-elementeistä omaa id:n ja toinen ei. XPath on kuitenkin virheherkempi tapa viitata elementteihin verrattuna siihen, että niillä olisi omat id:t. Esimerkiksi, jos esimerkkikoodissa 4 esitettyjen span-elementtien väliin lisättäisiin kolmas elementti, ei jälkimmäiseen elementtiin tehty XPath-viittaus enää toimisi. Vastaavasti id:n omaavaa elementtiä voidaan siirtää ympäri sovellusta ilman, että siihen tehdyt viittaukset rikkoutuvat. Esimerkkikoodissa 5 alempi viittaus on toteutettu XPathin avulla. Esimerkkikoodista 5 voidaan samalla havaita, kuinka XPathilla toteutettu viittaus on riippuvainen HTMLtiedoston rakenteesta aina ensimmäiseen HTML-elementtiin saakka. Esimerkkikoodi 5. Id:n sekä XPathin avulla toteutetut viittaukset Robot Frameworkiin toteutetussa avainsanassa 35

41 5. SOVELLUSKEHYKSEN VAIHTO HYÖDYNTÄEN OHJEL- MISTOROBOTIIKKAA Web-sovelluskehityksessä JavaScript-sovelluskehykset ovat saavuttaneet viime aikoina entistä enemmän suosiota. Samalla myös sovelluskehykset ovat kehittyneet valtavasti ja tarjoavat tehokkaampia mahdollisuuksia toteuttaa sovelluksia. Samalla kun sovelluskehykset kehittyvät kiihtyvällä tahdilla ja tarjoavat mahdollisuuksia tehokkaampaan kokonaisvaltaiseen sovelluskehitykseen, aikaisemmin toteutettujen sovellusten tekniikat vanhenevat eikä niissä kyetä hyödyntämään viimeisimpiä ominaisuuksia tai niiden ylläpitokustannukset ovat suuremmat verrattuna uusiin sovelluksiin. Sovelluskehykset tarjoavat eri asteisia uusia versioita ja versiot, jotka sisältävät rikkovia muutoksia sovelluskehykseen kyetään yleensä rajaamaan helposti. Esimerkiksi Angular-sovelluskehys käyttää semanttista versionumerointia, jonka avulla voidaan erotella bugikorjaukset, uudet ominaisuudet ja rikkovat muutokset (Minar, 2017). Semanttisessa versioinnissa käytetään kolmea versionumeroa, joista ensimmäinen kuvaa versioiden yhteensopivuutta, toinen numero kuvaa uusia ominaisuuksia ja kolmas numero kuvaa bugikorjauksia. Semanttista versiointia käyttävä julkaisu siis on yhteensopiva versioiden ja välillä, mutta ei välttämättä versioiden ja välillä. Kuva 6. Havainnekuva semanttisesta versioinnista 36

42 Ulkoisten kirjastojen yhteensopivuudet ja JavaScript-kielestä puuttuva vahva tyypitys kasvattavat riskiä ongelmien ilmenemiselle kirjastojen ja sovelluskehysten vaihtoa suoritettaessa. Ulkoiset kirjastot eivät välttämättä osaa ottaa kantaa kaikkiin riippuvuuksiin kolmansista kirjastoista tai itse hallitsevasta sovelluskehyksestä. Sovelluskirjastojen välille syntyvien riippuvuuksien hallintaa helpottaa moduulirakenne, jonka avulla kyetään määrittämään moduulin vaatimat versiot muista sovelluskehyksistä. Tässä tutkielmassa esitetyssä projektissa toteutetun refaktoroinnin tarkoituksena on muokata vanhalla sovelluskehyksellä toteutetut komponentit uudelleen toteutetuksi uudella sovelluskehyksellä. Uuden sovelluskehyksen tarkoituksena on tuoda hyviä puolia sovelluksen ylläpitoa ja jatkokehitystä varten. Samalla sovelluskehyksen vaihdoksen on tarkoitus nopeuttaa sovelluksen toimintaa pala palalta uuden sovelluskehyksen paremman suorituskyvyn ansiosta. Tämän avulla käyttäjälle kyetään tarjoamaan parempi käyttökokemus. Tässä luvussa käydään läpi, kuinka ohjelmistorobotiikkaa kyetään hyödyntämään web-sovellukseen toteutettavassa sovelluskehyksen versionvaihdoksessa parantaen sovelluksen laatua ja helpottamaan sovelluksen julkaisua. 5.1 Alkuvaatimukset Ohjelmistorobotiikan hyödyntäminen sovelluskehyksen versionvaihdoksessa vaatii projektilta valmistautumista ja valmiutta sen käyttöönottoon. Jotta automaattisia hyväksymistestejä voidaan hyödyntää, projektin tulee olla jatkuvan integraation alaisena tai projekti tulee tuoda jatkuvan integraation alaiseksi ohjelmistorobotiikkaa käyttöönotettaessa. Robottitestausta voidaan hyödyntää lähes missä tahansa projektissa. Robottitestauksen suurimmat hyödyt saadaan kuitenkin ketterästä kehityksestä, jossa suurin osa kehitystyöstä tehdään mukaillen iteratiivisinkrementaalista kehitysmallia. Iteratiivisessa kehitystyössä tapahtuva jatkuva uusien ominaisuuksien ja muutosten määrä kasvattaa regressiotestauksen määrää, jonka kustannuksia voidaan hillitä testauksen automatisoinnilla. 37

43 5.2 Projektin esittely Tässä tutkielmassa käytetään esimerkkinä projektia, joka on valmis tuote ja ollut reilun vuoden verran tuotannossa. Sovelluksen tuotannossa olon aikana siihen on tehty muutamia pieniä muutoksia ja virheiden korjauksia. Suurempia muutoksia sovellukseen ei ole toteutettu. Sovellukseen tehdyt muutokset on testattu manuaalisesti, eikä sovelluksessa ole juurikaan aikaisempia hyväksymistestejä. Aikaisemman sovelluskehityksen aikana sovelluksen käyttöliittymää varten on tehty muutamia yksikkötestejä. Pääpiirteissään sovelluksen tarkoituksena on ainoastaan esittää kaikille julkista tietoa. Sovelluksessa ei ole autentikointia, eikä sillä pystytä tallentamaan tietoa minnekään. Nämä asiat on hyvä ottaa huomioon työmäärää arvioidessa, koska ne yksinkertaistavat testausta merkittävästi suhteessa sovellukseen, jossa kyseiset ominaisuudet ovat ja käsiteltävä tieto on salaista tai yksilöityä. Projektista on tarkoitus saada yksi tai useampi tuotantoversio, jossa molemmat sovelluskehykset ovat yhtäaikaisesti toiminnassa. Koska kyseessä on responsiivinen sovellus, jota on tarkoitus pystyä käyttämään yhtä hyvin mobiililaitteilla, kuin myös suurempinäyttöisillä laitteilla, on sovelluksen käyttöliittymäkoodin paketin koolla merkitystä. Heikolla internet-yhteydellä sovellusta käytettäessä sovelluksen lataukseen voi mennä turhan paljon aikaa sovelluspaketin ollessa suuri. Tämä tulee ottaa huomioon sovelluksen tuotantoon vientiä suunnitellessa, koska se tarvitsee toimiakseen kahden eri sovelluskehyksen kirjastot. Samalla myös ulkoiset riippuvuudet, jotka ovat sidoksissa tiettyyn sovelluskehykseen, tuovat lisää kirjastoja, jotka selaimen täytyy ladata käyttöönsä sovellusta esitettäessä. Nämä kompromissit ollaan kuitenkin valmiita tekemään, koska Angular omaa paremman suorituskyvyn suhteessa vanhaan AngularJS-sovelluskehykseen (Peyrott, 2017). Projektin palvelin on toteutettu hyödyntäen REST-arkkitehtuurimallia (w3, 2004). Tässä työssä emme kuitenkaan keskity muuhun kuin sovelluksen käyttöliittymän refaktorointiin ja testaukseen. Kyseisellä arkkitehtuurimallilla toteutettu sovellus sopii hyvin käyttöliittymässä tehtävään suurimittaiseenkin refaktorointiin, koska palvelin ja käyttöliittymä eivät ole riippuvaisia toisistaan muuten kuin rajapinnan kautta. 38

44 5.3 Projektin teknologiat Sovellus on toteutettu AngularJS-sovelluskehyksen versiolla Sovelluksen versio on merkittävä, koska version 1.5.x jälkeisissä versioissa AngularJS-sovelluskehystä alettiin valmistella jo siirtymistä Angular-sovelluskehyksen uuteen versioon. Näistä ominaisuuksista yksi suurimmista on komponenttirakenne, joka on vahvasti esillä Angular-sovelluskehyksessä (Google, 2016). Vaikka Angular- ja AngularJS-sovelluskehysten ekosysteemit ja arkkitehtuuri eroavat toisistaan merkittävästi, on Angular toteutettu niin, että ne kykenevät toimimaan sujuvasti keskenään. Tämä on mahdollista sen ansiosta, että Angular-sovelluskirjasto sisältää Angular/Upgrade-moduulin, jonka avulla sovelluksen eri osa-alueet kykenevät kommunikoimaan keskenään, vaikka ne olisi tehty eri sovelluskehyksen versioilla. Eri sovelluskehysten toiminta samanaikaisesti mahdollistetaan niin, että Angular-sovelluskehyksen Upgrade-moduuli kääntää komponentit ja palvelut vanhan AngularJS-sovelluskehyksen tukemaan muotoon (Google, 2017). Sovelluskehysten yhtäaikainen toiminta mahdollistaa sovelluksen refaktoroinnin iteratiivisen kehityksen mallilla. Ketterän kehityksen mallilla, erityisesti iteratiivisen kehityksen, sekä jatkuvan integraation mahdollistamana kehitystiimillä on sovelluksesta koko refaktorointiprosessin ajan toimiva versio. Koska kehitystiimillä on olemassa sovelluksesta jatkuvasti toimiva versio, on se mahdollista viedä tuotantoon saakka hyvinkin nopealla aikataululla ja näin toteutetut muutokset saadaan nopeasti käyttöön. Koska sovelluskehyksen versionvaihdosta ei tarvita tehdä kertarysäyksellä (Big bang), on mahdollista, että vain sovelluksen yksi osa-alue refaktoroidaan toteutetuksi uudella sovelluskehyksellä. Muut osat voidaan toteuttaa myöhemmin tai jättää kokonaan toteuttamatta. Tämä pienentää riskiä, jossa projektin refaktorointiin budjetoidut rahat loppuvat kesken pitkittyneen projektin takia ja koko refaktorointiprosessin aikaansaannokset menevät hukkaan. On myös mahdollista, että jotkin sovellukseen toteutettavat osa-alueet ovat lähes mahdottomia toteuttaa vanhalla sovelluskehyksellä, joten ne voidaan toteuttaa uudella sovelluskehyksellä olemassa olevan sovelluskoodin sekaan sen sijaan, että koko sovellus tulisi kirjoittaa uudelleen. 39

45 5.4 Projektin koonti Vanhassa sovellusversiossa sovelluksen ohjelmakoodien kääntäminen tarvittavaan tiedostomuotoon sekä ohjelmakoodien koostaminen tapahtuu Gulp-taskrunneria käyttäen. Gulp on Node.js-ympäristössä ajettava sovelluskirjasto, jolla pystytään ajamaan haluttuja tehtäviä automaattisesti. Tässä tutkielmassa esitellyssä projektissa Gulpin tehtävänä on kääntää Jade- ja Stylus-kielillä kirjoitetut ohjelmakoodit HTML- ja CSS-tiedostomuotoihin sekä yhdistää JavaScript-koodit haluttuihin kokonaisuuksiinsa. Gulpin toteuttamat tehtävät ajetaan aina kehittäjien toteuttamien muutosten jälkeen, jotta tehdyt muutokset näkyvät välittömästi selaimessa. Muutosten jälkeiset tehtävät ajetaan Gulpin toimesta automaattisesti. Gulpia hyödynnetään myös sovelluksesta toteutettavan tuotantoversion luonnissa. Jatkuvan integraation palvelimella ajettavat Gulp-tehtävät toteuttavat sovelluskoodin käännösten ja paketoinnin lisäksi myös optimointia sovelluskoodille kommenttien poiston sekä koodin minimoinnin osalta. Projektiin toteutettavan refaktoroinnin yhteydessä siihen käyttöönotettavan Angular-sovelluskehyksen suosittelemana projektissa otetaan käyttöön Webpack-työkalu korvaamaan Gulpin vanhassa sovelluskehitysympäristössä toteuttamia tehtäviä. Webpack-työkalun vaihdokseen vaikuttaa myös sen käytön yleistyminen ja liitännäisten saatavuus. Projektiin toteutettavan refaktoroinnin ja hybridisovelluksen luonteen takia sovelluskehityksen aikana sovelluskoodissa tulee olemaan useilla eri kielillä toteutettua sovelluskoodia. JavaScript-tiedostot päivittyvät Typescriptillä toteutetuiksi tiedostoiksi ja Jade-kielellä kirjoitetut tiedostot päivittyvät Pug-tiedostoiksi. Jaden päivitys tapahtuu pääasiassa kielen lisensointiongelman takia (pugjs, 2017). Nimen vaihdoksen johdosta koodin syntaksi pysyy lähes samana kuin aiemmin, mutta vaihdos sisältää kuitenkin rikkovia muutoksia. Ohjelmointikielten sekä sovelluskehysten muutosten takia vanhat Gulpilla toteutetut tehtävät eivät enää vastaa sovelluskehityksen tarpeita, vaan niihin tarvittaisiin muutoksia. Vanhat tehtävät kyettäisiin toteuttamaan myös Webpackilla, mutta tässä tapauksessa päädyttiin käyttämään molempia työkaluja samanaikaisesti ajamaan omia tehtäviään. Gulpin toteuttamat paketit yhdistetään Webpackin tehtävissä yhteiseen sovelluspakettiin. Tällä tavalla toteutettuna säästytään ylimääräiseltä työltä ja testaukselta, jota uusien ja lopulta turhaksi jäävien tehtävien toteuttaminen aiheuttaisi uuden Webpack-työkalun käyttöönotolle. 40

46 5.5 Työmäärät Sovelluskehityksessä työmäärien arviointiin on useita erilaisia tapoja. Ketterän kehitysmallin mukanaan tuomat käyttäjätarinat mahdollistavat työmäärän arvioinnin niiden avulla. Perinteinen tapa arvioida työmääriä on käyttää aikamääreitä yksittäisten tehtävien työmäärän arviointiin. Aikamääreitä käyttäessä on kuitenkin omat ongelmansa liittyen muun muassa muihin työtehtäviin ja kyseisen tehtävän muuttuviin vaatimuksiin. Dan Radigan esittää Atlassianille kirjoittamassaan blogissa (Radigan, 2017), kuinka käyttäjätarinoiden työmäärää voidaan arvioida ketterässä kehityksessä tarinapisteiden avulla. Työmäärää arvioitaessa käyttäjätarina voidaan pilkkoa tehtäviin, joiden työmäärää voidaan suhteuttaa toisiinsa tarinapisteiden avulla. Tehtävien painoarvoa voidaan tarkentaa tulevissa sprinteissä, jolloin työmääräarviot tarkentuvat. Samalla kehitystiimille selvenee myös se, minkä määrän tarinapisteitä tiimi kykenee toteuttamaan yhdessä sprintissä. Työmäärää arvioitaessa on myös muitakin keinoja, kuten esimerkiksi toimintopisteanalyysi, jossa työmäärää arvioidaan toimintojen vaikeusasteella ja määrällä suhteutettuna aikaisempiin vastaaviin toteutuksiin (Alarakkola, 2012). Työmäärän kokonaisvaltaista arviointia hankaloittaa se, ettei sovelluskehyksiä ole yleensä tarkoitettu toimimaan keskenään. Kahden eri sovelluskehyksen yhtäaikainen toiminta voi johtaa olettamattomiin virhetilanteisiin ja mahdollisesti myös pattitilanteeseen, jossa kyseiset sovelluskehykset eivät vain kykene toimimaan keskenään toisen estäessä toisen toiminnan. Esimerkkiprojektin tapauksessa lähtökohtana toimii AngularJS-sovelluskehys, jonka uusi versio, Angular, on toteutettu niin, että se kykenee toimimaan vanhan AngularJS-sovelluskehyksen kanssa. Tämä helpottaa työmäärän arviointia, koska Angular-sovelluskehys on kehitetty toimimaan yhdessä AngularJS-sovelluskehyksen kanssa. Tähän lisähelpotusta tuo se, että Angular-sovelluskehitystiimi tarjoaa dokumentaatiossaan ohjeet migraatiopolulle AngularJS-sovelluskehyksestä Angular-sovelluskehykseen (Google, 2017). 41

47 5.6 Testien suunnittelu ja toteutus Sovelluksessa ei ole aikaisempia hyväksymistestejä, eikä myöskään käyttäjätarinoita aikaisemman sovelluskehityksen tukena. Kuten ketterässä sovelluskehityksessä on tapana, tässä tapauksessa versionvaihdosta toteutettaessa on tarkoitus hyödyntää käyttäjätarinoita, joiden perusteella hyväksymistestit suunnitellaan. Hyväksymistestien suunnittelussa on hyvä ottaa huomioon niiden käyttötarkoitus. Tässä tapauksessa hyväksymistestien tarkoituksena on varmistaa sovelluksen toiminta ennen versionvaihdosta, sen aikana sekä myös sen jälkeen. Tällöin testien suunnittelussa tulee ottaa huomioon, että ne ovat mahdollisimman vähän sidoksissa alkuperäisen sovelluskehyksen tuottamiin rajoitteisiin tai sen vaatimiin ylimääräisiin komponentteihin. Hyvillä testien suunnitteluilla pystytään minimoimaan itse testien uudelleenkirjoittamisesta seuraava työmäärän lisääntyminen sekä koodin uudelleenkirjoituksesta johtuva testien vanhentuminen. Vaikka testit olisi suunniteltu etukäteen hyvin versionvaihdosta silmällä pitäen, on todennäköistä, että osa sovelluksen hyväksymistesteistä tulee vaatimaan uudelleenkirjoitusta. Tämä johtuu siitä, että sovelluskehystä vaihdettaessa teknisellä tasolla elementtien käsittely ja esitys saattavat erota toisistaan. Tätä esimerkkisovellusta varten toteutetut testit on toteutettu Robot Frameworkin avulla, joka lopulta käyttää Seleniumia testatakseen sovellusta. Selenium käyttää HTML-elementtien luokkia (class) ja tunnisteita (id) löytääkseen HTML-elementtejä. Seleniumilla on mahdollista tehdä myös elementtien etsimistä XPathin avulla, jolloin se etsii HTML -elementtejä dokumentin puusta käymällä puuta läpi sille asetettujen ohjeiden mukaisesti. Dokumentin puurakenne voi kuitenkin muuttua ja tällöin testille asetetut ohjeet eivät enää pidä paikkaansa ja testit epäonnistuvat. Yleisesti XPathia joudutaan käyttämään sellaisissa tapauksissa, joissa elementeille ei ole mahdollista antaa tunnistetta. Tällaisia tapauksia tulee usein eteen käytettäessä ulkoisia kirjastoja, koska niihin tehtävät muutokset eivät ole järkeviä. Koska tässä kyseisessä projektissa toteutettava versionvaihdos muuttaa koko sovelluksen ekosysteemiä, vaatii se myös muutoksia ulkoisiin kirjastoihin. Tästä johtuen on hyvin todennäköistä, että XPathilla toteutetut testit eivät enää läpäise testejä. Esimerkkikoodi 5. XPathilla toteutettu elementin klikkaus. Klikkaus tehdään suhteessa lower-navigation -tunnisteella olevaan elementtiin. 42

48 5.7 Versionvaihdos hyödyntäen hyväksymistestausvetoista kehitysmallia Olemassa olevaan projektiin toteutettava sovelluskehyksen versionvaihdos on projektin osalta suuri muutos ja se tulee toteuttaa perustellusti. Kun projektin muutoksesta uuteen sovelluskehykseen ollaan varmistuttu, tulee sen budjetti ja aikataulut suunnitella realistisiksi, jottei muutosprosessi jää kesken ja käytetyt resurssit on hukattu. Stamelos ja Sfetsosin mukaan olemassa olevan sovelluksen tuonti testivetoisen kehitysmallin alaiseksi tulisi tehdä pienissä osissa (Stamelos & Sfetsos, 2007). Tästä syystä iteratiivinen kehitysmalli sopii hyvin asteittaiseen refaktorointiin, jota toteutetaan testivetoista kehitysmallia myötäillen. Tässä tutkielmassa esitetään malli, jossa mukaillaan ketteriä kehitysmenetelmiä ja refaktoroidaan sovellusta asteittain uuteen sovelluskehykseen. Samalla myös luodaan sovelluksesta käyttäjätarinat, jotka toimivat päivitettynä dokumentaationa sovelluksesta ja tarjoavat mahdollisuuden luoda robottitestaukselle käyttäjätarinoihin perustuvia hyväksymistestejä. Käyttäjätarinat voidaan kirjoittaa suoraan Robot Frameworkin tiedostoihin testien vaatimaan muotoon, joista ne voidaan johtaa lopulta tekniselle tasolle varsinaisiksi testeiksi. Testien kirjoittaminen erilliseen sijaintiin hankaloittaa käyttäjätarinoiden ylläpitämistä, koska muutokset täytyy toteuttaa useampaan paikkaan. Kuvasta 6 voidaan nähdä, kuinka sovelluksen iteratiivinen muutosprosessi tapahtuu aina komponentin valinnasta tuotantovalmiiseen versioon saakka. Jokaisen iteraation on tarkoitus olla kooltaan helposti hallittavissa ja jokaisen iteraation jälkeen sovelluksesta on tarkoitus olla tuotantovalmis versio. Näin sovellus on koko refaktorointiprosessin ajan kykenevä tuotantoon vientiä varten. 43

49 Kuva 7. Sovelluksen refaktorointi hyödyntäen iteratiivisen kehityksen mallia Refaktoroitavan komponentin valinta Iteratiivis-inkrementaalisessa versionvaihdoksessa muokattavan komponentin tai kokonaisuuden rajaaminen voidaan toteuttaa usein eri tavoin. Sovellukseen toteutettava uusi toiminnallisuus voidaan valita toteutettavaksi uudella sovelluskehyksellä. Uuden komponentin tai osion toteuttaminen sovellukseen ei varsinaisesti ole refaktorointia, vaan jo olemassa olevan sovelluksen jatkokehitystä. Tässä tutkielmassa esitetyt refaktorointia tukevat eri osa-alueet auttavat myös sovelluksen jatkokehityksessä. Jos lisättävä toiminnallisuus liittyy johonkin olemassa olevaan käyttäjätarinaan, täytyy kyseistä käyttäjätarinaa muokata. Samalla voidaan refaktoroida myös muut käyttäjätarinaa koskevat 44

50 osiot sovelluksesta. Jos sovelluksessa ei ole aikaisemmin toteutettuja käyttäjätarinoita, voidaan kyseisestä toiminnallisuudesta toteuttaa käyttäjätarina vastaamaan uutta toiminnallisuutta. Samalla saadaan dokumentoitua sovellukseen toteutettava toiminnallisuus. Kokonaisvaltaista refaktorointia toteutettaessa sovelluksen refaktorointia voidaan toteuttaa yksi käyttäjätarina kerrallaan. Toteutettavien käyttäjätarinoiden järjestystä voidaan priorisoida käyttäjätarinan tärkeyden ja uuden sovelluskehyksen tuomien etujen perusteella. Esimerkiksi uusi sovelluskehys voi tuoda uuden ominaisuuden sovellukseen tai parantaa jo olemassa olevan toiminnallisuuden toimintaa parantamalla sen suorituskykyä. Tässä tutkielmassa käytetyn esimerkkisovelluksen aikaisemmassa kehitystyössä ei ole käytetty käyttäjätarinoita, joten tätä tutkielmaa varten ne täytyi suunnitella ja luoda. Kahden eri sovelluskehyksen toimiessa saumattomasti yhteen, ei sovellukseen aikaisemmin toteutetut komponentit ja palvelut välttämättä tarvitse muutoksia. Olemassa olevaan sovellukseen voidaan lisätä uusi toiminnallisuus tai toteuttaa vanha toiminnallisuus uudella sovelluskehyksellä hyödyntäen jo olemassa olevia palveluita sekä tukevia komponentteja. Käyttäjätarinat toimivat hyvin apuna refaktoroitavan kokonaisuuden rajaamisessa. Samoin, kuin testivetoisessa kehitysmallissa kehittäjä tekee testit, jotka epäonnistuvat. Tämän jälkeen kehittäjä kirjoittaa sovelluskoodin, jotta testit läpäisevät. Refaktoroitaessa sovellusta, refaktoroitavan koodin määrä helposti laajenee liian suureksi ja ulottuu alkuperäisiä suunnitelmia kauemmas. Refaktoroinnin rajaus yksittäiseen käyttäjätarinaan rajaa toteutettavan refaktoroinnin määrän selkeäksi ja helposti hallittavaksi kokonaisuudeksi Hyväksymistestien luonti Sovelluksen refaktorointiprosessin onnistumisessa suuressa roolissa ovat suojakeinot, joiden avulla kyetään varmistamaan refaktoroinnin aikaansaannokset. Suojakeinojen avulla voidaan varmistua, ettei refaktoroinnin myötä ole rikottu ennalta määriteltyjä käyttötapauksia, jotka on toteutettu aiemmin sovellukseen, eikä sovelluksessa myöskään ilmene uusia virheitä, jotka johtuisivat refaktorointiprosessista (Alliance, 2017). Tässä tutkielmassa esitetyssä projektissa refaktoroinnin suojakeinoina laadun varmistamiseksi käytetään automaattisia yksikkötestejä sekä robottitestausta. Jotta hyväksymistesteistä olisi hyötyä refaktorointiprosessin aikana, tulisi hy- 45

51 väksymistestit olla valmiina ennen refaktorointiprosessin aloittamista. Jos sovelluksessa on olemassa vanhat hyväksymistestit, tulisi refaktorointiprosessia aloitettaessa tarkastaa, että sovellus läpäisee ne. Puutteelliset hyväksymistestit tulisi korjata ennen refaktoroinnin alkua. Tässä tutkielmassa toteutuksen alla olevan esimerkkiprojektin hyväksymistestit on tarkoitus toteuttaa Robot Frameworkin avulla. Robot Frameworkin avulla hyväksymistestejä voidaan tehdä monella eri tavalla, mutta tässä esimerkkiprojektin tapauksessa tarkoituksena on seurata aikaisemmassa vaiheessa toteutettuja käyttäjätarinoita, joiden perusteella testit toteutetaan ylemmän tason avainsanoiksi, joita täsmennetään tarkemmalle tekniselle tasolle. Hyväksymistestejä luodessa kehittäjillä on tiedossa, että niitä tullaan käyttämään sovelluksen muutosprosessin tukena. Tästä syystä testejä suunnitellessa ja toteutettaessa tulisi ottaa huomioon, kuinka niistä saadaan mahdollisimman vähän riippuvaisia vanhaan sovelluskehykseen nähden. Vanhaan sovelluskehykseen tukeutuvat riippuvaisuudet aiheuttavat testien rikkoutumista ja niiden korjausta refaktoroinnin jälkeen. Hyvien testien kirjoittaminen esimerkiksi Robot Frameworkin avulla vaatii yhteistyötä myös sovelluskehityksen osalta, mutta tässä tapauksessa tulee ottaa huomioon, mitä muutoksia on järkevää tehdä sovellukseen, jotta niitä voidaan hyödyntää myös sovelluksen refaktoroinnin jälkeen Refaktorointi Refaktoroinnilla yleensä tarkoitetaan sovelluskoodin selventämistä ja sen toteutuksen yksinkertaistamista (Stamelos & Sfetsos, 2007). Mahdollisesti voidaan myös pyrkiä karsimaan ylimääräistä koodia ja luomaan yhteiskäyttöisiä osioita sovellukseen. Refaktoroinnin tarkoituksena ei siis ole toteuttaa uusia toiminnallisuuksia sovellukseen. Tässä tutkielmassa refaktoroinnilla viitataan sovelluskehyksen versionvaihdokseen, jota toteutetaan jo olemassa olevaan sovellukseen. Vaikka refaktoroinnin tarkoituksena ei ole toteuttaa uutta toiminnallisuutta sovellukseen eikä muuttaa jo olemassa olevaa toteutusta, sovelluskehystä vaihdettaessa ei tähän välttämättä kyetä. Tietyissä tilanteissa voi olla järkevämpää toteuttaa vanha toiminnallisuus eri tavalla muutettaessa uuteen sovelluskehykseen. Joissain tilanteissa vanhan toiminnallisuuden toteutus voi olla myös mahdotonta toteuttaa mukailemalla vanhaa mallia. Tästä huolimatta tässä tutkielmassa sovelluskehyksen versionvaihdoksesta puhu- 46

52 taan refaktoroinnista, koska perustarkoituksena on sovelluksen toiminnan nopeuttaminen ja sovelluskoodin tuominen ylläpidettävämpään muotoon. Tämä mahdollistetaan uuden sovelluskehyksen tarjoamilla työkaluilla ja uudella arkkitehtuurimallilla. Sovellusta refaktoroitaessa tulisi refaktorointia pyrkiä pilkkomaan pieniin palasiin, jotka ovat mielekkäitä toteuttaa ja ovat helposti hallittavissa (Stamelos & Sfetsos, 2007). Tällä mallilla toteutettu refaktorointi tukee myös hyvin iteratiivista kehitysmallia, jolloin pienet refaktoroidut kokonaisuudet on helppo yhdistää versionhallinnassa olevaan yhteiseen sovelluskehityshaaraan ja saada uudet toiminnallisuudet ja refaktoroidut komponentit nopeasti käyttöön. Tutkielmassa käytetyn esimerkkiprojektin toiminnallisuudet ovat melko pieniä, jonka ansiosta refaktorointiprosessin uusia aikaansaannoksia saadaan sidosryhmien nähtäville lyhyin intervallein. Komponentin refaktorointiprosessiin vaikuttaa aikaisempi toteutus samoin kuin myös se, millainen komponentti itsessään on. Jos sovellus on aikaisemmin toteutettu mukaillen komponenttiarkkitehtuuria, on sovelluksessa käytettävien komponenttien vaihtaminen helpompaa verrattuna siihen, että sovelluksen eri osa-alueet olisi toteutettu ilman sitä. Komponenttiarkkitehtuurilla toteutetut sovellukset rajaavat muokattavaa kokonaisuutta jo itsessään komponenttikohtaisesti, joka helpottaa muutosten tekemistä. Tutkielmassa käytetyn esimerkkiprojektin toteutuksessa ei aikaisemmassa toteutusvaiheessa ole hyödynnetty komponenttiarkkitehtuuria. Tämä omalta osaltaan vaikeuttaa refaktoroitavan kokonaisuuden rajausta, koska yksittäiseen käyttäjätarinaan liittyviä osioita ulottuu selvästi kyseisen käyttäjätarinan ulkopuolelle. Nämä tapaukset ovat kuitenkin vähäisiä ja pääasiassa sovellus on toteutettu helposti pilkottaviin osiin. Refaktorointia helpottaa myös Angular- ja AngularJS-sovelluskehysten hyvä yhteensopivuus, jonka avulla sovelluskehyksiä voidaan käyttää limittäin ja ristikkäisyydet sovellusosioiden välillä eivät ole ongelma. Refaktoroinnin yhteydessä on tärkeää pystyä palaamaan taaksepäin viimeisimpään toimivaan versioon (Stamelos & Sfetsos, 2007). Tällä tavalla pystytään varmistamaan, ettei vanhaa toiminnallisuutta tarvita toteuttaa uudelleen, jos uudella tavalla toteutettuna sovellus ei toimikaan halutulla tavalla tai sen toteuttaminen osoittautuu liian työlääksi. Esimerkiksi uudella sovelluskehyksellä toteutettuna jonkin osuuden suorituskyky voi laskea dramaattisesti hybridisovelluksessa. Tällöin on järkevämpää odottaa, että sovelluksen muut osa-alueet ovat refaktoroitu uuteen sovelluskehykseen ennen, kuin kyseinen osio otetaan käyttöön. Tärkeiden, ja useista läh- 47

53 teistä käytettävien, osioiden refaktorointi vaikuttaa suureen osaan sovellusta. Samalla refaktoroitaessa on myös mahdollista rikkoa monia osioita sovelluksesta huomaten, ettei jokin osio toimikkaan johtuen uudelleen refaktoroidusta komponentista. Tällöin on hyvä olla mahdollisuus palata taaksepäin versioinnissa. Tutkielmassa käytetyssä esimerkkisovelluksessa tätä varten käytetään GIT-versionhallintaa. Refaktorointiprosessin onnistumisen varmistamiseksi on eri keinoja, joihin kuuluvat muun muassa yksikkötestit ja automatisoidut hyväksymistestit (Alliance, 2017). Nämä varmistukset voidaan toteuttaa esimerkiksi hyödyntäen eri DevOps-työkaluja tavallisen sovelluskehityksen ohella. Refaktorointia varten toteutetut varmistukset helpottavat kehittäjien työskentelyä heidän tehdessään laajempia muutoksia sovelluskoodiin, jotka vaikuttavat suureen osaan sovellusta. Yksittäisen komponentin refaktorointi voi vaatia muutoksia useampaan osioon sovelluskoodissa. Samalla myös useat tiedostot vaativat muutoksia. Samassa projektissa toimivat eri kehittäjät saattavat tehdä muutoksia samoihin tiedostoihin, jolloin kehittäjän omaa tuotosta yhdistettäessä versionhallintaan törmätään useinkin konflikteihin. Konfliktit ovat useasti helposti ratkaistavissa, mutta konfliktien kasautuessa niiden selvittämiseen kuluu yhä enemmän aikaa (Stamelos & Sfetsos, 2007). Jatkuvan integraation hyödyntäminen sovelluskehityksessä pienentää konfliktien määrää ja niiden selvittämisen vaikeusastetta, koska jokaisella kehittäjällä on sovelluksesta versio, joka on mahdollisimman lähellä muiden kehittäjien tekemiä muutoksia. Tässä tutkielmassa käytetyn esimerkkisovelluksen toteutuksessa kehittäjätiimi oli erittäin pieni, ainoastaan kaksi henkilöä, joilla molemmilla oli selvät roolit projektin toteutuksessa. Tästä syystä projektin aikana ei juurikaan syntynyt mitään konflikteja versionhallinnassa. Suuremmissa projekteissa versioiden ylläpitämisen tärkeys korostuu entisestään Integrointi Tässä tutkielmassa integraatiovaiheeseen liittyy kehittäjän tekemien muutosten yhdistäminen olemassa olevaan sovelluskoodiin yhteisessä versionhallinnassa sekä koodiin tehtyjen muutosten yhteensopivuuden varmistus. Tämä sisältää hyväksymistestien suorittamisen ja niiden mahdollisen korjaamisen. 48

54 Jotta refaktorointiprosessin aikaansaannosten aiheuttamat muutokset sovellukseen kyetään varmistamaan, tulee kehittäjien varmistaa sovelluksen hyväksymistestien läpäiseminen. Kehittäjän refaktoroitua rajattu kokonaisuus, on hyvin todennäköistä, etteivät kaikki hyväksymistestit enää läpäise. Hyvin suunniteltujen ja toteutettujen hyväksymistestien tulisi suoriutua mahdollisimman hyvin myös uuden sovelluskehyksen kanssa, mutta muutokset ovat usein välttämättömiä. Kun kehittäjä on toteuttanut halutut muutokset sovellukseen, on hänen tarkoitus suorittaa hyväksymistestit ensin omassa kehitysympäristössään ja varmistaa niiden toimivuus. Vasta lokaalisti toimivan version jälkeen kehittäjä voi yhdistää omat muutoksensa versionhallintaan ja todeta testien toimivan myös yhteisessä testiympäristössä. Hyväksymistesteihin toteutettavien muutosten ei ole tarkoitus muuttaa käyttäjätarinaa, vaan testeihin tehtävät muutokset on tarkoitus toteuttaa ainoastaan teknisellä tasolla. Tällä kyetään varmistamaan se, että sovellus vastaa aikaisemmin asetettuihin vaatimuksiin myös refaktoroinnin jälkeen eikä itse toiminnallisuus ole muuttunut. Tutkielmassa käytetyssä esimerkkiprojektissa kehittäjillä on käytössään versionhallintatyökaluna Git-versionhallinta. Jatkuvan integraation palvelimena sovelluskehityksen apuna toimii Jenkins, jonka tarkoituksena on hoitaa version koonti, automaattisten testien ajo sekä robottitestauksen suoritus. Sovelluksen asennus testiympäristöön tapahtuu myös Jenkinsiä käyttäen. Kehittäjän tehdessä muutoksia yhteiseen haaraan versionhallinnassa, Jenkins saa käskyn aloittaa uutta versiota varten olevat tehtävät. Tähän liittyy sovelluksen koonti ja automaattisten testien ajo. Automaattisiin testeihin kuuluvat tässä tapauksessa yksikkötestit sekä robottitestit, joiden läpäistyä sovelluksen oletetaan olevan valmis tuotantoon julkaisua varten. Jos testit eivät läpäise, sovellus jää virhetilaan ja kyseisen virhetilanteen aiheuttaneen kehittäjän tulee se korjata mahdollisimman pian. Tuotantovalmis versio voidaan asentaa yksinkertaisesti käynnistämällä asennusprosessi silloin, kun se ei ole liian suurena esteenä sovelluksen peruskäyttötarpeille. Automaattinen tuotantoonvienti mahdollistaa lyhyemmät katkot sovelluksen uutta versiota asennettaessa, koska asennukset ja tarvittavat muutokset voidaan tehdä oikeassa järjestyksessä peräkkäin lähes välittömästi toistensa jälkeen. Tämän lisäksi automaatio pienentää virheiden riskiä tekemällä samat muutokset automaattisesti tuontantoympäristöön kuin testausympäristöön, jossa sovellusta on testattu ennen sen julkaisua. 49

55 Kuva 8. Sovelluksen kehitysprosessi kehittäjän paikallisesta ympäristöstä tuotantoon. Kehittäjän näkökulmasta integraatioprosessi on kokonaisuudessaan monivaiheinen. Kehittäjän aloittaessa muutosten toteuttamista sovellukseen, tulee hänen päivittää oma paikallinen sovelluskoodinsa yhteisestä versionhallinnasta. Tämä vaihe tapahtuu jo ennen refaktorointia. Refaktorointiprosessin kestosta ja kehitystiimin koosta riippuen sovelluskoodin valmistuttua voi olla mahdollista, että versionhallinnassa oleva versio eroaa kehittäjän aikaisemmin omaan paikalliseen vedokseen päivittämistään muutoksista. Tästä syystä kehittäjän tulee hakea muutokset uudelleen versionhallinnasta ja yhdistää muuttuneet osat keskenään. Viimeiseksi koodin yhdistysprosessissa kehittäjä siirtää omat tuotoksensa yhteiseen versionhallintaan. Kuva 9. Sovelluskoodin yhdistäminen yhteiseen versionhallintaan. Refaktoroidun sovelluskoodin versionhallintaan yhdistämisen jälkeen laadunvarmistamiseksi on tärkeää suorittaa automaatiotestit yhteisessä ympäristössä, jonka kautta kaikki sovelluskehitys kulkee. Tällä voidaan varmistua, ettei kehittäjän omassa kehitysympäristössä olevat asetukset vaikuta sovelluksen toimintaan. Testien suorittamisessa voidaan hyödyntää jatkuvan integraation järjestelmiä. Jos sovelluksen yhteinen vedos ei toimi testiympäristössä, tulee kyseisen muutoksen tehneen kehittäjän korjata hajonneet muutokset mahdollisimman nopeasti, jotta yleinen sovelluskehitys pystyy jatkumaan muiden kehittäjien toimesta normaalisti. 50

56 6. ANGULAR VS. ANGULARJS: KÄYTÄNNÖN OSA Tässä osassa käsitellään AngularJS- ja Angular-sovelluskehyksillä toteutettuja sovelluksia ja niiden suorituskykyä sekä muistinkäyttöä. Vertailu koostuu kahdesta eri osasta, joissa ensimmäisessä vertaillaan pientä esimerkkisovellusta ja jälkimmäisessä tutkitaan tässä tutkielmassa esitettyä esimerkkisovellusta ja sitä, kuinka sovelluskehyksen versionvaihdos on vaikuttanut suorituskykyyn ja muistinkäyttöön. Näissä suorituskykytesteissä on huomioitavaa, että kumpaakaan sovellusta ei ole varsinaisesti optimoitu muistinkäytön tai suorituskyvyn osalta. Suorituskyvyn testaaminen eri sovelluskehysten välillä on hyvin haastavaa, koska molempien osalta sovellukseen voidaan tehdä lukuisia eri optimointeja parantamaa suorituskykyä eri osaalueilla. Eri sovelluskehykset myös kykenevät useasti toteuttamaan jonkin osa-alueen paremmin kuin toinen, joten tässä tutkielmassa on pyritty ainoastaan vertaamaan kahta sovelluskehystä samanlaisen sovelluksen toteutuksessa. Vertailussa on keskitytty muistin käyttöön ja sovelluksen kykyyn käsitellä sovelluksessa esitettäviä HTML-elementtejä. Angular-sovelluskehystä on kehitetty Angular-tiimin ylläpitämän blogin mukaan nopeammaksi ja tehokkaammaksi edeltäjäänsä verrattuna (Angular, 2017). Erityisesti DOM-puun käsittelyssä AngularJS on kohdannut suorituskykyongelmia, joita on ratkottu Angular-sovelluskehyksessä. Tässä tutkielmassa ei käydä tarkemmin läpi eroavaisuuksia sovelluskehysten välillä niiden suorituskyvystä, koska se on tämän tutkielman ulkopuolella. Havainnot on tehty toteutetusta sovelluksesta sekä hallitusta pienestä ympäristöstä. Suorituskykyyn ja muistinkäyttöön kohdistuvat testit on toteutettu Chrome-selaimella ja sen tarjoamalla kehittäjien työkalulla. Työkalu tarjoaa mahdollisuuden tarkastella sovelluksen suorituskykyä sitä suoritettaessa. Näihin kuuluu muun muassa osio, jolla voidaan tarkastella aikajanalta, kuinka sovellusta käytettäessä ja ladattaessa selaimen tehonkäyttö on jakautunut. Sovelluksesta on myös mahdollisuus nauhoittaa tai ottaa tilannekatsaus muistinkäytöstä ja tutkia, kuinka sovelluksen muistinkäyttö on jakautunut JavaScript-olioiden ja DOM-elementtien välillä (Google, 2017). 51

57 6.1 Kontrolloidun ympäristön esimerkkisovellus Ensimmäisessä esimerkkisovelluksessa näytölle piirretään taulukko, joka sisältää 31 päivän ajalta kaikkien päivien tunnit omiin taulukon soluihin sijoitettuna. Tämän jälkeen käyttäjä voi hakea ajankohtien soveltuvuutta, jotka esitetään eri värein taulukossa. Sovelluksella ei ole varsinaista käyttötarkoitusta, vaan se on toteutettu ainoastaan esittämään sovelluskehysten välillä olevia eroja pienessä ja hallitussa ympäristössä. AngularJS-sovelluskehyksellä tehty toteutus on johdettu Dave Smithin vuoden 2015 ng-conf-konferensissa pitämän esityksen pohjalta (Smith, 2015). Angular-sovelluskehyksellä tehty toteutus on toteutettu tätä mahdollisimman paljon mukaillen. Esimerkkikoodi 6. Esimerkkisovelluksen solun päivitys toteutettuna AngularJS-sovelluskehyksellä Esimerkkikoodi 7. Esimerkkisovelluksen solun päivitys toteutettuna Angular-sovelluskehyksellä Tässä testisarjassa esimerkkisovelluksesta on käytetty kahta eri versiota sovelluskehyksestä. Ensimmäinen versio on toteutettu AngularJS-sovelluskehyksen versiolla ja toinen esimerkkisovelluksista on toteutettu Angularin versiolla. Sovellukset on toteutettu mahdollisimman paljon vastaamaan toisiaan, mutta toinen sovelluskehys voi tarvita toteutukseensa eri tapoja, jotka on täytynyt ottaa huomioon toteutuksessa, kuten esimerkkikoodeista 7 ja 8 voidaan havaita. AngularJS sovelluskehys vaatii timeout -funktiota käytettäessä käytettävän sen omaa 52

58 $timeout -funktiota, jotta kyseisen funktion tekemät muutokset saadaan mukaan sovelluskehyksen hallinnoimiin muutoksiin. Ilman $timeout -funktiota kyseinen sovellus toimisi nopeammin, mutta osa sovelluksesta jäisi piirtämättä näytölle johtuen AngularJS-sovelluskehyksen sisäisestä arkkitehtuurista ja tavasta käsitellä muutoksia. Sama funktio kuitenkin toimii Angular-sovelluskehyksessä ilman erillistä toteutusta Testitapaus 1: Taulukon lataus Testitapauksessa yksi, sovelluksessa esitettävät 744 taulukon solua ladataan ensimmäistä kertaa näytölle ja niihin asetetaan samalla arvot. Molemmat sovellukset ovat tässä vaiheessa jo ladattuna valmiiksi ja taulukkojen lataus tapahtuu painikkeesta painamalla. Alla olevassa kuvassa 10 nähdään, kuinka sovellusten ensimmäiset lataukset eivät eroa toisistaan merkittävästi. AngularJS-sovelluskehyksen latausaika oli 296 millisekuntia, kun taas Angular-sovelluskehyksen latausaika oli 300 millisekuntia. Molempien sovelluskehysten ajankäyttö jakautui hyvin samankaltaisesti eri tehtävien välille. AngularJS vs Angular ,45% 73,00 % ,64 % 1,62% 6,28 % 17,12 % 3,10 % 6,78 % Kuva 10. AngularJS vs. Angular. Esimerkkisovelluksen taulukon ensimmäinen lataus. Suoritusaika millisekunneissa. AngularJS vasemmalla ja Angular oikealla. 53