Ohjelmistotestaus osa tietojärjestelmien hallittua uudistamista, päivitys 18.1.2015

Ohjelmistotestauksen käsikirja avaa mielenkiintoisen maailman ohjelmistojen suunnitteluun ja määrittelyyn, rakentamiseen sekä käyttöönottoon. (1) Kirja on ajankohtainen, koska monin tavoin tutkitusti ja käytännössä on todettu tietojärjestelmien toiminnassa ja käytettävyydessä paljon ongelmia. Julkisten hankintojen tekeminen hankintalainsäädännön viitoittamaa tietä ei avaa kunnolla tätä puolta ongelmasta ja sen ratkaisemisesta. Jussi Pekka Kasurinen on pureutunut IT-ohjelmistotalojen toiminnan ja tekemisen ytimeen. Samoin kirjoittaja valottaa yhteistä haastetta tietojärjestelmän tilaajan ja tuottajan välillä. Testauksen kautta avautuu koko kehittämisprosessi aina ylläpitoon ja siihen liittyviin tietojärjestelmän ylläpitoon, riskien minimointiin ja vastaavaan. Perinteinen tietojärjestelmien suunnittelumetodi "vesiputousmalli" saa oman kriittisen arvioinsa. Mallissa tietojärjestelmä rakennetaan vaiheittain: määrittely, suunnittelu, toteutus, testaus,ylläpito. Eivät ole ongelmattomia nyt kovasti suosiossa olevat "ketterät menetelmät". "Skrum-mallissa vaatimusmäärittely tehdään käyttäen parhaiten tilanteeseen sopivaa menetelmää, esimerkiksi asiakkaita haastattelemalla tai markkinatutkimuksen avulla. Kun toteutettavalle tuotteelle on olemassa vaatimusmäärittely ja suunnitlema, jaetaan tuotteen toteutus yhden iteraation -sprintin - kokoisiin paketteihin, jotka toteutetaan osa kerrallaan."(s.28). 

Kirjan sanoma tiivistettynä. Testauksen periaatteet (s.48-49) on tiivistetty ISTQP 2013 sertifikaatissa: 1. osoittaa vikojen oloemassaolon, 2. täydellinen testaus on mahdotonta, 3. aikainen testaus: aloitettava jo esituotantovaiheessa, 4. vikojen kasaantuminen, 5.hyönteismyrkkyparadoksi (testitapaukset pitää päivittää, muuten vaikutus häviää), 6. testaus on tilanneriippuvaista, 7. virheettömyyden harhaluulo (väärin suunniteltu tuote ei testauksesta parane). Niin testauksessa voidaan löytää virheitä,  erehdyksiä (mistake) tai häiriöitä. Virhe voi olla ohjelmistossa, sen lähdekoodissa tai dokumentaatiossa. Testauksesta voi löytyä myös vika tai bugi (bug) ohjelmistossa tai sen dokumentaatiossa. Ja vielä testauksessa voi löytyä häiriö (failure), jolloin ohjelmisto toimii eri tavoin kuin mitä sen pitäisi toimia. Testausta tehdään useilla tasoilla. Yksikkötestaus varmistaa, että juuri tehty toiminto, moduli toimii. Integrointitestauksessa selvitetään järjestelmän eri toimintojen yhteensopivuus. Järjestelmätestaus tehdään kokonaiselle järjestelmälle. Hyväksymistestaus osoittaa sen, että järjestelmä toimii vaatimusmäärittelyn mukaisesti. Kasurisen mukaan testauksessa tulee olla yleinen kokonaismalli: testauspolitiikka, testausstrategia jne. Testauksen keskeiset toiminnot pitää olla jaoteltu yritystason testaustehtäviin, projektitason tehtäviin ja yksittäisen testaajan tehtäviin. Testauksessa on aina otettava huomioon asiakkaan tarpeet ja asiakkaan liiketoimintamalli, ulkoa tuodut komponentit, ulkoa ostetut palvelut sekä lainsäädännöllliset rajoitteet. Lopputuloksena pitäisi olla laatukriteerit täyttävä tuote. Laatu voi tarkoittaa teknistä laatua, asiakkaan kokemaa laatua tai odotettua laatua suhteessa hintaan. Testauksen kokonaisuus muodostuu ohjelmistokehityksen ja tuotteen käyttäjän välisestä yhteistyöstä (ns. sosioteknologinen organisaatio). Testaustyötä pitää johtaa samaan tapaan kuin  muutakin toimintaa ja testaustoimintaa pitää arvioida ja jatkuvasti kehittää.

Flow-IT-hankkeen asetelma

Käytettävyystestaus jää kirjassa vähemmälle huomiolle. (2) Käytettävyydessä ei ole kyse aina viasta, virheestä tai häiriöstä, vaikka juuri nämä tekijät tietysti eniten vaikuttavat käytettävyyteen. Voidaan oikeastaan todeta, että käytettävyystestaus on kokonaan oma näkökulmansa ohjelmistoihin. Ehkä eniten julkisuudessa on juuri esillä käytettävyyshaasteet. Tietojärjestelmä hidastaa työprosesseja, antaa mahdollisuuksia tehdä toiminnallisesti vääriä ratkaisuja tietojärjestelmien avulla. Niin  ja sitten on tämä osaaminen eli mitä osaamista vaaditaan tietojärjestelmän käyttäjältä. Käytettävyyteen liittyy myös erilaiset tekniset ja toiminnalliset ohjeet ja miten ne on sisään leivottu ohjelmistokokonaisuuteen. Olen ollut mukana Työterveyslaitoksen ja Aalto-yliopiston yhteisessä projektissa ulkoisena asiantuntijana. Projektin nimi on FlowIT ja se päättyy vuoden 2014 lopussa (3).


Kokonaisarkkitehtuurin ratkaisumalli vaikuttaa omalta osaltaan siihen, miten valittu ohjelmisto toimii. (4) Itse asiassa pitäisi aina ohjelmistojen rakentamisen alkuvaiheessa selvittää, miten aiottu uudistus liittyy yrityksen, viraston, toimintayksikön kokonaisarkkitehtuuriin. Kyse on toiminnan, tietojen, tietojärjestelmien ja teknologian yhteentoimivuudesta. Jos yhteentoimivuus ontuu, ei ohjelmisto sinänsä toimi järkevästi kokonaisuudessa. Esimerkiksi samoja jo tietojärjestelmissä olemassa olevia tietoja voidaan joutua kirjaamaan uudelleen jne. Sinänsä kokonaisarkkitehtuurinkin korostaminen saattaa johtaa moniin ongelmiin, kuten vaikkapa monoliittisen ratkaisun hakemiseen. Todellisuudessahan ei kuitenkaan yleensä lähdetä puhtaalta pöydältä liikkeelle, vaan useimmiten uusi ohjelmistoratkaisu korvaa jotain vanhaa.

Ollin päätelmiä- oppia itselle ja muille:

• Uuden tietojärjestelmän rakentamisessa tai vanhan uudistamisessa kannattaa aina aluksi peilata sitä kokonaisarkkitehtuurikuvaan.

•  Hankintaprosessissa kannattaa selvittää, minkälainen testauspolitiikka IT-ohjelmistotalolla on ja mikä on tilaajan ja tuottajan välinen työnjako.

• Kannattaa selvittää, minkälainen laatujärjestelmä IT-toimittajalla on ja miten läpinäkyvä on kehittämisprosessi sekä dokumentaatioprosessi.

• Kehittämisessä on kolme perusmallia: vesiputousmalli, ketterän kehityksen malli ja sekamalli. Tilaajan pitää tietää, mitä mallia toimittaja käyttää ja läpivalaista yhdessä toimittajan kanssa testauspolitiikka. 

• Käytettävyys on avainsana ja se on otettava kehitystyöhön mukaan jo alkuvaiheessa ja jatkuvasti eri vaiheissa. Käytettävyys liittyy jo kokonaisarkkitehtuurivaiheeseen, kun varmistetaan yhteentoimivuus toiminnan, tietojen, tietojärjestelmien ja teknologian välillä.

• Loppukäyttäjät pitää saada ajoissa mukaan ja toimintaprosessit pitää saada uusittua. Vaarana on, että rakennetaan tietojärjestelmä, jossa vanhat työprosessit ja uusi järjestelmä ajautuvat ristiriitaan keskenään.

Päivitys 18.1.2015: Ketterästä kehittämisestä blogikirjoitus: http://castrenblog.com/2015/01/13/ketterasti-kohti-kaaosta/
Sitaatti juristien Maiju Klemola ja Jaakko Lindgren blogikirjoituksesta Ketterästi kohti kaaosta:  "IT-markkinaa tuntevan juristin on helppo todeta, että ketterän kehitysmenetelmän projektisopimuksiin törmää huomattavasti harvemmin kuin perinteisiin vesiputousprojekteihin. Mistä tämä johtuu? Ei ainakaan ketterien menetelmien vähäisestä käytöstä. Väitämme, että ketterien projektisopimusten karttamiseen liittyy kaksi juurtunutta käsitystä:

1. Ketterä projekti ei tarvitse sopimusta, koska juristin laatima sopimus tappaa kaikki ne hienot tavoitteet, joihin ketterän kehitysmenetelmän valinnalla on pyritty.
2. Jos sopimus on pakko laatia, sen pitää olla mahdollisimman suppea. Vanhat sopimusarkistot ovat täynnä pohjia projektia varten."

Viitteet

(1) Jussi Pekka Kasurinen: Ohjelmistotestauksen käsikirja, Docendo 2013; Kirja antaa eväitä tilaajalle puuttua ja vaikuttaa tietojärjestelmän rakentamiseen ja toteuttamiseen ja käyttöönottoon.
"Kirja opastaa muun muassa seuraavissa aiheissa:- Testauksen tärkeimmät työmenetelmät- Testauksen tärkeimmät työkalut- Testauksen organisointi yrityksissä (ISO/IEC 29119 periaatteita noudatellen)- Testaus ja laadun mittaaminen (ISO/IEC 25010 periaatteita noudatellen)- Tärkeimmät ammattitestaajan sertifikaatit ja standardit- Testaustoiminnan kehittäminen. Kirja sisältää myös ohjelmistontuotannon perusteet siinä määrin kuin mitä kirjan sisällön ymmärtämiseksi on tarpeellista. Kirja on jaettu 14 aihekokonaisuuteen, joten se sopii itseopiskelun lisäksi myös oppikirjaksi testauksen peruskurssille."

(2) Käytettävyysatestaus: "Verkkosisällön saavutettavuusohjeet 2.0 (Web Content Accessibility Guidelines [WCAG] 2.0) kattaa laajan joukon suosituksia, joiden avulla verkkosisällön saavutettavuutta voidaan parantaa. Näiden ohjeiden noudattaminen tekee sisällön saavutettavaksi laajalle joukolle ihmisiä, joilla on vammoja tai rajoitteita. Tällaisia ovat mm. sokeus ja heikkonäköisyys, kuurous ja huonokuuloisuus, oppimisvaikeudet, kognitiiviset rajoitteet, liikuntakyvyn rajoitteet, puhevaikeudet, valoherkkyys sekä näiden yhdistelmät. Näiden ohjeiden noudattaminen tekee verkkosisällöstä usein myös yleisesti käytettävämpää."
http://creause.wikispaces.com/yleiskuva
http://www.w3.org/Translations/WCAG20-fi/

(3) Flow-IT-hanke:   www.ttl.fi/flowIT    Ks. Ollin blogikirjoituksia tästä projektista:  http://ollintuumailut.blogspot.fi/2013/09/saako-hyvaa-halvalla-tietojarjestelmien.htm
Projektin vastuuhenkilöiden viesti yhteistyötahoille: "Kiitos yhteistyöstä FlowIT-hankkeen kohdalla. Hanke jatkuu tämän vuoden loppuun saakka. Esittelemme FlowIT – Virtaa IT-hankintoihin –tutkimusavauksen julkisia tuloksia maksuttomassa seminaarissa Helsingissä Korjaamolla tiistaina 20.5.2014 klo 12 – 16. Ilmoittautua voi kuukautta ennen verkkosivullamme."

(4) Kokonaisarkkitehtuuri:  http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/03_muut_asiakirjat/Kokonaisarkkitehtuuri.pdf
Oheisessa blogikirjoituksessa avataan kokonaisarkkitehtuurin ongelmakohtia: 
http://www.tietoviikko.fi/cio/blogit/CIO_100_blogi/kokonaisarkkitehtuuri+ja+todellisuus/a980765 

Päivitys 28.5.2014: Puhutteleva kuva poimittu Linkedinin puolelta.