tiistai 10. marraskuuta 2020

Ketterä testaus

Perinteisesti testaus on ollut viimeinen vaihe järjestelmän kehityksessä ennen valmistumista. Lähtökohtaisesti se ei siis ole voinut tapahtua kovinkaan ketterästi koska kattava testaus tarvitsee toimivan version koko järjestelmästä.

Uudet kehitysmallit kuitenkin kyseenalaistavat tätä ajattelua, ja harvassa projektissa on enää mahdollisuutta varata testaukseen riittävä aika ja resurssit projektin loppuvaiheeseen. Tarvitsemme siis ehdottomasti testausta pitkin matkaa, mutta käytännössä siinä on kuitenkin erilaisia haasteita.

Ketterän testauksen haasteita


Muuttuvat vaatimukset

Kattava ja laadukas järjestelmän testaus edellyttää riittävän tarkkoja määrittelyitä, joiden pohjalta testitapaukset ja mahdollinen testiautomaatio rakennetaan. Ketterässä kehityksessä vaatimukset kuitenkin tarkentuvat tai jopa muuttuvat matkan varrella. Käyttäjätarinat ovat harvoin projektin alkuvaiheessa riittävän tarkkoja kaikkien testitapausten määrittelyä varten. Sprinttien valmistumisen ja katselmoinnin myötä tiimin näkemys ratkaisusta muuttuu tai vähintään tarkentuu ja sitä kautta testejä tulee tarkentaa projektin edetessä.

Testausasiantuntijat onkin syytä ottaa mukaan tärkeisiin kokouksiin, kuten sprintin suunnitteluun ja katselmointiin. Ja on tärkeää että he ymmärtävät sekä asiakkaalle tärkeimmät ominaisuudet että ei-toiminnalliset vaatimukset (kuten tietoturvan) ja osaavat kohdistaa testauksen panokset näihin. Mutta heidän roolinsa ei enää ole suorittaa kaikkea testausta.


Sprinttien testaus

Kehitystiimi toteuttaa tuotteeseen uutta toiminnallisuutta jokaisessa sprintissä viikon-kahden välein. Miten nämä saadaan testattua kattavasti niin, että tiimi voi luottavaisesti demonstroida uusia toimintoja? Tämä onkin keskeinen kysymys, jota kannattaa pohtia jo ennen kuin projekti on käynnissä.

Ketterän testauksen periaatteiden mukaan koko tiimi testaa ja valvoo laatua aina kun tuotoksia syntyy. Kehittäjät tekevät yksikkötestit ennen koodauksen aloittamista ja testaavat tarinat niiden valmistuttua. Ihanteellisesti näiden tulisi olla mahdollisimman pitkälle automatisoitu. Tuoteomistaja (Product Owner) määrittelee käyttäjätarinoille hyväksymiskriteerit, ja myös testaa niiden toteutumisen kun kyseinen tarina on toteutettu. Asiakas tekee hyväksymistestauksen kun sopiva julkaisu on valmiina tuotantoympäristössä.


Testaustiimin laajempi rooli

Kun ketterässä kehittämisessä koko tiimi on vastuussa laadusta, perinteisen testaustiimiin (tai paremminkin testausasiantuntijoiden) rooli on hyvin erilainen. Heidän tehtävänsä on ennen kaikkea tukea muuta tiimiä, niin että testaus voi edetä muun kehittämisen mukana. Käytännössä tähän voi kuulua esimerkiksi:
  • Testausnäkökulman (hyväksyntäkriteerit) edistäminen ja varmistaminen käyttäjätarinoiden kirjoittamisessa
  • Testiautomaation ja muiden testausvälineiden käyttöönotto ja tuki
  • Muun tiimin avustaminen laadunvarmistamiseen liittyvissä tehtävissä
Tehokas testaus ja sen automaatio edellyttää tänä päivänä vahvaa osaamista sekä siihen käytettävistä välineistä että testattavasta järjestelmästä. Jos esimerkiksi järjestelmiin rakennetaan uusia rajapintoja, tulisi nämä testata erikseen eikä vain niitä käyttävien sovellusten kautta.

Riittävää osaamista ei kuitenkaan välttämättä kaikilla kehittäjillä tai tuoteomistajilla ole, ja testaajien apu on tällöin kullan arvoinen. Tämä pitää myös muistaa kun tiimejä resurssoidaan, valitettavan usein käytännössä testausosaaminen on pahasti aliedustettuna.


Automaation merkitys

Miksi automaatio on tärkeää ketterässä testauksessa? Vastaus on lopulta varsin yksinkertainen. Iteratiivinen kehitys tuottaa uusia toiminnallisuuksia tietyn perustan päälle, joka kasvaa joka iteraatiossa, mutta on (yleensä) muuttumaton tulevissa iteraatioissa. Olisi tärkeätä, että tähän perustaan kohdistuvat testit saataisiin automatisoitua mahdollisimman pitkälle ja suoritettua kaikkien tulevien iteraatioiden aikana regressiotesteinä.

Mikäli automaatiota ei saada rakennettua, tarvittavan testauksen määrä kasvaa kohtuuttoman suureksi kun uutta toiminnallisuutta on testattava tarkkaan, mutta perustakin on testattava, jotta varmistutaan että muutokset eivät ole vaikuttaneet sen ulkoiseen toimintaan. Kannattaa myös muistaa, että ketterään kehittämiseen usien kuuluva refaktorointi lähtökohtaisesti lisää regressiotestauksen tarvetta.

keskiviikko 30. syyskuuta 2020

Sanojen merkityksestä

Vaatimusten määrittely on periaatteessa yksinkertainen tehtävä. Kuunnellaan, mitä asiakas haluaa ja kirjoitetaan vaatimukset sopivaan muotoon, niin että kehittäjät voivat ne toteuttaa. Tehtävä sisältää kuitenkin monia haasteita ja mahdollisia sudenkuoppia.

Kehitysmalleja on erilaisia ja vaatimukset voivat olla käyttäjätarinoita tai muodollisempia kuvauksia määrittelydokumentissa. Silti lähes poikeuksetta ne kuvataan sanallisesti, Suomessa yleensä suomeksi, ruotsiksi tai englanniksi.

Luonnollisen kielen haasteita

Kieli on viestintää kirjoittajalta lukijalle, ja on todennäköistä että kirjoittajan ja lukijan tiedoissa ja kokemuksissa on eroja. Tällöin tekstin ymmärtäminen voi olla vaikeata tai monimerkityksinen ilmaisu ymmärretään väärin. Esimerkiksi seuraavat asiat aiheuttavat usein haasteita vaatimusteksteissä:
  • Ammattislangi ja lyhenteet
  • Epäselvät sanat
  • Sekavat ja monimutkaiset lauserakenteet
  • Liiallinen tarinointi
  • Kielimuuri

Slangi ja lyhenteet

Omassa työporukassa on luontevaa käyttää ammattislangia ja lyhenteitä. Kuitenkin, jos halutaan tuottaa muille sidosryhmille ymmärrettävää tekstiä, slangi tulisi korvata selkeällä yleiskielellä. Usein esimerkiksi teknisten järjestelmien vaatimuksissa toki tarvitaan täsmällisiä ammattitermejä. Näistä voidaan tehdä erillinen sanasto, jossa niiden merkitys avataan sidosryhmille tarpeellisella tarkkuudella. Samalla varmistetaan, että yhdestä käsitteestä käytetään aina samaa termiä. Lyhenteet voidaan koota samaan sanastoon.

Epäselvät sanat

Adjektiivit ovat usein luonnostaan epätarkkoja, vailla selkeää mittaria tai vertailukohtaa. Vaatimusteksteissä näkee edelleen valitettavan usein epämääräisiä määreitä kuten "helppokäyttöinen", "standardinmukainen" tai "nopea vasteaika". Korusanat ovat käytännössä vailla merkitystä ellei niihin saada liitettyä todennettavia mittareita. Helppokäyttöisyyteen voi pureutua esimerkiksi määrittämällä tarvittavien hiiren klikkausten määrän jonkin tehtävän suorittamiselle.

Sekavat ja monimutkaiset lauserakenteet

Matematiikassa loogisissa lauseissa eri operattoreilla on määrätyt ensisijaisuudet (EI, JA, TAI) ja lauseita voidaan tarvittaessa myös selventää sulkumerkeillä. Luonnollisessa kielessä näitä keinoja ei ole, vaan lauserakenne on muotoiltava niin että väärinymmärrys ei ole mahdollinen.

Esimerkiksi seuraava lause: "Bonuskorttia käyttävät tai alennuskoodi-asiakkaat ja yli 100 eurolla tilaavat saavat ilmaisen toimituksen" voidaan tulkita kahdella eri tavalla:
  1. bonuskortti TAI (alennuskoodi JA yli 100 €)
  2. (bonuskortti TAI alennuskoodi) JA yli 100 €)
Monimutkaisia ehtoja sisältävät pitkät lauseet kannattaakin yleensä purkaa erillisiksi lauseiksi taikka taulukoiksi. Jos tarkoitettiin tulkintaa 1, voidaan muotoilla esimerkiksi: "Bonuskorttia käyttävät saavat aina ilmaisen toimituksen. Lisäksi ilmainen toimitus annetaan, jos käytössä on alennuskoodi ja tilaus on arvoltaan yli 100 euroa."

Liiallinen tarinointi

Monet puhujat pitävät puhumisesta ja jatkavat tarinaansa erilaisilla täytesanoilla ja poikkeavat asiasta sivuraiteille. Samoin sitten käy helposti kirjoitettaessa.

Vaatimuksia kirjoitettaessa kannattaa sensijaan harkita tarkkaan jokaisen sanan merkitys ja miettiä lauseista onko se tarpeellinen asian ymmärtämisen kannalta vai turhaa täytettä. Asioiden kertaaminen on ehdottoman turhaa. Tulee muistaa, että turhaan pidennetty teksti hidastaa lukemista ja tekee mahdollisista muutoksista aina vaikeampia.

Toki liian niukkakaan ei saa olla, vaan tekstissä tulee olla kaikki tarpeellinen muttei mitään ylimääräistä.

Kielimuuri

Englannin kieltä käytetään Suomessa ja muissa ei-englanninkielisissä maissa paljon työkielenä. Monet kieltä osaavat (yli 75%) eivät kuitenkaan puhu sitä äidinkielenään. Vaikka kieli on yleinen, se ei ole erityisen helppo, muun muassa sanaston rikkauden johdosta. Tästä seuraa paljon potentiaalisia ymmärtämisen ongelmia.

Mitä siis neuvoksi? Yllä olevat keinot auttavat paljon tässäkin. Kannattaa ehkä harkita onko aina pakko käyttää englantia vai voisiko täysin kotimaassa tehtävän projektin määritellä suomeksi.

Kokemuksen ja koulutuksen kautta opimme paremmiksi vieraan kielen käyttäjiksi. Jos teksti on tärkeä, kannattaa se aina tarkastuttaa toisella lukijalla. Myös ammattiapua on tarjolla. ImproveIt:n tytäryhtiö WriteIt tarjoaa englannin kielentarkastusta vankalla kokemuksella. Siitä voit lukea lisää täältä.

keskiviikko 2. syyskuuta 2020

Vaatimusten määrittely hybridiprojekteissa

Kokoan tähän artikkeliin ajatuksiani vaatimusten määrittämisestä hybridiprojekteissa, joissa sovelletaan perinteistä projektinohjausta yhdistettynä ketterän kehittämisen menetelmiin. Tällainen malli on tänä päivänä erittäin yleinen tapa toteuttaa ohjelmistoja muun muassa suurissa suomalaisyrityksissä.

Hybridiprojektin dilemma

Perinteisen projektin eteneminen on tyypillisesti sidottu joihinkin ohjauspisteisiin, laatuportteihin tms. Yksi kriittinen portti on se, jossa projektille myönnetään rahoitus ja muut resurssit varsinaista kehittämisvaihetta varten. Perinteisellä mallilla tässä vaiheessa kyseisen vaiheen vaatimukset olisivat valmiit ja niiden perusteella voitaisiin arvioida työmäärä ja sitoutuminen vaiheen tavoitteisiin.

Ketterässä mallissa sen sijaan tällaista laajempaa sitoutumista ei tehdä, vaan työhön lähdetään yksi sprintti - yleensä kaksi viikkoa - kerrallaan. Vaatimuksia voidaan tarkentaa, lisätä tai poistaa vaiheen aikana kun tarpeet ja toteutuksen reunaehdot tarkentuvat. Ketteriin työtapoihin kuuluu kuvata vaatimukset pääsääntöisesti yksinkertaisesti käyttäjätarinoiden muotoon. Esimerkiksi näin:

Asiakkaana haluan, että voin antaa osoitteeni profiilitiedoissani, jotta saan toimitukset oikeaan osoitteeseen.

Haasteeksi muodostuu helposti "liikkuva maali". Projektinohjauksen edellyttämät korkean tason tavoitteet on ollut pakko määritellä ilman tarkkoja vaatimuksia. Riskialtteissa hankkeissa nämä tavoitteet todennäköisesti elävät paljonkin projektin aikana kun ketterä toteutus tuottaa uusia prototyyppijulkaisuja ja ymmärrys niiden toiminnasta lisääntyy. Lopputulos voi olla hieno, mutta se ei vastaa alkuperäisiä tavoitteita. Projektin ohjausryhmä on vähintään hämillään ja liikennevalot keltaisena tai punaisena.

Miten tätä dilemmaa voidaan lievittää?

Hybridiprojektien määrittelyssä lähtökohtana ei tulisi olla pelkästään käyttäjätarinat. Monet ketterien mallien variaatiot antavat mahdollisuuden koota tiettyyn toiminnallisuuteen liittyvät tarinat featureiksi ja/tai epiceiksi. Onkin järkevää käyttää näitä samoja määrittelyn elementtejä myös projektin tavoitteiden kuvaamiseen. Pelkkä featureiden nimeäminen ei kuitenkaan ratkaise asiaa, vaan niihin täytyy sisällyttää tarpeeksi yksityiskohtia, jotta tiedetään ainakin:
  1. Featuren hyväksymiskriteerit ja työmäärä (karkealla tasolla)
  2. Riippuvuudet muihin projekteihin
  3. Toteutukseen liittyvät riskit (esim. uudet alustat tai teknologiat)
Hybridiprojektissa ei siis yleensä kannata lähteä heti alussa ajamaan toteutusta eteenpäin kehitystiimin kanssa. Sen sijaan seuraavan kehittämisvaiheen featuret tulisi ensin määritellä riittävällä tasolla, jotta projektinohjauksen tarpeet katetaan. Kun laatuportista on sitten päästy läpi, sprinttien suunnittelu on jatkossa helpompaa, kun riippuvuudet ja riskit on jo kartoitettu.

Projektin testausorganisaatio on yleensä myös mielissään, jos heillä on selkeät feature-tason vaatimukset käytettävissään kun kehitysvaihe alkaa.

Sitten on tälläinen NFR

Ei-toiminnalliset vaatimukset, (Nonfunctional Requirements) voivat ketterissä tai hybridiprojekteissa tulla tiimille yllättäen tietoon. Nimensä mukaisesti nämä eivät yleensä tule ilmi, kun käyttäjätarinoita kartoitetaan käyttäjien kanssa. Ei-toiminnalliset vaatimukset liittyvät yleensä johonkin seuraavista osa-alueista:
  • Suorituskyky
  • Tietoturva
  • Käytettävyys
  • Saavutettavuus
  • Brandin mukaisuus
Projektilla tulisikin olla sovittu menettely, jolla nämä kootaan ja käsitellään tarvittavien sidosryhmien kanssa. Tyypillisesti muun muassa organisaation laki-, tietoturva- ja tietohallinto-osasto määrittelevät omia ei-toiminnallisia vaatimuksia uusille projekteille tai tuotteille. Jos nämä jätetään huomiotta projektin alussa, niin kustannus niiden lisäämisestä jälkikäteen voi olla huomattavasti korkeampi.

Lopputuloksena ei-toiminnallisten vaatimusten käsittelystä syntyy projektin backlogille käyttäjätarinoita vastaavia teknisiä "enabler-tarinoita", tarvittaessa myös kokonaisia teknisiä featureita. Kun pidetään mielessä edellä mainittu hybrididilemma, niin nämä tulisi sisällyttää alkuvaiheen feature-suunnitteluun.