Arkisto: huhtikuu 2011



Testaaja on asiantuntija. Ketä kiinnostaa?

27. huhtikuuta, 2011 | Kirjoittaja: Antti Niittyviita
Kommentit: 2

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.

Omaan ketteryyteen on helppo kompastua

19. huhtikuuta, 2011 | Kirjoittaja: Jussi Niittyviita
Kommentit: 3

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:

  1. Toimita säännöllisesti jotain
  2. Varmista, että toimitat korkeimman prioriteetin asiat
  3. 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ä.

Testaus 2011 seminaari ja vuoden testaajan valinta

11. huhtikuuta, 2011 | Kirjoittaja: Antti Niittyviita
Kommentit: 5

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 parantaa prosessia

5. huhtikuuta, 2011 | Kirjoittaja: Antti Niittyviita
Kommentit: 1

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.