Testaajan muuttuva rooli ja Ohjelmistotestaus 2016

Tänä vuonna sain tilaisuuden puhua Ohjelmistotestaus 2016 tapahtumassa, ja hyödynsin samalla mahdollisuuden osallistua tapahtumaan kokonaisuudessaan. Päivistä jäi hyvä fiilis, oikeastaan kaikki esiintyjät onnistuivat tarjoamaan jotakin pohdittavaa, vaikka kaikkien aiheet eivät tietenkään omaan tilanteeseeni verraten olleet niin relevantteja. Koin tilaisuuden myös mukavan kokoiseksi: kun porukkaa ei ollut valtavaa määrää, juttuseuraa oli jotenkin luontevampaa etsiä, ja taukokeskustelut olivatkin antoisia. Ekstraohjelmana pääsin vielä kuuntelemaan Anssi Lehtelän harjoituspuhetta testattavuudesta Nordic Testing Daysin esitystä varten. Nyt pääni viliseekin uusia ajatuksia, jotka toivottavasti ehdin jalostaa itselleni läheisempään muotoon ennen kuin ne pääsevät liikaa haalistumaan.

Oma puheenvuoroni liittyi testaajan roolin muuttumiseen ja perustelemiseen tilanteessa jossa kenties perinteiset vesiputousmallilla toimivat testaustiimit maastamme vähenevät, rekrytointia tehdään kenties aikaisempaa enemmän yrityksiin joissa testausta ei niin hyvin ymmärretä, ja ketterät toimintatavat vaativat muutenkin vähän toisenlaisia taitoja. (Tauolla sain kuitenkin palautetta että puhumani asiat olivat ajankohtaisia myös ainakin yhdessä yrityksessä, jossa testauksella oli pitkät perinteet ja vakiintunut asema, koska testaajien on esimerkiksi ansaittava erikseen jokaisen uuden kehittäjän luottamus.) Samaa aihepiiriä eri näkökulmista käsitteli muutama muukin esiintyjä, ja sitä pohdittiin myös paneelikeskustelussa.

Yksi ajatus esityksessäni liittyi siihen, miten testaaminen ja testaajan rooli voidaan nähdä monella tavalla, erityisesti sellaisten silmin jotka eivät itse ole testaajia. Muiden esityksiä kuunnellessa vahvistui entisestään ajatus, miten erilaisia asioita testaus ja testaajan rooli voivat tarkoittaa myös meille testaajille. Tämä tekee haasteelliseksi puhua seminaareissa testauksesta tavalla, jossa konkretia yhdistyisi kaikkien kuulijoiden kannalta relevanttiin asiaan. Toisaalta moni nykypäivän IT-osaaja vaihtaa työpaikkaa suht tiuhaan, ja sitä kautta hyötyy myös tarinoista jotka eivät itselle ole juuri nyt ajankohtaisia. Jotenkin konkreettisten aiheiden löytäminen tuntuu kuitenkin esiintyjille vaikealta - tässä täytyy itsekin jatkoa ajatellen pohtia tapoja parantaa tilannetta. 

Tällä kertaa konkretian puolesta itselleni antoisin esitys oli Maaret Pyhäjärven esitys ryhmäohjelmoinnista (mob programming), josta sain vihjeitä joiden pohjalta kokeilla tekniikkaa myös omassa tiimissä (plus kirjavinkki jonka kautta hakea lisää ymmärrystä aiheesta). Hyvin konkretiaan menivät myös Katri Halla-Ahon esitys riskipohjaisesta testauksesta, jossa käytiin esimerkein läpi riskianalyysia ja miten sitä voidaan hyödyntää testauksen suunnittelussa ja seurannassa, sekä Karla Niemisen esitys testaajan keskustelutaidoista. Lisäksi testiautomaatioon liittyen käsiteltiin melko konkreettisiakin asioita sekä Jari Mäkeläisen että Disa Kakon esityksissä, joista ensimmäinen tarjosi sekä vinkkejä (kuten automaattitestien liittäminen samaan versiohallintaan missä varsinainen koodikin on) että sitä tuskaa mitä tiedon lisäämisestä tässä maailmassa yleensäkin seuraa (kuten automaatiotyökalujen valtava määrä ja monet tekijät jotka vaikuttavat työkalujen soveltuvuuteen eri käyttötarkoituksiin), jälkimmäinen enemmänkin näkymää niihin kipukohtiin, joita liittyy jokseenkin täydellisen erilaiseen toimintaympäristöön kuin missä itse työskentelen.

Osa esityksistä toi esiin hajautetun tuotannon haasteita. Kotimaisen monitoimittajaympäristön ongelmiin tarjottiin ratkaisuksi eri firmoista tulevien tekijöiden tuomista samaan tilaan tekemään yhteistyötä (joko muodostamaan yhteisen projektitiimin kokoaikaisesti, tai sitten erillisessä integraatiovaiheessa), mikä omien kokemusteni perusteella kuulosti mainiolta idealta. Kansainvälisessä toimintaympäristössä tämä ei ole niin helppoa, esimerkkinä kuitenkin kerrottiin myös tarina siitä, miten scrum on saatu toimimaan tilanteessa jossa tuoteomistaja, projektipäällikkö ja scrum masterit olivat Suomessa, kehittäjät ja testaajat taas Intiassa. Pidän itse melkoisena saavutuksena, että tällaisista lähtökohdista voidaan tulla kertomaan onnistumisista, kun ei se agileen siirtyminen aina ole ihan helppoa niissäkään organisaatioissa, joissa kaikki työskentelevät saman katon alla.

Testaukseen kohdistuvat vaatimukset riippuvat paljon myös toimialasta, esim. nettiviihdealalla AB-testaus ja virheiden päästäminen tietoisesti päiväksi tuotantoon (silloin kun lätkän MM-kisat eivät ole käynnissä) voi olla järkevä toimintatapa, toisena ääripäänä esimerkiksi potilasturvallisuus saattaa jättää niukemmin liikkumavaraa sen suhteen, miten lähellä täydellistä tuotantoon vietävän softan tulee olla. Mobiilitestauksen haasteet kasvavat hiljaksiin jokaisen uuden Android-laitteen myötä, ja esimerkiksi IoT nostaa esiin uudenlaisia kysymyksiä, joita myös testauksen kehittämisessä on tarpeen perusteellisesti pohtia. Maailma muuttuu vauhdilla, ja niin myös se, millaisia taitoja testaamiseen voi tarvita. Testauksen tulevaisuudennäkymistä tuntuikin olevan yhteisymmärrys siitä, että vaatimustaso testaajan osaamista kohtaan on kasvamaan päin.

Renessanssi-nerous alkaa siis olla mahdotonta ohjelmistotestauksen kentällä. Puhtaasti testaustekniikoiden näkökulmasta erilaisten mahdollisten taitojen kirjo on valtava, ja lisäksi monella toimialalla on tarpeen erikoistua juuri tuon alan haasteisiin pärjätäkseen itsenäisenä testaajana. Vaikka ei olisikaan innostunut tilannetekijäohjatusta testauksesta, testaus on väistämättä monella tavalla kontekstisidonnaista, ja vaihtoehtoisia konteksteja on valtava määrä.

Testauksen tulevaisuuden kannalta onkin tärkeää, miten me testaajat itse osaamme tehdä näkyväksi toimintakenttämme kompleksisuutta. Käytyjen keskustelujen perustella testiautomaation valtava tarve liittyy osin ohjelmistotuotannon valtavaan määrään, jossa vain pieneen osaan maailman projekteja riittää niitä teräsmies-kehittäjiä, joiden koodi on niin kaunista ja virheetöntä ettei sen jatkokehittäminen vaadi kummoistakaan regressiotestiarsenaalia. Keskinkertaisten, kelvollisten ja kehnompien kehittäjien jälkien paikkailu taas vaatii melkoisia batman-testaajia, mutta heitäkään ei joka firmaan riitä. 

Kysymys kuuluukin, onko automaation auvoisuutta rummuttavassa maailmassamme ymmärretty riittävän hyvin testaajan arvo, se kuinka paljon yksilön oppimiseen on oltava valmis sijoittamaan jotta hänestä voisi kehittyä batman-testaaja, ja ollaanko hänelle tuon tason saavutettuaan valmiita maksamaan vastaavia summia kuin teräsmies-kehittäjälle? Kuinka me testaajat voisimme paremmin näyttää tekemisemme arvon ja ne mahdollisuudet, joiden tavoittamiseen tarvitsemme lisää pelimerkkejä? Ja kuinka mahdollistamme jatkossakin keltanokka-testaajien pääsyn alalle, että heidän tuleva arvonsa nähtäisiin riittävän suureksi, jotta heidänkin työssäoppimiseensa ja kouluttamiseensa kannattaa panostaa?

Kieliversiot

Muutama vuosi sitten kokeilin lyhyen pätkän kotirouvan elämää Saksassa. Mieheni oli väliaikaisesti töissä Freiburgissa, ja me lasten kanssa vietimme kesän siellä hänen kanssaan. Oma saksankielentaitoni ei ole kovin kaksinen, mutta "lebensmitteldeutch" riitti suhteellisen hyvin arkiseen kaupassa ja torilla asioimiseen, ja kielitaidon loppuessa kesken asiat saatiin käytännössä aina hoidettua niin että minä puhuin englantia ja toinen osapuoli saksaa.

Suurimmat kielellisen turhautumisen hetkeni koinkin erilaisten nettipalveluiden käyttäjänä. Koska olimme Saksassa, jokainen kansainvälinen palvelu jonka sivustolle menin, tarjosi minulle oletuksena saksankielistä sivustoa. Ja koska Saksassa pärjää vain osaamalla saksaa, näistä palveluista ei koskaan löytynyt mahdollisuutta vaihtaa sivuston kieltä englanniksi. Siispä esimerkiksi asensin tietokoneeseeni Spotifyn ymmärtämättä sopimusehtoja. Kun tilasin lapsilleni crocseja, sain mm. selville että ko. merkin saksalaisen verkkokaupan valikoima poikkesi hieman suomalaisen verkkokaupan valikoimasta, mutta kenkien toimitusosoitetta ei ollut kuitenkaan rajoitettu maantieteellisesti.

Kun on itse ollut testaamassa verkkosivustoja, joissa on "tietenkin" vähintään kolme kieliversiota Suomessa asuvien ihmisten tarpeisiin, tuntuu hassulta, että yritykset, joilla täytyy olla olemassa jokaiselle myyntiartikkelilleen lukuisia kieliversioita, eivät tule ajatelleeksi että joku heidän sivustonsa käyttäjä saattaisi haluta asioida muulla kuin saksan kielellä ottaessaan palveluun yhteyttä Saksasta. (Toki tuntuu myös hassulta, että jos nettikaupat on rajattu kieliversioihin sillä ajatuksella, että asiakas saisi aina tuotteensa lähimmästä varastosta, tuo rajaus koskee nimenomaan asiointikieltä eikä toimitusosoitetta.) Toisaalta, kieliversioita testanneena ymmärrän myös, että niiden lisääminen on vähän sama asia kuin tuettujen selainten lisääminen - pienet muutokset lisäävät työmäärää yllättävän paljon.

Tässä listattuna muutamia asioita, joita kannattaa miettiä kieliversioita testattaessa:

• Löytääkö käyttäjä kielenvaihtotoiminnon?
• Mihin käyttäjä ohjautuu vaihtaessaan kieltä? Jos sivun pitäisi pysyä samana millä käyttäjä on kieltä vaihtaessaan (mikä on omasta mielestäni käyttäjäystävällisin vaihtoehto, sisäsivuille kuitenkin yleensä päädytään siksi että ollaan kiinnostuneita juuri sen sivun sisällöstä), mitä tapahtuu jos ko. sivulta puuttuu tuo toinen kieliversio?
• Jos saman sivun eri kieliversiot ovat julkaisujärjestelmän näkökulmasta sama sivu, vaikuttaako pääkieliversion puuttuminen siihen miten ko. sivun muut kieliversiot toimivat? 
• Onko yhteisiä elementtejä, jotka näkyvät samanlaisina kaikissa kieliversioissa? Jopa yhteiset kuvat voivat aiheuttaa ongelmia. Näkyykö käyttöliittymässä väärän kielisiä tekstejä?
• Tehdäänkö käyttäjästä kielen perusteella oletuksia (esim. osoitteen maa-tieto, kansalaisuus), ovatko ne ko. palvelun kannalta mielekkäitä oletuksia, ja ovatko ne käyttäjän vaihdettavissa jos oletukset ovat virheellisiä?
• Löytyykö palvelusta kokonaisuuksia, joihin mennessä kielivalinta nollautuu?
• Näkyvätkö kielikohtaiset erikoismerkit (å, á jne) oikein?
• Miten sanojen pituudet vaikuttavat käyttöliittymän elementteihin? Esim. mahtuvatko nappien tekstit nappeihin, tai hajoaako leiska kun joku elementti on isompi tai pienempi kuin mitä graafikko oli ajatellut? Onko muita ulkoasullisia eroja kieliversioiden välillä, esim. etusivun elementtien käytössä tai navigaatiolinkkien määrässä, ja miten hyvin ne toimivat?
• Yllättävätkin asiat voivat olla hajalla kieliversiokohtaisesti. Kieliversioihin päteekin pitkälti sama asia kuin selaimiin, testaajan ei kannata keskittyä ensisijaisesti samaan kuin mitä kehittäjä käyttää.

Tuleeko mieleen muuta olennaista?

Testattavuudesta ja omien rajojen tunnustamisesta

Testaajan rooli nähdään helposti puutteiden etsimisenä muiden tekemisistä. Kun koodi on kehittäjän mielestä riittävän hyvä ollakseen valmis, testaajan tehtävä on tavallaan löytää kaikki merkitykselliset kysymykset, joita ei ole vielä esitetty tai joihin ei ainakaan ole vielä löydetty vastauksia. Tyypillisesti ajatellaan kysymyksen olevan siitä, toimiiko ominaisuus ja vastaako se speksejä. Näkökulmia on kuitenkin monia muitakin. Löytääkö käyttäjä toiminnallisuuden? Ymmärtääkö hän, mitä se tekee? Eteneekö prosessi riittävän sujuvasti? Selviääkö järjestelmä riittävän hyvin raskaista operaatioista? Mitä muutokset tarkoittavat testattavuuden, ylläpidettävyyden tai tietoturvallisuuden näkökulmasta?

Yhden ihmisen voi olla vaikea löytää kaikkia kulmia, joista kysymyksiä voi esittää. Oma osaaminenkaan ei välttämättä riitä kaikkeen. Siksi on tärkeää tunnistaa omat rajansa ja puutteensa ja miettiä, miten niiden yli on mahdollista päästä. Joskus vastaus voi olla tiedon etsiminen, jotta oma näkemys ja osaaminen laajenisi. Joskus vastaus voi olla avun pyytäminen.

Minä kokeilin pari viikkoa sitten esittää tiimille testaukseen liittyvän ongelman, jota en itse pystynyt ratkaisemaan. Saimme aikaan mainion keskustelun testattavuudesta, sekä tavoista mahdollistaa nykyistä paremmin testiautomaation rakentaminen. Suunnittelupöydällä on nyt jo aikaisemminkin pohdittu mutta keskustelumme jälkeen prioriteetiltään noussut muutos, joka toivottavasti parantaisi yhden keskeisen toiminnon käytettävyyttä, sekä vähentäisi testausta vaativien prosessikulkujen määrää. Automaation rakentamiseen liittyviä ongelmia on ratkottu yhdessä, työ on vielä kesken, mutta se kaikkein perustavanlaatuisin este on jo saatu purettua.

On mahtavaa saada työskennellä ympäristössä, jossa ongelmista ollaan valmiita tekemään yhteisiä, ja jossa niihin myös halutaan löytää ratkaisut.

Minä näen testaajan työn keskeisenä tarkoituksena auttaa kehittäjiä työssään. Tärkeää on myös muistaa, miten monin tavoin kehittäjät voivat auttaa testaajaa tekemään työnsä paremmin.

Kun aika ei vain riitä - hajanaisia ajatuksia

Talvi on kulunut töissä vauhdikkaasti. Tuotteemme on ollut poikkeuksellisessa myllerryksessä, jonka myötä sen toimintalogiikka on jatkossa aikaisempaa helpommin yleistettävissä uusiin tarpeisiin. Käyttöliittymän kautta katsoen muutokset ovat suuria, mutta konepellin alla on tapahtunut paljon enemmän. Nyt muutos on vihdoin saatu kokonaisuudessaan tuotantoon, ja tuotekehityksessä voidaan taas palata normaalimmille urille. Kiire ei toki mihinkään ole häviämässä, uutta pitää tehdä koko ajan, ja rosoja viilailla siistimmiksi. Pitää ottaa askel taakse, katsoa kokonaisuutta kriittisesti ja löytää paikat joissa on kenties oiottu liikaa.

Arki vie helposti mennessään, tekeminen taantuu suorittamiseksi. Taustalla kulkee kuitenkin koko ajan ajatus siitä, miten asioita voisi tehdä paremmin, mitä uutta pitäisi oppia. Kiireessä ne ajatukset eivät vain aina pääse kiteytymään niin nopeasti kuin toivoisi. Eikä työ ole ainut, mikä vie. Lapset tarvitsevat aikaa, harrastukset ja vapaaehtoistyö vievät aikaa. Nukkuakin täytyy, nykyään aika paljonkin. Kaikkeen ei vain ehdi.

Omaa ammatillista kehittymistäkin voi miettiä monella tavalla. Mihin suuntiin haluan syventää, mihin laajentaa. Jälkimmäisessä mahdollisuudet tuntuvat nyt lähes rajattomilta, mutta kaikkiin tilaisuuksiin ei voi tarttua kerralla, tai muuten fokus hajoaa ja se perustyö jää retuperälle.

Myös jakamisen tavat mietityttävät. Pitäisikö kirjoittaa muutakin kuin blogia? Riittääkö aika osallistua johonkin, missä on ulkoa annetut aikataulut? Saisinko aikaan enemmän, jos minulla olisi dl? Mistä minulla on tarpeeksi sanottavaa, ja osaanko muotoilla sen kiinnostavasti?

Nämä pohdinnat saivat yllättävää vauhtia, kun minut kutsuttiin puhujaksi Ohjelmistotestaus 2016 -tapahtumaan. Tuntuu aika huikealta saada tällainen tilaisuus, kun listalta myös puuttuu joitakin nimiä joiden esityksiä mielelläni kuulisin. Odotan mielenkiinnolla, mitä tästä tulee.

Priorisointia, tavoitteita ja tehtävänhallintaa

Joulukuu kului joulukiireissä, joten jäi blogin kirjoittaminen taas vähemmälle. Testaukseen liittyviä ajatuksia loppuvuosi herätteli työn lisäksi parinkin testaukseen liittyvän tilaisuuden tiimoilta.

Toinen näistä oli testausyhdistyksen järjestämä teemailta, jonka aiheena oli ajanhallinta. Teemu Vesalan ansiokkaan alustuksen pohjalta keskusteltiin erilaisista haasteista, joita oman työn aikatauluttamiseen liittyy.

Aihetta käsiteltiin monesta kulmasta, erityisesti haasteena nostettiin esiin mahdollisuudet uppoutua keskeytyksettä työhön ja toisaalta myös irtautua siitä. Keskustelu oli kiinnostavaa ja tarjosi hyviä uusia ajatuksia, vaikka monet näkökulmat muistuttivatkin minua lähinnä siitä, miksi olen nauttinut niin paljon mahdollisuudesta siirtyä isosta firmasta pieneen.

Minun ajankäytölliset haasteeni eivät tällä hetkellä liity siihen, että kalenterini täyttyisi turhista palavereista, joihin on vaellettava valtavan rakennuksen toisesta päästä toteamaan, että tapaamisen avainhenkilöt eivät ole edes tulossa paikalle. Työsähköpostini ei täyty kummoistakaan vauhtia, eivätkä työtäni rajoita byrokraattiset käytännöt, joista ei itse työn kannalta ole mitään hyötyä. Organisaation sisäisten siilojen väliset haasteet ovat muisto vain.

Sen sijaan haasteita syntyy ajankäytön priorisoinnista, tekemisen fokuksoimisesta ja tehtävänhallinnasta.


Kun on kiire saada valmista, tekemistä täytyy priorisoida. Se tarkoittaa sitä, että oleellisimmat asiat tehdään mahdollisimman hyvin, ja vähemmän tärkeät unohdetaan väliaikaisesti.

Tällaista toimintatapaa voi perustella useammallakin tavalla.

Ensiksikin, joskus deadlinet ovat ihan aitoja deadlineja. Jos ominaisuus X ei ole vielä ollenkaan käytettävissä kun sitä pitäisi esitellä messuvieraille, tai asiakkaan aikataulukriittinen asia Y pitäisi saada vietyä sillä läpi, aikataulua venyttävä pilkunviilailu tulee kalliiksi.

Toisekseen, joskus asiakkaasta on mahdotonta saada irti riittäviä tietoja jonkin toiminnallisuuden valmiiksisaattamiseksi ennen kuin hänet päästetään koekäyttämään sitä. Silloin ei välttämättä ole tarkoituksenmukaista tehdä sitä kovin pikkutarkasti heti ensimmäisellä kierroksella.

Kolmanneksi, työtä voi sisäisessäkin kehityksessä tehdä ja jaksottaa eri tavoin. Yhden päivän aikana ei voi tehdä kaikkea, eikä testausta ole mielekästä lähestyä joka kerta täsmälleen samalla tavalla. Vain pieni osa tehtävistä on sellaisia, joissa pikaisesta vilkaisusta ennen seuraavaa kontekstin vaihtamista olisi minkäänlaista hyötyä, ja siksi työtä pitäisi saada tehdä riittävän pitkinä sessioina. Toisaalta usein tauon ottaminen on välttämätöntä uusien lähestymistapojen löytämiseksi, ja siksi myös mahdollisuus vaihdella tehtävien välillä on hyvä asia. 

Nämä kaikki asiat vaikuttavat siihen, että kaikkea ei tehdä kerralla täydellisesti, vaan tietyt polut ja tietyt piirteet jäävät perusarjessa vähäisemmälle huomiolle kuin toiset.

Priorisoinnissa on kuitenkin riskinsä.

Yksi riski on vääränlainen priorisointi, eli se että keskitytään kuitenkin vääriin asioihin, tai ainakin jotain tärkeää jää huomaamatta.

Toinen asia on jälkien siivoaminen deadlinen jälkeen. Jääkö tekemisen puutteista riittävät tiedot, että tekemätön työ on mahdollista muistaa dl:n jälkeen? Tuleeko se tehtyä? Onko olemassa jonkinlaista suunnitelmaa, miten epämääräiseksi jääneet asiat saadaan tarkentumaan? Onko analysoitu asiakkaan tarvetta käyttöönottoon liittyvään lähitukeen? Ymmärtävätkö kaikki, että vielä ei ole valmista, vaikka lyhyen tähtäimen tavoite saavutettiin?

Ajanhallinnan kannalta haasteellista on löytää tapa huolehtia aikataulukriittisten asioiden riittävän nopeasta etenemisestä pitäen samalla vähemmän kiireiset asiat aidosti työlistalla, niin että nekin tulevat hoidetuksi. Jatkuvalla kiireellä on tapana pitkällä aikavälillä kostautua. Teknisen velan lisäksi ongelmaksi saattaa muodostua se, että tuotteen kasvaessa pienen prioriteetin asioiden imagovaikutus voi käyttäjän silmissä kasvaa yllättävän merkitykselliseksi.

Samalla omaa tekemistä pitää osata arvioida kriittisesti. Tuliko työ tehtyä riittävän hyvin? Tuliko mieleen asioita, jotka olisi syytä lisätä backlogiin? Oliko tekeminen hyödyllistä? Mikä on oleellista siinä mitä teen, ja miten pian tätä on tarpeen arvioida uudelleen? Mikä minua juuri nyt häiritsee käsillä olevien tehtävien asettamien tavoitteiden ulkopuolella? Mitä minun juuri nyt olisi hyödyllistä opetella? Onko jotain mihin liittyen pitäisi pyytää apua?

Rutiinien keskellä on löydettävä tavat katsoa tilannetta konkreettisten tehtävien ulkopuolelta ja saada palautetta tekemästään työstä. Asettaa pidemmän tähtäimen tavoitteita ja etsiä uutta. Kyseenalaistaa.

Jotta tämä olisi mahdollista, on löydettävä säännöllisesti tilaisuuksia irtautua projektia suoraan edistävistä tehtävistä. Vähän päivittäin, ja silloin tällöin ihan kunnolla.

Näin ruuhkavuosirumban keskellä tuntuu välttämättömältä, että tähän voi varata myös ihan oikeaa työaikaa. Silti sen ajan ottaminen vaatii hieman itsekuria.


Minulle luontevin tapa jäsentää ajatuksiani on kirjoittaminen. Alkavan vuoden tavoitteisiin voisinkin asettaa aktiivisemman blogin kirjoittamisen. Aika näyttää, kuinka moni sepustukseni lopulta tulee julkaistua. Toivottavasti lopputuloksesta on iloa myös muille.

Löydä se mitä on vaikea nähdä

Tiimillämme on pyrkimyksenä pitää kahden viikon välein retroja. Jokainen valitsee vuorollaan aihepiirin, jonka puitteissa laittaa muut täyttämään post-it-lappuja, joita ryhmitellään etsien työskentelyn kipukohtia.

Tällä viikolla pääsimme isojen kysymyksien äärelle etsimällä asioita, jotka eri vaiheissa prosessia tuottavat arvoa, hämmennystä tai ajanhukkaa. Iso tussitaulu peittyi post-it-lapuilla minulle ennennäkemättömällä tavalla.

Suurimmaksi ongelmaksi keskustelussa nousivat isot muutostyöt, joissa usein speksauskin on hieman epämääräinen. Niitä on vaikea edistää, ne vievät paljon aikaa, ja niissä on tavanomaista suurempi riski päätyä tekemään vääriä asioita.

Se, minkä itse koin erityisen mielenkiintoiseksi, oli että puhuimme tavallaan ihan samoista asioista, joilla vain pari viikkoa aikaisemmin olin perustellut testausstrategian luomista: hyödyllistä puuhasteltavaa riittää aina, joten ikäviin tai hankaliin hommiin ei välttämättä koskaan tule tartuttua ainakaan riittävällä tarmolla, jos ei ole tiettyä kurinalaisuutta omassa tekemisessä. 

Siinä missä minä testaajana tarvitsen strategista ajattelua edes nähdäkseni ne kokonaisuudet, jotka eivät mukavuusalueella pysytellen tule testatuksi, kehittäjä tarvitsee kurinalaisuutta ja strategista ajattelua jotta nuo isot ja vaikeat kokonaisuudet saataisiin pilkottua ja tehtyä pois alta. Vaihtoehto on, että niitä joko vältellään, tai edistetään vastahakoisesti mitenkuten milloin ehditään. Ja kun ympärillä tapahtuu koko ajan, rakennettava tuote saa jatkuvasti uusia ominisuuksia, pieniä parannuksia tai vähintään bugifiksejä, vältellen ja nitkutellen edistettävät kokonaisuudet helposti kasvavat, muuttuen yhä vaikeammiksi toteuttaa loppuun asti. 

Ja lopulta aika usein ne hankalimmin edistettävät asiat ovat kuitenkin tärkeitä.

Keskustelimme tavoista, joilla näiden isojen asioiden edistymistä voisi nopeuttaa, ja pohdimme syitä jotka ovat estäneet tässä onnistumista. (Ja vain pari päivää myöhemmin kävimmekin yhteistuumin pilkkomaan yhtä elefanttia.)

Jälkikäteen aloin muistella asioita, joita olen pitänyt testaajan urani suurimpina saavutuksina. Niistä lopulta aika harvat liittyvät tilanteisiin, joissa olen löytänyt bugin toteutetusta järjestelmästä. Parhaita ovat olleet hetket, kun olen keksinyt esittää kysymyksen, joka on paljastanut vältellyn aiheen. Usein ne ovat olleet asioita, jotka ovat selvästi vaivanneet kehittäjiä itseäänkin, mutta kissaa ei ole tullut nostettua pöydälle koska ei ole ollut pakko, ja muita, akuutimpia asioita on riittänyt enemmän kuin omiksi tarpeiksi. Joskus kyse on ollut asioista, jotka vain on ymmärretty eri tavoin, eikä kukaan ole pysähtynyt ajattelemaan asiaa huomatakseen ongelman laajuutta.

Kun puhutaan laadunvarmistuksesta, softan testaaminen on vain pieni osa kokonaisuutta. Vaikutuksiltaan merkittävintä on löytää niitä asioita, joita vältellään tai ei edes nähdä. Vaikeaa tästä tekee se, että testaajan näkökulmasta ne kaikki saattavat olla näkymättömiä. Kehittäjän taas voi olla vaikea nähdä juuri näiden asioiden esiin nostamista oleellisena, ne voivat tuntua joko vähäpätöisiltä tai kaikkien tuntemilta kollektiivisesti vaietuilta asioilta, mikäli niiden olemassaoloon edes kiinnitetään huomiota.

Tässä mielessä retrot ovat loistavia. Loistavia ovat myös hetket, kun löytää paljastavia kysymyksiä. Hyvä alku ovat "miten tämän voi testata", "kuka tätä käyttää", "mihin tämä vaikuttaa" ja "miksi tämä asia ei ole edennyt".

Testaajien ja kehittäjien välillä on joskus melko voimakastakin vastakkainasettelua. Itse pidän enemmän yhteistyömeiningistä. Toivon, että kehittäjät voivat nähdä minun ongelmani yhteisinä ongelminamme. Tämän viikkoinen retro konkretisoi itselleni myös sitä sinänsä aika itsestäänselvää asiaa, että myös kehittäjien ongelmat ovat minun ongelmiani. Lopultahan ne testaajan turhauttavimmat pulmat liittyvät usein juuri asioihin, joista myös kehittäjä on ollut epävarma. Meistä jokainen tekee osansa löytääkseen ja selkiyttääkseen epämääräisiä asioita. Myös minun tehtäväni on tarttua tähän työhön mahdollisimman varhaisessa vaiheessa.

Testausstrategiaa luomassa osa 1

Aloitin hiljattain uudessa työpaikassa. Siinä missä aikaisemmin olin yksi testausasiantuntija testaustiimissä, osana satojen henkien kokoista organisaatiota, nyt olen ainoa testaaja, ja muut työntekijät ovat kaikki kehittäjiä. Aikaisemmin työskentelin käytännössä vesiputousmallilla, nyt tarkoitus olisi päästä osaksi ketterää tekemistä. Ennen testasin useita tuotteita, nyt keskityn vain yhteen. Monet asiat ovat siis hyvin eri tavalla kuin edellisessä työssäni.

Testauksen näkökulmasta monet asiat ovat hyvin. Käytössä on TDD, kaikki koodi katselmoidaan, ja normaaliin työskentelyrytmiin on varattu aikaa vapaamuotoiselle toiminnan kehittämiselle sekä yhteisille retrospektiiveille. Organisaatio on testausmyönteinen, vaikka osaaminen sen suhteen on ollut jossain määrin rajoittunut tekniseen näkökulmaan. Tätä olisi nyt tarkoitus laajentaa.

Viime viikolla aloitin testausstrategian muodostamisen. Pidimme tiimin kanssa session, jossa kerroin lyhyesti, mitä testausstrategia tarkoittaa, ja sitten pureuduimme pohtimaan testauksen nykytilaa ja kehitystarpeita käyttäen työkaluna Sami Söderblomin FIT(Q)CODES-mallia. 

Selvitin jokaisen näkökulman osalta, minkä tyyppisiä asioita siihen liittyy (käyttäen pitkälti lähteenä James Bachin heuristista testausstrategiaa). Sitten tiimi sai äänestää, ovatko nämä asiat oleellisia lasilaatikko- vai mustalaatikkonäkökulmasta vai molemmista, kuinka tärkeästä kokonaisuudesta on kyse tuotteemme kannalta, ja kuinka hyvin pärjäämme siihen liittyvien piirteiden testauksessa. Sitten keskustelimme siitä, mitkä asiat ovat tästä näkökulmasta tärkeitä, ja mitkä vaatisivat enemmän huomiota. (Mustalaatikkopuolelta olin jo itse listannut näitä asioita.)

Vaikka tiimi ei ollut osannut odottaa ihan näin interaktiivista sessiota, keskustelu oli vilkasta, ja paikoin sen ohjaaminen tarkkaan suunnitelmani mukaan tuntui turhalta, niin luontevasti pohdinta eteni. Sain uusia eväitä oman testaustyöni suunnitteluun, ja esiin nousi myös joitakin tuotteen kipukohtia, joiden ratkaiseminen ei ole kiinni minun testauksestani.

Kirjasin parhaani mukaan muistiinpanot esiin nostetuista havainnoista ja listasin muutamia asioita, jotka vaativat erityistä huomiota sekä ideoita testauksen parantamiseen prosessin eri vaiheissa. Tällä mennään nyt muutama viikko, ja sitten jatkamme aiheesta etsien konkreettisempia tavoitteita ja vastuita. Sitä ennen minun olisi toki hyvä keksiä jotain uutta ajatuksia herättämään.

Tämä on varmasti hidas tapa luoda testausstrategia, mutta itse näen tärkeämmäksi tiimin yhteisen pohdinnan ja tavoitteiden etsinnän kuin nopean lopputuloksen. En myöskään näe mielekkäänä luoda testausstrategiaa vain oman työni lähtökohdista, ja vielä oudommalta tuntuisi lähteä suoraan ohjeistamaan kehittäjiä heidän työnsä tekemisessä, kun asiat ovat kuitenkin pääpiirteissään hyvin. Koen myös, että minulle yksi syy testausstrategian muodostamiseen on nimenomaan hakea eväitä yhteiseen keskusteluun. Ainoana testaajana joudun näkemään hieman vaivaa löytääkseni tiimistä tukea oman työni kehittämiseen, strategian muodostaminen ja myöhemmin sen arviointi ja eteenpäin kehittäminen tarjoaa tähän yhden työkalun.