Tag: Suomi

Ossi on henkilöstöpäällikkönä kasvavassa softa-alan yrityksessä. Hän seuloo päivittäin hakemuskasoja ja etsii firmalle sopivia uusia työntekijöitä. Osaajia tarvitaan erityisesti devaukseen, mutta joku oli ohimennen maininnut yhden projektin etsivän myös testaajaa. Ossia se ei kauheasti kiinnosta, koska yrityksen kannalta testaus on vain turha kuluerä.

Testaaja on kuitenkin pomon käskystä etsittävä, joten Ossi ryhtyy toimeen. Kun hän vihdoin on seulonut joukosta kolme sopivinta kandidaattia, heidät kutsutaan haastatteluun. Kaikki kutsutut ovat testauksen asiantuntijoita. Heillä on sopivasti kokemusta alalta ja ansioluettelot kohdallaan.

1. Minna 32v on pitkän linjan testausosaaja 12 vuoden kokemuksella. Haastattelussa hän kertoo tarkasti itsestään ja aikaisemmasta urastaan. Minna vastaa myös asiantuntevasti Ossin heittämiin haasteisiin.
2. Jarkko 34v on myös kokenut asiantuntija 9 vuoden kokemuksella. Haastattelussa hän avaa koulutustaustaansa ja osaa jopa kertoa raflaavan menestystarinan uransa varrelta. Kysymyksiin tulee vastaus kuin apteekin hyllyltä.
3. Heli 26v on joukon nuorin. Kokemusta hänellä on vain vähän reippaat 5 vuotta. Hänen palkkatoivomuksensa on kuitenkin lähes sama ja sitä Ossikin ihmettelee. Haastattelussa Heli kuitenkin lyö tiskiin jämäkät faktat siitä, miksi hyvin hoidettu testaus säästää takuuvarmasti Ossin firman rahaa. Se parantaa firman mainetta ja säästää myös devaajien aikaa. Omaan uraansa Heli ei puutu. Eikä Ossi kysy.

Mitäpä luulette. Kenet Ossi päättää palkata?

Homman nimi on tietysti siinä, että ensimmäiset kaksi hakijaa ovat insinöörejä henkeen ja vereen. He ovat kyllä todellisia ammattilaisia ja osaavat myös kertoa osaamisestaan. Ossia ei kuitenkaan kiinnosta ehdokkaiden elämäntarina tai ura. Häntä kiinnostaa se, mitä hyötyä kandidaatista oikeasti on hänelle ja yritykselle.

Valinta on helppo ja Ossi päättää palkata Helin, sillä Heli kertoi selvästi tärkeimmät asiat:

a) Miksi testaus on rahan arvoista työtä ja

b) Mitä hyötyä hänestä konkreettisesti on Ossille ja yritykselle.

Hyvä testaaja. Sinä olet ammattilainen ja sinä tiedät mitä hyötyä testauksesta on. Valitettavasti se ei kuitenkaan vielä riitä:

Sinun on opeteltava kertomaan siitä myös muille!

* P.S. Voit aloittaa vaikkapa lukemalla muutaman hyvän blogin.

Scrum! Ketteryys! Nopeus ja tehokkuus! Kuulostaa hienolta ja käytännölliseltä. Näitä hyveitä soveltaen ei mikään voi mennä pieleen! Motivaatio on huipussaan ja tekeminen alkaa hampaat hulmuten. Jossain vaiheessa tie kuitenkin käy kiviseksi.

Liikkuvia lajeja harrastaneena voin kertoa, että liika luottamus omaan ketteryyteen ja nopeuteen ei vie kovin pitkälle. Juosten ja kärrynpyöriä/voltteja tehden liikkuminen näyttää tyylikkäältä ja vakuuttavalta, mutta suorittajan kannalta on valittu juurikin se mahdollisimman epäedullinen liikkumismuoto.

Kävellessä ehtii havainnoimaan paljon enemmän mitä ympärillä tapahtuu, kompastumisen vaara on huomattavasti pienempi ja liikkuminen on myös tehokkaampaa. Kävellessä on aikaa katsoa mihin seuraavan askeleen astuu.

Nokkelimmat saattoivat jo päätellä tämän metaforan juontavan työtapojen kehittymiseen. Maltillinen ja jatkuvan tarkkailun alla oleva muutos on aina lopputulokseltaan tehokkaampi kuin päätäpahkaa metsään juokseminen. “Kokeillaan toimiiko tämä, koska se toimi myös naapurin organisaatiossa!” -mentaliteetti johtaa väistämättä ongelmiin. Jokainen organisaatio on erilainen. Jokainen organisaatio vaatii erilaisia työmenetelmiä.

Kuinka sitten ketteryys näkyy käytännön työelämässä? Valitettavan monissa projekteissa ei osata naulata seinälle selkeitä toimintatapoja, joita kaikkien on helppo noudattaa. Valitettavan monissa projekteissa menettelytavat ovat jatkuvasti suunnittelu- ja muutostilassa. Ei ehditä kokeilemaan mitään tapaa kunnolla ja kokemukset jäävät keräämättä. Parhaat käytännöt jäävät oppimatta.

Valitettavan useat firmat ovat sokaistuneet sanan Scrum valovoimasta ja ajautuvat aina vain kauemmaksi tehokkaan kehityksen tieltä. Lopulta ne vieraantuvat tuotekehityksen todellisuudesta. Tekijät, tiimipäälliköt ja sadanpäämiehet istutetaan samaan suureen tilaan siinä toivossa, että tieto kulkisi vaivattomammin. Työkaluiksi valitaan massiivisia ja kalliita multimonitoimi-vasaraporamittanauharuuvimeisseli-työkaluja, joiden pitäisi tukea Scrumin periaatteita. Tämäkö on sitä ketterää ohjelmistokehitystä?

Lare Lekman on listannut Ketteryys.fi blogissa Scrumin tärkeimpiä asioita:

Toimita säännöllisesti jotain

Varmista, että toimitat korkeimman prioriteetin asiat

Pyri parempaan jokaisessa iteraatiossa/julkaisussa

Ketteryys ohjelmistokehityksessä perustuu selkeisiin suuntaviivoihin, joita kaikki pystyvät noudattamaan. Se ei ole jatkuvasti muuttuvaa sekameteliä tai nopean näköistä sähläystä. Se on asiantuntemuksella otettuja hallittuja askelia. Jatkuvaa liikettä eteenpäin.

Kiireelliset deadlinet eivät muuta toimintatapaa tyylikkäiksi juoksuaskeliksi. “Toimita säännöllisesti jotain” ei tarkoita, että merkataan keskeneräinen taski valmiiksi. Sähläten puoliksi implementoitu done tuottaa varmasti enemmän ylimääräisiä kustannuksia kuin vähän myöhemmin kunnolla implementoitu done. Siitä myös testaus pitää huolen.

Oikeaa ketteryyttä on siis ottaa laadukkaita, tasapainoisia ja riittävän lyhyitä askeleita tavoite kirkkaana mielessä.

Hei lukija! Tieturilla on tapana järjestää testausaiheinen seminaari joka kevät. Aiheet iskevät jälleen napakasti testauksen kuumimpien puheenaiheiden ja kestosuosikkien ytimeen: Testausautomaatio, pilvipalvelut, mallipohjainen testaus sekä ketterät menetelmät saavat kaikki osansa puhujan pöntöstä käsin.

Lisäksi seminaarin loppuhuipennuksena palkitaan jälleen kerran vuoden testaaja. Koska olen itse ehdokaslistalla, niin mainostan:

1. Itseäni: Ehdokas numero 2, Antti Niittyviita
2. Itse äänestystä: Ilman muuta kannattaa äänestää!

Käy siis antamassa äänesi parhaalle ehdokkaalle täällä!

(19.4.2011:Testaaja 2011 -äänestys on nyt päättynyt. Jos et äänestänyt et voi valittaa.)

Testausguru Esko työskenteli softakehittäjien kanssa tiiviissä yhteistyössä projektissa, jonka työtapa oli jatkuva integraatio. Eskon vastuulla oli huolehtia, että softan laatu on aina hyvä. Testauksen lisäksi Esko huolehti siitä, että löydetyt virheet myös korjataan.

Jatkuva integraatio tähtää aina toimivaan järjestelmään. Kun kehittäjä lyö tekemänsä muutoksen versionhallintaan, niin järjestelmän pitäisi olla sen jälkeen ehommassa iskussa. Yleensä järjestelmästä tehdään buildi heti muutosten jälkeen tai joka yö töiden päätyttyä. Perinteisesti testaaja iskee kiinni nimenomaan näihin yöllisiin buildeihin.

Esko tiesi tämän tavan ongelmat. Kun testaaja työstää yöllistä buildia, niin kehittäjä painiskelee jo uusien asioiden kanssa. Vaikka kehitys ketterää onkin, niin silloin testaaja työstää vanhaa softaa. Kun virhe löytyy tässä vaiheessa, se on jo myöhäistä. Testaaja ja kehittäjä joutuvat hyppäämään aikakoneeseen ja palaamaan ongelman alkulähteelle.

Tämä menetelmä lähestyy aivan huomaamatta perinteistä vesiputousmallia. Se on siis sarja pieniä vesiputouksia. Speksaus-devaus-testaus. Näin toimii hämmästyttävän iso osa yrityksistä, jotka väittävät testauksen olevan saumaton osa ketterää kehitystä.

Jotta testaus kulkee ketterän kanssa käsi kädessä, edellä kuvattua kuilua pitää kaikin tavoin kaventaa. Esko osasi hommansa, otti härkää sarvista ja kavensi kuilua. Esko ehdotti kehitykselle yhteistyön tiivistämistä entisestään. Mitä siis Esko ehdotti?

Kehittäjä toimittaa JOKAISEN tuotoksensa AINA ensin testaukseen. Vasta sen jälkeen tulee versionhallinnan vuoro.

Esko otti rohkeasti vastuun muutoksen lanseeraamisesta. Hän rohkaisi kehittäjiä tuomaan kaikki korjaukset ensin itselleen ja vasta sitten versionhallintaan. Tuloksena löytyi iso määrä bugeja jo ennen yöllisiä buildeja. Virheet siis löytyivät yli vuorokauden aikaisemmin, mikä oli oikeasti merkittävä aika kahden viikon sprintissä.

Regressiovirheiden määrä yöllisissä buildeissa putosi 60% ja niistä löytyneiden muiden virheiden selvittelyyn haaskattu aika putosi lähes puoleen.

Kun testausguru parantaa prosessia, se tuottaa hyvää tiimin kaikille pelaajille.

Oletko koskaan reklamoinut saamastasi tuotteesta tai palvelusta? Oletko koskaan vienyt tuotetta takuuhuoltoon? Tältä homma näyttää tiskin toiselta puolelta tarkasteltuna.

1. Asiakaspalvelu kuuntelee valituksesi ja yrittää auttaa: 10 min
2. Tekninen asiakaspalvelu yrittää korjata vian kanssasi: 10 min
3. Lopulta tekninen asiakaspalvelu kirjaa virheraportin: 10 min
4. Tukivastaava tutkii raportin, testaa ja lähettää sen tuotekehitystiimille: 1 tunti
5. Tuotekehitystiimi tutkii, korjaa ja testaa: 10 htp (70 tuntia)
6. Korjaus jaellaan nykyisille asiakkaille, mikäli mahdollista 2 htp (15 tuntia)
7. Lähetetään palaute valituksen tehneelle asiakkaalle läpi koko ketjun: yht 30 min

Kun yksi asiakas valittaa, niin silloin ei vielä lähdetä tekemään korjaavia töitä. Kun 100 asiakasta valittaa on vian syykin varmasti ilmeinen. Koko valitusrumba vie yhden valituksen kohdalta noin 2 tuntia. Kun valittajia on 100, se tekee 200 tuntia. Korjaaminen ja korjauksen jakelu syö vielä 85 tuntia.

Siis yhteensä 285 tuntia! Työpäivissä se tekee 38. Hyvinkin maltillisella 350 euron päiväkustannuksella koko show syö rahaa 13.300 €! Eikä siihen ole vielä laskettu virheellisestä tuotteesta aiheutunutta imagohaittaa tai mielipahaa asiakaskunnassa. Lisäksi korjauksen jakelu voi todellisuudessa viedä jopa 100 kertaa enemmän aikaa, mikäli se vaatii tuotteen takaisin kutsumisen.

Testauksen tehtävä on eliminoida mahdollisiman tehokkaasti nämä kustannukset jo tuotekehityksen aikana, ennen kuin tuote on käynyt yhdelläkään asiakkaalla.

On siis täysin turha selitellä, miksi testaus on vain turha kuluerä.

Tänäaamuna herätessäni fiilis oli hyvä. Keväinen aamuaurinko lämmitti mukavasti sälekaihtimien läpi, linnut lauloivat ulkona ja aamukahvin aromi täytti talon. Sunnuntaiaamun perinteinen paahtoleipä pomppasi terhakasti paahtimesta ja aamupalan aika oli käsillä.

Heti aamupalan alkumetreillä jokin tuntui kuitenkin olevan pielessä. Perinteisen paahtoleipäni suutuntuma oli jotenkin laimea. Rapeaa se kyllä oli, mutta makumaailmasta puuttui jokin olennainen. Iskiessäni hampaat leivän toiselle kolmannekselle vihdoin ymmärsin, että kysymys on suolasta. Tai tarkemmin ottaen sen puuttumisesta.

Urheasti päätin kuitenkin jatkaa leipäprojektini viimeiselle kolmannekselle, mutta sitten alkoikin tapahtua. Tunnistin napakan suolaisen maun, joka alkupäästä oli puuttunut. Maku saapui viipyillen, mutta ylitti pian kaikki odotukseni. Kaikki tähän leipään mitoitettu suola oli leipurin näpeissä jäänyt tuohon dramaattiseen viimeiseen kolmannekseen. Ja pahaltahan se maistuikin! Välillä oli jopa pysähdyttävä sammuttamaan palavaa janon tunnetta.

Ohjelmistokehitys on kuin tuo paahtoleipä. Jos kaikki ymmärtäisivät sen, suurin osa projekteista pysyisi aina aikataulussa. Mistä siis on kyse?

Testaus on ohjelmistokehityksen suola. Leipurini tavoin, hämmentävän iso siivu softaprojekteista sijoittaa yhä edelleen koko testauspanoksensa projektin viimeiselle kolmannekselle. Silloin softakehityksen alkupäästä puuttuu särmä ja palautemekanismi. Toisaalta tönkkösuolaamalla projektin loppupää testauksella, törmätään valtavaan määrään ikäviä yllätyksiä. Siksi aikaa palaa myös palopesäkkeiden perässä säntäilyyn ja aikataulut pettävät.

Paras tulos syntyy aina, kun sekoitat ainekset heti alussa!

Teppo Testaajan (nimi muutettu) harteille on vyörytetty suuri vastuu. Tepon on valmisteltava testausraportti viimeisimmästä testikierroksesta. Useita kertoja raportin tehneenä Tepon otsaan alkaa jo ennen kierroksen loppumista ilmestymään pieniä hikipisaroita. Viimein tulee raportoinnin aika. Tärisevin käsin Teppo suorittaa piinaavan pitkän ja turhauttavan prosessin:

1. Teppo exporttaa kalliilla rahalla hankitusta testauksenhallintajärjestelmästä testikierroksen tarkat tiedot käyttäen hyväksi Excel-makroa (jonka hän on itse verta ja kyyneliä vuodattaen tehnyt).
2. Excel-makron tuottamasta taulukkojen sekasotkusta Teppo eristää olennaisimmat tiedot – kuvat ja diagrammit – ja liittää ne lopuksi lähetettävään sähköpostiin. Useat kuvista ja diagrammeista vaativat tarkkaa uudelleen skaalausta liittämisen jälkeen, jotta sähköpostista tulisi luettavan näköinen.
3. Managerit haluavat myös nähdä tarkan listauksen testitapauksista, joten Tepon on edelleen palattava Excel-taulukoiden pariin. Koska suoraan Excelistä rivien liittäminen sähköpostiohjelmaan ei ikinä toimi halutulla tavalla, Teppo joutuu avaamaan notepadin, jonka kautta rivit saadaan liitettyä lopulta sähköpostiin sopivan näköisenä ja muotoisena.
4. Hiki otsalla kimallellen Teppo lisää postin alkuun lyhyen kuvauksen testikierroksen tapahtumista, ongelmista ja niiden ratkaisuista.
5. Lopuksi Teppo liittää kalliilla rahalla hankitusta testauksenhallintajärjestelmästä exportatun Excel-taulukkohelvetin kokonaisuudessaan postiin mukaan. Excel-taulukkohelvetissä löytyy kaikki samat tiedot, mitä Teppo oli juuri tuskalla ja vaivalla koostanut postiin. Teppo tekee parhaansa ymmärtääkseen, että Excel-tiedoston avaaminen ja tietojen lukeminen sieltä on monelle manageritason henkilölle kovin vaikeaa.
6. Teppo lisää sähköpostin vastaanottajakenttään erinäisen määrän osoitteita ja muutaman sähköpostilistankin.
7. Turhautuneena ja lähes itkua tihrustaen Teppo, iso mies ja aikanaan ylpeä Ammattitestaaja, painaa Send-nappia. Lukeekohan tätäkään raporttia kukaan? Viestiin vastaa odotetusti ainoastaan Testimanageri Urpo joka ilmoittaa, että seuraavaan raporttiin on saatava lisää sitä ja tätä ja sen on oltava myös powerpoint-muodossa. Vastauksen lopussa komeilee vielä kysymys, joka pudottaa pohjan kaikelta testauseettisesti oikealta: Miksi raportissa on niin paljon punaista!? Ikäänkuin Teppoa syytettäisiin tästä…
8. Takki täysin tyhjänä Teppo alkaa henkisesti valmistautumaan seuraavaan testikierrokseen.

Kuulostaako tutulta? Hyvän testiraportin aikaansaamiseksi ei nykyaikaisessa kustannustehokkuuden säätelemässä bisnesmaailmassa riitä lopputulos, vaan tärkeää on myös raportin tuottamistapa. Harmillisen useat työkalut eivät edelleenkään synny loppukäyttäjän, eli testausasiantuntijan tarpeista. Käyttäjä on se, joka mukautuu työkalun kiristämässä pakkopaidassa.

Onko liikaa vaadittu, että työkalu tarjoaa suoraan mahdollisuuden koostaa sellainen raportti, joka sisältää yksittäisen käyttäjän itsensä vaatimat kohdat? Onko liikaa vaadittu, että millä hetkellä hyvänsä kuka tahansa työkalun käyttäjä näkee projektin etenemisen vaiheet ja kehityksen kannalta olennaisimmat asiat? Olisihan se utopiaa jos kaikki yllämainittu kävisikin muutamalla hiirenklikkauksella!

Helppokäyttöinen, yksinkertainen ja aikaa säästävä työkalu on tulevaisuuden työkalu. Ihmiset, joilla ei ole tietoa paremmasta ovat urautuneet raiteilleen ja eivät näe uusien työkalujen mukanaan tuomia etuja. Jos on koko ikänsä käyttänyt päivittäin pakkopaitaa ja siveysvyötä, saattavat Havaijipaita ja rennot shortsit kommandona tuntua aluksi melko oudoilta.

Lyhyen päänsisäisen tutustumistyön jälkeen vanhat kiristävät tamineet poljetaan kuitenkin syvälle suohon. On vain ajan kysymys kun kankeat suurten firmojen suurille firmoille valmistamat työkalut syrjäytyvät oikeasti käytännöllisten työkalujen tieltä.

Tyydytkö istumaan pehmustetussa huoneessa pakkopaita päällä juoden valkotakkisen miehen tarjoamaa taikajuomaa tikkupillillä, vai istutko aurinkoisella hiekkarannalla Havaijipaita päällä piña colada kädessä seurustellen mukavien kavereiden kanssa?

P.S. Suosittelemme tutustumaan suomalaislähtöiseen ryhmätyökaluun nimeltä FlowDock. Se on tehty juuri oikealla asenteella loppukäyttäjä mielessä pitäen.

Olemme vuosien varrella valittaneet ankarasti testaukseen liittyvistä asioista. On valitettu huonoista työkaluista, testitapausten suunnittelusta, jäykkäniskaisesta yrityskulttuurista, väärien asioiden tekemisestä ja tehottomuudesta. Valitusta on riittänyt, mutta nyt päätimme muuttaa testaustyön luonnetta heti kerralla. Päätimme kirjata ylös sen mitä useimmat testaajat huomaamattaan jo työkseen tekevätkin.

Me törmäämme yhä maailmalla liikkuessamme muka superhienoihin testispekseihin. Testien suunnitteluun on käytetty pirusti työaikaa ja se tuntuu maksajasta varmasti hyvältä. Yhteistä näille noin 80%:lle perinneprojekteista on törkeän huonot testitapaukset. Yleensä testitapaukset kertovat yksityiskohtaisesti MITEN testi suoritetaan. Silloin nus.. viilataan pilkkua.

En tietenkään sano, että viilaminen on mitenkään tylsää hommaa. Bisneksen tekemisessä paukkuja vain käytetään silloin ihan vääriin asioihin.

Testitapauksen tulee ensisijaisesti kertoa MITÄ tulee tulla testatuksi! Sen voi ihan oikeasti sanoa muutamalla lauseella. Oikeastaan Twitter on todistanut, että useimmat asiat voi sanoa vain 140:llä merkillä!

Testauksenhallintajärjestelmien käyttöä ja testaustyön dokumentointia puoltavia perusteluja on runsaasti. Mutta kuinka voitaisiin yhdistää nopea ja tavoitekeskeinen testaussuunnittelu, tutkiva testaus ja sopiva dokumentoinnin taso raportointia ajatellen?

Erittäin toimivaksi ratkaisuksi olemme huomanneet tutkivan testauksen jota tuetaan tarkistuslistoilla. Homma toimii siten, että testispeksit tehdään yksinkertaisena tarkistuslistana asioista mitä session lopussa tulee vähintään olla testattuna. Otsikointiin riittää helposti tuo 140 merkkiä ilman että järkeään käyttävälle testaajalle jää epäselväksi testin tavoite. Testitapauksen askelet ja muun oheiskrääsän olemme heittäneet mäkeen. Yleensä niiden kanssa säätäminen syö vain aikaa, eli rahaa.

Tarkistuslistaa voi käyttää testauksenhallintajärjestelmästä ja tuloksetkin voi kirjata sinne. Myös Excel toimii varsin helposti kun muistaa minimalistisen lähestymiskulman.

• Testien suunnittelu ja speksaaminen on supernopeaa
• Testien ajaminen ei aiheuta putkinäköisyyttä vaan on tutkivaa
• Virheitä löytyy merkittävästi enemmän käytettyyn rahamäärään nähden
• Pomokin tykkää kun pystytään lyömään statsit ja rapsat tiskiin
• Tarkistuslistat kelpaavat myös esimerkiksi käyttöönottoinsinöörin työvälineeksi

Asiaa voi pysähtyä pohtimaan myös testausammattilaisen näkökulmasta. Hänen voi huomata tekevät töitä hyvin saman kaltaisilla menetelmillä jo valmiiksi. Ainoa ongelma on, että usein hän tekee sen kaiken jäykkäniskaisen, pysähtyneen ja muutosvastarintaisen prosessin kahlitsemana. Siksi tuloskaan ei aina tyydytä!

Saat enemmän vastinetta rahoillesi, kun uskallat antaa testausosaajasi hoitaa hommat kuten osaajan kuuluukin.

Juuri pöllimäni tarina kertoo ukrainalaisesta luutnantista, joka lähetti pienen tiedustelujoukon Alpeille. Raju lumimyrsky yllätti ryhmän ja pyryä jatkui taukoamatta kaksi päivää. Luutnantti oli varma karvaasta miestappiosta, kun ryhmästä ei toisenkaan päivän iltana kuulunut uutisia. Kaikkien suureksi yllätykseksi ryhmä kuitenkin palasi vuorilta kolmantena päivänä ja vieläpä ehjin nahoin. Mitä oli tapahtunut? Kuinka ryhmä selviytyi tukalasta tilanteestaan?

Helmikuun kuumottavin puheenaihe on ollu palava lautta. Erityisesti Nokian sellainen. Stephen Elopin kirje työntekijöille kertoi karua kieltä. Erityisesti siitä että Nokialla tehtään yhä paljon vääriä asioita.

Chinese OEMs are cranking out a device much faster than, as one Nokia employee said only partially in jest, “the time that it takes us to polish a PowerPoint presentation.”

Karkeasti ottaen kysymys on siitä, että kiinalainen laitevalmistaja pukkaa tuotteen markkinoille nopeammin kuin Nokialla saadaan PowerPoint kalvot kasaan. Sama ongelma vaivaa isoa siivua suomalaisia yrityksiä tuotekehityksestä testaukseen. Työpanoksesta suuri osa valuu monesti suunnitteluun, säätämiseen ja excelien pyörittelyyn. Tuloksen syntymisen kannalta siis joutavaan puuhasteluun.

Ukrainalainen tiedustelijaryhmä selvisi tukalasta tilanteestaan nopealla toiminnalla. Tilanne oli näyttänyt epätoivoiselta myös tiimin näkökulmasta kunnes joku oli löytänyt taskustaan kartan. Sen jälkeen tiimi ryhtyi toimeen. He pystyttivät leirin, odottivat myrskyn loppumista ja selvisivät lopulta takaisin tukikohtaan. Mielenkiintoista tarinassa on se, että tämä kartta oli Pyreneiltä, ei Alpeilta.

Jos ryhmä olisi alkanut viilaamaan suunnitelmaa, selviytymisstrategiaa ja vielä dokumentoimaan sitä, kaikki olisivat auttamatta paleltuneet kuoliaaksi. Sen sijaan he päättivät rauhoittua, ottaa härkää sarvista ja panna toimeksi. Tarinan opetus tietysti on se, että usein huonokin suunnitelma riittää.

Testaustyössä kuvitellaan usein, että hyvä testiplani ja tarkka testispeksi ovat olleet menestyksen salaisuus. Esimiehet ovat tykänneet kivoista exceliraporteista ja softakin on saatu yleensä aikataulussa valmiiksi, kiitos devausgurujen. Siksi liian moni testausasiantuntija urautuu. Hän kuvittelee, että menestys on saavutettu nimenomaan suunnitelmien ja speksien kautta ja alkaa panostaa aina enemmän näihin asioihin.

Kun urautunut asiantuntija panostaa jatkuvasti enemmän suunnitteluun ja excel-harjoituksiin, amatööriltä näyttävä kilpailija painaa ohi oikealta ja vasemmalta.

Kun yksi laittaa töpinäksi, hän tutkii hetkessä monta reittiä loppuun saakka. Samassa ajassa ns. fiksut hädin tuskin ehtivät valmistautua edes ensimmäiselle etapilleen.

Todelliset onnistujat menestyvät, koska he riisuvat kravaatin, käärivät hihat ja ryhtyvät heti toimeen! Siksi hyvin suunniteltu ei ole puoliksi tehty.

Jos softakehitystä ja laatua ei voi mitata rahalla, niin millä sitten?

Oletetaan että sinulla on softatuote ja yksi 10 hengen softankehitystiimi. Tuote pitää päivittää uuteen versioon neljä kertaa vuodessa ja päivitysten asentaminen asiakkaille on hoiduttava mutkattomasti.

Jokainen virheestä johtuva myöhästyminen toimituksen valmistumisessa viivästyttää koko projektia 3 päivää. Se vaatii koko tuotekehitystiimin työpanoksen. Maltillisella 50 euron tuntihinnalla viivästys kustantaa 11000,-/laaki. Lisäksi se myöhästyttää seuraavan tuotekehityssyklin aloitusta ja pakottaa asennustiimin pyörittelemään peukaloitaan. Ja taksamittari raksuttaa.

Jokainen vakava asiakasreklamaatio työllistää tuotetukeasi 2 tuntia, tuotekehitystä ja testausta fiksien muodossa 3 päivää. Hinta 1200,-/laaki. Lisäksi se vaikuttaa negatiivisesti yrityksesi imagoon!

Jokainen uusi asiakas, joka takuuaikana valittaa toimituksesta, työllistää asennustiimiäsi 5 päivää lisää. Hinta 1900,-/laaki.

Esimerkiksi 15 tarpeetonta asiakasreklamaatiota vuodessa, 3 virheestä johtuvaa myöhästymistä ja 4 uuden asiakkaan reklamaatiota takuuaikana kustantavat vuodessa yhteensä 58600,-

Järkevästi rakennettu testaus maksaa itsensä aina takaisin.