Tag: Suomi

Mitä aikaisemmin virheet löydetään, sitä edullisemmaksi niiden korjaaminen tulee. Jotta virheet löydetään ajoissa, pitää testaukseen panostaa mieluummin kehityskaaren alkuvaiheessa.

Tietenkin testauksen laatu ja tarkoitus täytyy aina suhteuttaa tuotekehityksen vaiheeseen. Arkkitehtuurin suunnitteluvaiheessa ei voida todentaa napin paikkaa ja väriä. Mutta ilman muuta voidaan varmistaa, että arkkitehtuuri mahdollistaa myöhemmin nappuloiden sijoittelun halutulla tavalla!

Projekteissa on jatkuva kiire ja rahakin on tiukalla. Siitä huolimatta varmista, että suunta on oikea.

Teuvo Testaajan vastuulla on loppukäyttäjätuotteen viikkoreleasejen regressiotestaus. Pirun tylsää hommaa ja vie yllättävän paljon aikaakin. Testit Teuvo ajaa Excelissä olevan testispeksin perusteella ja tulokset hän raportoi listalle tyyliin pass tai fail. Löydetyistä vioista Teuvo toki heittä failin perään vielä kommentit. Lisäksi löydetyistä virheistä pitää kirjoittaa bugirapsa tuotekehityksen virheidenhallintajärjestelmään. Virheraportin tunniste kopioidaan sitten exceliin failin perään ja ollaan tyytyväisiä työn tuloksiin.

Viimeviikon Kauppalehdessä pisti silmään otsikko “10 vinkkiä liiketoiminnan tehostamiseen”. Visman ilmoituksessa olleet 10 vinkkiä pääset lukemaan tästä. Juttu oli minusta erinomainen yhteenveto asioiden järkeistämisestä. Mielestäni listan tärkein kohta oli ensimmäinen. Opetus on kaikille järkeä käyttäville ihan itsestään selvä: “Tee työt vain kerran”. Mutta mitä se tarkoittaa Teuvon kannalta katsottuna?

Tyypillisen failin kohdalla Teuvo käyttää

• 5 minuuttia työtä virheen toteamiseen,
• 10 minuuttia menee toistamistapojen tutkimiseen ja impaktiarvioon,
• 5 minuuttia kuluu kun ongelman kirjoittaa testituloksiin ja kuvaa sen vaikutukset,
• 5 minuuttia vierähtää helposti virhetietokannan käytössä, kun vian kirjaa sinne ja
• 30 sekuntia kuluu kätevästi kun vielä kopioi käsin tietokantatunnisteen tuloksiin.

Yhteensä Teuvolla meni hommaan aikaa 25 minuuttia ja 30 sekuntia. Tästä ajasta menee 5 minuuttia ja 30 sekuntia aikaa työn tekemiseen kahdesti. Yhteensä se tarkoittaa noin 22% Teuvon työajasta.

Sitten täysin oma lukunsa on virheen korjaaminen. Kun virhe on tietokannassa eikä kukaan ole vaivannut päätään sillä viikkoon, niin kuinka käy Teuvon seuraavalla testikierroksella?

Teuvo toki ajelee testit kuten ennenkin. Sama virhe tulee jälleen kummittelemaan testikierrokselle, koska tieto ei kulje virhetietokannasta Teuvolle. 5 minuuttia menee saman testitapauksen uudelleen ajamiseen ja virheen uudelleen toteamiseen. 3 minuuttia vierähtää kun virhetietokantaan käy päivittämässä että virhe on uudessakin releasessa ja vaikutus on sama. Äkkiä samasta virheestä aiheutuva ylimääräinen työmäärä onkin kasvanut 40%:een. 150 tunnista näin käytettyä työaikaa menee siis 60 tuntia samojen töiden uudelleentekemiseen. Minusta aika hurjat lukemat sekä ajassa että rahassa.

Kotitehvät sinulle hyvä lukija: Koita keksiä vastaavanlainen skenaario omassa projektissasi.

Epäkohtia on mukava esitellä ja nostaa pöydälle. Mutta mintenkäs sitten niiden ratkaisuiden laita? Miten esimerkiksi tässä Teuvon tapauksessa olisi voinut säästää työaikaa ja kohdentaa sen järkevämmin?

Meillä homma on hoidettu kahdella muistisäännöllä:

1. Huolehdi että järjestelmät keskustelevat keskenään. Kun Teuvo kirjoittaa virheen kerran ylös, sen kopiointi muihin järjestelmiin tapahtuu automaattisesti.
2. Huolehdi että informaatiolle on takaisinkytkentä. Kun virheelle ei ole tehty mitään viikkoon se näkyy myös Teuvon testauksenhallinnassa.

Jos siis haluat saada samalla rahalla enemmän aikaan: Tee työt vain kerran!

Tällä hetkellä pelataan lätkän maailmanmestaruudesta. TV:n äärellä on miljoonia ihmisiä, jotka kannattavat omia joukkueitaan tai ovat muuten vain kiinnostuneita lajista.

Lätkäjoukkueen työnjakohan on kutakuinkin seuraava: Valmentaja päättää kuka pelaa ja milläkin paikalla. Hyökkääjien tehtävä on tehdä maaleja. Puolustus ja maalivahti yrittävät pitää oman pään puhtaana. Joukkue pelaa faneille, jotka myötäelävät joukkueen mukana. Fanien painostuksesta on jopa saatettu antaa valmentajille kenkää.

Maalinteko vastustajan verkkoon useimmiten onnistuu ainostaan, mikäli varsinaisten hyökkääjien lisäksi myös puolustajat osallistuvat järkevällä tavalla hyökkäyksen tukemiseen. Hyvä yhteispeli hyökkääjien ja puolustajien välillä mahdollistaa suuremman määrän erilaisia hyökkäysvariaatioita, jolloin maalinteon onnistumisen todennäköisyys kasvaa. Kun joukkue tekee maalin, koko kentällinen juhlii varsinaisen maalintekijän kanssa.

Vastaavasti puolustajien työ pitää kiekko pois omasta maalista on käytännössä mahdotonta, mikäli hyökkääjiä ei kiinnosta oman pään pelaaminen pätkän vertaa. Tyypillisesti omaan päähän tullut maali aiheutuu hyökkäyspäässä otetusta riskistä, jolloin puolustus on väistämättä myöhässä tilanteesta. Puolustaja on sankari tai konna, riippuen viimeisimmän pelitilanteen onnistumisesta. Tilanteen, joka olisi voitu välttää hyvällä viisikkopuolustuksella.

Pärjätäkseen joukkueen tulee olla hyvin johdettu ja puolustuksen ja hyökkäyksen tulee toimia saumattomasti joukkueen voiton eteen. Onnistuneesta suorituksesta fanit palkitsevat.

Sama pätee myös softakehitykseen. Devaajan tehtävä on pelata peliä kohti tavoitetta, testaajan tehtävä on pitää oma pää puhtaana. Kumpikaan ei kuitenkaan voi menestyä ilman toista. Kun homma toimii, niin myös loppukäyttäjä kiittää.

Yksikään tiimi ei voi ulkoistaa onnistumista yhdelle osaajaryhmälle: Pelkästään hyökkäykseen panostava joukkue häviää varmasti.

Asiakaslähtöisyys ja joustavuus. Siinä arvot, joita lähes jokainen suomalaisen yritys mainostaa. Asiakashan on aina oikeassa. Eikö totta?

Näin meitä toki on opetettu, mutta ajatellaampa asiaa tarkemmin.

Mannertenvälisellä lennolla viihtyminen on tärkeää. Se on jopa niin tärkeää, että matkustamossa on henkilökuntaa pitämässä siitä huolen. Matkustajalle kannetaan huopaa, tohvelia, leffaviihdettä sekä juotavaa nokan eteen. Sekoitetaan juuri niin mielikuvituksellinen drinksu kuin vain keksiä saattaa. Tarjoillaan ruokaakin oli matkustaja sitten vegaani tai barbaari. Asiakaslähtöistä sanon minä.

Entäpä sitten jos asiakas tulee matkalla siihen tulokseen että hän tietää parhaiten miten päästään Sydenystä Los Angelesiin ja vaatii lentäjää vaihtamaan lentokorkeutta? Entäpä jos suunta pitäisikin ottaa asiakkaan toivomuksesta New Yorkin kautta?

Koneen pilotti ei tietenkään edes harkitse ideoiden toteuttamista. Pilotti noudattaa laatimaansa lentosuunnitelmaa, koska se on toimivin juuri tällä konetyypillä ja näissä olosuhteissa. Sitäpaitsi sääpalvelu on ilmoittanut tuhkapilvestä taivaalla. Pilotti on tämän tarinan asiantuntija, guru joka tietää mikä tässä tilanteessa on järkevin etenemistapa.

Äkkiä joustavuutta ja asiakaslähtöisyyttä ei enää tarvitakaan. Kunhan matkustajat pääsevät turvallisesti ja ajallaan perille. Se jos mikä on asiantuntijan rooli.

Juttelin erään testauspäällikön kanssa taannoin testauksesta ja työajankäytöstä. Erityisesti keskustelu raportoinnista herätti ajatuksemme vallitsevaan ajatusmalliin. Käsittämätöntä mutta totta: Usein ajatusmalli on että työkalut maksavat, mutta työaika ei.

Testauspäällikön kanssa keskustellessa kävi ilmi, että hän käyttää testauksen raportointiin työaikaa noin 3-4 tuntia viikossa. Kerää testauksen tulosdatan yhteen exceliin käsin ja lähettelee raportit sidosryhmille. 3-4 tuntia oli mielestämme vähän työaikaa testauspäällikön tehtäviä ajatellen.

3-4 tuntia viikossa tarkoittaa kuitenkin hyvin suoraviivaisesti 141-188 tuntia vuodesta. Siis henkilötyökuukauden verran! Pelkkään manuaaliseen excelien pyörittelyyn. Eihän se tietenkään tunnu pienissä erissä pahalta, mutta aika hurjat lukemat siihen nähden kuinka arvokasta testauspäällikön työaika yleensä on. Siinähän kuluu helposti 6000 euroa vuodessa pelkästään exceleiden kirjoitteluun.

Muista tämä: 3 haaskattua tuntia viikossa tarkoittaa 141 haaskattua työtuntia vuodessa

Testaajat tekevät hirvittävän usein töitä juuri niillä toiseksi parhailla työvälineillä eli toimistosovelluksilla. Se on puhdasta käsityötä alusta loppuun ja käy aika kalliiksi meillä päin.

Rakennustyömailla tämä homma on jo huomattu. Siellä ostetaan mieluummin kunnon sirkkeli työntekijöille kuin laitetaan kaverit tekemään samat työt pokasahalla.

Asiaa palautteen antamisesta ja sen kommentit kertovat ohjelmistokehityksen kommunikoinnin haastavuudesta. Kehittäjiä tympii, kun testaajilta tulee negatiivista palautetta virheraporttien muodossa. Testaajat joutuvat olemaan kieli keskellä suuta miettiessään kuinka asian voisi ilmoittaa siten, että devaajat eivät vedä hernettä nenään.

Ongelma ei ole niinkään koodareitten ja testaajien välisessä kommunikaatiossa ja sen tavassa, vaan projektijohdon asettaman roolituksen toteuttamisessa.

Kokonaisuuden kannalta on tehokkainta, että devaajat kirjoittavat koodia vaatimusten mukaan riittävällä tarkkuudella. Testaajat puolestaan pyrkii löytämään koodista oleelliset puutteet. Molemmat ovat ammattilaisia omassa tehtävässään. Eikö olekin kokonaisuuden kannalta järkevintä, että projektissa asioita tekevät ne, jotka asiat parhaiten osaavat?

Mikäli vastuunjako ja henkilövälit eivät ole täysin kunnossa, kehittäjät voivat pelätä virheitä ja niistä johtuvaa negatiivista palautetta.

Tällaisissa tilanteissa projektijohdon tulisi olla hereillä. Projektijohdon pitää viestittää aktiivisesti kehittäjille, että heiltä ei odoteta virheetöntä koodia, koska testaajat löytävät puutteet ja ongelmat kehittäjiä nopeammin. Tuote valmistuu nopeammin, koodi uskalletaan jättää testattavaksi ilman päivien tai viikkojen hierontaa.

Virheraportit eivät ole enää negatiivista palautetta vaan normaalia kommunikointia hyvän lopputuloksen saavuttamiseksi. Hyvästä työstä on syytä kehua, sekä koodaajia että testaajia.

Oleellista ei ole se, kuka virheen löytää. Oleellista on se, kuinka nopeasti virhe löydetään ja korjataan.Molemmat ovat ammattilaisten töitä.

Kyllä suomalainen osaa antaa palautetta!

Työskentelin opiskeluaikojen alkupäässä Soneran puhelin- ja liittymämyynnissä Teleringillä. Tyypilliseen työpäivään kuului joukko uusia liittymiä ja myytyjä puhelimia. Asiakkaiden kanssa saatettiin myös ratkoa heille tärkeitä ongelmia puhelinten asetusten säätämisessä, eli toimittiin tukipalveluna.

Jokaiseen päivään kuului rutiinitoimintojen lisäksi asiakkaiden murheiden kuunteleminen. Asiakkaat tulivat myymälään avautumaan milloin mistäkin liittymän tai puhelimen ongelmasta. Asiakaspalvelijan rooli oli kuunnella, ymmärtää ja auttaa mikäli vain mahdollista. Yksi heinäkuinen lauantai kuitenkin jäi kaikkein elävimmin mieleeni. Se oli poikkeuksellinen päivä.

Myymälään tuli asiakas, jonka muistin käyneen meillä edellisellä viikolla ongelminensa. Synkkiä pilviä ehti kerääntymään pään yläpuolelle, kun ei taas jaksaisi kuunnella valitusta. Asiakas yllätti meidät kaikki lyömällä pöytään pussin pullaa ja kiittämällä saamastaan hyvästä palvelusta! Positiivinen palaute nosti hymyn huulille ja koko tiimin asiakaspalveluhenki oli loppupäivän huipussaan. Ja lisäksi pullakin oli hyvää. Sitä Dallaspullaa, jossa on vanilijakreemiä keskellä.

Tämän kokemuksen jälkeen jäin ajattelemaan palautteen antamisen voimaa. Miksi suomalainen antaa palautetta pääasiassa silloin kun joku on persiillään? Kun kaikki menee hyvin, suomalainen on hiljaa. Minä väitän että suomalaiset ovat todella huonoja palautteen antajia! Siinäpä meille opettelemista.

Miten tämä kaikki sitten liittyy testaamiseen?

Joel Spolsky kirjoitti blogissaan otsikolla Why testers? Teksti avasi uuden näkökulman testauksen tarpeellisuuteen. Koodaaja nimittäin kehittyy työssään nimenomaan palautteella. Mitä nopeampaa palaute on, sitä paremmin siitä voidaan ottaa opiksi. Tehdyt virheet ovat nimittäin vielä hyvin muistissa kun palaute tulee välittömästi. Kun softan kääntää ja sen itse toteaa toimivaksi, koodaaja saa ensimmäisen siivun palautteestaan. Toinen siivu onkin sitten testaajan vastuulla.

Huippuluokan testaaja on siis nopea palautteen antaja. Palautteen tulee olla suoraa ja täsmällistä, MUTTA:

Testaajan yksi arvokkaimista ominaisuuksista kehitystyössä on positiivisen palautteen antaminen. Luit oikein: positiivisen palautteen. Aivan kuten pienen koiranpennun koulutuksessakin, järkevämpää on kannustaa hyvää käytöstä kehuilla ja herkkupaloilla, kuin rangaista aina huonosta käytöksestä.

Koodaajan, kuten kenen tahansa ihmisen moraalin, motivaation ja onnellisuuden tason parantamisessa nimenomaan positiivinen palaute on kaikkein keskeisintä. Kyllä kaverille tulee hyvä mieli, kun välillä joku taputtaa olkapäälle ja sanoo:

“Sinä olet tehnyt perhanan hyvää työtä tänään! Sä oot hyvä tyyppi ja oot kyllä ansainnut pullakahvit.”

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?