Category: Ohjelmistotestaus

Muutama kaveri työskentelee Oulun yliopistolla. Kuten monissa muissakin julkisen palvelun laitoksissa, on sielläkin käytössä Travel-matkalaskutusjärjestelmä. Käytettävyysongelmien takia softa on ollut päivityksessä kuukausia. Eräs kaveri päivitteli ircissä uutta päivitystä:

13:20 info: ei valuuttakurssia
13:21 tämä fyi kun valitset euron valuutaksi
13:30 aah aa! asiaa tutkittuani intter.netistä, tämähän onkin varsin loogista ja taas vaan käyttäjän vika.
13:30 “taksi, kotimaa” on nimittäin sen verta spesiaali kululaji muiden 300 eri kululajin joukossa että sen tapauksessa ei saa mennä valitsemaan valuutaksi euroa
13:30 vaan se pitää jättää tyhjäksi

13:32 mutta nyt kun tuon opin niin ehkä jopa onnistun ihan koko laskun tekemään omin kätösin nyt

13:42 VIRHE: Pakollinen lisäseliteteksti puuttuu kulu/km -riviltä [-25]
13:42 nuolasin ennenkuin tipahti
13:47 jep. tähän tyssäs. mistään ei puutu mitään. en ainakaan löydä, eikä löytänyt xx:kään.
13:47 tallennus ja kuitit sihteerille ja siitä jatkaa sitten se
13:54 oih, löyty syy. kotimaan kulut vaatii “seliteteksti”-kentän lisäksi vielä “lisäselitteen” joka pitää käydä eri ikkunassa kokonaan syöttämässä 😀
13:54 sillä eihän se taksi nyt yhdellä selityksellä selity

Kuinka huono Travel onkaan ollut ennen kuukausia kestänyttä päivitystä?

Tästä purkauksesta kiinnostuneena googlettelin travelia hieman. Mielenkiintoisin keskustelu löytyi suomi24-palstalla, jossa keskustelunavauksessa siteerattiin Helsingin Sanomia 4.1.2009. Hesarin juttu löytyy digilehdestä, josta sen pääsee Hesarin verkkotunnuksilla lukemaan.

Jutussa haastatellaan TKK:n vuorovaikutteisen digitaalisen median professoria, joka on tutkinut valtionhallinnon ohjelmistohankintoja. Ei silitellä päätä ei. Hyvä herra professori oli ottanut yhteyttä Travelin tilaajaan, ja vähän kysellyt asioista.

Vastaanotto oli nihkeä. Takala sai muun muassa kuulla, että ohjelman testaamisessa haluttiin lakisyistä sulkea pois nykyiset Travelin käyttäjät.

Peruste, oli että koska olemme käyttäneet ohjelman aiempaa versiota, voi meillä olla sen toimittajaa kohtaan ennakkoasenne, minkä takia emme ole puolueettomia.

Vetää sanattomaksi.

Ennen kuin julkaiset ohjelmiston, pyydä nyt hyvänen aika kommentit edes peruskäyttäjältä.

Niina oli siirtynyt duuniin kunnalliselle puolelle. Tarkemmin ottaen tietohallintoon. Tietohallinnon tehtävänä oli ensisijaisesti pitää järjestelmät iskussa, hoitaa uusien käyttäjien koulutukset ja mikä tärkeintä, huolehtia uusien järjestelmien käyttöönottoprojekteista. Kunnassa oltiin käynnistämässä projektia taloushallinnon tuntikirjanpitojärjestelmän uusimiseksi ja asianmukainen kilpailutuskin oli lähtenyt käyntiin pykälien mukaan.

Plani näytti tältä: Hankintailmoituksessa sisällytetään projektin läpivientiin myös testaus ja sen raportointi. Se olisi yksi vaatimuksista toimittajalle. Näin toimittaisiin, koska näin on aina ennenkin toimittu. Tyypillisesti kunnan kilpailutuksissa tarjouksen jättäneistä yrityksistä seulottiin parhaiten kriteerit täyttävät toimittajaehdokkaat. Niistä valittiin lopulta halvin.

Niinaa koko homma hieman askarrutti jo projektin alussa, sillä hän oli yritysmaailmassa kohdannut kerta toisensa jälkeen projekteja tiukalla budjetilla. Yhteistä näissä kaikissa projekteissa oli että jostain kohtaa oli ollut pakko tinkiä. Tuotteet on aina saatava valmiiksi, joten koodauksesta harvoin pystyy paljoa tinkimään. Niinan kokemuksen mukaan ensimmäisenä kokonaisratkaisuun tähtäävät projektit viilasivatkin resurssointia testauksesta.

Eli yhteistä kaikissa tiukalla budjetilla toimivissa projekteissa on että testauksesta viilataan ensimmäisenä ja eniten.

Niinan voimakkaista vaatimuksista johtuen kunnassa päätettiin ottaa riski. Ensimmäistä kertaa lähdettiin kokeilemaan uutta lähestymistapaa: Niinan idea oli että kilpailutetaan toimitus ilman testausta ja hankitaan erikseen testaus kolmannelta osapuolelta. Ratkaisu tuntui päättäjistä kyllä vähän kalliimmalta. Tulihan kilpailutuksia nyt kaksi ja yhteishinta olisi todennäköisesti muutenkin vähän kalliimpi. Niina kuitenkin vaati että kokeillaan tällaista lähestymistä yhdesti ja haudataan toimintamalli, mikäli kuvio tulee kalliimmaksi.

Kilpailutusten lopputuloksena oli projektin toteutuksen suuremmat välittömät kulut, kuten oltiin ennustettu. Päättäjät jupisivat jo että “Eipäs olisi kannattanut kuunnella tuota Niinaa, tuli kalliiksi tämä kokeilu”.

Projektin edetessä kuitenkin eroja entiseen toimitamalliin alkoi löytyä. Testaukselta saatiin ajantasaisesti raportteja ja selkeää tietoa järjestelmän kehittymisestä. Virhetietokantaan kertyi vikatietoja koko projektin aikana melkein 3 kertaa enemmän kuin koskaan aikaisemmin ja lisäksi kunnalla oli suora pääsy virhetietoihin. Objektiivinen näkemys tuotteeseen ja sen tilaan poiki siis paljon aikaisempaa parempaa tulosta. Projektinaikaista suoraa kustannusetua ei kuitenkaan vielä syntynyt.

Järjestelmän käyttöönottopäivästä kunnalla oli sopimuksen mukaan 30 päivää aikaa huomauttaa ja raportoida virheistä. Kaikki myöhemmin löydetyt virheet menisivät sitten korjaukseen todella tyyriiseen tuntihintaan. Vielä 30 päivän huomautusaikana ammattitestaajat löysivät joukon vikoja ja tietysti vielä korjaamattomia virheitä oli kertynyt myös projektin aikana. Kaikki keskeiset ongelmat saatiin korjaukseen huomautusajan puitteissa. Ja tietysti ilman lisäkustannuksia kunnalle!

Suorien korjauskustannusten lisäksi lisää kustannusetua tästä projektista paljastui myöhemmin, kun kunnassa alettiin uusimaan palkanlaskentajärjestelmiä. Tuntikirjanpitojärjestelmän ja palkanlaskentajärjestelmän välillä ei aikaisemmin ollut toimivaa integraatiota, mutta Niinan kilpailutusmallissa testaaja oli osannut ottaa huomioon myös järjestelmän jatkokehitysvaatimukset. Testaus oli valvonut kunnan etua vaatimalla että toimitettavan tuntikirjausjärjestelmän rajapintojen tulee olla avoimet jatkokehitykselle. Näin kunta välitti kalliit kustannukset suljettujen rajapintojen avaamisesta. Kiitos laatupoliisin.

Niina sai kiitosta rohkeudesta vaatia muutoksia. Tästä kokeilusta tuli kunnassa lopulta hyvä tapa, jota uskallettiin mainostaa myös naapurikunnan johtajalle.

Kaiken kilpailuttaminen yhdessä nipussa aiheuttaa väistämättä töiden priorisointia. Ensikerralla kun kilpailutat, mieti tarkoin oletko oikeasti valmis tinkimään testauksesta kehityksen hyväksi.

P.S. TestausOSY:n oulun ryhmällä vedettiin viimeviikolla miniseminaari testauksen ulkoistamisesta, josta tämäkin aihe sai alkunsa. Jäsen tai ei: Tervetuloa matkaan tuleviin tapahtumiin. Seuraa tapahtumakalenteriamme täällä.

Keskikokoisessa IT-yrityksessä projektipäällikköönä työskentelevä Pekka on järkevä kaveri. Työ vie perheellisen Pekan aikaa riittävästi, mutta perheen kanssa touhuamisen lisäksi Pekka ehtii harrastaa aktiivisesti urheilua ja elokuvien katselua.

Pekalla käy jalkapalloharjoituksissa huono tuuri. Polvi vääntyy ikävästi ja sairaalareissu on edessä. Pekka valittelee lääkärille, että polveen sattuu. Lääkäri tutkii Pekan polven ja kertoo, että ulompi sivuside on revennyt ja että repeäminen vaatii leikkaushoidon. Jalka leikataan ja Pekka aloittaa ahkeran kuntouttamisen. Ei polvesta aivan uuden veroista tullut, mutta jalka paranee pelikuntoon muutamassa kuukaudessa.

Pekka joutuu käyttämään omaa autoaan kohtuullisen paljon. Lapsia kuskataan harrastuksiin ja töidenkin puolesta saa ajaa ihan riittävästi. Töistä kotiin ajellessaan Pekka huomaa, että auton ohjaus on epätarkka ja ratissa tuntuu ajoittain lonksumista. Pekka ajaa suoraan kodin lähellä olevalle korjaamolle, että nyt on joku vikana. Tuttu autonkorjaaja kertoi, että ulompi raidetangon pää on hyvin väljä. Se on syytä vaihtaa, että ajaminen on jatkossa turvallista. Raidetangon pään vaihtamisen jälkeen myös aurauskulmat on säädettävä. Hintaa remontille kertyy osineen arviolta 100-150€.Pekka miettii, että se on halpa hinta omasta ja lasten turvallisuudesta. Onneksi on ammattimiehet apuna.

Töissä Pekka saa vastuulleen yrityksen historian suurimman projektin. Asiakas on maailmanlaajuisesti toimiva finanssialan yritys, joka on laajentamassa voimakkaasti Euroopan markkinoille. Pekan yrityksen tehtävänä on toteuttaa eurooppalaiseen lainsäädäntöön ja kulttuuriin sopiva asiakasportaali. Samankaltaisia projekteja Pekan yritys on toteuttanut usein, mutta ei tässä mittakaavassa ja yhtä kovilla tietoturva- ja luotettavuusvaatimuksilla.

Pekka ymmärtää, että tämän projektin laadunvarmistuksella on valtava merkitys yrityksen tulevaisuutta ajatellen. Onnistuessaan referenssi poikii lisää töitä taatusti. Pekka pohdiskelee tietoturvatestaukseen liittyviä kysymyksiä. Pekan pomot ovat linjanneet, että Pekan tiimin osana töitä painava testiryhmä keskittyy testitapausten laatimiseen ja varsinainen testaus ulkoistetaan testauksen asiantuntijayritykseen. Pekka tietää, että yrityksestä ei välttämättä löyty riittävän kovan tason osaamista tietoturva-asioihin.

Projektinjohtoryhmä vaatii Pekalta hyvät perustelut. Pekka yrittää kertoa, että kokemusta ei ole riittävästi ja että tätä projektia ei voi harjoituksena käyttää. Ei mene pomoille jakeluun. Sitten Pekka keksii vertauskuvan. “Jos polvemme tulee kipeäksi, pyydämme lääkäriä tutkimaan, että mikä siinä on vikana ja miten vamman voisi hoitaa. Jos autossamme on joku vikana, pyydämme korjaamoa tutkimaan ongelman ja antamaan hinta-arvion korjauksesta. Miksi haluaisimme rajoittaa yrityksen kannalta erittäin tärkeässä asiassa asiantuntijoiden työtä? Emmekö todennäköisemmin saisi oikean diagnoosin ongelmasta, mikäli asiantuntijat tekisivät myös testisuunnitelman alusta asti?”

Ei tarvinnut johtoryhmän kauaa miettiä Pekan lausuntoa. Tietoturvatestaukseen erikoistuneeseen yritykseen otettiin yhteyttä jo samana päivänä

Milloin sinä luotat asiantuntijaan?

Hei! Milloin viimeksi olet ottanut rokotteen? Itse otin yhden viimeksi ennen Kiinan matkaani.

Rokottautuminen saattoi tulla edellisen kerran eteen sikaflunssa-aallon aikaan syksyllä tai vaikkapa Intiaan työmatkalle lähtiessäsi. Rokotteiden saaminen Suomessa on itsestään selvää. Se on osa kansan terveyttä. Oletko kuitenkaan pysähtynyt ajattelemaan minkä takia täällä tuetaan rokottautumista niin avokätisesti?

Todellinen syy maksajan kannalta tarkasteltuna on tietysti sama kuin ohjelmistotuotteiden testauksessa. Kustannukset.

Yhdysvalloissa tehdyn kustannusanalyysin perusteella jokainen rokotuksiin nyt investoitu dollari säästää 2–27 dollaria terveydenhuollon kustannuksista myöhemmin. Oletko koskaan tullut ajatelleeksi, että oikein toteutettu lopputuotteen testaus voi aivan hyvin säästää saman verran reklaamaatioiden, aikatauluongelmien, takuuhuoltojen ja pakollisten päivitysten kustannuksista?

Kun meiltä kysytään apua testaukseen, se tapahtuu hämmentävän usein tuotekehityksen loppusuoralla. Tuotekehitys on saattanut olla tulilla jopa pari vuotta, mutta nyt 3kk ennen tuotteen markkinoille astumista pitäisi vielä varmistua laadusta. Aika uskaliasta sanon minä. Tutkimusten mukaan vian löytyminen myöhäisessä vaiheessa voi nimittäin kustantaa vaatimustenmäärittelyyn verrattuna:

• 90 kertaa enemmän kun vika löytyy järjestelmätestausvaiheessa
• 440 kertaa enemmän kun vika löytyy hyväksymistestausvaiheessa ja
• 470-880 kertaa enemmän kun vika löytyy tuotantovaiheessa.

Kertoimet tuntuvat hurjilta, mutta ne saattavat olla täyttä arkipäivää esimerkiksi Toyotalla, joka on joutunut jälleen kutsumaan miljoona autoa huoltoon. Pistää miettimään.

Testaus on aina investointi. Se maksaa nyt, mutta säästää varmasti kustannuksiasi tulevaisuudessa.

Jarkon uusin projekti oli alkanut painaa hommia jatkuvan integroinnin periaatteella. Projekti oli ensimmäinen tyyppiään organisaatiossa, jossa Jarkko teki testimanagerin hommia. Projektin alussa testauksen haluttiin toimivan varsin perinteisellä mallilla. Testauksessa nimittäin suunniteltiin releaselle savustustestit ja iso kasa toiminnallisuustestejä. Ne paketoitiin ennalta suunniteltuihin testisetteihin.

Jarkon testaustiimi käytti noin 4000 testitapauksen speksattua joukkoa. Testitapaukset oli jaoteltu erillisiin testisetteihin ohjelmiston osa-alueen mukaan. Yhden testisetin ajaminen vei aikaa tiimiltä kolme päivää. Ongelma tässä oli se että buildiautomatiikka teki aina uuden releasen joka yö. Kun yksi testikierros valmistui, sen tulokset tulivat kaksi päivää myöhässä. Kaksi uutta rellua oli jo ehtinyt tuutista ulos. Testitulosten parasta ennen päiväys siis meni jo!

“Tämähän ei varsinaisesti kuulosta ongelmalta!” totesi projektipäällikkö. Jarkko kuitenkin laski että testikierroksen loppusuoralla löytynyt vakava integraatiobugi voi pahimmassa tapauksessa aiheuttaa kolmen päivän töiden reverttauksen versionhallinnasta. Pahimmassa tapauksessa töitä saattoi mennä hukkaan jopa 8 developperin ja 3 testaajan, eli 33 miestyöpäivän verran! “Kalliiksi tulee” -perusteli Jarkko.

Jarkko ja testaustiimi olivat onneksi tiedostaneet riskin hyvissä ajoin ja etsivät aktiivisesti ratkaisua ongelmaan jo ennen kuin projektijohto asian ymmärsi. Tiimille oli projektin alussa valittu kätevä testauksenhallintajärjestelmä, jossa testisettejä ei ollut pakko rakentaa ennalta. Niitä pystyi muodostamaan dynaamisesti tarpeiden mukaan. Kun pullonkaulat projektissa lopulta ymmärrettiin ja ratkaisun löytämiseen allokoitiin vielä lisäresursseja, tiimi ryhtyi ripeästi toimeen:

Testauksenhallintajärjestelmä integroitiin buildiautomatiikkaan siten että aina uuden buildin valmistuessa, testausjärjestelmään luotiin automaattisesti uusi testauksen kohde (release). Jokainen testitapaus piti sisällään jo ennalta tiedon siitä millä releasella kyseinen testi oli viimeksi tehty. Yksittäiselle testitapaukselle voitiin siis näin muodostaa myös “parasta ennen” -päiväys. Tämän jälkeen joka aamu tiimi rakensi päiväkohtaisen testaussuunnitelman ja testisetit dynaamisesti. Testisettien rakennuksen kriteereinä olivat:

1. top-10 testitapaukset, eli järjestelmän ylläpitämän kirjapidon mukaan kymmenen eniten virheitä löytänyttä testitapausta
2. aikaisemmin epäonnistuneet testitapaukset, jotta nähdään onko tullut parannuksia aikaisempiin releaseihin
3. releasen muutoskohteet, eli testauksen riskipohjainen suunnittelu
4. “parasta ennen” -päiväyksen eniten ohittaneet testitapaukset ja lopuksi
5. tutkiva testaus

Näin toimiessa testaustiimillä oli jatkuvasti ajantasaisempi kuva lopputuotteen kypsyydestä ja siitä millä osa-alueilla kaivattiin eniten korjauksia. Kriittisimmät virheetkin saatiin kiinni keskimäärin työpäivää aikaisemmin, kun ei väkisin väännetty ennalta suunniteltuja testisettejä samassa järjestyksessä kuin aina ennenkin. Muutosten toteutus oli lopulta niin onnistunut että firma päätti muuttaa testauksen toimintatapoja muissakin projekteissa samaan suuntaan.

Kuinka usein teillä on paukutettu aina saman regressiotestisetin alkupäätä päivän verran ja löydetty sitten testauksen keskeyttävä virhe viimeisestä kolmanneksesta testitapauksia? Aika ärsyttävää sanon minä. Usein vanhassa mallissa pysytään siksi että joku haluaa menneisyyden testimetriikat vertailukelpoisiksi tulevien testikierrosten kanssa. Tästä syystä testsetin muuttaminen on joskus niin pirullisen työläs prosessi. Unohda perinteinen:

Saat väistämättä testauksestasi enemmän irti kun avaat toimintaympäristön ja testispeksit muutoksille. Huolehdi siis aivan aluksi että testaus saa tehokkaammin ja aikaisemmin bugit kiinni ja vaivaa päätäsi vasta lopuksi metriikoilla. Näin myös lopputuotteesi kiittää!

Minä pidän seminaareista. Niissä tapaa uusia ihmisiä ja puheenvuorotkin onnnistuvat yleensä herättämään paljon hyviä ajatuksia. Tästä kirjoitan siksi että pistäydyin viime viikolla Helsingissä Tieturin Testaus 2010 -seminaarissa. Tapahtuma oli ehdottomasti antoisa ja puhujat alan huippuja. Tapahtumassa palkittiin myös vuoden testaaja Tero Jyrinki Enderolta. Onnittelut hyvästä työstä Terolle!

Seminaariohjelman puheenvuoroista eniten ajatuksia herättivät Logican Bob Verhoeffin puheenvuoro riskipohjaisesta testauksesta sekä Qentinelin Katja Kuusikummun esitys testauksen mittaristojen valitsemisesta. Näistä aiheista keskustellaan blogin tulevissa numeroissa enemmän. Tilaa siis feedi nyt!

Mutta sitten itse asiaan. Tämänkin seminaarin teemoissa toistui aihe ketterä testaus: “Löytyykö oikopolkuja ketterään testaukseen?“, “Ketterän testaustoimintatavan käyttöönotto ja sen vaiheet“, “Agile testing in real life“. Ketterä on selkesäti trendikästä, ketterästä kuulee jokaisessa seminaarissa, ketterää puskee jokaisesta tuutista, ketterää, ketterää ja ketterää.

Ketterää.

No huhhuh. Ketterästä huolimatta testaukselta halutaan useimmiten vankkaa ja uskottavaa dataa projektista. Kuten Katja seminaarissa kertoi, testauksen tulee pystyä esittämään tarkkoja metriikoita projektissa edistymisestä, lopputulosten laadusta ja jopa rahasta. Miten ihmeessä näitä asioita voidaan mitata kattavasti, jos palautetaan mieleen:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Eikö asioiden mittaaminen nimenomaan vaadi vähintäänkin hyviä prosesseja ja toimivia työkaluja? Eikö asioiden mittaaminen vaadi hyvää dokumentointia ja päälle ripauksen suunnitelmallisuutta? Melkoinen dilemma selvitettäväksi sanon minä. Asiasta on helppoa puhua ja sitä on helppoa vaatia. Ja kyllähän se myös joskus toimiikin.

Ennen seuraavaa projektia kannattaa kuitenkin todeta että SEIS, hengähtää hetki ja miettiä:

Kaikki ei sovi samaan yhtälöön. Jos vaadit tiimiltäsi todellista ketteryyttä, se tapahtuu vähintäänkin metriikoiden kustannuksella.

Työntekijämme Heimo (nimi muutettu) työskentelee edistyksellisessä softaprojektissa, jossa on kymmentä developperia kohti kokonaista kolme testaajaa. Projektin laadunvarmistus toimii tutkivan testauksen periaatteilla eikä Heimo ole koko projektin aikana joutunut testispeksien kanssa tekemisiin kertaakaan. Se on mielenkiintoista vaihtelua kokeneelle testausgurulle. Projektin tuoreinta softareleasea on hierottu nyt pari viikkoa ja ensi viikolla rellu pitäisi saada ulos.

Heimo tietää kuitenkin että softassa on muutama vakava vika, jotka hän on raportoinut jo aivan tämän releasekierroksen alussa. Vikoja ei vain jostain syystä ole otettu vielä korjattavaksi. Heimo on kuitenkin fiksuna miehenä tutustunut viallisesta osa-alueesta vastaavaan developeriin kahvihuoneessa ja työpisteessä ihan vieressä istumallakin. “Kas tässä se vika nyt sitten olisi”.

Vaikka vikaa ei ole vielä korjattu, Heimo ei ole eskaloinut asiaa ylemmäs projektimanagementille. Hän pystyy perustelemaan virheen seuraukset tuotteelle, maksajalle ja loppukäyttäjälle. Lisäksi hän pystyy eliminoimaan yksi kerrallaan esteet vian korjaamiselle tarjoamalla riittävästi tietoa viasta ja mahdollisesti myös debug-informaatiota.

Koska Heimo on hyvä tyyppi ja pidetty mies projektissa, perustelut otetaan vakavasti ja lopulta vika korjataan. Heimo sai haluamansa, tuotekehitys ei joutunut napit vastakkain testauksen kanssa eikä vastaava developeri joutunut selittelemään managerille miksi vikaa ei korjattu. Kaikki tämä kiitos fiksun lähestymisen. Vaan eikös kuulostakin ihan myyntityöltä?

Softanmurskausta -blogin Teemu Vesala kirjoitti aiheesta “Laatukonsultti -mikä se on?“. Lista oli pitkä ja täyttä asiaa. Tuohon listaan minä lisäisin että testausguru on myös tuotekehittäjän tukihenkilö ja hyvä myyjä. Kovan luokan testaaja osaa myydä näkemyksensä tuotteen edusta developereille ja managementille ja silti säilyttää “asiakassuhteensa” devauksen kanssa hyvänä ja lämpinänä.

Testaaja: Perustele hyvin syyt virheenkorjaustarpeelle ja poista yksi kerrallaan korjaamisen esteet. Näin teet myyntityötä joka edistää lopputuotteen etua ja helpottaa myös sinun elämääsi.

Olipa kerran messut. Messujen vetonaulana oli arvontastandi huikeilla palkinnoilla. Koko homman keskiössä oli iso purkki täynnä ranskanpastilleja, josta pastillimäärän tarkimmin arvannut henkilö tietysti voittaisi palkinnon. Useimmat messuvieraat totesivat homman olevan täyttä arpapeliä.

Messupäivän aikana standilla kävi tuhat ihmistä tekemässä omat arvauksensa. Jokainen arvasi tietysti parhaan kokemuksensa mukaan. Ständille saapunut Jaakko oli kuitenkin fiksu kaveri. Hän ei heittänyt omaa arvaustaan kehiin heti vaan seurasi päivän ajan muiden arvioita ja lopulta voitti pääpalkinnon.

Jaakko oli lukenut James Surowieckin kirjan The Wisdon of Crowds. Hän toimi seuraamalla koko arpajaisyhteisön vastaukset ja muodosti sen perusteella oman mielipiteensä. Arpajaisyhteisön kollektiivinen mielipide osui tarkemmin kohdalleen kuin yhdenkään yksittäisen asiantuntijan lausunto pastillien määrästä. Kuinka usein sinä olet törmännyt työelämässä Jaakon lähestymistapaan?

Testaajan näkökulmasta näin ihan kärkeen tulee mieleen projektien error-palaverit, joissa muutama projektin viisas käy viikon virhelistan läpi arvioiden mm. virheiden vakavuutta, vaikutusta loppukäyttäjään tai korjauksen työmäärää. Arviot virheistä toki ovat asiantuntijoiden tekemiä, mutta voisiko kehittäjäyhteisöä hyödyntää arvion muodostuksessa tarpeeksi helpolla tavalla?

Mielipiteen kysyminen tuntuu työläältä ja palavereihinkaan ei kannata kutsua koko kööriä äänestämään. Mielipiteen antamisen voi silti tehdä helpoksi kuten Taloussanomat tekee kommenttiosastollaan. Siellä lukija voi kertoa oliko kommentti hyvä vai huono naksauttamalla jompaa kumpaa peukkua:

Vastaavanlainen toiminnallisuus olisi omiaan rankkaamaan virheraportteja kun tuoreimmat rapsat listattaisiin esimerkiksi projektinhallinnan etusivulle tai testauksenhallinnan dashboard-näkymään. Järjestelmään, joka on yhteinen ja aktiivisesti käytössä koko projektihenkilöstöllä. Samainen toiminnallisuus on helposti laajennettavissa virheraporttien arvioinnista myös testitulosraportteihin, testisetteihin tai jopa projektin vaatimustenmäärittelyyn.

[poll id=”2″]

Erilaiset yhteisötyökalut ovat osa nykyaikaista Internetiä. On Facebookia, Twitteriä, Erilaisia Wikejä, Sumplia ja Etherpadia. Valtavat määrät erilaisia ja oikeasti varsin hyödyllisiä työkaluja. Yhteisöpalvelut käyttävät jatkuvasti paremmin hyödykseen menetelmiä, jotka ovat muodostuneet käyttäjäyhteisöiden tarpeista ja niiden ehdoilla. Vain loppukäyttäjän näkökulmasta hyvät ja toimivat ratkaisut jäävät eloon.

Ammattilaisorganisaatioissa kuitenkin käytetään hyvin paljon välineitä, joiden toteutustavat ja menetelmät poikkeavat merkittävästi yhteisöpalveluista. Ammattilaisjärjestelmien pitäisi olla hinnan, monipuolisuuden ja tulosvastuun perusteella merikittävästi harrastejärjestelmiä parempia. Tästä huolimatta uusien tapojen ja tekniikoiden omaksuminen tapahtuu pääasiassa yhteisöpalvelujärjestelmistä ammattilaisjärjestelmiin.

Kuinka usein sinä olet nähnyt esimerkiksi tutkivan testauksen raporttia blogitekstin muodossa tai rss-feediä testitulosraporteista? Milloin viimeksi olet törmännyt testitapausten asiasanalajitteluun tai vaikkapa projektin sisäiseen pikaviestinkanavaan? Onko teillä joskus käytetty koko kehittäjätiimin(yhteisön) mielipidettä virheraporttien vakavuuden arviointiin? Itselläni ei kyllä tule kovin montaa hyvää esimerkkiä mieleen edellä mainituista.

Pienten mutta oikeasti toimivien ratkaisuiden tuominen matkaan ei tietenkään ole helppoa. Se vaatii työkaluilta paljon valmiuksia ja avoimuutta. Kaupalliset sovellukset valitettavasti tarjoavat pelivaraa uusien temppujen kehittelyyn varsin vähän. Mitä kaikkea oikeasti toimivaa ja tehokasta saisikaan aikaan, jos loppukäyttäjälle tarjottaisiin vähän lisää aseita omien työkalujen kustomointiin ja pelikentän paranteluun.

Tietohallintojen strategiat ja ohjeistukset harmillisen usein blokkaavat tai vähintäänkin hidastavat tarpeettomasti hyviä paikkoja parantaa toimintaa. Avoimuus ja toiminnan vapaus veisivät komuunikaatiotakin roimasti eteenpäin.

Tein vuosi takaperin puhelinprojektia, jossa oli mullistavasti otettu Wiki käyttöön projektinsisäisen tiedon jakamisessa. Idea oli hyvä ja innostuin toki itsekin. Kuitenkin ensimmäisen kerran yrittäessäni ediotoida dokumenttia johon itselläni oli testipäällikkönä inputtia, huomasin että käyttöoikeuksia dokumenttien päivittämiseen ei ollut annettu kuin muutamille projektin henkilöille. Jätin siis sivun päivittämättä ja laitoin kaikille mailia aiheesta. Wiki unohtui vähitellen koko projektista kun kukaan ei sitä päivittänyt. Ne kenellä oikeuksia oli eivät ehtineet ja ne kenellä annettavaa olisi ollut eivät voineet. Wikistä tuli työlään käyttöönoton jälkeen käyttäjäoikeuksin rajattu paikka jonne informaatio meni vanhenemaan ja lopulta kuolemaan. Kylläpä kannatti.

Väitän että tässäkin projektissa kontrollista löysääminen ja käyttäjäoikeuksien vapauttaminen olisi nostanut dokumentoinnin ja ryhmätyön tason aivan uudelle tasolle. Suurimmat ongelmat meillä nimittäin tuli lopulta tiedon versionhallinnassa. Vaatimusmäärittelydokumentteja oli useissa formaateissa ja wordifilejen versioissa. Omassa versionhallintajärjestelmässä oli yksi kopio ja loppuasiakkaan järjestelmässä toinen kopio. Lisäksi sähköpostissa läheteltiin kolmansia kopioita katselmointia varten. Ne eivät koskaan olleet synkassa. Työaikaa haaskaantui versiohistorioiden kiinni juoksemiseen ja dokumenttien vertailuun kohtuuttomia määriä. Ei ollut kivaa mutta kyllä siitä jotain jäi käteenkin.

Ensikerralla kannattaa luottaa omiin asiantuntijoihin enemmän. Laajentaa tiimin oikeuksia informaatioon ja sen muokkaamiseen. Kehittäjäyhteisön älykkyys ja sosiaalisen verkoston tukeminen vähentää paitsi inhimillisten virheiden riskiä, myös tarpeetonta dokumentaatiokuormaa, aikaa ja hermoja.

Osto-osaaminen on tärkeää. Kun ohjelmistoratkaisuja ostetaan on oltava asiantuntemusta asettaa vaatimukset oikein, arvioida tarjotun järjestelmän ominaisuuksia ja ostopäätöksen jälkeen toimitetun järjestelmän laatua. Ja tietysti hintaa suhteessa näihin.

Julkisella sektorilla kilpailutus toimii erinomaisesti. Järjestelmäratkaisuille asetetaan vaatimukset, niiden perusteella seulotaan tarjoajista parhaat ja valitaan halvin. Homma toimii ja ongelmia ei ole… Eihän?

Professori Matti Pohjola on eri mieltä:

Pallo on täysin hukassa

Eri hallintoalat tuottavat omat tietotekniikkapalvelunsa, kun valtiolle riittäisi yksi Googlen kaltainen palvelukeskus. Näin saataisiin tietotekniikan mittakaavaedut hyödynnettyä.

Mielestäni tässä on nimenomaan kyse vääränlaisesta vaatimustenasettelusta.

Maailmalta löytyy kasa tekstinkäsittelyohjelmia. On Word, OpenOffice, Google Docs ja muutama muu. Tietokoneita lienee lähes 1,5 miljardia. Jokaiselle tekstinkäsittelyohjelmalle pitäisi siis löytyä varsin asiallinen markkinaosuus kappalemäärissä mitattuna vaikka aivan jokaisessa koneessa ei tekstiä käsitelläkään.

Sitten Suomeen. Suomessa kunnilla ja lääkäripalveluita tarjoavilla yrityksillä on erilaisia potilastietojärjestelmiä lähes saman verran kuin tekstinkäsittelyohjelmia koko maailmassa. Effica, Pegasos ja Uranus vain muutamia mainitakseni. No huhhuh.

Potilastietojärjestelmien käyttäjäkunta on tasan kansallinen terveydenhuollon väkimäärä. Järjestelmät eivät tietenkään keskustele keskenään ja hankintavaiheen jälkeen jatkokehityshankkeita on mahdotonta kilpailuttaa. Järjestelmien rajapinnathan ovat suljettuja. Lisäksi järjestelmätoimituksissa on lyhyt huomautusaika ja tämän jälkeen löytyvät virheet korjataa tuntitaksalla.

Eikö olisi ollut järkevämpää heti hankintavaiheen alussa määritellä vaatimuksiin muutama lisäpykälä ja huolehtia että ne täyttyvät. Eikö voisi vaatia että rajapinnat ovat avoimet ja että rajapintakuvaukset jäävät työn tilaajalle. Jos toimittajia ei löydy, niputetaan usemman kunnan ja yrityksen vaatimukset yhteen. Kun potti kasvaa, niin kyllä ne tekijät löytyvät.

Panosta osto-osaamiseen. Huolehdi että tiimistäsi löytyy ainakin teknologia-, testaus- ja talousammattilaiset. Jos oma kompetenssi ei riitä, pyydä ammattilaista apuun.