Ohjelmistotiimeillä on enemmän vapautta kuin koskaan. Heillä on käytettävissään monenlaisia työkaluja, ja monet niistä ovat ilmaisia. Sovellusten luomiseen on saatavilla runsaasti avoimen lähdekoodin rakennuspalikoita. Kaikista parasta on, että monet työnantajat kannustavat tiimejä määrittämään itse omat kehitysjärjestelmänsä ja menetelmänsä sekä siihen, että tiimin jäsenet tuovat mukanaan omat työkalunsa.
Vapaus käyttää eniten pitämiäsi ja parhaiten tuntemiasi työkaluja, menetelmiä ja teknologioita auttaa todennäköisesti tiimisi tuottavuutta – siihen asti, kunnes tiimin itsenäisyys saavuttaa rajansa.
Vältä testauksen pullonkaulaa
Ystäväni Jan johti erittäin pätevää ohjelmistotiimiä räätälöityjen ohjelmistojen kehitykseen erikoistuneessa yrityksessä. He todella ymmärsivät, miten ketterästi toimitaan. Heillä oli kuitenkin laatuongelma. He nopeuttivat julkaisusykliään niin tehokkaasti, että testauksesta oli tullut pullonkaula.
He ratkaisivat pullonkaulan jättämällä testauksen väliin. Jan tietenkin ymmärsi, mitä piti tehdä. Hän latasi Robot Frameworkin, käytti sitä rakentaakseen tiimille räätälöidyn testiautomaatiojärjestelmän ja liitti sen jatkuvan integraation putkistoon. Vähitellen hän lisäsi yhä enemmän testejä ja laajensi järjestelmää suurella määrällä korkean tason avainsanoja, jotta testien kirjoittaminen olisi helppoa.
Samaan aikaan muut tiimit – ja niitä oli runsaasti – kohtasivat samankaltaisia haasteita ja ratkaisivat ne omilla tavoillaan käyttäen Seleniumia tai jotakin valitsemaansa työkalua.
Tiimit tarvitsevat kaikille yhteisen automaatiokehyksen
Pessimistit sanovat, että jokainen ratkaisu sisältää uuden ongelman siemenen. Jan huomasi pian ryhtyneensä kokopäiväiseksi testiautomaatioinsinööriksi. Hänen kirjastonsa olivat toki helppokäyttöisiä – hänelle – ja hänen testiarkkitehtuurinsa oli helppo ymmärtää – hänelle. Jokaisessa muussa tiimissä oli samassa tilanteessa oleva kollega. Yksi heistä vaihtoi työpaikkaa. Hänen tehtävänsä vastaanottanut kehittäjä päätti kirjoittaa kaiken uudelleen, koska ei pitänyt automaation toteutustavasta ja koki sen vaikeaksi ymmärtää. Kun yhä useammat tiimit alkoivat raportoida näistä haasteista esihenkilöilleen, esiin nousi ilmeinen kysymys: miksi tiimien välillä ei ole johdonmukaisuutta?
Jotakin oli tehtävä. Ratkaisu oli ilmeinen: perustetaan keskitetty testiautomaatiotiimi, joka palvelee kehitystiimejä tarjoamalla kaikille yhteisen automaatiokehyksen. Käytännössä tiimi koostui Janista ja toisesta kehittäjästä. Tässä vaiheessa kamppailu todella alkoi.
Jakakaa menetelmät, älkää vain työkaluja
Testit rikkoutuivat usein. Niin rikkoutui myös automaatiokehys. Kehitystiimien oli vaikea muuttaa käytäntöjään vastaamaan työkaluja, ja työkalutiimin oli vaikea vastata kaikkien erilaisten tarpeiden vaatimuksiin. Automaatiokehyksen monimutkaisuus kasvoi jatkuvasti. Testauksen pullonkaula oli muuttunut testiautomaatiotyökalujen pullonkaulaksi.
Jaetut sisäiset työkalut ovat hieno ajatus, mutta niiden saaminen toimimaan on vaikeaa. Onnistuakseen työkalua on hallittava kuin todellista tuotetta, ja se on testattava perusteellisesti. Paradoksaalisesti yrityksen sisäiset testiautomaatiokehykset ovat usein virheellisiä. Vielä suurempi haaste on kuitenkin olemassa. Jotta jaetuista työkaluista voisi hyötyä laajassa mittakaavassa, tarvitaan myös yhteinen menetelmä.
Janin tarina on tyypillinen – eikä se ole vielä ohi. He pohtivat nyt seuraavaa siirtoaan: palata itsenäisiin tiimeihin ja hyväksyä kustannukset, investoida enemmän jaettuihin työkaluihin ja luoda johdonmukainen menetelmä tai valita kaupallinen työkalu ja keskittyä vain menetelmään. Mikään näistä vaihtoehdoista ei ole väärä, mutta jokaisella niistä on erilaiset seuraukset.
