Kun pitkään testaa, pääsee monenlaisiin projekteihin useilla sovellusalueilla. Joka projektilla on omat reunaehtonsa tai ”paikalliset itsestäänselvyytensä”, johtuen organisaation kulttuurista, bisnestilanteesta ja tuotteen historiasta – toisin sanoen kontekstista. Tietoisuus kontekstista on erityisen tärkeää projektin vaihtuessa ja konsultille aina.
Ennen testaajaksi ryhtymistä
Aloitin ”alan työt” 1982 tallennus- ja operointitöillä. Olin ohjelmoinut lukiossa ja halusin oppia lisää. 1985 alkaen ohjelmoin seksikkäällä pelialalla. Opetuspeleissä tarvittiin grafiikkaa. Pidin eniten grafiikkakirjastojen ja pelimoottorin rakentamisesta. Jätin asiakkaan ymmärtämisen ja bisnespuolen muille, keskityin teknologiaan. Vaikka tämä järjestely oli motivoivaa, se ei ollut pidemmän päälle fiksua.
Kun tekee lennokasta ohjelmointia ja opettelee olio-ohjelmoinnin kirjoista, sitä kuvittelee olevansa päteväkin tekijä. Aika näyttää mitkä taidot kantavat tulevaisuudessa.
Keskeinen havainto kehittäjäajoistani on, että kaikki firman kehittäjät saivat aikaan hyvää laatua, kun ymmärtävät mitä on tekemässä ja tekee muutokset tiukoin syklein, kokeillen heti. Peleissä ratkaisevaa on käyttäjän kokemus, joten pieniäkin muutoksia piti kokeilla aidossa tilanteessa. Kaikki tämä ilman kirjattuja testejä.
Testaajaksi päätyminen
Pääsin kuuden ohjelmointivuoden jälkeen isoon firmaan kehittäjäksi ja osana parinkymmenen hengen tiimiä tekemään pilottiversiota teknisesti vaativasta tuotteesta. Sovellusala ei ollut tuttu, mutta C-kielen ja C++:n kanssa homma sujui, pidinpä C++-kurssinkin kollegoille.
Julkaisun alla tuli puhe, että kuka tämän testaisi ja kollegan kanssa saimme testaushatun ”pariksi viikoksi”, tästä on nyt 30 vuotta… Testit olivat avoimia, kuten ”kokeile tuo toiminnallisuus tältä kantilta”. Kun vikoja löytyi, korjasin osan saman tien ja laitoin kehittäjälle korjauksen hyväksyttäväksi. Huonon pelisilmäni takia hämmästyin, kun tämä auttavaisuus ei saanut odottamaani arvostusta! 😉
Ensimmäisen julkaisun rauhallinen kehitystahti mahdollisti hyvän luotettavuuden tuotteelle, jolloin epämääräinen testaus ei sotkenut asioita. Seuraavassa projektissa oli jo erillinen testaustiimi, mutta silloin olin siirtynyt eteenpäin.
Isompi ohjelmistotuote – Monta hattua
Aiempaa suuremmassa organisaatiossa oli hyvin toimiva testauskoneisto. Sain vedettäväkseni parin vuoden mittaisen EU-tutkimusprojektin testiautomaation soveltamisesta, ja tilaisuuden oppia lisää testauksesta. Lisäksi sain verkostoitua alan toimijoiden kanssa ja mahdollisuuden puhua konferensseissa.
Olennainen havainto projektissa oli, että testejä voi automatisoida isolla panoksella ilman kummempaa kytköstä muuhun testaukseen, tuottamatta hyötyä laadussa. Jos testauksen kokonaisuutta ei kontrolloida, tehdään kallista turhaa työtä.
Erityisen hedelmällinen oli mahdollisuus osallistua kehittäjien testauksen parantamiseen. Oma kehitystausta, testauskokemus ja oppi oliomenetelmistä auttoi kehittäjiä nostamaan testiensä tasoa. Testaajat löysivät oliomalleista heikkoja paikkoja arkkitehtuurianalyysin kautta tai vaan kysymällä tyhmiä: ”mitä tapahtuu, jos näiden kahden laatikon välinen yhteys katkeaa?”
Välillä hallinnollisempia rooleja
Intensiivisen tutkimusprojektin jälkeen oli mukava päästä linjarooliin junailemaan projektien testaustukea ja oppimaan esimiestaitoja. Tiimini neuvoi, tuunasi välineitä ja ympäristöjä. Testausvälineistä hyödyllisimmät olivat Perl-kieli ja itse kehitetty testauksen hallintaväline.
Sain olla 1994 alkaen mukana Intranet-kehityksessä ja kohta päädyin myös webmasteriksi. Siinä pysyi sopivasti kiinni nörttimaailmassa sekä oppi viestinnästä ja informaatioarkkitehtuurista.
Testaustuen järjestämisessä opin, että tarpeiden ennakointi, priorisointi ja budjetointi on jonkun tehtävä. On parempi, että mukana on testausta ymmärtäviä ihmisiä. Sain balansoida nörttiminää ja manageriminää ja vaikuttaa testauksen sujuvuuteen. Havaitsi, että iso osa johtamista ovat hyvät arvaukset.
Testauskonsultointia
Päädyin sisäiseksi testauskonsultiksi pitkän tuotekehityskauden jälkeen ja sain loistavan näkyvyyden suureen organisaatioon. Käytin kaikkea kokemustani ja uskallustani testaajana, testauspäällikkönä, ongelmanratkaisijana, valmentajana ja kouluttajana. Erillisten toiminnankehitysprojektien rinnalla järjestin kursseja ja tietoiskuja. Aiemmin saatu verkosto oli kullan arvoinen, kun toin erilaisten erikoistumisten asiantuntijoita maahan. Luin tässä jaksossa kymmeniä testauskirjoja, osan jopa työaikana.
Konsulttiroolin lisäksi sain pienen tiimin lahjakkaita testaajia, joista kasvattaa sisäisiä konsultteja. Konsultin perustaidot fasilitointi, ongelmanratkaisu, viestintä, tiedon keruu ja jäsentäminen ovat yhtä tärkeitä testaajallekin.
Sain tässä vaiheessa panostaa myös testaajien verkostoitumiseen ja perustin ulkoisen testaajien yhteisön, Sytykkeen TestausOSY:n. Parhaimpana vuonna järjestimme 6 ilmaista seminaaria.
Viimeisenä roolinani tässä firmassa järjestin testauksen välineitä ja ulkopuolista tukea tuotekehitysorganisaatioille, jääden itse aina ulkopuoliseksi (kaksi vuotta riitti!) Parhaana tappelukaverina olivat oman kustannuspaikan budjettivälineet ja Excel. Vaikkei tämä ollut testausta, opin miten päätöksiä isossa firmassa tehdään sekä miten yleisimmät testaushaasteet toistuivat eri liiketoiminta-alueilla.
Uudet kontekstit – Silmien avautuminen
Sisäisen konsulttitaustan jäljiltä oli luonteva luiskahtaa konsulttifirmaan. Sain jatkaa monien asioiden tekemistä rinnakkain. Olennainen oppi konsulttivuosista oli, että joka projektissa oli uusia lainalaisuuksia, tuoteteknologioita, ihmisiä ja välineitä. Tähän uuden tilanteen hahmottamiseen löytyy yksinkertaisia konsteja, lähinnä tarvitaan viitseliäisyyttä. Hyväkään testausammattilainen ei voi edes hyvällä analyysillä tuottaa järkevää testausta yksin, vaan onnistumisten takana on aina monien ihmisten osaamisen ja panoksen ohjaaminen yhteisen tavoitteen taakse.
Opin verkkopankkiprojekteissa pankkipalveluista, moderneista hajautustekniikoista ja REST-rajapinnoista. SoapUI ja myöhemmin Postman ovat olleet hyödyksi monesti. Hajautustekniikoista on apua testaajalle, joka muuten jäisi ”mustan laatikon” ulkopuolelle.
Ohjasin etätiimiä ja havaitsin, miten ohutta kaistaa tieto rajojen yli kulkee ja miten tärkeää on tutustua ihmisiin. Testaus jää ”ohueksi hymistelyksi”, elleivät testaus ja kehitys koe olevansa samaa porukkaa.
Logistiikkaprojektissa tulivat tutuiksi uudet hajautustekniikat, XML:n puukottaminen, myyntitapahtumien hallinta ja ”kellon siirto”, hinnoittelun koukut ja varastot. Oma roolini sisälsi järjestelmäintegraatiota ja asiakastestauksen järjestelyt. Mukana oli monta peluria ja ihmisiä monesta maasta. Yhteinen ateria auttaa ihmisiä tutustumaan ja yllättävää joustavuutta muutostilanteissa löytyykin tuttujen kesken. Elegantit laiteintegraatiot olivat tämän keikan suola.
Tietoliikennettä eri näkökulmista
Aiemmin olin lähinnä nähnyt tietoliikennettä tuotekehityksen kannalta suurissa hankkeissa. Nyt sain tutustua alan liiketoimintaan. Oli kiehtovaa nähdä miten dynaamista liiketoiminta voikaan olla. Se saattoi tarkoittaa, että liikkeelle laitettu kehityshanke kohdistetaan uudelleen kuukauden päästä. Kiehtovaa oli nähdä, miten käyttöön otettu uusi teknologia ja käytännöt maksoivat välillä paljon, mutta saattoivat tuottaa suuren hyödyn.
Konttiteknologia kolahti: saimme asiakkaan laajan ja monilla tekniikoilla rakennetun tuotannon lukuisat osajärjestelmät kontteihin – ensin pilveen ja sitten pyörimään läppärillä sopivasti testiautomaation kehittämistä varten. Lisäksi DevOps muuttui ”kohinasanasta” todeksi, kun aamuinen ongelma korjattiin tuotantoon jo ennen lounasta riittävän hyvin testattuna. Sykähdyttävin hetki oli, kun Robot Framework-testijoukko raportoi pilvestä itse tilansa suoraan Jiraan.
Lääketieteellinen sovellusala – Hötkyily on pahasta
Kun jäi aikaa pohtimiselle, huomasin kaipaavani takaisin tuotekehitykseen. Sain vinkin avoimesta paikasta ja hain nykyiseen firmaani. Ensimmäinen tittelini oli ”System Integration Manager”. Toimeksiantoni oli tukea integrointia pienellä spesialistitiimillä ja myöhemmin johtaa testausta tuotekehitysprojekteissa.
Lääketieteellinen sovellusala on vahvasti reguloitua, eli kansalliset ja kansainväliset standardit sanelevat tarkat reunaehdot tuotekehitykselle. Koska kyse on potilaan turvallisuudesta, tämä on alalla hyvin ymmärretty. Projektikäytännöt ovat vahvasti orientoituneet siihen, että tehdään oikein alusta asti ja vältetään hötkyilyä. Tämä kasvattaa vastuuta ja lisää valtaa testaustoimelle.
Sain olla mukana uuden tuoteperheen rakentamisessa. Oli ilo olla mukana löytämässä ketteriä tapoja tehdä laadukkaita tuotteita toimialallamme. Testaus on pääosin jokaisen kehitystiimin omassa kädessä ja testimanagerin (”Verification Test Lead”) vastuulle jäi lähinnä huolehtia viestinnästä, yhteisten testauskohteiden kattamisesta ja tiimien tarpeista. Mikromanagoinnin vähyys on ollut virkistävää, vaikka näinkin on tekemistä riittänyt. Päivän huono vitsi: ”Laitoin tiketin tietohallintoon saadakseni toisen kalenterin, kun mun Outlook-kalenteri on jo täysi”.
Kuuden vuoden ja kahden tiimin jälkeen päädyin äskettäin taas testausasiantuntijaksi. Tässä palasin tavallaan alkuun; valmennus ja ihmisten kehittäminen on koko matkan ollut osa tekemistäni, mutta ei aikoihin näin yksiselitteisesti. Tulevaisuudessa tulee käyttöä jokaiselle kikalle, jonka olen oppinut.
Mitä kaikesta tästä opin?
En riittävästi. Joitain virheitä olen toistanut ja joitain maailmankaikkeuden eteeni heittämiä vihjeitä en ole vieläkään tajunnut. Joka kontekstissa on ollut omat haasteensa ja niiden ratkomisessa on tarttunut jotain henkiseen työkalupakkiini.
Alla pari havaintoa:
- Ihmiset luovat ongelmia ja myös ratkovat niitä – muttet sinä yksin!
- Verkostoituminen firman ulkopuolella auttaa oppimisessa ja uuden uran löytymisessä.
- Teknisistä taidoista ei ole ollut haittaa, paitsi kun kuvittelin näiden perusteella itsestäni liikoja.
- Testaus on leveää ja syvää, aina löytyy lisää testattavaa – kikka on löytää eri testaustilanteisiin sopiva taso. Ensimmäisenä keksitty testi ei ole sitä mitä tarvitaan.
- Professori Jukka Paakin sanoin: ”Turha testaus on turhaa”. Monesti olen tehnyt turhaa työtä, aloittaessaan ei aina tiedä, mikä on lopulta turhaa.
- Mitä pikemmin jätät illuusion yksin pärjäämisestä, sitä parempi – testaus on joukkueurheilua, vaikka olisit firman ainut testaaja (muut osallistuvat testaukseen nimikkeistä riippumatta).
Erkki Pöyhönen on pitkän linjan nörtti – kehittäjä ja testaaja, jolle on eri kautta siunaantunut erilaisia vastuita ja saanut olla monessa mukana. Vuonna 2001 Erkki perusti Sytykkeen testauskerhon, joka myöhemmin sai nimen “Testauksen Osaamisyhteisö – Finnish Association for Software Testing”, toimi pari kautta Tietotekniikan Liiton hallituksessa, oli perustamassa ISTQB-järjestöä ja oli sen ensimmäinen varapuheenjohtaja. Vuonna 2008 Erkistä tuli “Vuoden Testaaja”, on mukava todeta, ettei yksi vuosi riitä vaan on saanut jo 30 vuotta testausta tähän mennessä. Nykyisin Erkki toimii Varian Medical Systems Finland:ssa nimikkeellä “Senior Test Strategist and Coach”.