keskiviikko 25. toukokuuta 2016

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?

sunnuntai 15. toukokuuta 2016

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?