Arkisto: maaliskuu 2011



Ei mikään turha kuluerä

28. maaliskuuta, 2011 | Kirjoittaja: Antti Niittyviita
Kommentit: 2

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ä.

Paahtoleipä parantaa maailmaa

20. maaliskuuta, 2011 | Kirjoittaja: Antti Niittyviita

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!

Pakkopaita vai Havaijipaita?

10. maaliskuuta, 2011 | Kirjoittaja: Jussi Niittyviita

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.

Tarkistuslistapohjainen tutkiva testaus

2. maaliskuuta, 2011 | Kirjoittaja: Antti Niittyviita
Kommentit: 2

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.