Category: Ohjelmistotestaus

Sucker Punch oli hyvä leffa. Uskallan sen sanoa, vaikka eriäviä mielipiteitä sataa kaatamalla. Päällimmäisenä koko elämyksestä minulla jäi mieleen uskomattoman osuva lainaus:

You have all the weapons you need… now fight!

Tuo kohtaus pysäytti minut. Se pysäytti siksi, että sain itseni kiinni mitä typerimmästä ajatusmaailmasta. Olen kai aina ajatellut, että tuloksen aikaansaamiseksi tarvitaan työkaluja. Aseita, joilla homma hoituu aina tehokkaasti ja mutkattomasti.

Kun suomalaista miestä kohtaa ongelma, pihalamppu on palanut tai toimiston wc-istuin on rikki, mies lähtee rautakauppaan. Reissulta tarttuu mukaan uskomattoman tarpeellinen joukko uusia työkaluja, joita ilman ei takuuvarmasti olisi tullut toimeen. Joskus siinä hässäkässä saattaa unohtua jopa itse asia, eli se pihalamppu tai istuin.

Sama ongelma lyö päivittäin kapuloita rattaisiin lukuisissa softaprojekteissa ympäri maailman. Tuskallisen luovan työn ja hommiin ryhtymisen sijasta ihmiset etsivät mitä hienoimpia työvälineitä netistä, virittelevät niitä toimintaan ja saattavat jopa maksaa niistä mansikoita. Kuitenkin lähes poikkeuksetta nämä työvälinehankinnat ovat tuloksen aikaansaamisen pahin este.

Testauksenhallintajärjestelmä on yksi näistä vehkeistä. Useimmiten niitä otetaan isolla tohinalla käyttöön ja aletaan paiskimaan kunnolla töitä työkalun täyttämiseksi dokumentaatiolla. Suomeksi sanottuna siis testitapauksilla, vaatimuksilla ja testien toistokierroksilla. Oikeasti samat testaustyön tulokset olisi voinut saavuttaa hyödyntämällä järkevästi vain 10% järjestelmän ominaisuuksista. Tai kokonaan ilmankin!

Tieturin Testaus 2011 -seminaarista minulle jäi elävimmin mieleen Elisa Puoskarin puheenvuoro Sulakkeen toimintatavoista. Sulakkeella sprintit ovat päivän mittaisia. Sulakkeella on heitetty myös virhetietokantajärjestelmät mäkeen. Projektihuoneen seinällä komeilee taulu post-it lappuja, yksi erroria kohti. Sillä ei voi haaskata aikaa rautakaupassa norkoiluun, konffaukseen, servereihin, tietohallintoon eikä käyttäjäoikeuksiinkaan.

Työkaluihin keskittymisen sijaan Sulakkeella on ymmärretty se, mitä Sucker Punch yritti sanoa.

Lopeta joutava esteiden, ongelmien tai syyllisten etsintä ulkopuolelta ja pysähdy hetkeksi miettimään. Sinulla on jo kaikki työkalut, mitkä onnistumiseen tarvitset. Älä pelkää käyttää niitä!

Hyvin hankalaksi, on oikea vastaus. Sain asiakaspalvelukokemuksen siivittämänä ajatuksen kirjoittaa juuri sattuneesta tapahtumasta. Tapahtuman kulku on seuraavanlainen:

Kävin ostamassa Anttilasta uudenkarhean ja laadultaan peruskäyttöön välttävän Samsungin dvd-soittimen. Soittimessa ilmeni yllättäen selkeästi käyttäjästä riippumaton virhe: soitettaessa dvd-(tai cd-)levyn trackit saattavat välillä hypätä kokonaan seuraavalle kesken trackin toiston.

Tästä pienestä ja satunnaisesti toistuvasta viasta johtuen kiikutin soittimen takaisin Anttilaan vaatien takuukorjausta. Vähäpätöisesti asiakkaaseen suhtautuen tekniikan osaston myyjä yritti vääntää kättä viimeiseen asti, että kyseessä olisikin vain käyttäjän naarmuinen cd-levy. Yllättävän kovan kädenväännön jälkeen vedin viimeisen kortin hihasta ja kerroin myyjälle: “Olen tietotekniikan diplomi-insinööri ja ammatiltani ohjelmistotestaaja. Olen vakuuttunut, että vika on laitteessa.” Ääni muuttui nopeasti kellossa ja laite otettiin korjaukseen. Liekkö ensimmäinen kerta historiassa kun diplomi-insinöörin tutkinnosta on konkreettista hyötyä? 😉

Reilun kuukauden päästä olin jo lähes unohtanut omistavani dvd-soittimen, kun Anttilasta kilahti tekstiviesti Nokialaiseen. “Tuotteenne on saapunut korjauksesta ja valmis noudettavaksi.” Hain soittimen ja kotona avasin korjaussaatteen sisällön: Firmware päivitetty. Ajattelin OK, saattaahan moinen virhe korjaantuakkin firmwaren päivityksellä. Aloin heti koestamaan soitinta niin eiköhän se taas muutamien Pink floydin rallattelujen jälkeen pompannut seuraavalle trackille kesken hyvän fiilistelyn! Liekköhän Infocaren (Oulun Anttila ulkoistaa tuotekorjauksensa nähtävästi sinne) pojat eteläisessä Suomessa olivat edes testanneet virheen toistuvuutta. Eikun takaisin Anttilaan laite kainalossa. Tällä kertaa soitin otettiin mukisematta korjaukseen.

Parin viikon kuluttua Nokialaiseen kilahti tekstiviesti, jossa pyydettiin asiakasta lähettämään mallilevy Infocarelle, jotta virhe saataisiin toistettua. Viestissä ei ollut minkään valtakunnan tietoja postitusosoitteesta, sähköpostiosoitteesta tai asiaa käsittelevän henkilön nimestä. Viestin loppuun ladattiin vielä ultimaattum: mikäli asiakas ei lähetä mallilevyä 7 päivän kuluessa laite postitetaan takaisin siten, että asiakas maksaa kustannusarviomaksun ja lähetyskulut. Kovin asiakasläheistä toimintaa!

Tapahtuman kulku on tänään viestin saapumispäivänä edelleen auki.

Äkkiä aiheesta herää kysymyksiä. Kuinka perinpohjaisesti Infocaren pojat ovat eteläisessä Suomessa yrittäneet varmistaa virheen oikeellisuutta? Millä logiikalla on halvempaa lähettää laite korjaukseen Oulusta Helsinkiin kuukauden ajaksi, jotta siihen tehtäisiin ainoastaan 5 minuutin firmwaren päivitys? Onko todellakin valmistajan, myyjän tai korjausfirman etu, että asiakasta uhkaillaan postikuluilla, kun kaikki olisivat selvinneet helpommalla vain antamalla toinen laite tilalle?

Kun asiaa ajattelee tuotteen valmistajan Samsungin kannalta tuntuu pahalta. Virheen hinta pääsee moninkertaistumaan näin älyttömän ja tehottoman takuukorjausmenettelyn ansiosta. Kulujen karsimiseksi tulee mieleen kaksi vaihtoehtoa. Ottaa bugit kiinni jo tuotekehityksessä tai alkaa runnomaan korjausputkea paremmaksi.

Koko tarina kiteytyy vinkiksi valmistajalle:

Käyttäjä voi olla tuotteesi parissa 24/7. Et voi olettaa, että yksittäinen korjaaja pystyy havaitsemaan satunnaisesti tapahtuvan virheen parin minuutin (tai tunninkaan aikana). Virhettä ei kannata asettaa lyhyen tarkastelun jälkeen ignored-tilaan mikäli se toistuu vain satunnaisesti. Välinpitämättömyys kostautuu kalliisti.

Kun testaus puuttuu tai se ei toimi, ongelman myöntäminen on yhtä tuskaa. Yleensä se paljastuu vasta kun tavara on jo osunut tuulettimeen. Edelleenkin liian usein puhelin soi meidän toimistolla kun huonot on jo housussa.

Meiltä puuttuu toimiva testaus. Miten tässä nyt kannattaa toimia?

Koska epävarmuus niin usein kalvaa toimivan testauksen rakentajaa, ne ensiaskelet jäävät ottamatta. Vasta pakko pistää liikettä niveliin. Silloin asiakas hengittää jo niskaan ja softakehittäjän aika palaakin yllättäen virheiden korjailuun.

Me päätimme tarjota ilmaisen opetuksen siitä, miten toimiva testaus voidaan rakentaa sopivan pienistä rakennuspalikoista.

1. Kehitä: Rakenna softakehittäjien kanssa säännöllinen elämänrytmi. Jotain testattavaa on tultava tuutista ulos usein. Ilman tätä ei ole mitään järkeä investoida testaukseen.
2. Resurssoi: Palkkaa riittävän kokenut testausosaaja tai osta palvelu partnerilta. Pääasia on, että tyyppi on oikeasti testaaja, eikä vain huono devaaja!
3. Testaa: Polkaise hommat käyntiin tutkivan testauksen menetelmällä. Asiakkaasi elämään vaikuttavien vikojen löytyminen mahdollisimman aikaisin on oikeasti se, mihin kannattaa investoida heti!
4. Rakenna: Tuo mukaan uusia työkaluja. Paranna testauksen- ja virheidenhallintaa. Rakenna systemaattinen tapa toimia esimerkiksi tarkistuslistoilla. Voit pohtia myös automaatiota.
5. Tiivistä: Tiivistä kuilua kehityksen ja testauksen välillä. Tähtää testauksessa pitkistä vesiputouksista lyhyisiin tai Agileen.
6. Mittaa: Rakenna enintään kolme helppokäyttöistä mittaria softan laadun arviointiin. Meidän mittarimme perustuvat kaikki virhetietoihin.
7. Optimoi: Säädä testauksen määrää asteittain kunnes optimaalinen taso on löytynyt.

Hoitamalla yhden asian kerrallaan pääsee softakehityksessä jo pitkälle. Näiden askelmerkkien avulla on mahdollista rakentaa täysin uusi ja laadukas näkökulma ohjelmistojen rakentamiseen alle kuukaudessa.

Voit rakentaa toimivan testauksen pienistä osatavoitteista. Sinun on vain otettava härkää sarvista ja ryhdyttävä toimeen!

P.S. Jos alkuun pääseminen tuntuu vinkeistä huolimatta hankalalta, voit tilata meiltä Kick-offin. Me hoidamme kohdat 1.-4. pois kuleksimasta vain kahdessa viikossa! Sinun ei tarvitse osallistua kuin aloitustapaamiseen ja loppukatselmointiin.

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.