Author: ohjelmistotestaus

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.

Talouselämän “Minä Väitän” osastolla NSN:n johtajat puivat Suomen kilpailukykyä. Avainsanana tässäkin tapauksessa komeili tuottavuus. Teksissään Ilkka Lakaniemi ja Anne Larilahti nimittäin väittävät että suomalaisten yritysten kyvyssä ottaa käyttöön ja hyödyntää tietotekniikkaan on vielä paljon tekemistä.

Olen heidän kanssaan samaa mieltä. Uskallan jopa väittää että usein päätökset pitäytyä vanhoissa menetelmissä tai työkaluissa syntyvät mukavuuden halusta. Toiminnan kehittämishankkeiden ja järjestelmämuutosten lykkäämistä tai hylkäämistä on helppoa perustella vaikkapa taloudellisilla näkökohdilla, mutta väitän että todellisuus on toinen.

Muutos on työlästä, muutoksesta aiheutuu riskejä ja joku kantaa myös vastuun. Oikeastaan vastuukaan ei ole sitä suurinta herkkua. Kaikkein mukavinta olisi pysyä tutulla ja turvallisella maaperällä. Mukavuusalueella. Onhan se toiminut tähänkin asti ! ?

Entäpä sitten kun uskallus ja innostus on lopulta saatukin riittämään muutokseen? Uusi tietotekninen ratkaisu on valittu työskentelyn tehostajaksi ja on käyttöönoton aika. Käyttäjiä alkaa ahdistaa ja muutosvastarintaan käydään ennen kuin työkalut ovat edes koulutusvaiheessa. Johdon esittelemät muutokset aiheuttavat lähes poikkeuksetta vastareaktoita henkilöstön keskuudessa. Mistä tämä johtuu?

Lakaniemi ja Larilahti esittivät että olisi tärkeää hankkia valmiuksia teknologian käytön laajentamiseen yritysten sisällä.

Tämän tulisi tapahtua niin, että tietotekniikka tehostaa koko henkilöstön toimintaa, ei pelkästään johdon tai tiettyjen asiantuntijaryhmien.

Johtuisiko vastarinta siis tottumuksesta? Työntekijä on tottunut siihen että tietotekniikka ei tehostakaan oman pelikentän toimintaa vaan se saattaa jopa työllistää lisää. Valitettavasti useimpien työkalu-uudistusten voittajana selviää ainoastaan johtaja joka saa kätevät raportit ja hyvät seurantatyökalut. Ratkaisun myyjä (*) on siis tehnyt työnsä hyvin kohderyhmässä. Tässäpä siis haaste:

Uskalla vaatia enemmän kun ensi kerralla käynnistätte toiminnan tehostamishankkeen! Vaadi ensimmäisenä että valitsemasi ratkaisu oikeasti tehostaa koko käyttäjäkunnan työskentelyä. Lopulta huomaat että myös muutosvastarinta vähenee ja organisaatiosi uskaltaa opetella uutta.

(*) Myyjällä tarkoitetaan tässä tapauksessa sitä tahoa joka on onnistuneesti ajanut uuden ratkaisun käyttöönottopäätöksen läpi. Ajatuksen myyjä voi siis tulla myös organisaatiosi sisältä.

Minkälaisella autolla ajat? Pidätkö siitä, että ohjaamossa on ainoastaan polkimet, vaihdekeppi ja ratti vai vaaditko elektronisia ajotietokoneita ja hilavitkuttimia joka lähtöön? Oletko ihminen, jolle auto on ainoastaan keino päästä paikasta A paikkaan B vai onko autosi sinulle mukavuustekijä?

Kuvitellaanpa tilanne, jossa autoon ahtautuu kokonainen testaustiimi. Suurena herrana testimanageri istuu ensimmäisenä ohjaajan pallille, jonka jälkeen pienet testaajat sulloutuvat muille vapaille paikoille. Tilanne on tukala. Liikkuminen tuottaa yllättäviä vaikeuksia ja viime hetkellä havaitaan, että autossa ei ole edes turvavöitä ja ainoa turvallisuustekijä äkkipysähdyksen varalle on muutamaan otteeseen uusitut airbagit kuskin paikalla. Sekalainen porukka lähtee liikkeelle jo ennen kuin viimeinen ovi saadaan edes kiinni. Kuulostaako tilanne tutulta projektielämästä?

Selvennyksenä tähän väliin, tässä tekstissä vertaan edellisten kappaleiden perusteella testauksenhallintatyökalua geneeriseen autoon painottaen peruslaatukriteereihin. Kimppakyyti voi siis alkaa.

Ensimmäisenä autoon istuessa on tärkeätä löytää sopiva ajoasento sekä kuljettajalle että matkustajille. Autossa on siis oltava tilaa liikkua ja penkkien on oltava säädettävissä jokaisen ruumiinrakenteelle sopivaksi. Tämä heijastuu testauksenhallintatyökalun käytössä perustestaajan mahdollisuuksiin vaikuttaa testauksen etenemiseen. Harmillisen monesti työkalun käyttöoikeudet ovat rajoitettu execute-tasolle, jolloin pieni testaaja ei voi kuin istua paikallaan kädet kahlittuna käsinojiin (mikäli niitä mukavuutena on autoon lisätty) ja päätyä tasan sinne minne testimanageri ajaa. Perillä kahleita irrotettaessa todetaan, että testaajan oma-aloitteisuus ei ollut toivottua tasoa. Kehitystä on siis tapahduttava.

Palataan kuitenkin ajassa takaisin matkan päälle. Automatkassa kiistämättä tärkein asia on nähdä mihin ollaan menossa. Tämä seikka on hyvin löyhästi riippuvainen käytetystä testauksenhallintatyökalusta. Tärkeämpää työkalun kannalta on nähdä taustapeileistä millaista jälkeä maantiellä auton takana on. Näkyykö verissäpäin makaavia jalankulkijoita ja hollywoodista tuttuja räjähdyksiä vai normaaliin tapaan eteenpäin soljuvaa liikennettä? Tästä saadusta informaatiosta kuljettajan paikalla istuva testimanageri voi päätellä jo pitkälle ovatko hänen hätäpäissään tekemänsä ratkaisut olleet matkan etenemisen kannalta järkeviä samalla kun takapenkiltä kuuluu jatkuvaa narinaa “Ollaanko jo perillä? Kauanko vielä? Missä mennään?”. Ihannetilanteessa kaikkien matkustajien ikkunan vieressä on omat taustapeilinsä, joista he näkevät sen pienen osan tilanteesta joihin heillä on ollut mahdollisuus vaikuttaa, ja ehkä vielä enemmänkin.

Matkaan kuuluu luonnollisesti myös kyytiläisten mukaan hakeminen. Näin ollen perusoletuksena heillekin täytyy olla tilaa. Projektimanageri soittaa kuljettajalle kesken matkan tarvitsevansa kyytiä paikasta A paikkaan B. Hänelle täytyy luonnollisesti olla paikka varattuna etupenkiltä siten, ettei hän herrasmiehenä joudu katselemaan nahistelevaa testaajalaumaa takapenkillä, vaan näkee selkeästi mistä tullaan ja mihin mennään. Kyyti onnistuu hyvin kun testauksenhallintatyökalusta löytyy tarvittavat tiedot ilman suurempia tuskallisia oikeusprosesseja. Projektimanaageri poistuu kyydistä hymyssä suin ja kiittää kauniista näköalareitistä. Tällainen ominaisuus on työkalun käytössä harvinaista herkkua.

Yhtenä tekijänä autojen hankinnassa arvostetaan niiden ympäristöystävällisyyttä. Eihän kukaan tee työkalullakaan mitään jos se saastuttaa ja tuhoaa ympäristöään. Tämä on melkoisen kärjistetysti sanottu, mutta kyseisenlaisia työkaluja todellakin on olemassa. Jopa suurista alaa hallitsevista nimistä löytyy sellaisia työkaluja, joiden käyttöä kartetaan mahdollisimman pitkään koska ne hidastavat testausprosessia ja tekevät työnteosta kaikkea muuta kuin mielekkään. Ympäristöystävällisyyden kannalta on otettava huomioon myös polttoaineenkulutus. Hankintavaiheessa jokaisen auton ja testauksenhallintatyökalun maksaminen kirpaisee, mutta ensishokin jälkeen 3,5l/100km dieseliä juova mukavan rennosti pörräävä auto on niiden kaikkien kymmenien tai satojen tuhansien kilometrien jälkeen kannattavalta tuntuva hankinta. Tämän huomaa myös testimanageri kuljettajan penkillä ajotietokoneen kattavia valikkoja selatessaan.

Millä saataisiin autosta sitten juuri sellainen kuin halutaan? Auton varustelu on monelle omistajalle tärkeä tekijä matkustusmukavuuden kannalta. Samalla tavalla kuin autosta on valittavissa perus- ja lisävarusteet myös testauksenhallintatyökalu voi olla räätälöitävissä tarkoitukseen sopivaksi.

Miksi työkalun pitäisi ohjata testausprosessi tietyille raiteille, kun työkalun voi myös ohjata testausprosessin raiteille?

Tiptap!

Vetäydymme joulutauolle pariksi viikoksi. Uusi teksti murjaisee käyntiin vuoden 2010 heti viikolla 1. Palataan silloin asiaa.

Rauhallista joulua ja menestyksekästä vuotta 2010 lukijoille!