Testausguru parantaa prosessia
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.
Tämähän on vallan mainio esimerkki siitä mistä olen puhunut eli tuotekehityspari! Tuotekehityspari muodostuu koodaajasta ja testaajasta. Koodaaja siis tekee sitä missä on huippu eli koodaa. Ei ole mitään järkevää syytä sille miksi koodaajien pitäisi yhtäkkiä kesken työnsä vaihtaa ikään kuin viittaansa ja alkaa tekemään täysin eriä työtä eli testaamaan. Eihän siinä ole edes hituista järkeä. Testaamaan pakotettu koodaaja kyrsiintyy projektiin alle viikossa se on nähty jo riittävän monesti.
Tuotekehityspari-malli pitää huolen siitä, että koodaaja koodaa ja testaaja testaa sekä varmistaa koodin toimivuuden ja sen, että tuotosta voi ihminen käyttää ilman insinöörin koulutusta. Kun näin kehitetty koodinpätkä on sitten valmis, niin sen voi hyvillä mielillä pätkäistä versionhallintaan eikä tarvitse räjäyttää sitä nightly buildia sillä se ei ole hauskaa.
Silloin kun ammattilaiset tekevät töitä porukalla siten, että jokainen saa keskittyä siihen missä on ammattilainen eikä tarvitse alkaa leikkimaan asioiden kanssa mitkä ei aivan ole hallussa, niin se homma toimii. Se toimii itseasiassa niin hyvin, että sen näkee tiimiläisten naamalta kun se hymy viimein sinne kasvoille leviää. Se on mukava fiilis tehdä hommia toimivassa tiimissä 🙂