Miltä näyttää yritysten toiminnanohjaus 2020-luvulla?

Blogitekstit • Digitalisaatio • Teknologia

Sanasta toiminnanohjausjärjestelmä, lyhemmin ERP, tulee ensimmäisenä mieleen raskas ja vaikeakäyttöinen tietojärjestelmä, joka yrityksen toiminnan sujuvoittamisen sijaan lähinnä hankaloittaa sitä. ERPit (Entreprise Resource Management) ovat kuitenkin viimeisen parin vuoden ajan eläneet murrosvaihetta, jota koronapandemia on entisestään kiihdyttänyt. ERPin tarkoituksena on aina ollut parantaa yrityksen liiketoimintaa: se on ollut työkalu niin talouden kuin tuotannon ja jakeluketjun hallintaan. Vanhat on-premises-toiminnanohjausjärjestelmät ovat kuitenkin vaatineet yritykseltä resursseja sekä järjestelmän käyttöönotossa että sen ylläpidossa, joista vastuu onkin usein kasautunut ”IT-puolelle” yrityksen muiden työntekijöiden jäädessä ihmettelemään järjestelmää ja sen tuomia ”etuja”. 2020-luvulla toiminnanohjausjärjestelmät eivät kuitenkaan ole enää näitä 90-luvun ATK-tuulahduksia – ne ovat ketteriä yrityksen bisnestä buustaavia järjestelmiä! 

Itsestään selvin ja yksi näkyvimmistä muutoksista toiminnanohjauksessa on palvelujärjestelmien muuttuminen pilvipohjaisiksi. Vanhoissa on-premises-ratkaisuissa yritystä kuormittavat käyttöönottokustannusten lisäksi kiinteät laite- ja käyttökustannukset, minkä vuoksi esimerkiksi startup-yrityksellä ei välttämättä ole mahdollisuutta tai halua sijoittaa kalliiseen järjestelmään. Pilvipohjainen palvelu mahdollistaa yritykselle sekä nopean käyttöönoton että matalammat kustannukset, kun yritys maksaa palvelusta kuukausittain vain käytön mukaan. Toinen ja yksi keskeisimmistä pilvipohjaisuuden eduista on se, ettei yrityksen itse tarvitse huolehtia järjestelmän ylläpidosta tai päivityksistä – palveluntarjoaja pitää järjestelmän kunnossa ja ajan tasalla.  

Koronaviruspandemian myötä yrityksillä on tarve yhä paremmalle ja tarkemmalle riskienhallinnalle sekä resurssien ohjaamiselle mahdollisimman tehokkaasti. Samalla etätyön määrä on kasvanut räjähdysmäisesti. Pilvipohjainen ERP mahdollistaa palvelun käytön ajasta ja paikasta riippumatta. Nykyaikainen ERP ei ole siis enää IT-osaston käyttämä järjestelmä, vaan liiketoiminnan ohjaukseen voivat osallistua kaikki yrityksen tekijät ja sidosryhmät, jolloin tiedon kulku tapahtuu ilman mutkia ja viivästyksiä. Toiminnanohjausjärjestelmä takaa luotettavan ja tarkan tiedon reaaliaikaisesti – ja juuri siihen yrityksen tulisikin päätöksentekonsa perustaa! Ajantasainen data mahdollistaa sekä toiminnan ennakoinnin että muutokset toimintaan lyhyelläkin varoitusajalla. 

Yksi nykyaikaisten toiminnanohjausjärjestelmien eduista on kerätyn datan analysointi tarkoituksenmukaisesti ja tarkasti. Kun päätöksiä yrityksessä halutaan tehdä tietoon nojaten, on tarve analyysiperusteisille ratkaisuille: yritykset, jotka käyttävät analysointityökaluja, tekevätkin kaksi kertaa todennäköisemmin vahvaa taloudellista tulosta, viisi kertaa todennäköisemmin kriittisiä ratkaisuja nopeasti ja kolme kertaa todennäköisemmin toteuttavat tehtyjä päätöksiä ja suunnitelmia tehokkaasti! Pääsy reaaliaikaiseen dataan ja sen analyysiin tuo toisin sanoen merkittäviä hyötyjä yritykselle. Toimintavarmuuden ja ketteryyden lisäksi data-analyysi parantaa bisnestä mahdollistamalla paremman asiakaskokemuksen tarjoamisen. Yritys voi seurata esimerkiksi asiakkaan ostohistoriaa ja kulutuskäyttäytymistä, jolloin yritys voi lisätä sekä myyntiään että sitoutumista toimimalla asiakkaan mieltymysten mukaisesti. 

2020-luvulla ERPin ehdottomia etuja on se, että palvelu on räätälöitävissä yrityksen yksilöllisten tarpeiden mukaiseksi, ja sen käyttöä voidaan laajentaa uusiin kohteisiin tarpeen mukaan. 2020-luvun ERP on käyttäjäkeskeinen, joustava ja saavutettava – työkalu, joka on suunniteltu yrityksen kaikkien työntekijöiden käyttöön! 

Palveluväylästä lyhyesti

Blogitekstit • Digitalisaatio • Teknologia

Palveluväylä on hämäävästi nimetty tiedonsiirtoalusta, joka nimestään huolimatta ei perustu ESB (Enterprise Service Bus) -malliseen integraatioon vaan X-ROAD-teknologiaan. Teknologia on alunperin Viron sähköisen hallinnon toimintoihin kehittetty integraatioratkaisu, joka on myöhemmin julkaistu avoimena lähdekoodina. Nykyään sen kehityksestä vastaa Nordic Institute for Interoperability Solutions (NIIS.org). Sähköisellä hallinnolla tarkoitetaan Internetiin tuotuja julkisia palveluita. Käytännössä voidaan puhua julkisen hallinnon Internet-käyttöliittymistä. Tyyppilisiä sähköisen hallinnon tarjoamia asiointipalveluita ovat vero-, sosiaaliturva- ja päätösasiat.

X-ROAD teknologia tarjoaa vakioidun ja tietoturvallisen tavan siirtää tietoa eri osapuolien välillä. X-Road koostuu liityntäpalvelimista (secure server) ja keskuspalvelimista (central server). Keskuspalvelin vastaa hallinnoinnista, lokituksesta ja varmentamisesta – liityntäpalvelimet taas toimivat kuluttajien (consumer) ja tuottajien (producer) välillä tiedonsiirrossa. Palveluväylän toiminnasta ja ylläpidosta vastaa Digi- ja väestötietovirasto.

Kuten arvata voikin, palveluväylään liittymistä varten tarvitaan oma liityntäpalvelin. Liityntäpalvelimen pystyttäminen on nykyään hiukan käsittelyajoista riippuen helppo ja nopea toimenpide. Liityntäpalvelinta pystyttäessä luodaan allekirjoitus- ja autentikointivarmenteet, jotka toimitetaan DVV:lle allekirjoitettaviksi. DVV:n allekirjoittama varmenne mahdollistaa liityntäpalvelimen liittämisen keskuspalvelimeen. Tämän jälkeen muita palveluväylän alipalveluita voidaan lisätä omien palveluiden käyttäjiksi. X-Roadin liityntäpalvelinta hallitaan web-käyttöliittymän kautta.

Palveluväylällä on olemassa kolme eri ympäristöä: FI-DEV, FI-TEST ja FI. Näistä kolmesta FI on tuotantoympäristö; muut ovat testauskäyttöön. Kehitysympäristö eli FI-DEV on avoin kehitysympäristö, johon voi hakea käyttöoikeuden myös yksityishenkilönä. FI-TEST on taas enemmin testiympäristö, joka vaaditaan palveluiden toimivuuden testaukseen ennen tuotantokäyttöä.

Liityntäpalvelimen ja siihen liittettävän palvelun väliin on tarpeiden mukaan hyvä liittää sovitinpalvelu, joka hoitaa WSDL-kuvauksen (=teknisen kuvauksen) mukaisen parsinnan kutsuille ja palauttaa oikeassa SOAP-muotissa kyselyn vastauksen. XRD4J -javaliitännäisellä tämä on helppo toteuttaa.

Kaiken viranomaisten välisen tiedonsiirron tulisi tapahtua nykyään palveluväylän kautta, mutta se tarjoaa myös yksityisille toimijoille vakioidun ja luotettavan tavan tiedonhallintaan. Jos teillä on tarvetta erillaisille ratkaisuille liityntäpalvelimista adaptereihin, me Joinexilla mielellään autamme sinua helpottamaan arkeasi.

Ihmiskeskeisyys digipalveluiden kehittämisessä

Blogitekstit • Digitalisaatio • Verkkopalvelut

Digitalisaatiosta puhuttiin pitkään ihmisestä irrallisena toimintana, minkä vuoksi digitalisaatio onkin saanut huonon kaiun ja vaikuttaa kaukaiselta asialta vaikka todellisuus on ihan muuta! Digitalisaation yksi keskeisimmistä tavoitteista on tehdä kaikesta toiminnasta helpompaa ihmisille. Kun ihmiset saavat palveluita entistä paremmin ja monipuolisemmilla tavoilla, myös yritysten toiminta tehostuu. Ihmiskeskeisyys digitalisaatiossa ja digipalveluissa on äärimmäisen tärkeää, jotta ihmisten tarpeisiin vastataan ja arjesta tehdään helpompaa. 

Ihmiskeskeisyydellä tarkoitetaan kykyä ymmärtää ihmisten tarpeita, arkea ja kulttuurista syntyviä tarpeita. Tällä periaatteella varmistetaan, että kehitys tapahtuu aina ihmisten tarpeista eikä keskiössä ole pelkästään yrityksen toiminnan tehostaminen ja rahansäästö. Ihmiskeskeisyyden yksi hienoimmista puolista palvelunkehittäjän kannalta on se, että se haastaa pohtimaan palvelun kehittämistä monipuolisesti erilaisten käyttäjien näkökulmasta. Ihmiskeskeisyydellä varmistetaan myös se, että digipalvelu onnistuu eikä ole vain näennäinen parannus, joka palvelee vain murto-osaa käyttäjistä. 

Mielestäni digipalvelu onkin onnistunein silloin, kun erilaiset ihmiset pystyvät käyttämään palvelua omista rajoitteistaan ja osaamistasosta huolimatta sekä sen lisäksi haluavat palata käyttämään palvelua. Tällöin on murrettu monia aitoja, jotka estävät digipalvelun käytön ja toisaalta varmistettu, että käyttäjä todella hyötyy palvelusta. 

Digipalvelun avulla voidaan monesti tehostaa toimintaa ja nopeuttaa palveluketjua, mikä varmasti kiinnostaa palveluntarjoajia. On kuitenkin huomioitava, että digipalvelu ei aina ole kaikille paras asiointitapa vaan digipalvelun ohella on tärkeää säilyttää myös muunlaisia tapoja asioida. Digipalvelu voi kuitenkin täydentää nykyistä palveluportfoliota ja on suurimmalle osalle käyttäjistä luontevin tapa asioida. 

Miten palvelun kehittämisessä huomioidaan ihmiskeskeisyys?

Kokosin tähän vinkkejä, joista on hyvä lähteä liikkeelle. 

  1. Design for all – älä oleta ihmisten digitaitoja vaan kehitä kaikille.  

Kun palvelu on saavutettava ja yhä useampi pystyy käyttämään sitä, sitä paremmin palvelu palvelee käyttäjiään. Yleensä kehittämisessä sorrutaan monimutkaisuuteen yksinkertaisuuden sijaan. 

  1. Kehitä käyttäjien kanssa – älä laput silmillä 

Ymmärrä palvelun käyttäjää: keille suunnittelet ja miksi? Millaisessa kontekstissa palvelua käytetään ja mikä on palvelun ydintehtävä? Yksi tärkeimmistä asioista on muistaa, että ihmiset ovat erilaisia etkä voi lopulta ikinä tietää suoraan, millaisia haasteita tai odotuksia ihmisillä on palvelun suhteen. Ihmisten tarpeita ei kannatakaan täyttää mutuilemalla omien näkemysten pohjalta. Erilaiset käyttäjät voidaan ottaa osaksi palvelun kehittämistä esimerkiksi käyttäjätutkimuksen avulla – tällöin saatte paljon lisää arvokasta tietoa ja vältätte monet sudenkuopat palvelun kehittämisessä.  

  1. Kuuntele ja testaa

Kun palvelu kehitetään ihmiskeskeisesti, käyttäjien tarpeet huomioidaan. Kuuntele käyttäjiä tarkasti ja testaa palvelua heidän kanssaan. Kuulette suoraan palvelun käyttäjiltä, mikä palvelussa on heille tärkeää ja mikä taas turhaa. Samalla säästätte resursseja, kun ette kehitä turhaan vaan tarpeeseen. 

  1. Tee palvelun käyttöönotosta helppoa ja kivaa 

Käyttäjälle yksi tärkeimmistä kohdista palvelun käytössä on ensimmäinen käyttökerta. Sen perusteella luodaan mielikuva palvelun helppoudesta, käytettävyydestä ja laadusta. Lyhyesti sanottuna siis hyvä palvelu on helppo ottaa käyttöön. Suosittelen keskittymään käyttäjän alkutaipaleeseen palvelussa: ohjaa tarvittaessa ja osoita tärkeimmät toiminnot. Personoitu aloitus myös luo siteen palvelun ja käyttäjän välille. 

  1. Palvelun kehittäminen on jatkuvaa työtä 

Ihmiskeskeisellä kehittämisellä voidaan kuitenkin varmistaa, että palvelun pohja on jo hyvä eikä tärkeitä toimintoja tarvitse heti korjata tai kehittää uudelleen. Luo käyttäjille helppo väylä antaa palautetta ja suuremmissa muutoksissa osallista heitä. 

Kun digipalveluiden kehittämisessä ymmärretään ihmiskeskeisyyden arvokkuus, myös palvelun laatu ja palvelukokemus paranevat. Tällä on suora vaikutus kokemukseen yrityksestä: huono palvelu muistetaan eikä palvelun kehittäminen välttämättä paranna huonoa mielikuvaa. Muista siis aina: digipalvelun ydintarkoitus on lopulta se, että ihmiset saavat tarvitsemansa palvelun helposti ja heille sopivalla tavalla. 

Saavutettavuus tekee digitaalisesta maailmasta paremman

Blogitekstit • Digitalisaatio • Verkkopalvelut

Tänään vietetään kansainvälistä saavutettavuuspäivää! Suomessa väestö ikääntyy ja yli miljoonalla suomalaisella on vaikeuksia verkkopalvelujen käytössä. Tänäänkin on siis hyvä syy pohtia, miksi saavutettavuus on tärkeää, ja mitä etuja se tuo yrityksen liiketoiminnalle. Saavutettavuus tarkoittaa lyhyesti sitä, että kuka tahansa, taustastaan ja vammoistaan huolimatta, pystyy käyttämään verkkopalveluita. 

Yhä useammat palvelut ovat saatavilla myös verkossa. Tilastokeskuksen mukaan yli 80 prosenttia 16-89-vuotiaista suomalaisista käyttää internetiä useasti päivässä, ja yli puolet käyttää internetiä ostosten tekemiseen. Selvityksen mukaan internetiä käytetään yleisimmin viestintään, medioiden seuraamiseen, ostoksiin sekä asioiden hoitamiseen. Näiden lukujen jatkuva kasvu kertoo myös verkkopalveluiden käytön lisääntymisestä. 

Tämän kasvusuunnan itsessään pitäisi jo herättää palveluntarjoajien huomio: kun yhä useampi käyttää verkkopalveluita, palveluntarjoajan tulisi varmistaa, että palvelu on kaikkien käytössä. Laki digitaalisten palvelujen tarjoamisesta velvoittaa julkista sektoria ja osaa yksityisen ja kolmannen sektorin organisaatioista noudattamaan saavutettavuusvaatimuksia. Tulevina vaatimuksina esimerkiksi verkkokauppojen tulee olla saavutettavia 2025 mennessä – muutoin laajoja velvoitteita yksityiselle sektorille ei ole. Velvoittavuuden puute ei mielestäni kuitenkaan ole peruste saavutettavuuden huomiotta jättämiselle, sillä saavutettavuus lisää yhdenvertaisuutta ja tuo mukanaan kilpailuedun.  

Kun palvelusi on saavutettava, yhä useampi pystyy käyttämään palvelua – samalla potentiaalisten asiakkaiden määrä kasvaa. Saavutettavuus tekee palvelusta helppokäyttöisemmän kaikille, mikä puolestaan parantaa asiakaskokemusta. Saavutettavuus on etu myös hakukoneiden kannalta: Google nimittäin arvostaa sivustoja, joita on helpompi käyttää ja ymmärtää. 

Miten palvelusta voisi sitten tehdä saavutettavan? Mielestäni parasta on tarttua saavutettavuuteen heti alusta alkaen, eli huomioida se jo palvelua rakennettaessa. Myös jo olemassa olevan palvelun saavutettavuutta voidaan parantaa. Edistitpä saavutettavuutta kummassa tilanteessa tahansa, tee se aina asiantuntijan kanssa. Osaava saavutettavuusasiantuntija auttaa sinua korjaamaan ja kehittämään palveluasi. Sen lisäksi opit itse saavutettavuudesta ja voit jatkossa huomioida sen helpommin! 

Saavutettavuus ei ole irrallinen käyttäjä- ja asiakaskokemuksesta, vaan se hyödyttää aivan kaikkia. Saavutettavuus kannattaa ottaa osaksi yrityksen omaa digitaalista strategiaa, jottei yritys tietoisesti jätä osaa asiakkaista palvelun ulkopuolelle. Saavutettavuus ei ole turhaa vouhotusta, vaan keino tehdä digitaalisesta maailmasta parempi ja helpompi – ihan meille kaikille. 

Saavutettavuutta rakennetaan ihmisen ja työkalujen yhteistyöllä

Blogitekstit • Digitalisaatio • Verkkopalvelut

Digipalvelulaki velvoittaa julkisen sektorin toimijoita täyttämään saavutettavuusvaatimukset verkkosivustoillaan. Saavutettavuuden arviointi on monipuolista työtä, jossa verkkopalvelun toimivuutta tarkastellaan sekä teknisestä että sisällöllisestä näkökulmasta. Tämä voi kuulostaa monimutkaiselta ja jopa hieman tylsältä, mutta kyse on ennen kaikkea siitä, kuinka helppoa verkkosivuston käyttö on. Kun saavutettavuusvaatimukset ovat kunnossa, myös sivuston käyttö on miellyttävää ja helppoa. Kukapa tällaista ei haluaisi?

On selvää, että kaikki sivustot eivät ole muuttuneet saavutettaviksi sen jälkeen, kun digipalvelulain siirtymäaika päättyi. Tällä hetkellä moni palveluntarjoaja pähkäileekin, miten omasta sivustosta voisi saada saavutettavan. Sivustoja arvioidaan paljon ja valmiita sivustoja korjataan arviointiperusteisesti. Kysymys kuitenkin kuuluu: miten saavutettavuus huomioidaan jatkuvasti? Tarjotaksemme entistä laadukkaampia digitaalisia palveluita ja varmistaaksemme, että kuka tahansa voi käyttää niitä, saavutettavuus on huomioitava myös itse kehitystyössä sekä sisällön tuottamisessa. Ei riitä, että vasta valmis tuote arvioidaan – arviointia on tehtävä jatkuvasti.

Saavutettavuuden arviointi vaatii paljon työtä, ja arviointiin vaikuttavatkin keskeisesti sekä palvelun laajuus että sen sisältö. Arviointi vie asiantuntijalta aikaa työn laajuuden mukaan tunneista päiviin. Arvioinnissa on hyötyä monipuolisesta ja tehokkaasta työkalusta, jolla voidaan osittain automatisoida saavutettavuuden arviointia. Tällä hetkellä arvioinneissa tukeudutaan moniin erilaisiin työkaluihin, joista yksikään ei anna valmiita vastauksia saavutettavuuden tilasta: saavutettavuus arvioidaan ihmisen ja työkalujen yhteistyössä.

On kuitenkin tärkeää huomata, että monipuolisinkaan työkalu ei täysin korvaa ihmistä saavutettavuuden arvioinnissa: verkkopalvelut suunnitellaan ihmisille, joten on tärkeää, että myös ihminen testaa palvelua. Digitaalinen työkalu ei tuota tietoa ihmisen kokemuksesta sivuston käytettävyydestä tai kuormittavuudesta. Saavutettavuuden arvioijan tulee myös tunnistaa erilaiset syyt, jotka voivat rajoittaa palvelun käyttöä.

Saavutettavuus on jatkuvaa työtä. Tämän vuoksi on tärkeää tehdä myös sivuston kehittäjistä ja sisällöntuottajista saavutettavuusosaajia, eikä tukeutua pelkästään saavutettavuusasiantuntijoihin. Saavutettavuus on ennen kaikkea yhdenvertaisuuskysymys. Kun haluamme rakentaa entistä digitaalisempaa yhteiskuntaa, saavutettavuuden tulee olla keskiössä. Ilman saavutettavia ratkaisuja merkittävä osa ihmisistä jää digipalveluiden ulkopuolelle.

Taukoviikkoblogi – osa 2

Blogitekstit • Yrityskulttuuri

Keppiä henkilökunnalle

Marraskuu on juuri oikea hetki herätellä IT-persoonia näytön äärestä venymään omiin mittoihinsa. Mikä onkaan parempi väline tehostamaan suoristumista kuin keppi? Toimistolle hankittiin jokaiselle ikioma ja koronaturvallinen keppi. Nimikoituihin keppeihin jäävät vain kunkin omat sormenjäljet – myös turvavälit ovat taatut.

Marraskuinen viikko vierähti keppejä pyöritellessä ja heilutellessa. Hartiat tykkäsivät ja veri virtasi mukavasti. Hartioiden kireyttä testailtiin alkuviikosta, ja useimmilla joustavuus olikin kohdillaan. Kireysaste oli huolestuttava vain parilla vapaa-aikaansa rakennushommien parissa viettävällä…

Eipä harjan varsi mikään teknologinen härpäke ole, mutta sitäkin toimivampi lihasten ja nivelten verryttäjä. Lihasvoimaakin voi kepin avulla hankkia, vaikkapa kyykistelemällä. Kun kepin pitää tiukasti kiinni lavoissa ja takamuksessa, liike ohjautuu haluttuun suuntaan. Ei siis mikään hassumpi investointi.

Toimistolla muistutukset taukojen pitämisestä ovat paikallaan. Tauot ovat myös helposti kuitattavissa: ainakin pari kertaa tunnissa on hyvä katkaista aivotyöskentely ja vaihtaa asentoa. Toimiston sähköpöydät luovat edellytykset asennon vaihtelulle. Ergonominen istuma-asento on jo hyvin tiedostettu, mutta myös seisominen vaatii huomiota – ja etenkin hyviä tukilihaksia, jotta asento ei petä ja lipsahda kiemuralle.

Loppuviikosta havaitsimme jo pientä laajentumista liikeradoissa ja lihaksetkin alkoivat antaa jo periksi. Pienet breikit työn lomassa eivät olleet siis turhia. Väistämättä kokeilussa olivat myös akrobatiset temput – onneksi toimistolla selvittiin ilman vammoja.

Ja saivat IT-persoonat loppuviikosta myös porkkanansa. Ehkäpä allekirjoittaneen kliseinen vitsi ei sittenkään maistunut puulle, sillä mukava porkkanoiden rouskutus taotti toimiston tilaa perjantai-iltapäivän.

Porkkanapussi pöydällä

Työvelvollisuusrekisteri

Caset • Teknologia

Työvelvollisuusrekisteri – varautumista poikkeustilanteisiin

Omasivari

Caset • Teknologia

Omasivari – Siviilipalvelus haltuun ajasta ja paikasta riippumatta

Tekninen velka voi johtaa konkurssiin

Teknologia • Yleinen

Tekninen velka tarkoittaa ohjelmiston kehityksessä syntyvää toteutusvelkaa. Joskus on perusteltua tehdä jokin ominaisuus nopeasti (quick and dirty) tiedostaen, että oikominen johtaa tulevaisuudessa lisätyöhön ominaisuuden muuttamisen tai ylläpitämisen suhteen.

Tekninen velka syntyy, kun ei ole mahdollisuutta, aikaa tai kykyä investoida työtä jonkun asian tekemiseen kestävällä tavalla. Kuten taloudelliseen velkaan, myös tekniseen velkaan liittyy korko. Korko on se lisätyö, joka joudutaan laittamaan sen asian jatkokehittämiseen, jonka tekemisessä alunperin oiottiin. 

Velkaa voidaan poistaa investoimalla kehitykseen myöhemmin, eli teknisen velan korkoa voidaan pienentää poistamalla huono ratkaisumalli. Korkoja voidaan toisaalta maksaa, jos korkotaso pysyy matalana ja velan poiston vaatima investoinnin hinta on korkea. Huonoimmassa tapauksessa velka kasvaa koko ajan, samoin korko, ja lopulta edessä on konkurssi – koko ohjelmiston uudelleenkirjoitus.

Teknisen velan ajatus on kohtuullisen yksinkertainen ja havainnollistava, mutta sen mittaaminen on hankalaa. SonarQube:lla on tähän mittari, jolla mittaaminen ei kuitenkaan ole ongelmatonta: mittarin osoittamat työmäärät velan poistamiseksi ovat noin 14-kertaiset testattaessa toteutuneisiin työmääriin nähden (testattu yksittäisessä projektissa). Ansioistaan huolimatta SonarQube ei myöskään arvioi perusteellisesti suunnittelun ja arkkitehtuurin velkaa, mikä edellyttäisi sekä asioiden arvioimista kokonaisuuksina että sisällön ymmärtämistä. SonarQube arvioi tehokkaasti yksittäisiä tiedostoja ja niiden formaaleja ominaisuuksia, mutta sisällön ymmärtämiseen tarvitaan ihmistä.

Sekä teknisen velan syntymiseen että koodin laatuun voi koodaaja vaikuttaa itse: teknisen velan syntyminen vahingossa ja huomaamatta pitää estää, ja työkalujen lisäksi tärkeimmät aseet siihen ovat ongelman tiedostaminen ja oikea toimintamalli.

Teknisellä velalla on suora (joskin käänteinen) yhteys laatuun ja laadunvarmistukseen: mitä suurempi tekninen velka, sitä heikompi laatu ja laadunvarmistus. Johdatuksen aiheeseen saat lukemalla esimerkiksi lopussa olevia lähteitä.

Takaisin otsikkoon: tarvitseeko velka maksaa takaisin? Pandemian ja siihen liittyvän keskuspankkielvytyksen myötä esitetty kysymys nousi esiin poliittiselta taholta, mutta sai varovaista vastakaikua myös talousasiantuntijoilta. Ehkä taloudellista velkaa on järjestelmän uskottavuuden nimissä pidettävä takaisinmaksettavana, mutta taloudellinen velka on validi vain niin kauan kuin velallinen on olemassa.

Myös tekninen velka raukeaa, kun ohjelmistosta aika jättää. Ohjelmiston elinkaaren pituus on joskus vaikeasti hahmotettavissa, ja väliaikaiseksi ajateltu ratkaisu voi osoittautua kovin sitkeähenkiseksi, kun taas hartaudella rakennettu ohjelmisto ei välttämättä koskaan näe tuotannon käynnistystä. Herääkin kysymys: kannattaako laatuun panostaa lainkaan? Kyllä kannattaa, sillä laadun rakentaminen kehityksen yhteydessä ei tuo lisätyötä verrattaessa laaduttomuuteen, johon palaa helposti enemmän aikaa kerrannaisvaikutuksina. Olennaista on laadun syntyminen tekemisen pisteessä – ei testauspisteessä.

http://martinfowler.com/bliki/TechnicalDebt.html

http://www.sonarqube.org/

https://en.wikipedia.org/wiki/Technical_debt

http://www.agiledeveloper.com/presentations/caring_about_code_quality.pdf

React-lomakkeiden testaaminen käytännössä

Teknologia

Esitin edellisessä kirjoituksessa näkemykseni siitä, miten React-komponentteja kannattaa testata, ja mihin testityökaluihin päädyin. Tällä kertaa sukelletaan testin ATV-rakenteeseen ja testataan React-lomaketta koodiesimerkkien avulla.

Alkuvalmistelut

Testaamiseen tarvitsemme seuraavat työkalut: Jest, jest-dom, React Testing Library ja user-event. En tässä käy läpi, miten nämä asennetaan tai paneudu kovin yksityiskohtaisesti siihen, miten testiajoja konfiguroidaan. Create React App -pohjaisissa sovelluksissa Jest on asennettu valmiiksi, ja testiajon voi käynnistää komentoriviltä komennolla:

npm run test # Suorittaa package.json tiedostossa olevan "test"-komennon

Muiden kuin Create React App -pohjaisten sovellusten kohdalla suosittelen vilkaisemaan Jestin selkeää dokumentaatiota.

# Suorittaa testejä ja jää kuuntelemaan muutoksia
# niiden kohteina oleviin tiedostoihin
jest --watch

Kirjoitan testit aina niiden komponenttien viereen, jotka ovat testauksen kohteena. LoginForm.jsx-komponentin vierestä löytyy LoginForm.test.jsx-niminen testitiedosto. Jest tunnistaa tällä tavalla nimetyt tiedostot ja osaa käynnistyessään ajaa niissä määritellyt testit.

// LoginForm.test.jsx
describe('LoginForm', () => { // Ryhmä, lohko tai muu vastaava!
  test('näyttää virheen kun lomake lähetetään puutteellisena', () => { // Testi
    /* Testin kaikki vaiheet tehdään täällä */
  });
});

Yksi testitiedosto voi sisältää useita testejä. Näitä voi halutessa ryhmitellä describe-lohkoihin, joita itsessään voi edelleen ryhmitellä describe-lohkoihin. Näin testit pysyvät järjestyksessä ja ongelmia tuottava testi on helppo paikallistaa. Jestin näppärällä komentorivityökalulla voi kätevästi suorittaa vain halutun nimiset tai tietyssä lohkossa olevat testit.

Mönkijä kiipeää rakennusmateriaalien päältä valmiin rakennelman huipulle

ATV: Aseta, Toimi, Varmista

Testauksen kulmakiveksi on vakiintunut Aseta, Toimi, Varmista -malli (englanniksi Arrange, Act, Assert).

  • Reactin kontekstissa ensin asetetaan DOM siihen tilaan, jossa sitä halutaan testata. Käytännössä tämä tarkoittaa jonkin komponentin renderöimistä.
  • Seuraavaksi toimitaan esimerkiksi painamalla painiketta tai muuttamalla lomakekentän arvoa.
  • Lopuksi varmistetaan, että toiminnasta aiheutui juuri ne seuraukset, jotka pitikin.

Aseta

React Testing Libraryn render-metodilla luodaan testattava komponentti ja annetaan sille tarvittavat propit. Tämän nimenomaisen render-metodin käyttö on tärkeää, koska ilman sitä emme myöhemmin pysty vuorovaikuttamaan renderöityjen elementtien kanssa.

// LoginForm.test.jsx
import { render } from '@testing-library/react';
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  test('näyttää virheen kun lomake lähetetään puutteellisena', () => {
    // Aseta: renderöidään LoginForm komponentti
    render(<LoginForm />);
  });
});

Toimi

Kirjoittamamme testin tarkoitus on varmistaa, että käyttäjälle näytetään virheilmoitus, jos lomake lähetetään puutteellisena. Puutteellisuus voi tarkoittaa käytännössä mitä haluamme; jonkin kentän arvo on tyhjä, salasana on liian lyhyt tai käyttäjätunnus ei läpäise annettua validaattoria. Kaikki riippuu siitä, miten LoginForm-komponentti on toteutettu ja mitkä kaikki syötteet se hylkää (tai kääntäen, mitä haluamme sen hylkäävän, jotta testi menee läpi!). Sovitaan tässä kohtaa, että haluamme lähetyksen epäonnistuvan silloin, kun joko käyttäjätunnus- tai salasanakenttä on tyhjä. Luodaan ensin testi, jossa käyttäjätunnukselle annetaan arvo, mutta salasanalle ei.

// LoginForm.test.jsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  describe('näyttää virheen, kun lomake lähetetään', () => {
    test('ilman salasanaa', () => {
      // Aseta: renderöidään LoginForm komponentti
      render(<LoginForm />);

      // Toimi: etsitään käyttäjätunnuksen syöttökenttä
      const kayttajatunnusInput = screen.getByLabelText('Käyttäjätunnus');

      // Toimi: muutetaan käyttäjätunnuskentän arvoa
      userEvent.type(kayttajatunnusInput, 'kroisos.pennonen');

      // Salasanakenttään ei kosketa!

      // Toimi: lähetetään lomake etsimällä ensin lähetä-painike
      userEvent.click(screen.getByText('Kirjaudu'));
    });
  });
});

Toimimisen perustana on React Testing Libraryn screen. Sen avulla voimme vuorovaikuttaa synteettisellä testiruudullamme olevan sisällön kanssa. Käytämme edellä paria React Testing Library querya renderöityjen elementtien löytämiseen. getByLabelText hakee elementin, jonka <label>-elementin tekstisisältönä on annettu merkkijono. Voimme tehdä näin, koska LoginFormin toteuttanut koodari on antanut vastuullisesti kaikille lomakekentille labelit (tai jos ei ole, testi epäonnistuu ja sellainen pitää lisätä!). getByText puolestaan hakee elementin, jonka tekstisisältö on annettu merkkijono. Tämä soveltuu oikein hyvin painikkeiden hakemiseen.

React Testing Libraryn query-dokumentaatiossa on selkeästi kerrottu näiden hakufunktioiden toiminnasta. Suosittelen jättämään sen välilehteen auki ensimmäisiä testejä kirjoittaessasi!

Käyttäjän toimintojen matkimiseksi käytämme user-event-kirjaston type– ja click-funktioita. Kuten kaikki user-event-kirjaston funktiot, näiden vaikutukset ovat niiden nimien perusteella itsestään selviä. Testikäyttäjämme kirjoittaa käyttäjätunnuskenttään ja klikkaa ”Kirjaudu”-painiketta.

Varmista

Lopuksi haluamme varmistaa, että edellisten toimien seurauksena käyttäjälle todellakin näytetään virheilmoitus.

// LoginForm.test.jsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import '@testing-library/jest-dom';                      // Uusi!
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  describe('näyttää virheen, kun lomake lähetetään', () => {
    test('ilman salasanaa', () => {
      // Aseta: renderöidään LoginForm komponentti
      render(<LoginForm />);

      // Toimi: etsitään käyttäjätunnuksen syöttökenttä
      const kayttajatunnusInput = screen.getByLabelText('Käyttäjätunnus');

      // Toimi: muutetaan käyttäjätunnuskentän arvoa
      userEvent.type(kayttajatunnusInput, 'kroisos.pennonen');

      // Salasanakenttään ei kosketa!

      // Toimi: lähetetään lomake etsimällä ensin lähetä-painike
      userEvent.click(screen.getByText('Kirjaudu'));

      // Varmista: varmistetaan, että näytöltä löytyy virheestä ilmoittava teksti
      expect(
        screen.getByText('Unohtuiko salasana?'),
      ).toBeInTheDocument();
    });
  });
});

Viimeinen importimme on jest-dom. Sen avulla voimme näppärästi varmistaa kaikenlaisia DOM-elementteihin liittyviä asioita. Tässä tapauksessa meille riittää pelkästään sellaisen olemassaolo, kunhan tekstisisältönä on ”Unohtuiko salasana?”.

Kas näin! Ensimmäinen testimme on paketissa. npm run test komentoriville ja se suoritetaan automaattisesti.

Jo opituilla menetelmillä voimme helposti tarkistaa myös tapaukset, joissa salasana tai molemmat lomakkeen kentät ovat tyhjiä:

// LoginForm.test.jsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import '@testing-library/jest-dom';
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  describe('näyttää virheen, kun lomake lähetetään', () => {
    test('ilman salasanaa', () => {
      // Tätä testiä on hieman typistetty
      render(<LoginForm />);

      const kayttajatunnusInput = screen.getByLabelText('Käyttäjätunnus');
      userEvent.type(kayttajatunnusInput, 'kroisos.pennonen');
      userEvent.click(screen.getByText('Kirjaudu'));

      expect(
        screen.getByText('Unohtuiko salasana?'),
      ).toBeInTheDocument();
    });

    test('ilman käyttäjätunnusta', () => {
      render(<LoginForm />);

      const salasanaInput = screen.getByLabelText('Käyttäjätunnus');
      userEvent.type(salasanaInput, 'roopeAlas€€€2020');
      userEvent.click(screen.getByText('Kirjaudu'));

      expect(
        screen.getByText('Unohtuiko käyttäjätunnus?'),
      ).toBeInTheDocument();
    });

    test('tyhjänä', () => {
      render(<LoginForm />);

      userEvent.click(screen.getByText('Kirjaudu'));

      expect(
        screen.getByText('Anna nyt edes jotain tietoja!'),
      ).toBeInTheDocument();
    });
  });
});

Voit varmaankin kuvitella miltä näyttäisi testi, joka testaa lomakkeen onnistunutta lähetystä?

Jatkan tästä vielä myöhemmin kirjoituksella, jossa käyn kevyesti läpi isomman sovelluksen testaamisen haasteita ja mockausta. Mitä tehdä, kun komponentti vaatii toimiakseen jotain korkealla komponenttipuussa asuvaa dataa, kuten teeman, Routerin tai lokalisaatiotietoja? Palaan näihin tuonnempana. (Seuraa meitä Twitterissä, niin saat tiedon uusien kirjoitusten ilmestymisestä!)