Category: Ohjelmistotestaus

  • Monologi kostautuu tuotekehityksessä

    Viimeviikolla tutustuimme projektiin, joka oli kuukauden myöhässä määräajasta. Koska raha ajaa yritysten toimintaa ja testauksen tulee aina olla investointi päätimme selvittää mistä oli kysymys: Haastattelimme projektiryhmää.

    Tuotekehityksen sykli yrityksessä oli kokonaisuudessaan 3 kuukautta ja testaus painottui syklin loppuun. Haastattelun jälkeen saatoimme todeta, että syklin loppusuoralla löydettyjen bugien määrä oli, kuten aina, yllättänyt tuotekehityksen housut kintuissa. Bugien määrä ei kuitenkaan ollut suurin haaste. Ongelmien korjaaminen vain vei aina hämmentävän paljon aikaa. Mutta miksi niin kävi?

    Ajatellaanpa tilannetta, kun Kauno Koodaaja rakentaa uuden ominaisuuden. Koodirivejä tulee paukuteltua helposti satoja. Kaunon elo-syyskuussa tuottama koodi päätyy testausvaiheeseen lokakuussa ja bugiraportteja alkaa tipahdella. Korjaustoimet voivat alkaa, mutta mitäpä luulette: Muistaako Kauno vielä mitä muutoksia koodiin tuli elokuussa tehtyä?

    Onko ollenkaan ihme, että vanhojen koodirivien kaivelu vie paljon aikaa?

    Totesimme, että sama ongelma vaivasi lähes systemaattisesti projekteja, joiden tuotekehityssyklit olivat pitkiä ja testaus painottui loppusuoralle. Ensin tuli koodauksen monologi, sitten testauksen vuoro. Tuotekehitys oli ja pysyi tahmeana. Ratkaisuvaihtoehtoja ongelmaan keksimme kaksi:

    1. Nopeutetaan palautesykliä pakottamalla kehitys ja testaus vuoropuheluun
    2. Budjetoidaan aina projektille pitkästi korjausaikaa ja toivotaan parasta

    Ei varmaan tarvitse olla hirmuinen ruudinkeksijä, että arvaa kumman vaihtoehdon tuotekehityksen johto valitsi.

    Tuotekehitys on aina tiimipeliä. Laatu on myös aikatauluissa pysymistä. Vain nopea dialogi testauksen ja kehityksen kesken voi tuottaa nopeita tuloksia.

  • Eihän aikatauluun kannata investoida!

    Iskimme taannoin kiinni projektiin, jossa toimituksen määräaika oli myöhästynyt viimehetkellä löytyneiden virheiden takia jo kuukauden. Ei mitään uutta taivaan alla, totesimme. Tämä tuotekehityssykli oli jo mennyttä kalua.

    Aloituspäivän lounastauolla pysähdyimme puhumaan rahasta, kuten meillä usein on tapana.

    Kun projekti myöhästyy, niin mitä se tarkoittaa tuotteen tekemän liikevaihdon tai budjetin näkökulmasta?

    Jos tuotekehitystiimiin uppoaa 15 henkilön täysi työpanos kuukaudessa, niin varovaisen arvion mukaan ylimääräinen kuukauden uurastaminen ongelmien korjailussa maksaa helposti työnantajalle mansikoita.

    Palkkavertailu.com -palvelun mukaan ohjelmistokehittäjän keskipalkka on noin 3.600€. Työnantajan sivukulujen ja lomapalkkojen kanssa kokonaiskustannus on noin 5.400€. 15 henkilön tiimi kustantaa kuukaudessa 81.000€ (*)

    Pelkästään projektin myöhästymisestä aiheutuva suora kustannus on melko kova. Budjetti paukkuu pahasti ja kate rapautuu, vaikka kyseessä olisi pitkäkin projekti.

    Myöhästyminen ei maksa pelkästään rahaa. Asiakas voi odotella päivitystä kuin kuuta nousevaa. Pettymyksen tunnetta on aika paha paikata. Myös tulevaisuuden kaupat voivat lykkääntyä. Jopa jäädä kokonaan syntymättä. Yrityksen resursointi häiriintyy, sillä seuraavaan projektiin ei olekaan tekijöitä vapaana. Lopulta sekin viivästyy. Tulee ajolähtö. Vaikutuksia tulvii mieleen, vaikka vain hetkeksi pysähtyy pureskelemaan asiaa. Äkkiä herää kysymys.

    Paljonko sinä olisit valmis investoimaan, jotta projekti sittenkin pysyy aikataulussa?

    (*) Todellisuudessa kustannus on vielä suurempi. Työsuhde-edut, työterveyshuolto ja työvälineet maksavat myös!

  • Toimitusjohtajan kuuluisat viimeiset sanat

    Heräsin yöllä huutooni!

    Ohjelmistotestaus.fi sai viimeviikolla odottamattoman kävijäryntäyksen. Vuorokaudessa sivustollamme vieraili yli 33.000 lukijaa. Lukijamäärä yli 10-kertaistui yhdessä yössä. Olin varsin tyytyväinen, sillä tätä olimme salaa toivoneet blogin aloittamisesta alkaen. Olimme investoineet siihen massiivisen määrän työaikaakin!

    Testausgurumme Esa kysyi minulta tuona ensimmäisenä aamuna kysymyksen joka jäädytti kahvin kuppiinsa ja pysäytti seinällämme komeilevan kellon aikaan 09:54. Silmissä sumeni.

    Kestääkö blogi tällaista kuormaa? Onko sitä testattu?

    Siinä samassa mieleeni tulvi kauhutarinoita viittä vaille onnistuneista menestystarinoista ja hirveistä katastrofeista.

    1. Sampopankin verkkopankkiuudistus oli polvillaan välittömästi käyttökatkoksen jälkeen ja asiakkaat pakenivat joukolla.
    2. VR:n lippupalvelu-uudistuksesta puhutaan edelleen vaikka asiakasmäärät eivät ylittyneet edes 2-kertaisesti odotetusta.
    3. Fortumin vikailmoitusjärjestelmä meni nurin viimetalven lumimyrskyjen jälkeen. Asiakkaat jäivät sekä ilman sähköä että ilman toimittajan tukipalvelua.
    4. Marimekko onnistui huikeassa PR-tempussa saamalla logonsa Google -haun etusivulle. Marimekon koko PR-potentiaali valui hukkaan kun sivut kaatuivat alle tunnissa.

    Kaikki tämä kulki läpi tajuntani noin 30 sekunnissa.. Kellon lyödessä 09:55 sain juuri ja juuri koottua itseni. Vastasin Esalle viileästi ja sokean idioottimaisesti.

    Kyllä se varmaankin kestää. Blogi on kai melko kevyt ja palveluntarjoajamme kuulemma on ihan hyvä.

    Jokainen maalaisjärjellä varustettu ihminen näkee vastaukseni älyttömyyden välittömästi ja saattaa jopa vähän hymyillä. Valehtelin Esalle ja itselleni törkeästi. Onneksi nuo juuri lausumani sanat eivät jääneet tämän tarinan viimeisiksi.

    Tilaisuus räjähdysmäiseen onnistumiseen tulee yleensä yhden ainoan kerran. Jos palvelusi ei sillä hetkellä kestä, asiakkaat tuskin palaavat. Älä siis polta tuotekehityksesi ja markkinointisi investointeja laiminlyömällä yksinkertaisimpia testejä.

  • Tarinoita IT-hankkeiden ihmemaasta

    Lukijamme on lähestynyt meitä erittäin kiinnostavalla tarinalla julkisen sektorin IT-hankkeista. Tarina herättää varmasti fiiliksiä sekä puolesta, että vastaan.

    Hei,

    Olen lukenut blogistanne vuosien varrella pari juttua joissa on ohimennen puhuttu julkisista IT-projekteista. Haluaisin nyt tuoda tähän aiheeseen lisävalaistusta.

    Olin hiljattain isohkossa julkisen puolen IT-projektissa pääkaupunkiseudulla. Tavallisesta poikkeavaksi tilanteen teki se, että Tilaaja oli hankkinut itselleen ammattitestauksen turvaamaan tilauksen tason. Minä olin yksi näistä Tilaajan testaajista.

    Kyseessä oli SAP-ympäristössä pyörivä järjestelmä. Järjestelmässä oli useita osia ja näille omat Toimittajansa ja kaikkien Toimittajien piti saada omat palikkansa keskustelemaan toisten Toimittajien palikoiden kanssa.

    No aloitimme tietenkin heti testaustyön kun työmaalle päästiin. Toimittajat olivat saaneet rakennettua järjestelmän jo sille mallille, että järjestelmän eri osiin pystyi kirjautumaan ja niitä yksittäisinä palikoina testaamaan. Vain parin tunnin päästä testauksen aloittamisesta oli selvää, että nyt saattaa hyvin tulla bugien kirjoittamisen uusi Suomen ennätys tai jopa Maailman ennätys. Korostan, että olimme vasta aloittaneet Toimittajien yksittäisten järjestelmän osien testauksen. Bugeja löytyi kaikilta ohjelmistotestauksen osa-alueilta alkaen käytettävyydestä aina turvallisuuteen asti.

    Raportoimme välittömästi bugit ja kun raportti saavutti Toimittajat, niin alkoi show jota en ole urallani kertaakaan aikaisemmin nähnyt. Toimittajat ottivat välittömän puolustusaseman ja alkoivat asemasodan testausta vastaan.

    Emme osanneet testata, testasimme prosessin vastaisesti ja testasimme täysin vääriä asioita.

    Yksi SAP-Toimittajan edustaja huusi ihan suoraa huutoa, sillä bugeja oli liikaa. He eivät olisi millään niitä halunneet korjata niitä, ainakaan samalla rahalla.

    Tästä “prosessin vastaisesta” testauksesta nousi oma suosikkini. Toimittajat olivat sitä mieltä, että kun on prosessiksi sovittu nappien painamisjärjestys 1 ja 2 niin se on sitten se eikä muita hyväksytä. Me tottakai testasimme myös mitä tapahtuu kun painaa 2 ja 1, ja niinhän sieltä paljastui että luvattoman monessa kohtaa järjestelmä rakoili ja lopulta kaatui.

    On älytöntä olettaa, että loppukäyttäjä ei koskaan painaisi nappeja väärässä järjestyksessä.

    Minulle alkoi selviämään pala kerrallansa, että mistä on kyse. Toimittajat olivat vuosikausien aikana tottuneet siihen, että bugien korjaus laskutetaan erikseen ja siitä oli muodostunut heille merkittävä osa projektin laskutusta. Toimittajille on hyvää businesta IT-projektin venyminen, sillä heille se tarkoittaa isompaa laskutusta ja voit uskoa minua kun sanon, että laskutus juokseen.

    Toisinaan vitsailin kollegani kanssa, että taitaa olla laskutus Toimittajan ainoa asia mikä toimii hyvin. Minulle jäi käsitys, että oli varsinkin SAP-Toimittajille ensimmäinen kerta kun he kokivat, että Tilaaja testautti tilauksen ulkopuolisilla ammattilaisilla ennen tilauksen hyväksymistä ja tämä nyt sitten tavallaan vaaransi Toimittajien normaalit laskutusrutiinit. Itse henkilökohtaisesti selitin Tilaajalle, että näin bugisesta toimituksesta ei kannata maksaa mitään ja että ennen kuin edes harkitaan laskun maksua, niin bugit on korjattava ja testaamalla todettava korjatuiksi.

    Ehdimme toimia Tilaajan palomuurina puoli vuotta kunnes sitten eräänä päivänä tuli ilmoitus:

    Johtokunta oli päättänyt antaa potkut Tilaajan testaustiimille.

    No eipäs siinä mitään ihmeellistä, ajattelin. Olimme saaneet kuitenkin jo paljon asioita etenemään ja opetettua Tilaajalle tärkeitä asioita IT-järjestelmien tilausprosessista ja softatestauksesta. Olin siis kohtuullisen tyytyväinen kaikesta huolimatta, mutta toki samalla ymmärsin sen, että valmista ei tule tästäkään hankkeesta vuosikausiin, mutta hyvin lähellä he olivat.

    Tässä ei kuitenkaan ollut vielä kaikki. Vielä projektissa olessani, sain kuulla että tässä johtokunnassa istuu näppärästi Tilaajan ja Toimittajan edustajat yhdessä. Toki on hyvä asia, että Tilaajalla ja Toimittajalla on yhteinen foorumi, mutta tämä johtokunta pystyy päättämään esimerkiksi että poistetaanko Tilaajalta testaus.

    Päätöksen tämän kirjoituksen laatimisesta tein kuitenkin vasta sen jälkeen kun kuulin toiselta testaajakollegaltani, että hänen julkisen puolen IT-projektissa oli johtokunnassa sama järjestys. Heillä vain oli testaustulokset heitetty lähes sellaisenaan roskiin. Kyseinen IT-hanke meni pahasti pieleen ja saimme kaikki lukea siitä valtakunnan ykkösmedioissa.

    Tarinahan jatkuisi vaikka kuinka pitkään ja herkullisista yksityiskohdista ei ole puutetta. Lopuksi mainittakoon vielä yksi sellainen. Koimme nimittäin tilanteen, missä Toimittajat olisivat halunneet myydä Tilaajalle omat testaajansa tai “konsulttinsa” kuten SAP-piireissä on tapana sanoa. Tämä on ajatuksena aivan käsittämätön.

    Tilannehan olisi täsmälleen sama, jos huoltaisit itse oman autosi ja suorittaisit vielä katsastuksen päälle omakätisesti.

    Kaikesta huolimatta kyseinen projekti oli minulle ehkä urani paras. En nimittäin ole armeija-aikani jälkeen nähnyt kun aikuinen mies huutaa ja ulisee täyttä kurkkua työaikana. Sain kokea hurjan konkreettisesti testauksen tehon ja minä tarvitsin tämän kokemuksen. Tästä on hienoa jatkaa.

    Kun Toimittaja huutaa kurkku suorana, on testaaja saattanut tehdä jotakin oikein.

  • Ensin hutkitaan, sitten vasta tutkitaan

    Kävin kesälomilla huvipuistossa. Jokaisen huvipuiston vakiokalustoon kuuluun klassinen karnevaalivasarapeli. Mieleeni palasi elävästi viimekertaiset Aaltoyliopistolla järjestetyt TalentIT -messut. Reaktorin standilla oli kunnon bileet. Porukka jonotti päästäkseen tutustumaan messujen vetonaulaan, tuohon nimenomaiseen “High Striker” -peliin.

    Seurasin peliä ja ihmisten yrityksiä kiinostuneena. IT-alalle opiskelevat ja alalla työskentelevät jonottivat innokkaasti päästäkseen kiskaisemaan kiukkuisimman lyöntinsä, mutta kovin harva seurasi lyöntitekniikkaa sivusta tai pysähtyi miettimään, miten pelistä saisi parhaan tulokseen.

    Ensin vain hutkittiin ja lopulta kukaan ei pysähtynyt tutkimaan

    Harmillisen usein testaajat lähtevät kohteltamaan tutkivan testauksen ihmemaassa samalla tavalla. Eletään kuin pellossa metsästellen bugeja, mutta ei oikeasti yritetä ymmärtää mitä konepellin alla todella tapahtuu. Sehän on työlästä ja joutuu ajattelemaan liikaa.

    Kuitenkin lähes poikkeuksetta hyödyllisimmät testauksen tulokset syntyvät tuumaamalla hetken ennen suoritusta. Etsimällä ymmärrystä.

    High Strikerissä parhaan tuloksen olisi saanut tutustumalla ensin pelin mekanismiin sivulta päin. Tässä pelissä lyötiin vähän keinulaudan näköisen levyn toiseen päähän. Vastakkaisessa päässä oleva punnus pomppasi ylös lyönnin voimasta. Peli mittasi kuinka korkealle punnus sitten lensi ja kertoi tietysti lyöjän voiman.

    Punnus ei ole järjettömän painava, joten punnuksen hypähtämiseen ei olisi tarvittu suurta momenttia. Siksi järkevintä olisi ollut lyödä keinulautaan läheltä sen keskikohtaa ja toisaalta pitää mahdollisimman kaukaa kiinni vasaran varresta. Näin laudan heilahdusliike olisi ollut nopein mahdollinen ja punnus olisi näyttänyt varsin hyviä lukemia kaikille suorituksille.

    Kaikki löivät kuitenkin laudan päähän ja tulokset olivat sen mukaiset.

    Äkkiä herääkin kysymys: Mitä tutkiva testaus todella tarkoittaa? Minusta siinä on kysymys ensin tutkimisesta ja sitten testaamisesta.

    Testaajan on siis syytä pysähtyä säännöllisesti. Tutkia tuotteen arkkitehtuuria, konseptia ja toimintaa. Vain sillä tavalla voi ymmärtää kokonaisuuden ja lopulta tuottaa hyödyllisimmät tulokset myös testaamisesta.

  • Ehdokas vuoden 2012 kalleimmaksi bugiksi

    Kesälomat alkaa olla lusittuna, illat pimenee ja työtahti tiivistyy!

    Blogi avaa kevyellä bugi-aiheisella uutisella. Tämäkin blogi on ajoittain ruotinut kalleimpia virheitä. Vuoden 2012 kisaan on ilmoittautunut varteenotettava vaihtoehto.

    Jersey Cityssä pääpaikkaansa pitävän Knight Capitalin kaupankäyntiohjelmiston algoritmiin on livahtanut virhe, joka on aiheuttanut 440 miljoonan dollarin vahingon. Seuraavana päivänä yhtiön arvo romahti yli 50%. Päivän päätteeksi pörssikurssi oli n. kolmanneksen pienempi kuin ennen virheen sattumista.

    Eikä siinä vielä kaikki. Kun selailee Knight Capitalin verkkosivuja, voi tappio olla merkittävästi suurempi. Yritys nimittäin markkinoi sivuillaan hyvin voimaakkaasti teknologiaansa tehokkaan ja tuottoisan kaupankäynnin ytimenä. Teknologiaa esittelevällä sivustolla kerrotaan mm. näin:

    Our robust technology infrastructure and flexible architecture provides instant access across multiple asset classes to liquidity both within and outside of Knight.

    Ja näin:

    With our regular, prudent investments in our technology platform, Knight strives to remain ahead of the latest technology developments, providing advanced market access and trade execution services across multiple asset classes.

    Mitäpäs luulette nykyisten ja tulevien asiakkaiden ajattelevan yrityksen luotettavuudesta, kun keihäänkärjeksi nostettu teknologia pettää dramaattisella tavalla? Ei se ainakaan lisää asiakkaiden luottamusta.En ihmettelisi yhtään, vaikka sijoittajat alkaisivat vetää rahojaan pois. Ainakin uutisen kommentit ennustavat kovin synkkää tulevaisuutta yritykselle.

    Mikäli markkinoit yrityksesi teknologista ylivertaisuutta, joudut myös väistämättä panostamaan sen toimivuuteen. Muuten bugit käyvät reaalista arvoaan paljon kalliimmiksi.

  • Aurinkoista kesää – blogi jää kesätauolle!

    Meillä on tapana tarjoilla kahvia ja joskus jopa pullaa toimistollamme vieraileville ihmisille. On mukavaa kun käy vieraita!

    Keskimäärin kahville tulevat henkilöt käyttävät seuraavaa reittiä: kiinteistön alaovesta ovisummeria painamalla sisälle rappukäytävään, rappukäytävästä toimiston ovelle ja toimiston ovelta toimistoon. Toki tätä reittiä käyttävät yleensä myös työntekijämme.

    Tämä kaveri päätti kuitenkin käyttää vaihtoehtoista tapaa:

    Katulamppujen korjaaja vaikutti tyytyväiseltä tuoreeseen, maidolla ja sokerilla höystettyyn kahviinsa. Kuulemma hän ei ole koskaan ennen juonut taukokahveja nosturin korissa.

    Ohjelmistotestaus.fi jää kesätauolle heinäkuun loppuun saakka. Ota mallia katulamppujen korjaajasta ja tee kesän aikana jotain sellaista, mitä et ole koskaan aikaisemmin tehnyt. Mukavaa Juhannusta ja aurinkoista kesää kaikille!

  • Devaajan tilitykset (Osa 1)

    Me koodaajat olemme kofeiinia sovelluksiksi muuntavia otuksia joille tavallinen ihminen viestii lähettämällä bugiraportteja. Pahimmillaan “raportti” on vain ilmoitus “Tämä ei toimi”. Parhaimmillaan se on tyhjentävä, mutta napakka selostus, jota lukiessa voi jo keksiä ratkaisun.

    Valitettavan usein raportti on ensin mainitun kaltainen. Siitä seuraa verenpaineen nousua ja epäterve tarve kommunikoida. Usein haaskaantuu myös arvokasta aikaa useammalta osapuolelta.

    Peruskoulussa voisi aivan hyvin yhden ainekirjoituskotitehtävän vaihtaa bugiraportin kirjoittamiseen. Koodareiden ja FedExin lentokonemekaanikkojen hermojen säästämisen ohella siitä voi olla hyötyä vaikka takuupalautusasioissa. Tärkeä kansalaistaito siis!

    Riittävän hyvä raportti on mielestäni helppoa tehdä. Pitää vain muistaa kaksi ässää – stepit ja screenshot. Eli vaiheittainen selostus: mistä aloitettiin, mitä tehtiin, minne päädyttiin. Jos haluaa olla oikein super, niin kannattaa raportoida myös minne olisi pitänyt päätyä. Lisäksi tässäkin tapauksessa vanha sananlasku pitää paikkansa: Kuva kertoo enemmän kuin tuhat sanaa.

    Kirjoittaja tietää mistä puhuu. Hän on tuottanut enemmän bugeja kuin raportteja.

    * Juhamatti Niemelä on pitkän linjan testausautomaatioguru ja koodaaja kuumimmasta päästä. Hänellä on ollut sormensa pelissä myös Tarantula -testauksenhallintajärjestelmän kehityksessä.

  • Suomalaisen miehen ongelma

    Taulukisko on yksinkertainen lista, joka asennetaan talossa katon rajaan. Kiskosta voidaan ripustaa siimalla tauluja roikkumaan sopivalle korkeudelle ja sopivaan paikkaan. Seinään ei tarvitse porailla reikiä, joten taulujen vaihtaminen ja asemointi uudelleen on helppoa ja mukavaa.

    Minun taulukiskoni on pyörinyt vaatehuoneen perällä viimeiset kaksi vuotta. Tuona aikana olen ehtinyt myös muuttaa pari kertaa. Silti tuo kisko ei vain ikinä ole päätynyt oikealle paikalleen.

    Vaivani on lähes kaikkia suomalaisia miehiä häiritsevä ongelma.

    En pysty ryhtymään toimeen, sillä ensin pitäisi käydä rautakaupassa. Työkaluostoksilla siis. Pitäisi ostaa tikkaat, ruuvinväännin, erikoiskantaisia ruuveja ja työhousut, joiden taskuun välineet voi laittaa kiipeiyn ajaksi.

    Kun ongelmatilannetta pysähtyy pohdiskelemaan tarkemmin, niin ratkaisukin on selvä. Voisin nousta keittiöjakkaralle ja ruuvata sen kiskon vaikka käsipelillä. Lopputuloskin olisi varmasti oikein hyvä. Toimeen ryhtyminen on vain niin perhanan vaikeaa.

    Äkkiä mieleen palaavat työntekijämme Turkka Jalmasen sanat:

    Työkalut ja menetelmät tulevat ja menevät. Pääasia on, että tulosta syntyy. Siksi tänään on hyvä päivä kääriä hihat ja ryhtyä toimeen.

  • Löydä virheet, kun niiden korjaaminen on halvinta

    Proven Jukka on rakentamassa taloa. Nykysuuntauksen mukaan kylppäriin tulee kaksi suihkua, neliönmallisen huoneen vastakkaisiin nurkkiin. Suihkuja varten piti nurkkaa “oikaista”, jotta suihkun tarvittavine hanoineen saa kätevästi seinään kiinni.

    Koska oma ammattitaitoni soveltuu lähinnä vakuttavan kuuloiseen puheeseen ohjelmistojen testaamisesta, päätin tilata paikalle ammattimiehen.

    Ammattimiehen tehtävänä oli rakentaa metallikehikko suihkun taustaa varten ja kiinnittää se. Koska kyseessä oli ammattimies, kehikko valmistui nopeasti ja kiinnityskin onnistui kätevästi proppujen ja ruuvien avulla lattiaan.

    Seuraavaksi paikalle kutsuttiin LVI-asentaja, asentamaan suihkuja ja muita laitteita. Nähdessään metallikehikot, asentaja kysyi ensimmäisenä Jukaltamme, että eikös lattian alle asennettukin lattialämmitys. Tietenkin oli, sehän on modernin talon perusmukavuus.

    Esitietojen perusteella ja ennen työn aloittamista LVI-asentaja päätti kuitenkin vielä suhauttaa paineilmaa lattialämmityksen putkien läpi.

    Kuinka ollankaan, propun rei’istä suhahti ilmoille kunnon pölypatsas, putket olivat menneet rikki. Jos LVI-asentaja olisi tehnyt oman työnsä laput silmillä ilman edellisen työn testaamista, olisi tuloksena ollut mittava vesivahinko. Koko kylppäri olisi pitänyt uusia muutaman kuukauden sisällä muuttamisesta. Nyt selvittiin putkien vaihdolla ja varsin kohtuullisilla kustannuksilla.

    Alkuharmitus takapakista vaihtui äkkiä helpotukseen. Iloinen rakentajamme ymmärsi, että pahempaakin olisi voinut sattua.

    Vahinkoja sattuu ja virheitä tulee. Siksi tärkeiden ominaisuuksien testaaminen säännöllisesti on tärkeää. Liiketoimintaa vaarantavat virheet kannattaa löytää silloin, kun niiden korjaaminen on kaikkein edullisinta.