Teimme viime vuonna webinaarin nimellä Testaaminen on bisneskriittistä tekemistä. Bisneskriittisyyden perustelemisen lisäksi , webinaari käsitteli pitkälti ohjelmistotestauksen johtamista liiketoiminnan näkökulmasta. 

Saimme lukuisia kiitoksia sisällöstä, joten ajattelimme, että voisi olla hedelmällistä palata aiheeseen myös tekstimuodossa. Tämän kattavan tekstin luettuasi tiedät mitä ohjelmiston laatu tarkoittaa, miksi ohjelmistotestaus on tärkeää liiketoiminnan kannalta sekä miten ohjelmistotestausta tulisi johtaa. 

Teksti on melko tuhti, joten saatat haluta hypätä suoraan tiettyyn kohtaan. Tässä siis vielä sisältö: 

1. Miksi ohjelmistotestaus on liiketoiminnalle tärkeää
2. Mitä ohjelmiston laatu tarkoittaa
3. Miten rakentaa liiketoiminnan kannalta tehokas testausstrategia
4. Miten ohjelmistotestausta tulisi johtaa, jotta saavutetaan liiketoiminnan tavoitteet

1. Miksi ohjelmistotestaus on liiketoiminnalle tärkeää

Ohjelmistotestaus ei suinkaan ole tärkeää vain siksi, että vältyttäisiin virheiltä. Virheiden välttäminen on vain yksi osa ohjelmiston hyvää laatua. Mennään kohta syvemmälle ohjelmiston laadun eri aspekteihin. 

Kuitenkin, koska draama kiinnostaa aina, otetaan nyt alkuun herättelyksi muutamia esimerkkejä tilanteista, joissa testaus on mennyt pieleen ja liiketoiminta on ottanut iskun vastaan. 

Boeing

Moni on varmaan tästä kuullutkin, ei ne lentokoneet nimittäin taivaalta ihan joka päivä tipu. Tässä tapauksessa kuitenkin tippui, ja mikä pahinta, ohjelmistovirheen vuoksi. Koneen sakkauksenestojärjestelmä toimi virheellisesti ja pakotti koneen keulaa alas lentäjien toiminnasta huolimatta. Turmatutkimuksessa FAA löysi järjestelmän testaamisesta puutteita. 

Pepsi

Tämä on vähän erikoisempi. Pepsillä oli vuonna 1992 markkinointitempaus, jossa yhdessä korkissa piti olla numero 349, joka toisi löytäjälleen miljoonan peson voiton (useamman vuoden keskipalkka). Voittajakorkkeja kuitenkin painettiin ohjelmistovian vuoksi yhden sijaan 800 000 kappaletta. Hups. Ihmiset sekosivat korkkijahtiin, josta seurauksena oli valitettavasti taloudellisten tappioiden lisäksi mellakoita ja jopa ihmishenkien menetyksiä. 

Intel

Intelille matematiikkaprosessoriin sattui vuonna 1993 pääsemään pienen pieni pyöristysvirhe. Virhe oli jokseenkin marginaalinen, mutta maineen kannalta hyväksymätön. Paikatakseen mainettaan Intel lupasi kaikille halukkaille korvaavan tuotteen. Pienen pieni pyöristysvirhe johti satojen miljoonien eurojen kustannuksiin. 

McDonald’s

Loppuun hieman kevyempi kämmi. Mäkkärin softaan päätyi 2019 bugi mikä mahdollisti ilmaisten hampurilaisten tilaamisen. Automaatilla hampurilaista ostettaessa, sai pihvin poistamalla alennusta 1,10$ – näin automaateilta sai kikkailtua ilmaisia purilaisia. Automaateista löytyi myös useita muita aukkoja, joilla sai ilmaista ruokaa. Bugit eivät aiheuttaneet laajoja vahinkoja ja ne saatiin korjattua nopeasti. Sen sijaan episodista seurasi paljon hyvää keskustelua. 

Nämä esimerkit osoittavat, että puutteellisesta testauksesta voi syntyä todella vakavia seuraamuksia. Mutta kuten sanottua, testaus on liiketoiminnan kannalta tärkeää myös monilla muilla tavoin. Seuraavaksi lisää näistä. 

2. Mitä ohjelmiston laatu tarkoittaa

Asiakas määrittää laadun

Laadukas tuote ei ole pelkästään sitä, että tuote toimii kuten se on määritelty.

Laatu on sitä, että ratkaisu sopii käyttötarkoitukseensa, sellaisille käyttäjäryhmille joille sitä halutaan tarjota ja että laatu on kilpailukykyistä omassa markkinatilanteessaan. Tuotteen tai palvelun asiakas määrittää siis sen, mitä laatu tämän tuotteen osalta tarkoittaa. 

Viisi ohjelmiston laadun aspektia tuotteen käyttämisessä

Ohjelmiston laatua voidaan tarkastella monelta eri kantilta. ISO/IEC 25022 -standardi jakaa ohjelmiston käytön viiteen laatuaspektiin, joiden avulla voidaan tarkastella eri näkökulmista millaista ohjelmiston tai systeemin käyttäminen on. Näin me kuvailemme käytön laatuaspekteja:

Vaikuttavuus – Pääseekö käyttäjä tällä oikeaan lopputulokseen?

Tehokkuus – Kuinka paljon käyttäjä joutuu ponnistelemaan tehdäkseen asiat oikein ja valmiiksi?

Tyytyväisyys – Se fiilis, että käyttö on mukavaa, visuaalisesti selkeää ja ilahduttavaakin. Käyttäjälle herää luottamus siihen, että tämähän toimii niinkuin odotan sen toimivan.

Turvallisuus – Ovatko rahat ja tietoni turvassa käyttäessäni palvelua?

Sopivuus – Sopii käyttötarkoitukseensa, halutulle käyttäjäryhmälle. Tämä siis ylittää vaatimusmäärittelyissä luetellut asiat, ja sen saavuttamiseen tarvitaan hyvää asiakastuntemusta. Tämä syntyy esimerkiksi jatkuvan palauteluupin avulla asiakkaan suunnalta.

Tärkeintä on huomioida, että nämä laatuaspektit riitelevät keskenään, koskaan ei voi saada kaikkea. Siksi liiketoiminnan tavoitteista johdetut laatutavoitteiden prioriteetit pitäisi olla aina kirkkaana mielessä. 

3. Miten rakentaa liiketoiminnan kannalta tehokas testausstrategia

Testausstrategian resepti

Testaamisen strategian tulisi siis aina syntyä liiketoiminnassa.

Ensin mietitään mitä testattavalta tuotteelta halutaan bisneksen kannalta, sitten vasta pohditaan, mitä tämä tarkoittaa testauksen tavoitteiden ja lopulta käytännön testauksen osalta. 

Resepti testaamiselle tulisi olla yksinkertaisesti seuraavanlainen: 

1. Määritä liiketoiminnan tavoitteet ja sitä kautta testauksen prioriteetit.
2. Määritä testausstrategia, jota sovelletaan jo tiimiä valittaessa. Aina parempi olisikin kun laadusta vastaavat ihmiset pääsisivät mukaan projektiin niin aikaisin kuin mahdollista: näin syntyy syvempi tuntemus kaikkien osapuolten tarpeista ja tavoitteista tekeillä olevan ratkaisun osalta.

Liiketoiminnasta siis lähdetään. Liiketoiminnan tavoitteiden saavuttamiseksi halutaan monesti tehdä erilaisia toimenpiteitä. Lisämyyntiä haetaan verkkokaupan uuden ominaisuuden myötä, markkinointikampanjalla tavoitellaan uusia asiakkaita, chatbotti pyrkii parantamaan konversioita, paremmalla logistiikanhallinnalla tavoitellaan alhaisempia varastokustannuksia ja niin edelleen. Tavoitteita on lukuisia ja niitä tukevia toimenpiteitä vähintään yhtä paljon. Mutta yksikään näistä toimenpiteistä ei aja liiketoiminnan tavoitteita, jos sen toteutus ei toimi. 

Kaikki uudet sovellukset, toiminnallisuudet, rajapinnat, integraatiot jne. vaativat aina testaamista. Toimiiko sovellus tai sivu markkinoita johtavilla mobiililaitteilla? Toteutuuko personoitu ostokokemus? Kestääkö sivu suuren kampanjan aiheuttaman kuorman? Onko sivu luotettava / helppokäyttöinen / tyylikäs? 

Kun tiedetään tavoitteet, aletaanko sitten vain testaamaan kaikkea? Eipä toki. Testausta on ehdottomasti aina priorisoitava! Testauksen priorisointiin hyvä tapa on riskipohjainen testaus. 

Riskipohjainen testaus

Riskipohjainen testaus toimii yksinkertaisesti niin, että eri vioille määritetään todennäköisyys ja haitallisuus. Nämä pisteytetään, esimerkiksi yhdestä viiteen, kuten esimerkissä. Pisteytyksen jälkeen suoritetaan kertolasku ja korkeimmat pisteet saaneita vikoja painotetaan muihin verrattuna. Tämä työkalu auttaa jakamaan resursseja ja toisaalta kiireen sattuessa ohjaa toimintaa etukäteen harkittuun suuntaan. 

4. Miten ohjelmistotestausta tulisi johtaa, jotta saavutetaan liiketoiminnan tavoitteet

Nyt on taustat käyty läpi ja aika mennä itse asiaan, eli siihen, miten ohjelmistotestausta tulisi johtaa, jotta saavutetaan ne liiketoiminnan tavoitteet mistä kaikki on lähtenyt. 

Hyvä kielikuva testauksen johtamiseen on lentokonelento. Molemmissa tulee määrittää yhteinen suunta ja tarkistaa matkan erityispiirteet sekä ulkoiset tekijät, lisäksi tulee olla selkeät roolit omaava ja hyvin yhteen pelaava henkilöstö, jonka johdolla on vastuu kokonaisuudesta. 

Niin Kanarian lennolla kuin ohjelmistotestauksessakin, on tärkeää muistaa tarkastella omaa toimintaa kriittisesti, sekä tunnistaa riskit nopeasti ja reagoida niihin. Viimeisenä mutta ei suinkaan vähäisimpänä, eri tiimeillä on oltava vahva sisäinen luottamus sekä myös vahva luottamus eri sidosryhmien kanssa. 

Autonomiset pienet tiimit

Äskeiseen lentokone-esimerkkiin palaten, lento sinne Kanarialle ei todellakaan toimisi jos koko lentoyhtiön väellä olisi kädet sopassa. Sen sijaan, lennon vastuuhenkilöt vastaavat lennosta ja muut osa-alueet ovat tukijan roolissa (esim. lennonjohto). Itse lennolla on myös oltava autonomisia tiimejä kuten lentäjät tai stuertit, ja onhan myös asiakkailla roolinsa palvelun vastaanottajina ja palautteen antajina. Tiimien toiminnan kannalta autonomisuus tuo tehokkuutta, lentäjät eivät lähde puuttumaan stuerttien hommiin ja päinvastoin, toisten tiimien ammattitaitoon luotetaan. 

Jeff Bezos on sanonut, että tiimi on liian suuri jos sitä ei voi ruokkia kahdella suurella pitsalla. Joskin melko kulunut esimerkki, mutta yksinkertaisuudessaan tämä on kuitenkin edelleen toimiva. Mitä vähemmän on ihmisiä, sitä vähemmän on tehokkuutta heikentävää koordinointia ja nopeiden päätösten teko helpottuu. Pienempi tiimi myös parantaa sitoutuneisuutta, lisää motivaatiota ja mahdollistaa paremman skaalautuvuuden. 

Suosi siis pieniä tiimejä ja muista mahdollistaa tiimien autonominen toiminta. Luota tiimeihisi!

Tiimin suuntaviivat

Kun tiimi on saatu kasaan, pitää sen toiminnalle luoda suuntaviivat. 

Kuten sanottua, on todella tärkeää, että tiimeihin luotetaan ja niiden annetaan aidosti toimia autonomisesti. Samanaikaisesti, tiimillä on oltava omistajuutta. Omistajuudella tarkoitetaan sitä, että tiimille annetaan vastuu tietystä asiasta ja tiimi ottaa tämän vastuun omakseen. Ihmisille ei voi vain sanoa, että heidän pitäisi tuntea omistajuutta työtään kohtaan, omistajuus tulee luottamuksen ja vastuun antamisen kautta. 

Tiimin suuntaviivoihin kuuluvat elimellisesti myös englanninkieliset määritelmät Ways of working ja Definition of done; eli suomennettuna Työtavat ja Valmiin määritelmä. Työtavat lienee itsestään selvä asia; valmiin määritelmä taas tarkoittaa sitä, että tiimissä on yhteisesti sovittu, mitä meillä tässä meidän kontekstissa valmis tarkoittaa. Nämä eivät saisi tulla annettuna, koska sääntöihin sitoutumisen kannalta on erittäin hyödyllistä, että tiimin yksilöt ovat itse olleet määrittämässä sääntöjä ja määritelmiä, joita sitten pyrkivät noudattamaan.  

Tiimissä olisi hyvä noudattaa yhden totuuden periaatetta. Tällä tarkoitetaan sitä, että tieto löytyy yhdestä paikasta, minne kaikilla on pääsy. Näin vältetään tiedon hajanaisuus, mikä luo epävarmuutta ja tekee tiedon päivittämisestä hankalaa. 

Läpinäkyvyys on myös hyvin tärkeää nykypäivän tiimityössä. Informaatiota tulee jakaa kaikille ja mitään tietoa ei tule tarpeettomasti pimittää tiimin jäseniltä. Tehtävienhallintatyökalut kuten Jira, Trello, Asana jne. helpottavat tässä. Läpinäkyvyys lisää luottamusta. Kaikki mukaan päiväpalavereihin ja tieto liikkumaan!

Mittaristo – eli kuinka matkaa seurataan

Mittaamisesta sanotaan usein, että sitä saat mitä mittaat. Tämän vuoksi on kriittisen tärkeää pohtia huolella testauksessa käytettävät mittarit. Älä koskaan mittaa vain mittaamisen vuoksi. 

Tässä muutamia huomioitavia asioita omia mittareita määritettäessä: 

•Koodin laatuun liittyvät mittarit kannattaa jättää tiimin määriteltäväksi – testikattavuus, katselmointi (esim. GitHub).

•Valmiiksi saatujen tehtäväkokonaisuuksien määrä on hyvä mittari – jos valmiin määritelmä on kunnossa.

•Vakavien bugien määrästä voidaan tehdä johtopäätöksiä – kokonaisbugimäärästä ei niinkään.

•Tuotantovirheet – tätä pitäisi aina seurata analyysi, että miten virhe olisi voitu välttää.

•Jatkuvan kehittämisen metriikat; ajoittain tiimin tulisi arvioida omaa tekemistään ja mitata parannustoimia.

Automaatio

Kun puhutaan ohjelmistotestauksen johtamisesta, on vaikea olla käsittelemättä testausautomaatiota. Testiautomaatio on investointi – on osattava priorisoida automatisoitavat kohteet, valita oikea teknologia juuri kyseiseen käyttötarkoitukseen, ja ymmärtää myös automaation rajoitukset. 

Oikein tehdyllä testausautomaatiolla saavutetaan ajan kanssa todennäköisesti merkittäviä hyötyjä kuten: regressiotestauksen helpottuminen, palautteen lisääntyminen, luotettavuuden kasvu, ajan vapautuminen merkityksellisempään testaamiseen, yleinen laadun parantuminen sekä toki kustannussäästöt. 

Ihmisen tekemän testauksen arvoa ei kuitenkaan tule väheksyä tippaakaan, päinvastoin. Ihmisen kyky ajatella, aavistaa, oppia ja kyseenalaistaa on vielä toistaiseksi täysin ylivertainen koneisiin verrattuna. Siten tällaisia ominaisuuksia vaativissa tehtävissä ihmisen tekemä tutkiva testaus on edelleen kullan arvoista. Tutkivassa testauksessa pyritään toistettavien testien sijaan vapaamuotoisemmin, mutta hallitusti kohti määriteltyä maalia. 

Epäterveellisestä testaustötteröstä terveelliseen testauspyramidiin

Testauksen johtamisessa hyvin tärkeää on määrittää mitä testataan ja miten paljon. 

Usein esimerkkinä huonosti järjestetystä testaamisesta käytetään jäätelötötteröä, joka kapenee ylhäältä alas. 

Tässä epäterveellisessä tilanteessa vaativaa ja tehotonta manuaalista regressiotestausta tehdään kaikista eniten. Toiseksi eniten tehdään automatisoitua hyväksymistestausta, joka taas on kallista rakentaa. Integraatiotestausta, jossa testataan, miten järjestelmän eri osat keskustelevat keskenään, tehdään taas liian vähän. Kaikista vähiten tehdään yksikkötestausta, jolla voitaisiin helposti löytää yksinkertaiset yksikkötason virheet.  

Mikä sitten olisi parempi tapa? Voidaan puhua esimerkiksi testauspyramidista, joka pyramidin tapaan kapenee alhaalta ylös. 

Oikeaoppisen testauspyramidin mukaisesti eniten tehdään yksikkötestausta, missä päästään kiinni virheisiin heti kun se on mahdollista. Seuraavaksi eniten tehdään tärkeää integraatiotestausta, sitten automatisoitua hyväksymistestausta ja vähiten tutkivaa testausta. Tässä kohtaa on tärkeää huomioida, että vaikka tutkivaa testausta on testauspyramidissa vähiten, ei se suinkaan tarkoita, etteikö se olisi tärkeää, päinvastoin. 

5. Loppusanat

Mahtavaa, että pääsit tänne asti. Jos luit koko tekstin, tiedät nyt ainakin perusteet ohjelmistotestauksesta yleisesti sekä vähän sen merkityksestä liiketoiminnalle. Toivottavasti sinulle jäi myös jotain muistiin tehokkaan testausstrategian ja laatulähtöisen ohjelmistokehityskulttuurin rakentamisesta. 

Lopetetaan samoihin lennokkaisiin sanoihin kuin taannoinen webinaarimme: On kyseessä sitten tiimityö, asiakkuussuhde tai jopa pitkä alihankintaketju, voidaan todeta, että luottamus luo palveluihin luotettavuutta.

• Blog
|
• Liiketoiminta
|
• Ohjelmistotestaus