Category: Ohjelmistotestaus

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!

Uusi blogin osoite, vanhat vinkeet.

Silti harmittaa.

Testauksenhallintatyökalun osalta iso kauppa oli ns. lähes kiinni. Lupasimme vähentää (potentiaalisen) asiakkaamme laadunvarmistuskuluja 15%. He uskoivat sen.

Sitten meille näytettiin kämmentä! Miksi näin?

Olimme myymässä (potentiaaliselle) asiakkaallemme testauksenhallinnan tehostamista, eli vastaavan työn tekemistä vähemmällä tuntimäärällä. Valitettavasti emme tajunneet, että asiakkaamme asiakas maksaa edelleen testauksesta mieluummin tunti- kuin laatuperusteisesti. Emme ymmärtäneet paikkaamme arvoketjussa. (Potentiaalisella) asiakkaallamme ei ollut mitään syytä parantaa laadunvarmistusprosessiaan.

Ajattelumalli oli kutakuinkin seuraava:

• Maksamme 100 rahaa jokaista 100 testaukseen käytettyä aikayksikköä kohti
• Odotamme teidän löytävän yhden virheen jokaista aikayksikköä kohti
• Emme maksa tippaakaan enempää, vaikka saisitte kiinni 2 virhettä jokaista aikayksikköä kohti, koska hinnoittelemme alihankintatyömme tuntiperusteisesti. Alihankkijoiden vertailu on helpompaa siten!

Prosessin tehostaminen olisi tarkoittanut suoraan 15% pienempää laskutusta. Kuka sellaista haluaa?

Nykyään puhumme kovasti työn tuottavuuden kasvattamisesta. Käsittääkseni tuottavuuden kasvu tarkoittaa sitä, että samassa ajassa saadaan enemmän aikaiseksi. Tai vastaavasti sama määrä töitä saadaan tehtyä vähemmässä ajassa. Tuottavuuden kasvattamiseen vaikuttaa ensisijaisesti osaaminen. Osaamisen kautta työpäivän aikana saadaan aikaiseksi enemmän hyödykkeitä ja palveluita.

Ammattiliike vaihtaa autosi renkaat puolessa tunnissa. Kuinka paljon enemmän olisit valmis maksamaan siitä, että vaihtoon kuluisikin tunti? Maksaisitko tuplat? Tuskin. Minuakin kiinnostaa enemmän sovitun työn ja tuloksen lopullinen hinta kuin tuntiveloitus.

Isot laivat kääntyvät kovin hitaasti. Asiakkaamme (potentiaalinen) on aloittanut neuvottelunsa oman asiakkaansa siitä, että voisivat ottaa suuremman vastuun laadunvarmistustyöstä. Näin jokainen osapuoli voi keskittyä kokonaistuottavuuden kasvattamiseen.

Silloin myös laadunvarmistusprosessin kehittämiselle on tilausta. Me olemme siinä hyviä.

“Hirvi!” kuuluu pelkääjän paikalta. Kuski ei paina jarrua vaan kysyy ensin “Missä?”. Tottakai eläin on ensin nähtävä omin silmin ennen kuin painetaan jarrua. Tietenkään näin ei aina tieliikenteessä käy, mutta tuotekehityksessä tämä on arkipäivää.

Virheitä on kahdenlaisia. Niitä jotka tapahtuvat systemaattisesti ja niitä jotka tapahtuvat toisinaan. Jälkimmäiset ovat sitä sarjaa jonka tapahtumiseen olosuhteiden ja ajoitusten täytyy osua erityisen hyvin kohdalleen että virhe ilmenee.

Tällaisten virheiden raportointi on työlästä ja korjaaminen vielä työläämpää. Usein nämä virheet jäävätkin pitkäksi aikaa hoitamatta. Virheraportteja pallotellaan tuotekehityksestä testaukseen ja takaisin.

Developer: Could not reproduce, please retest on build 5
Test engineer: Still happens on 1 out of 10 tries
Developer: Could not reproduce, please retest on build 6, please provide a screenshot
Test engineer: Still happens… Did you even investigate?

Kallisarvoista aikaa kuluu tyhjänpäiväiseen pallotteluun todellisen syyn tutkimisen sijaan. Erityisesti tämä ongelma kertaantuu multi-site projekteissa, joissa kehitys tehdään kahdella aikavyöhykkeellä. Virheiden pallottelu saattaa kestää viikkoja ilman todellisia ratkaisuja.

Miksi testaajalla niin usein on raskas todistustaakka siitä että virhe todellakin ilmaantuu? Täytyy tuottaa kuvankaappauksia tai jopa videoita virheestä ennen kuin devaus oikeasti ottaa ongelman tutkintaan. Ongelma täytyy siis ensin omin silmin nähdä. Joskus testaajan on jopa kaivettava speksit esiin ja osoitettava niistä että raportti on todellakin vika eikä feature. Lopulta ongelmien selvittely tällä tavalla eskaloituu myös organisaatiossa ylöspäin ja ratkaisujen kustannukset kasaantuvat.

Tällaiset tilanteet johtuvat siitä että testaus ja tuotekehitys ovat niin usein napit vastakkain. Ei ole keskustelua, kommunikaatio ei ole pelannut ja tuotteen etu on unohtunut.

Ydinvoimalan suunnittelu- ja rakennusvaiheessa turvallisuustekijät ovat aivan oleellisessa asemassa. Työmailla on erikseen nimetyt henkilöt, jotka tarkastavat muiden tekemän työn. Kavereiden tulee olla kokeneita ja asiansa osaavia.

Auton voi katsastaa ainoastaan pätevä henkilö. Autoinsinöörin koulutus, työkokemusta, katsastuksen erikoiskurssit jne pätevöittävät tehtävään. Nollakoulutuksella ei pääse töihin.

Sähkötyömailla on nimetty vastuuhenkilö, joka tarkastaa kytkentöjen turvallisuuden. Ja kuittaa pöytäkirjat omalla nimellään.

Lääketieteellisiin toimenpiteisiin vaaditaan tietty pätevyys.

Kaikki edellämainitut asiat ovat yleisen turvallisuuden kannalta oleellisia, joten laadunvarmistuksen tulee olla huippuluokkaa. Mahdolliset virheet voivat johtaa kuolemiin, joten laaduntarkkailu on erityisen ymmärrettävää.

Entäs nämä:

Viskin- ja viinintuottajat ovat erityisen tarkkoja tuotoksiensa laadusta. Laaduntarkkailusta vastaavat henkilöt ovat omaan asiaansa vihkityneitä ja pitkän kokemuksen omaavia. Mieleen tulee valkopartainen ukkeli. Huono laatu voidaan myydä bulkkituotantoon, mutta oman brandin alla nitä ei markkinoille päästetä. Vaikka juoma päähän menisikin.

Musiikkiteollisuudessa levy-yhtiön edustajana toimii tuottaja. Tuottaja on se henkilö, joka vahtii levyn laatua aina biisien tekemisestä nauhoitukseen ja miksaukseen. Sisäinen laaduntarkkailija siis. Harvoin ihan kokemattomia kavereita.

Kummassakaan ei ole kysymys ihmishengistä, vaikka huono musiikki tai hapokas viini voivat joskus tympäistäkin.

Miten laadunvarmistuksen tärkeys näkyy ohjelmistojen kehityksessä?

• Meillä ei ole alalle valmistavaa yliopisto-/AMK-koulutusta
• Testaustehtäviä pidetään porttina oikeisiin kehitystehtäviin (“Noo, testaile nyt tämä kesä, katsotaan ensi kesänä sitten koodaushommia.”)
• Testaajien urapolku tyssää käytännössä testimanagerin tehtäviin. Seuraava askel on projektipäällikkö. Testausalan osaaminen ei pääse kehittymään.
• Testaajan palkka on saman työkokemuksen omaavaa koodaajaa reilusti huonompi

Ja edelleen puhutaan henkilöistä, joiden tulisi arvioida toisten työn tuloksia kriittisesti.

Softafirman väittäessä laadun olevan tärkeää, kannattaa kysyä miten se näkyy laadunvarmistajien arvostuksessa. Kohdellaanko testausta naapurin vähäpoikana, jota tuotekehityksen isot pojat pitävät lähinnä riesana? Vai pyydetäänkö testaus tasavertaisena peliin mukaan? Miten teillä?

Tuli kannattavammaksi myydä sutta halvalla kuin laatua kalliilla! Lepää rauhassa ammattimies!

…kirjoitti Markku Saksa Taloussanomien kolumnissaan näin ajettiin ammattimies alas. Nykytrendi tosiaankin tuntuu olevan nopea tuoton tavoittelu laadun kustannuksella. Onko testaaminen siis enää kannattavaa? Ylilaadun ja riittävän laadun rajat molemmat liikkuvat huonompaa kohti. Loppuasiakaskin on alkanut tyytymään siihen mitä tarjolla on.

Itse en koskaan osta kodintekniikan tuotteista ensimmäistä versiota. Mieluummin odotan että tuote on kunnolla testattu ja pahimmat viat on ehditty korjaamaan. Kaupassakin tsekkaan aina tarrat useampien pakettien kyljestä kuten parasta ennen päiväyksen maitopurkista. Tsekkaapa ensikerralla huvikseen tietoja usb-kovalevystäsi tai reitittimestäsi kaupan hyllyssä. Vertaile sarjanumerotarrojen tietoja. On jännää huomata kuinka monta eri versiota saman mallin tuotteesta voi hyllystä löytyä. Testausta on ulkoistettu loppukäyttäjälle. En tykkää!

Ammattilaisutta ei minusta silti ole ajettu täysin alas. Nykyammattilaisuutta on keskittyä oikeisiin asioihin.

Apple teki minusta ovelan tempun laadunvarmistuksen näkökulmasta puhelinbisneksellään. Koko tuotekehitys on silmin nähtävästi lähtenyt siitä että loppukäyttäjälle tarjotaan positiivisia käyttäjäkokemuksia. Todellisuudessa iPhonen taustalla oleva toiminnallisuus ei ole niin hyvää. Tyypihyväksyntätestit takkuavat ja operaattoria ahdistaa kun yksi iPhone saattaa kerralla varata kymmenien puhelinten verran verkon resursseja. Mutta ei se haittaa kun laadussa on panostettu juuri oikeaan paikkaan.

Laatukustannusten oikean ajoittamisen lisäksi laatukustannuksia pitää siis keskittää siihen missä se eniten merkitsee. Loppukäyttäjätuotteilla kannattaa keskittyä käyttäjäkokemuksiin. Se on myös bisnesriskien hallintaa.

Jatketaan hivenen viime viikon asiasta. Väitin kirjoituksessa, että testauksen tarkoituksen selvittäminen testaustiimille vähentää turhaa työtä. Mennään vielä pykälää korkeammalle.

Testauksen tarkoituksen määrittelee loppuviimein se optimitaso, millä ulkoisten laatukustannusten ja sisäisten laatukustannusten summa on mahdollisimman pieni. Raa’asti yksinkertaistaen ulkoisilla laatukustannuksilla tarkoitetaan tuotepalautuksista, takaisinvedoista, imagotappioista jne. koituvia kustannuksia. Sisäisillä kustannuksilla tarkoitetaan tuotteen kehityksen aikaisia testaus- ja virheenkorjauskustannuksia.

Aukipiirrettynä edellinen näyttää seuraavalta:

Optimitason määrittäminen on periaatteen tasolla varsin suoraviivaista toimintaa. Omat testauskustannuksetkin voidaan kohtuullisen hyvällä tarkkuudella saada selville ja niihin voidaan vaikuttaa mm. käyttötarkoitukseen sopivilla työkaluilla ja prosessien kehitämisellä. Eli kustannusten kertymisen kulmakerrointa saadaan loivennettua. On helppo ymmärtää, että virheiden etsiminen ja korjaaminen ikuisuuksiin ei palvele taloudellista tulosta.

Tulevien ulkoisten kustannusten arvioinnissa ensisijaisena lähteenä on aikaisempien hankkeiden ja projektien “jälkikustannusten” läpikäyminen. Toimintansa vakiinnuttaneissa yrityksissä on toivottavasti aikaisempi data tallella, mutta tuoreiden yrityksen kohdalla tämä voi olla hankalaa. Projektihistoriaa ei välttämättä ole riittävästi tarjolla. Silloin täytyy tehdä optimitason määrittely parhaan arvauksen mukaan.

Mitäpä luulette, tekisikö Sampo Pankki jotakin testauksen suhteen toisin, jos nyt aloittaisi verkkopankin muutosprojektin? Taikka sähköisen äänestyksen toteuttanut porukka?

Testaus ei ole kuluerä vaan investointi. Testaukseen investointi panostaa virheiden löytämiseen halvimmassa mahdollisessa vaiheessa. Kohtele testausta kuten mitä tahansa muuta investointia, kunnioittaen ja systemaattisesti.

Antti kertoi kirjoituksessaan “Feature managerin heiniä”, että projektissa oli käytetty varsin luovaa ja ketterää testitapausten päivittämistä. Kun projektin kannalta ikävään kohtaan testitapaus oli merkattu failiksi, muutettiin testiä siten, että tulokseksi tulikin pass.

Mikä onkaan testauksen tarkoitus? Voihan olla, että testitapaus oli vain niin spesifinen ja epätodennäköinen, että sen tuloksesta ei tarvitse välittää. Mutta silloin moista testitapausta ei olisi pitänyt edes alunperin laatia.

Kuinka monessa projektissa ylipäätään mietitään, että miksi jotakin testataan?

Cem Kaner toteaa mm. artikkelissaan What Is a Good Test Case, että testauksen tarkoitus tulee pitää mielessä testauksen suunnitteluvaiheessa. Miten muuten voisimme määritellä testauksen resurssit, työkalut, laatia testitapaukset jne?

Avataan Kanerin ajatuksia hieman. Testauksen tarkoituksen määrittelee testattavasta kohteesta, testauksen vaiheesta, kohteen ja käyttötarkoituksen kriittisyydestä jne. Näiden määrittelyjen jälkeen testauksen tarkoitus voi olla yksi tai useampia seuraavista:

• Teknisen tuen ja asiakaspalvelun kustannusten minimointi. Pyritään löytämään ne virheet, jotka aiheuttaisivat tekniseen tukeen paljon yhteydenottoja. Tällaisia voisivat olla esimerkiksi pankkien verkkopalvelut.
• Minimoida turvallisuudesta johtuvat syytteet. Onnettomuuteen tai loukkaantumiseen johtavien virheiden löytäminen on etusijalla. Lennonjohtosoftan kaatuminen voi aiheuttaa toimittajalle kylmää hikoilua.
• Tarkastus ohjelman spesifikaatiota vastaan. Ainoastaan spesifikaation vaatimukset testataan, muita mahdollisia kombinaatioita ei testata. Ei soveltune loppukäyttäjätuotteisiin 🙂
• Löytää tavat tuotteen käyttämiseen virheistä huolimatta. Vaikka jokin tapa ei toimisikaan spesifikaation mukaan, ei virhe ole kriittinen jos sen voi kiertää. Tähän ohjelmien käyttäjät ovatkin varmasti tottuneet.

Lista ei todellakaan ole täydellinen, mutta toimii esimerkinomaisesti. Jos Feature manager olisi ennen testausvaiheen alkua määritellyt testauksen tarkoituksen, ei a) epäkelpoja testitapauksia olisi suunniteltu tai b) olisi “vääriä” testituloksia.

Pysähdy hetkeksi, ennen kuin aloitat testauksen. Selvitä itsellesi ja tiimillesi, että miksi tässä oikein ollaan testaamassa. Turha riuhtominen jää paljon vähemmälle. Säästyy hermoja, aikaa ja rahaa. Lisäksi mahdollisuudet projektin läpimenoon kasvavat oleellisesti.

Onko teillä, blogin lukijat, täysin selvillä, että miksi asioita tehdään? Kertokaa hyviä tai huonoja kokemuksia.

Liiketoiminnan kehittämiskonsultin tehtävä ei ole taputella asiakasta selkään ja sanoa, että tässä firmassa on hommat hyvin hoidossa. Konsultti arvioi firman toimintaa armottomasti, etsii kehityskohteita ja nostaa ongelmat esiin.

Vaan eikös kuulostakin testaukselta?

Testauksen tehtävä ei ole tuottaa todisteita siitä kuinka hyvää softaa tässä vaiheessa onkaan saatu aikaan. Testauksen tehtävä on täsmälleen sama kuin edellä mainitulla konsultilla. Nostetaan kissa pöydälle ja katsotaan mistä kohdin ja millä tavoin softaa kannattaa lähteä parantamaan. Kaikissa projekteissa tietenkään näin ei käy.

Väitän, että testauksen tuloksilla on taipumusta värittyä aina kun testaus toimii osana tulosvastuullista kehittäjätiimiä. Jos en aivan väärin muista, niin Qentinelin Esko Hannula esitti taannoin lehtihaastattelussa rakennusteollisuuteen liittyvän kysymyksen:

Päästäisitkö sinä rakennuttajan tekemään myös kiinteistösi rakennustarkastuksen?

Minä en päästäisi. Minusta on älytöntä toteuttaa suuria tietojärjestelmähankkeita tilaamalla kaikki palvelut, toteutuksesta testaukseen, samalta toimittajalta. Menestyvätkö tällaiset hankkeet oikeasti hyvin vai onko puutteita kokemusten keräämisessä?

Saat paremmat tulokset tietojärjestelmähankkeestasi erottamalla testaus tuotevastuusta.