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ä!)

Liikkeelle React-komponenttien testaamisessa

Teknologia

Olen pitänyt ajatusta käyttöliittymien testauksesta haastavana. Selain on niin monimutkainen ympäristö – miten siellä testaaminen toimii käytönnössä? Kannattaako testien laatimiseen käyttää aikaa? Mitä ylipäätään kannattaa testata?

Mikä on testaamisen arvoista?

Refaktoroidessani Omasivarin lomakkeita huomasin nopeasti pallottelevani editorin ja selaimen välillä. Vaihdoin yhden tekstikentän toteutusta, jonka jälkeen kokeilin, päivittyikö sen arvo edelleen oikein, sainko virheilmoituksen syöttäessäni sähköpostiosoitteen väärin ja vähän kaikkea muuta, mitä keksin kokeilla. Sama toistui seuraavan kentän kanssa. Ja seuraavan. Ja seuraavan, kunnes lopulta aloin kokeilemaan, lähetetäänkö kaikki tiedot todella palvelimelle, kun painan lomakkeen lähetyspainiketta. Entä jos pakollinen etunimikenttä on tyhjä ja tilinumeron tilalla on tuliemoji? 🔥

Seuraavaa lomaketta työstäessäni uskalsin jo muuttaa kaikkien kenttien toteutukset kerralla ja näpertää selaimen kanssa vasta sitten. Kävin silti kaikki mahdolliset validaatiovirheet läpi manuaalisesti. Kolmannen lomakkeen kohdalla aloin jo kyllästyä samojen asioiden toistamiseen. Päätin luoda Omasivarin ensimmäisen testin.

Ennen tätä lomakekoettelemusta en ollut osannut tunnistaa kehittämistäni sovelluksista sellaisia osia, jotka olisivat hyötyneet automatisoiduista testeistä. Tästä viisastuneena ymmärsin, että testaaminen kannattaa aloittaa sellaisista komponenteista, joita huomaa testaavansa toistuvasti käsin. Usein tätä tehdään juuri lomakkeiden kanssa, joiden kentissä olevat arvot määrittävät muun muassa sen, tuleeko lisätietokenttiä näyttää tai saako lomaketta edes lähettää. Testi tekee kaiken käsityön muutamassa sekunnissa ja takaa lomakkeen toimivan halutulla tavalla seuraavankin kerran, kun sitä pitää muuttaa.

Mitä testataan?

Edellä kuvaamani testauksen lähtökohtana on tarve toistaa käyttäjän tekemiä toimintoja. Kirjoitettavien testien tulisi siis varmistaa, että näiden toimintojen seurauksena tapahtuu juuri sitä, mitä halutaan tapahtuvan. Käyttäjä syöttää lomakkeen tiedot oikein ja lomake lähetetään. Tyhjäksi jätetty pakollinen kenttä johtaa puolestaan virheilmoituksen näkymiseen.

Käytetään esimerkkinä tapausta, jossa käyttäjä yrittää kirjautua sovellukseen ilman salasanaa. Lomake huomaa puuttuvan tiedon ja huomauttaa tästä käyttäjälle.

Havainnollistava kuva kirjautumissivusta

Testissä voidaan varmistaa, että lomakkeen renderöivän React-komponentin sisäinen tila muuttuu kuvaamaan virhetilannetta. Tätä kutsutaan implementaation testaamiseksi: ei tutkita käyttäjälle näkyvää toiminnan seurausta vaan tapaa, jolla lopputulosta tavoitellaan. Testi onnistuu, jos jokin muuttuja saa arvokseen Error objektin, mutta on vaarallista olettaa sen johtavan automaattisesti ruudulla näkyvään virheilmoitukseen.

On luotettavampaa testata komponentin käyttäytymistä käyttäjän näkökulmasta. Tutkitaan oikeasti renderöityä HTML-dokumenttia ja etsitään sieltä elementtiä, joka kertoo virheestä käyttäjälle. Testi onnistuu, jos elementti löytyy.

Kuvituskuva painikkeen implementaatiosta versus käyttäytymisestä

Mikään ei kuitenkaan ole mustavalkoista. Joskus voi huomata testaavansa implementaatiota vahingossa. Toisinaan se voi olla perusteltuakin. Vaikeinta on löytää itsensä jostain näiden rajamailta.

Millä React-komponentteja testataan?

Omaan testityökalupakkiini päätyivät seuraavat työkalut:

  • Jest – pyörittää koko testikoneistoa
  • jest-dom – tarjoaa varmistuksia HTML-dokumentin testaamiseen
  • React Testing Library – työkaluja DOM-elementtien etsimiseen ja manipuloimiseen intuitiivisella tavalla
  • user-event – simuloi käyttäjän tekemiä toimintoja todella helppokäyttöisesti

Kokeilin seuraavia työkaluja, mutta jätin ne tarkoituksella pois:

  • Enzyme – täyttää saman roolin kuin React Testing Library, mutta painottaa enemmän implementaation testaamista ja React-komponenttien sisäisen tilan tutkimista.

Jatkan seuraavassa kirjoituksessa käytännöllisemmillä esimerkeillä React-lomakkeiden testaamisesta. Käydään siellä läpi miten testi luodaan, mistä osista se koostuu, ja kuinka testejä ajetaan.

KEHA-keskus

Caset • Teknologia

KEHA-keskus – Sähköistä viestinvälitystä Suomi.fi-viestit palvelun kautta

React hooks – React blogi part 2

Teknologia

Matrix-kuva "What if I told you functions can have state"-tekstillä

Otetaanpas jälleen kevyt tekstin aloitus asiaan liittyvällä meemillä.

Yleistä React hookeista

  • Hookit ovat täysin taaksepäin yhteensopivia.
  • Hookkeja ei ole pakko käyttää. Niitä voi helposti testata muutamassa komponentissa ilman, että joutuu kirjoittamaan olemassa olevaa koodia uusiksi.
  • Luokat eivät ole poistumassa Reactista.
  • Hookit tuli käytettäväksi Reactin 16.8 versiossa.

Mitä Hookit ovat?

Ne ovat funktioita, joilla voi hallita Reactin tilaa ja ”napata” kiinni elinkaaren (lifecycle) ominaisuuksiin funktionaalisissa komponenteissa. Hookkeja ei voi käyttää luokka-komponenteissa – ne sallivat Reactin käytön ilman luokkia.

Osalle JavaScript-luokkien käyttö on saattanut aiheuttaa päänvaivaa, sillä ne eroavat muiden kielien luokista melkoisesti. Luokkia voi kuitenkin huoletta käyttää jatkossakin, sillä ne eivät ole Reactista poistumassa.

Hookeilla voidaan ”kaivaa” tilallista logiikan komponenteista, joita voidaan riippumattomasti testata ja uudelleen käyttää. Hookit sallivat tilallisen logiikan uudelleenkäytön muuttamatta komponentin hierarkiaa. 

Hookit ovat JavaScript funktioita, mutta niillä on kaksi sääntöä:

  • Hookkeja ei saa kutsua looppien sisällä tai nestatuissa funktioissa.
  • Hookkeja ei saa kutsua tavallisista JavaScript funktioista –niitä voi käyttää vain Reactin funktionaalisissa komponenteissa.

Omasta kokemuksesta voin sanoa, että funktionaaliset komponentit + hookit yksinkertaistavat React-devausta ja ovat nopeampia oppia verrattuna luokka-komponentteihin.

Mitä Hookit korvaavat?

  • Luokat
  • Render Prop kuvion

Hieman vaihtelevaa mielipidettä on siitä, mitä ne eivät korvaa. Muutamia on tullut vastaan tuolla internetin ihmeellisessä maailmassa, mutta teemaksi on alkanut muotoutua esimerkiksi seuraavat:

  • Redux
  • Higher Order Components (HOC)

Tässä täytyy nyt mainita, että luokka-komponenttien kanssa HOC tulee epäilemättä pysymään käytössä, mutta funktionaalisissa komponenteissa sen voi korvata custom hookeilla. Täältä käytännön esimerkkiä kuinka korvata HOC custom hookeilla: https://dev.to/gethackteam/from-higher-order-components-hoc-to-react-hooks-2bm9

Erityisesti Reduxin suhteen tuntuu olevan paljon mietintää siitä, voivatko Hookit sen korvata. Reduxin käytöllä on omat etunsa, etenkin koko sovelluksen tilaa hallittaessa. Hookkeja käytettäessä taas ei tarvitse latailla/asentaa mitään riippuvuuksia. Molemmissa on puolensa, joten voidaan todeta, että riippuu täysin tilanteesta, sovelluksen koosta ja tarpeesta, kumpaa kannattaa käyttää; oman sovelluksen osalta ratkaisua kannattaa harkita ja päätös tehdä tilannekohtaisesti.

Lähteet ja lisää luettavaa

https://joinex.fi/react-pahkinankuoressa/

https://reactjs.org/docs/hooks-intro.html

https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672

https://www.simplethread.com/cant-replace-redux-with-hooks/

Taukoviikkoblogi

Blogitekstit • Yrityskulttuuri

Istuva IT-persoona

Hartioita kivistää ja niska tuntuu jäykältä. Tuntuu kyllä, mutta mitäpä muuta kuin eteenpäin. Kipaisee kupin kahvia näytön viereen, eiköhän se tästä. Tuttu juttu, bitit vievät mennessään ja it-persoona jatkaa, painaen lihasten kivistyksen ja niskan jäykkyyden taka-alalle. Hän päättää mennä töiden jälkeen lenkille ja löytää itsensä pelien äärestä. Yleistyshän tämä on, mutta aika tuttu persoona joukossamme.

Lokakuun viimeisellä viikolla toimistomme persoonat saivat päivittäisen annoksen taukovinkkejä ja tekoja. Allekirjoittanut ohjeisti joukkoamme erilaisiin ja eri tyylisiin mahdollisuuksiin pitää minitaukoja työn lomassa. Tarkoitus oli palauttaa tietoisuuteen pieni, mutta tärkeä asia (työ)hyvinvoinnissa. Kuten hampaiden pesu, työn tauotus pitäisi saada alitajuntaan niin, että automaatio toimii lähes huomaamatta.

Vaihtoehtoja riittää, kuten meidän tehotaukoviikkoon.

Maanantai

Keskityimme hartiajumeihin. Me jopa testasimme olkapäiden ja hartioiden liikkuvuutta ennen ja jälkeen liikkeitä. Tulos parani jo pienen venyttelyhetken jälkeen. 

Tiistai

Klingendahlin kiinteistössä riittää käytäviä ja portaita, joita voi helposti hyödyntää varsinkin jalkojen jumien aukaisuun ja hengityksenkin saa tihentymään mukavasti. Ai, miten lonkankoukistajat tykkäsivätkään kunnon venytyksestä.

Keskiviikko

Lokakuun kaunis aurinko houkutteli hengittelemään raikasta ilmaa ja samalla juttelemaan niitä näitä työkavereiden kanssa. Lenkin varrella olleet kuntolaitteet pääsivät kokeiluun. Olkapää, jalat ja hartiat saivat mukavaa vastapainoa näppäimistön nakutteluun.

Työporukka kävelyllä Pyynikillä

Torstai

Emme lähteneet kauaksi työpöydän äärestä. Pelkkä selän oikaisu, lapojen ja olkapäiden herättely tuntui mukavalta vastapainolta etukumaralle asennolle. Kumma juttu, tarkkailemalla omaa hengitystä se tehostuu. Aivot saavat tarvitsemaansa happea ja mahdollinen stressikin vähenee. Väsyneet silmät virkistyivät pyörittelemällä ja rutistelemalla niitä kiinni ja auki. Tervetullut minibreikki keholle tämäkin.

Perjantai

Kokosimme viikon yhteen. Jokainen tietää, että tauot ovat tärkeitä, 1-2 kertaa tunnissa on optimi. Se lisää virkeyttä, tehokkuutta ja kehon hyvinvointia. Kuulostaa pieneltä, mutta tutkimus tukee juuri pienten taukojen sijoittamista työpäivään säännöllisesti. Pieneltä se tuntuu hampaiden pesukin, mutta muutaman päivän pesemättömyyden jälkeen voi tuntua tahmaiselta. Jos vertaus on ontuva, saa siitä kuitenkin oivalluksen siihen, miten pieni kehon huolto pitkällä tähtäimellä voi olla ratkaiseva.

Niin, tiedämme kyllä, kyse ei ole siitä. Kyse on siitä, miten saisimme itsemme tekemään näitä pieniä tekoja. Tiedostaminen, se on kaiken A ja O. Kaikki sataa omaan laariin ja toinen ei voi liikutella toista. Mietimme yhdessä, mikä olisi se juttu, mikä saisi persoonan kuin persoonan tarttumaan taukoon. Joitakin ideoita syntyi. Niistä myöhemmin. 

Perjantain pizza- ja pelitauko täydensivät viikon – aika palkita itsensä.

Toimiston pelihetki kokoushuoneessa.

Kolme vinkkiä verkkopalvelun uudistamiseen

Verkkopalvelut

Digitalisoitunut ympäristö tuo kuluttajan ulottuville lukuisia erilaisia palveluita. Näitä palveluita käytetään jokapäiväiseen asiointiin, kuten pankki- ja veroasioiden hoitoon, matkalippujen ostamiseen ja ostosten tekemiseen verkkokaupoista.

Ihmisille on muodostunut kuva siitä, miltä laadukkaan verkkopalvelun tulee näyttää ja miten sen pitää toimia. Useat päivittäin käytetyt palvelut ovat syntyneet satojen työ- ja suunnittelutuntien tuloksena. Niiden käytettävyyteen, toimivuuteen ja saavutettavuuteen on kiinnitetty erittäin paljon huomiota. Hyvin käytettävä ja helppokäyttöinen palvelu on jo itsestäänselvyys.

Ulkoasun ja toiminnallisuuden lisäksi palvelun laatuvaikutelmaan vaikuttaa myös palvelin. Verkkopalvelun hitaus saattaa vaikuttaa negatiivisesti mielikuvaan, ja toki myös sijoituksiin hakutuloksissa. Ei siis ole ihan sama miltä palvelu näyttää ja miten se toimii. Ensivaikutelman voi tehdä vain kerran!

Aseta tavoitteet uudistamiselle

Verkkopalvelua ei kannata uudistaa vain uudistamisen takia. Asettamalla liiketoimintaa tukevia, selkeitä ja saavutettavia tavoitteita on uudistusprojekti investointi eikä kuluerä. Palvelun nopeuttaminen ja käyttöliittymän selkeyttäminen lisäävät asiakastyytyväisyyttä, ja sitä kautta saat aikaan parempia tuloksia.

Tavoitteiden asettamiseen voidaan käyttää esimerkiksi SMART-työkalua. Sillä tavoite voidaan asettaa järkevästi viiden eri määritteen avulla, jolloin tavoitteesta tulee mm. selkeä, mitattava ja realistinen.

Valitse kokenut kumppani

Paras kumppani omaa sopivan yhdistelmän kokemusta ja näkemystä. Kokemus takaa kuhunkin projektiin oikeat, järkevät ratkaisut. Kumppanilla tulee olla myös näkemystä digitaalisen maailman mahdollisuuksista, jotta projektiin saadaan kunnon pohja pitkäjänteiseen kehitystyöhön.

Suunnittele käyttäjälähtöisesti, toteuta ketterästi

Kun projektin lähtökohtina ovat sisältö ja asiakas, olet jo matkalla oikeaan suuntaan. Verkkopalvelua on helpompi käyttää ja hahmottaa, kun käyttöliittymä on suunniteltu asiakaslähtöisesti. Myös sisältö ja sen rakenne helpottavat käyttäjää sisäistämään ja hyödyntämään palvelua paremmin. 

Ketterällä ja joustavalla toteutuksella mahdollistat projektin etenemisen joutuisasti ja sen, että projekti valmistuu aikataulussa. Hyvän kumppanin kanssa pääset avoimesti seuraamaan projektin etenemistä sekä vaikuttamaan sen etenemiseen.

Suomi.fi-viestit osana EU:n digitaalista palveluväylää

Digitalisaatio • Teknologia

Asetus digitaalisen palveluväylän perustamisesta hyväksyttiin EU:n neuvostossa 27.9.2018. Palveluväylän on tarkoitus mahdollistaa esimerkiksi muuttoon, työskentelyyn tai opiskeluun liittyvien asioiden hoitamisen kaikissa jäsenmaissa digitaalisia kanavia pitkin. Asiointi tapahtuu euroopanlaajuisen Sinun Eurooppasi -portaalin kautta. Määräaikaa palveluiden sähköistämiselle on annettu vuoteen 2023 asti.

Tämä päätös pakottaa jäsenmaita uudistamaan järjestelmiään niin, että niitä voidaan käyttää kokonaan verkon välityksellä. Lisäksi kansalaisille tarjottavien palveluiden tulee noudattaa yksi tieto yhteen kertaan -periaatetta jonka mukaan tietoa ei saisi kysyä uudestaan, mikäli se on jo toisessa EU-maassa käyttäjästä olemassa. 

“Julkisen hallinnon asiakkuusstrategian mukaan viranomaisten tulee huolehtia siitä, että sähköinen kanava on asiakkaalle houkuttelevin vaihtoehto.”

Valtiovarainministeriö 2019

Laki digitaalisten palveluiden tarjoamisesta tuli voimaan 1.4.2019, ja se velvoittaa julkishallinnon toimijoita tarjoamaan jokaiselle mahdollisuuden asiointiin ja asiakirjojen lähettämiseen sähköisesti. Väestörekisterikeskuksen ylläpitämä Suomi.fi-palvelu on tärkeä osa näitä digitaalisia palveluita, ja tulevina vuosina pääpaino kehittämisessä onkin etenkin Suomi.fi-palvelun eri osa-alueissa, kuten Tunnistuksessa, Valtuutuksissa ja Viestit-palvelussa.

Suomi.fi-viestien kautta asioita voidaan hoitaa tunnistautuneena, luotettavasti ja turvallisesti. Käyttäjien määrä on kasvussa, ja elokuussa 2019 palvelua käytti yli 230 000 suomalaista. Käyttäjämäärä on yli kaksinkertaistunut vuodesta 2018. 

Viranomaisen lähettäessä salassa pidettävää tietoa tulee varmistua vastaanottajan henkilöllisyydestä. Perinteinen sähköposti ei siis ole tietoturvaltaan riittävä tällaiseen viestintään. Tällä hetkellä viestien lähettäminen tapahtuu suomalaisen henkilötunnuksen perusteella, mutta myös henkilötunnuksettomien käsittely tulee myöhemmin mahdolliseksi. Tietopyyntö tai viesti voi siis jatkossa tulla myös muusta EU-maasta.

Viestit-palvelu on usein integroitavissa osaksi olemassa olevaa järjestelmää, eikä kokonaan uutta järjestelmää tarvita. Samalla voidaan ottaa käyttöön myös muita Suomi.fi -palveluita, jolloin yhä enemmän toimintoja saadaan uuden palveluväylän piiriin. Esimerkiksi Suomi.fi-tunnistautuminen lisää turvallisuutta ja vapauttaa järjestelmät tunnusten ylläpidosta niiden ydintoimintojen suorittamiseen. Lisäksi Suomi.fi-tunnistautuminen tarjoaa kertakirjautumisen edut.

Sekä asiointi että asiakirjojen lähettäminen ja vastaanotto tapahtuu tulevaisuudessa yhä enemmän sähköisesti. Uuden lain tuoma velvoite aiheuttaa työtä Suomi.fi -palveluiden integroinnissa kuntien ja viranomaisten omiin järjestelmiin. Nämä uudistukset kuitenkin helpottavat ja nopeuttavat kansalaisten asiointia, ja sitä kautta säästämme myös yhteisiä verovaroja. Sähköinen viestintä vähentää paperipostia ja on paitsi taloudellista myös ympäristönsuojelua tukevaa.

Lisätietoa

https://uutiskirjeet.vrk.fi/uutiset/suomi.fi-palvelut/suomi.fi-palvelut-nyt-ja-tulevina-vuosina.html?p26=2

https://esuomi.fi/palveluntarjoajille/viestit/

https://vrk.fi/blogit/-/blogs/single-digital-gateway-ja-suomi-fi-palvelut

https://www.consilium.europa.eu/fi/press/press-releases/2018/06/20/digital-single-gateway-easier-access-to-online-information-and-procedures/

Saavutettavuudella varmistat viestisi perillemenon

Design • Digitalisaatio • Teknologia

Valtiovarainministeriön mukaan “saavutettavuudella tarkoitetaan, että verkkosivut ja mobiilisovellukset sekä niiden sisällöt ovat sellaisia, että kuka tahansa voisi niitä käyttää ja ymmärtää, mitä niissä sanotaan”. Toisin sanoen verkkosivut ja mobiilisovellukset tulee toteuttaa teknisesti ja visuaalisesti siten, että toimintarajoitteiset käyttäjät pystyvät käyttämään palvelua ja sen sisältöä. Nämä vaatimukset pohjautuvat WCAG-kriteereihin.

Kun puhutaan saavutettavuudesta, usein ensimmäiseksi mieleen tulee ikäihmiset sekä näkö- ja kuulovammaiset. Näiden lisäksi esimerkiksi aisti- ja kehitysvammaiset sekä keskittymisvaikeuksista kärsivät luetaan ryhmiin, jotka hyötyvät saavutettavuudesta eniten. Nämä ovatkin tärkeitä ja huomionarvoisia käyttäjäryhmiä. Saavutettavuuden tarve voi kuitenkin olla myös tilapäinen: kenen tahansa havainnointi- ja toimintakyky voi olla väliaikaisesti rajoittunut esimerkiksi onnettomuudesta, mielentilasta tai olosuhteista johtuen.


Ennusteen mukaan vuoteen 2020 mennessä yli 120 miljoonalla ihmisellä, eli 20% Euroopan väestöstä on jonkinasteinen toimintarajoitus.

https://europa.eu/rapid/press-release_IP-15-6147_en.htm

Saavutettavuutta parantamalla varmistetaan se, että käyttäjäryhmästä riippumatta verkkopalvelun käyttö on helppoa ja sen sisältö ymmärrettävää. Huomioon otettavia asioita ovat esimerkiksi navigaation selkeys, värit ja kontrastit, sisältötekstin ymmärrettävyys, asettelu ja rakenne, sekä myös tekniset asiat erilaisia lukulaitteita varten.

Verkkopalvelun käyttö pitää olla mahdollista myös pelkän näppäimistön avulla. Ihmiset, joilla on rajoitteita näkemisessä tai käsien toiminnassa, eivät välttämättä pysty käyttämään hiirtä lainkaan. Näppäimistöselaaminen asettaa vaatimuksia teknisiin valmiuksiin sekä visuaaliseen palautteeseen: linkit on rakennettava siten, että ne toimivat loogisesti sarkaimella sekä tarjoavat riittävän visuaalisen palautteen käyttäjälle.

Vaatimukset eivät koske pelkästään verkkosivustoja ja mobiilisovelluksia. Myös sivustoilla jaettavien videoiden, äänilähetysten ja tiedostojen on oltava saavutettavuusvaatimusten mukaisia. Word- ja PDF-dokumenttien saavutettavuus ei ole itsestään selvää, vaan vaatii johdonmukaisuutta sekä selkeyttä rakenteen ja tekstisisällön suhteen. Videoiden ja äänitteiden mukana tulee tarjota sisältöä myös tekstimuodossa. Sosiaalisessa mediassa videoiden tekstitys on jo havaittu toimivaksi keinoksi katsoa videoita ilman ääniä.

Lisäksi kannattaa muistaa, että saavutettava verkkopalvelu on todennäköisesti käytettävämpi myös ei-rajoitteisille käyttäjille!

Paranna näkyvyyttä ja tuloksia saavutettavuudella

Saavutettavuudella on myös hakukoneoptimoinnin kannalta merkitystä. Googlen algoritmi arvostelee verkkopalvelua sekä teknisesti että kävijöiden käyttäytymisen perusteella. Huonosti saavutettavissa olevasta verkkopalvelusta poistutaan, jolloin Google tulkitsee sivussa olevan jotain vikaa.

Tutkimuksen mukaan 71% toimintarajoitteisista kävijöistä poistuu verkkopalvelusta välittömästi, jos se ei ole saavutettavissa. He hakeutuvat saavutettavien palveluiden äärelle ja kuluttavat mielellään jopa enemmän. Kun parannat verkkopalvelusi saavutettavuutta, et vain pidä nykyisiä käyttäjiäsi, vaan saat heidät käyttämään enemmän rahaa.

Laskuesimerkki verkkokaupan saavutettavuuden vaikutuksesta:

  • 100 000 kävijää, keskiostos 100€, konversio 3%
  • Toimintarajoitteisia 20%, 20 000 kävijää
  • He kuluttavat 20 000 * 0,03 * 100€ = 60000€
  • Jos sivusto ei saavutettavissa, tästä 71% jää saamatta = 42600€

Lisää vaatimuksia verkkopalveluIlle

Saavutettavuus tuo mukaan myös oikeuksia verkkopalvelun käyttäjälle ja vaatimuksia ylläpitäjälle. Palvelusta täytyy tietosuojaselosteen lisäksi löytyä jatkossa myös saavutettavuusseloste, ja käyttäjän palautteeseen on vastattava kahden viikon kuluessa. Selosteen luomiseen on olemassa valmis työkalu, joka löytyy osoitteesta https://www.saavutettavuusvaatimukset.fi/saavutettavuusseloste/.

Aikataulullisesti vaatimukset ovat jo 23.9.2018 jälkeen julkaistujen verkkopalveluiden osalta voimassa. Sitä aiemmin julkaistujen palveluiden ja tiedostojen tulee olla saavutettavissa 23.9.2020.

Siirtymäajat

23.9.2019
Kaikkien julkishallinnon palveluiden, jotka on julkaistu 23.9.2018 jälkeen, on oltava vaatimusten mukaisia. Tämä koskee myös tiedostoja.

23.9.2020
Ennen 23.9.2018 julkaistujen julkishallinnon palveluiden ja tiedostojen tulee täyttää vaatimukset.

1.1.2021
Vaatimusten piiriin kuuluvien yksityisen sektorin toimijoiden (esim. pankki-, liikenne- ja vakuutusalojen) palvelut on oltava saavutettavuusvaatimusten mukaisia.

23.6.2021
Mobiilisovellusten tulee täyttää saavutettavuusvaatimukset.

Lisää aiheesta:

Saavutettavuusdirektiivi.fi
Saavutettavuusvaatimukset.fi
Valtiovarainministeriö
Lain saavutettavuusvaatimukset tuovat isoja muutostarpeita julkisen sektorin verkkosivustoihin (AVI)

PS. Tutustu myös Euroopan Unionin Esteettömyysdirektiiviin

Selainpohjaisilla sovelluksilla tavoitat käyttäjäsi paremmin

Digitalisaatio • Teknologia

Mobiilisovellukset on jo jonkin aikaa voitu toteuttaa natiivisovelluksien lisäksi myös selainpohjaisesti. Näitä selainpohjaisia sovelluksia kutsutaan termillä progressive web app tai lyhyemmin PWA. Ne mahdollistavat lähes samankaltaisen käyttökokemuksen kuin natiivisovellukset ja tarjoavat tavanomaisia verkkosivuja kattavammat työkalut puhelimen muiden ominaisuuksien hyödyntämiseen.

PWA-logo

Verkkosivujen latausajoista puhutaan paljon. Jos sivun latautuminen kestää liian kauan, katsoja kyllästyy helposti ja siirtyy toiselle sivustolle. Sama koskee myös natiivisovelluksia, joiden käyttökynnyksenä on lisäksi asennus. Toisin sanoen sivun ja sovelluksen nopeuttaminen lisää kävijöiden määrää ja saa kävijät viihtymään sivustolla kauemmin, jolloin kävijät myös konvertoituvat paremmin – eli he toimivat sivuston tavoitteiden mukaisesti. Myös PWA-sovelluksia voidaan verkkosivujen tavoin optimoida hakukonenäkyvyyden kannalta, sillä PWA-sovellus on käytännössä verkkosivu laajennetuilla ominaisuuksilla.

Twitter toteutti sovelluksensa PWA-muotoisena ja huomasi, että käyttäjien sitoutuminen parani merkittävästi. Sovelluksen käynnistysaika parani 50% ja tarvittavan tallennustilan määrä tippui 3%:iin (23,5Mt vs 0,6Mt). PWA-sovellus latautuu myös hitaammassa verkossa nopeasti.

Hotellien vertailupalvelu Trivago etsii jatkuvasti keinoja parantaa käyttäjäkokemusta ja tavoittaa uusia käyttäjiä. Heidän PWA-sovelluksensa ansiosta käyttäjien sitoutuminen parani 150% ja konvertoituminen 97%. Samanlaisia tuloksia oli nähtävissä myös Forbesin projektissa. Heillä istuntojen määrä kasvoi 43% käyttäjää kohden ja mainosnäyttöjen lukumäärä nousi 20%. PWA:n hyödyntäminen heijastuu siten selkeästi myös liiketoiminnan tuloksiin.

Jos harkitset natiivisovelluksen hankkimista, ota selvää, voisiko sen toteuttaa selainpohjaisena PWA-sovelluksena. Kehitysaika lyhenee, ylläpidettävyys helpottuu, eikä useiden sovelluskauppojen kanssa hallinnointia tarvita. 

Pähkinänkuoressa:

  • Selainpohjainen, ei vaadi sovelluksen asentamista.
  • Sovellus toimii myös ilman verkkoyhteyttä.
  • Käyttäjiä voidaan lähestyä ilmoituksilla suoraan laitteeseen.
  • Löydettävyys paranee hakukoneoptimoinnin ansiosta.
  • Ei laitekohtaisia versioita tai sovelluskauppoja.
  • Päivitykset ovat välittömästi saatavilla, ei asennuksia.

PWA-sovelluksen rakentaminen

PWA-sovellus rakennetaan samaan tapaan kuin tavallinen nettisivu. Sovellus koostuu HTML:stä, JavaScriptistä, kuvista ja tyylitiedostoista. Toiminnallisuutta täydennetään Service worker -JavaScripteilla, jotka tekevät määriteltyjä toimintoja taustalla. Nämä mahdollistavat mm. tiedostojen latauksen välimuistiin. Tutustu yksinkertaiseen rakennusohjeeseen täällä, ja hieman seikkaperäisempään ohjeistukseen Googlen Code Labsissa. Jos sinulta löytyy tekstieditori, ohjelmisto tiedonsiirtoon palvelimelle ja vaikka Google Chrome-selain, on käytössäsi jo tarvittavat työkalut selainpohjaisen sovelluksen julkaisemiseen.

Sekä iPhone että Android tukevat PWA-sovelluksia, joten saat nopeasti ja vaivattomasti julkaistua alustariippumattoman, responsiivisen sovelluksen.

Haluatko kuulla lisää?

Työ- ja elinkeinoministeriö

Caset • Teknologia

Työ- ja elinkeinoministeriö – Tehokkaampaa sovelluskehitystä mallinnuksen avulla