Koodikoulussa Eficodella

Vietimme parituntisen Eficoden koodikoulussa tyttäreni kanssa. Nämä sessiot ovat tosi suosittuja, kaikki koodikoulut ovat aina loppuun buukattuja hyvin pian ilmoittautumisen aukeamisen jälkeen ja meillä kävi tuuri että olin eilen peruutuspaikkailmoituksen saapuessa heti postieni äärellä. 

Vaikka tyttöni ei sitä koodikoulussa ääneen sanonutkaan, tämä oli meille jo kuudes sessio. Niinpä sessioita alkaa vähitellen katsomaan vertailumielessä. Ja minä vedän sessioita itsekin #LearnWithLlew -tyyliin. 

Eficoden koodikoulu

Koodikouluun jokainen saapuu mukanaan oma kone ja oma aikuinen. Vastaanottajia talon puolestakin oli reilusti, jokaisella askeleella ohjaten että löysimme oikeaan paikkaan. Varsinaista kurssia piti (mies)koodarikaksikko, joka jo sai minut toivomaan että olisivat mallintaneet tässä kohden tasaisempaa sukupuolijakaumaa. 

Koodiopet kertoivat alkuun vähän yksinkertaisesti ohjelmoinnista (annetaan käskyjä tietokoneelle) ja avasivat yhden pöytäkoneen sisuskalut lasten tarkasteluun. Ja sitten lähdettiin omien aikuisten avulla valinnaisesti johonkin kolmesta vaihtoehdosta: Turtle Roy, LightBot tai Code.org:n Angry Birds -sokkelo.

Tyttöni jaksoi tehdä kuusi ensimmäistä Angry Birds -sokkeloa, kun kyseinen peli oli jo "tylsä". Koitimme LightBotia, joka ei sitten toiminut koneellamme. Näinpä päädyimme Turtle Roy:n pariin, joka lopulta miellytti kaikkein eniten.

 

Turtle Royssa parasta oli että sai kirjoittaa. Vaikka käskyt ovatkin englannista lyhennettyjä, pienen lunttilapun kanssa ne tarttuivat nopeasti ja oli kivaa kun tuloksena tyhjä kangas täyttyi omilla kuvioilla. Tehtiin ohjeista suoraan toistolla ja sekvensseillä neliö, muunneltiin neliöstä kolmio ja ympyrä. Ja rakennettiin sitten se tehtävänannon mukainen talon kuva komento kerrallaan. Aliohjelmien kanssa ehdittiin vasta aloitella, kun jo aika loppuikin. 

Eficode antoi lopuksi pikkukoodareille diplomit suorituksesta, joka oli ilmeisen tärkeä juttu. 

Vertailua sessioiden välillä

Olemme olleet nyt tosiaan erilaisissa sessioissa niin että tämä oli meille kuudes sessio ohjelmoinnin esittelystä ja ensikokemuksista. 

Kolme sessioista on ollut minun vetämiäni tyttöni esikouluryhmälle. 

Ensimmäisessä setissä teimme code.org:n koodituntia pariohjelmointina. Vaihdoimme neljän minuutin kellolla kumpi oli "ajattelija" ja kumpi "kirjoittaja", ja koneella ajattelu oli tosiaan Strong-style Pairing -periaatteen mukaisesti kiellettyä. Dynamiikka toimi ihan mahtavasti ja 6-vuotiaista oli toisilleen paljon apua, 14 lasta meni hyvin kahden koodiopen voimin ja tuloksena syntyi upeita Frozen Elsa & Anna -lumihiutaleita. 

Toisessa setissä teimme unplugged (tietokoneeton tekeminen) kuppirobotin ohjelmointia, ja hyvin opittiin laskemaan että montako siirtoa mihinkin kuvioon saatiin ja paperille syntyi upeita ohjelmia. Testasimme ohjelmia ryhmästä toiseen, ja aina välillä testatessa selvisi että robotti ei teekään ihan mitä ajatteli, jos askel tai vaikka alkutilanne ei olekaan sitä mitä koodatessa kuvitteli. Sain opetettua hiukan ajatuksia testauksesta ja oletuksista. Tätäkin tehtiin pariohjelmointina.

Kolmannessa setissä teimme oman äänisatukirjan. Suurin osa ajasta kului kuvia piirtäessä, jotka sitten skannattiin ja joiden päälle rakennettiin kerrontaa ja leikattiin yhteen omat äänet. Ohjelmointia sessiossa ei suoranaisesti tehty kun tarina ei ollut haarautuvat.

Kaksi muuta sessiota, joissa olemme olleet ovat olleet Linda Liukkaan järjestämiä. Pääsimme osallistumaan Hello Ruby -materiaalien leikkitestaukseen osallistuen Rubyn synttärijuhliin (ja tästä edelleen muistetaan mitä eroa on RAMilla ja ROMilla, ja kuinka ohjelmointi on sitä että minä päätän mitä tehdään). Ja aikaisemmin osallistuimme Hello Ruby -sessioon, jossa tarkasteltiin että  missä kaikkialla tietokoneita on, mitä tietokone on syönyt Raspberry Pi:n avulla sekä rakennettiin oma tietokone askartelemalla.

Kysäisin tytöltäni että mikäs sessio on ollut paras. Kuulemma se jossa ei tehty vain harjoitusta, vaan luotiin jotain oikeasti omaa. Ja code.org:n juttuja oli vaan kivempi tehdä kun niitä sai tehdä kaverin kanssa. Äiti ei ole yhtä hyvä, vaikka sillä olisi kuinka monta vastausta valmiina.

Session jäljiltä olen yhä enemmän sitä mieltä että tytöille ohjelmoinnin opettamisessa pariohjelmointi on erityisen tärkeää. Tyttöjä oli tässäkin sessiossa vain muutama, joten taidanpa itse vetää muutaman koodikoulun, jossa kiintiöitetään tyttöjä. Ja tytöillekin opetus pitää tehdä parina: mies-nais -parina. Koska koodaus tulevaisuudessa on tasa-arvoisin tehtävistä asioista, ja kiero jakauma nykyisin alalla on historiaa siihen mennessä kun ekaluokkalaiseni pääsee työtehtäviään valitsemaan. Eikös niin?

Voisiko työ muokkautua ihmisen mukaan?

Kirjoitin tänään työpäivän kesken paperilapulle twitterin inspiroimana seuraavan lauseen, jonka joku sanoi.

Luo työpaikkoja, jotka sopivat ihmisille; älä etsi ihmisiä, jotka sopivat työpaikkaan. 

Monesti kun etsimme sitä uutta duunikaveria, mielessämme on joukko kriteereitä, joita kaverin tulee täyttää. Ehkä moni ominaisuus on tiivistelmä omista ajattelemistamme hyvistä ominaisuuksistamme. Ehkä etsimme sitä mille oman onnistumisemme kohdistamme.  Ehkä kyseessä on ominaisuus, joka meiltä kaikilta puuttuu. Ja oli kyseessä mikä tahansa ominaisuus, olemme aina jotenkin kovin varmoja että tunnistamme sen ominaisuuden kun sen näemme ihmisessä haastattelutilanteessa. Tai ainakin tiedämme mitä olemme etsimässä.

Testauskentällä hakemuksista voi tosiaan päätellä ettei kukaan etsi minua. Ja silti tiedän hyvinkin tarkkaan että moni tarvitsisi minua, ei vain osaa hakea oikeilla sanoilla. Joillain organisaatioilla on kaltaisiani testaajia, ja ehdotus on että opettelepa pythonia, tai korvaamme sinut jollakulla toisella. Siinäpä mainio esimerkki siitä kuinka ensisijaisesti ihmisen pitää mahtua työpaikkaan eikä haluta / osata rakentaa työpaikkaa, joka sopisi ko. ihmiselle. Sillä mitä elämältään haluaa on väliä. Jos asioita tekee kun käskettiin, sydän ei ole mukana. Ja jos sydän ei ole mukana, kannattaa etsiä jotain missä se on mukana eikä kiduttaa itseään. Maailma kun on mahdollisuuksia täynnä.

Yritän aktiivisesti uskoa siihen, että ohjelmistokehityksen maailmassa ihmiset, joiden kanssa olemme töitä päätyneet tekemään ovat älykkäitä ihmisiä. Ihmisiä, joilla on kyky kasvaa monenlaisiin suuntiin. Suuntaa rajaavat enemmän intressit (mihin haluamme aikaamme käyttää kun se on niin rajallista) kuin taidot. Tahdolla oppii mitä vain, eikä tässä enimmäkseen kuitenkaan ihan rakettitieteen kanssa olla tekemisissä. Ja rakettitiedettäkin tekee ihmiset.

Kannattaisi ehkä katsella vähän että millaisia erilaisia ihmisiä ohjelmistokehitysmaailmassa on tarjolla ennen kuin päättää että tarvitsee taas yhden "superautomatisoijan". Ohjelmoijan profiilin tiimeihin jättämä aukko kun useimmiten ei ole automaation muotoinen, vaan näyttää enemmän kaikelta siltä mitä automaatio-ajattelun väliin jää.

Opin vuosi sitten termin "job crafting". Ideana on että kun meille annetaan työpaikka ja rajattu rooli, muokkaamme työn rajoja erilaisin tavoin itsemme näköisiksi. Mietin vaan että mitä voisikaan saavuttaa jos kevyen venyttämisen sijaan voisimme oikeasti etsiä miten panostaa parhaiten intressiemme puitteissa?

Tiedäthän mitä olet rekrytoimassa?

Minulla on maailman mahtavin työ testaajana. Saan toimia organisaatiossa, joka ymmärtää antaa ihmisilleen vapausasteita toiminnan kehittämiseen kaikella sillä luovuudella, mitä innostuneeseen ihmiseen mahtuu. Innostukseni ei ole laantumassa, 20 vuoden kokemuksella oppimisen ja aikaansaamisen liekki vain kasvaa. Ohjelmistojen laatuun ja testaukseen liittyvät tehtävät ovat tärkeitä, monipuolisia ja töissä saa tehdä asioita yhdessä toisenlaisten ihmisten kanssa yhteiseen hiileen puhaltaen.

Yksi asia minua tässä modernissa maailmassa vain surettaa. Ja se tiivistyy lähes kaikissa tämän päivän työnhakuilmoituksissa, joissa "päätyösi on testauksen automatisointi".

(Ilmoitustrendiin hyvä poikkeus Provelta, mutta he erikoistuvatkin oikeasti auttamaan organisaatioiden laatu- ja testausasioita onnistumaan ja tietävät mitä tekevät.)

Miksi tämä on ongelma tiivistyy hyvin Lanette Creamerin tuoreessa kirjoituksessa siitä miksei enemmän ihmisiä hae juuri sinun avaamaasi positioon. Rajasit juuri, tarkoituksella tai ilman, minun kaltaiseni asiantuntijan ulos.


Minun kaltaiseni testausasiantuntija tekee töitä kädet savessa löytäen tekemätöntä työtä, jota jotkut virheiksikin kutsuvat. Tekemätöntä työtä löytyy jo silloin kun ominaisuus on vasta pilke silmäkulmassa, ja kun sen tekee ajoissa toimii ohjelmistokehityksestä toimittaminen huomattavasti jouhevammin. Tekemätöntä työtä löytyy kun yhdessä rakennetaan porukalla, kun joku osaa katsoa asiaa käyttökokemuksen, arvon ja monipuolisten näkökulmien kautta niin että virheet eivät pääse koodiin saakka. Tekemätöntä työtä löytyy myös kun kriittisesti katsotaan että mitä tuli tehtyä, miten se toimii ja istuu jatkuvan oppimisen kautta muuttuvaan ymmärrykseen maailmasta teknologia huomioiden.

Minun kaltaisellani testausasiantuntijalla on vahva testauspohja, jonka päälle joskus rakentaa automaatiota. Mutta yleensä kaltaiseni asiantuntija tasapainottelee ajankäytön kanssa mahdollistaessaan loppukäyttäjälle ja muille sidosryhmille paremman laatukokemuksen eikä kiinnitä huomiotaan ensisijaisesti automaatioon.

Minun kaltaisellani testausasiantuntijalla on vielä erityispiirre tuon testiautomaation tekemisen suhteen. Ohjelmointitaitoisena yksilönä voisin valita mieluummin olevani yksi kehittäjistä ja jakaa sen automaatiovastuun niiden muiden kehittäjien kanssa. Voisin ottaa kehittäjän palkan ja arvostuksen ilman yleensä kokemaani taistelua ymmärryksestä, erityisosaamisen ja palkkahierarkiasijainnin osalta.

Minä olen tehnyt valinnan olla testaaja/testauspäällikkö/testausasiantuntija. Ja kun testaan aivojeni avulla, sosiaaliset taitoni auttavat minua hyödyntämään mahtavia kehittäjäkolleegoita aina kun olen nk. "pakettiauton lainaamisen tarpeessa" testausta automatisoimassa. Silloin kun olen kehittäjä, valmistelen mieluummin taustalla sitä maailmaa muuttavaa sovellusta, joka tekee minusta startup-yrittäjän, jos testauksen vetovoima omalta kohdaltani koskaan himmenisi. Kaikkeen kun ei kerralla yksi ihminen ehdi.

Kun hait kaveria, jonka ensisijainen toimenkuva on testauksen automatisointi, toivottavasti tiesit että et etsi kaltaistani testausasiantuntijaa. Etsit jotakuta, joka on lähtenyt kehittämään testauksen taitojansa toiseen, tärkeään suuntaan. Etsit jotakuta, joka tuottaa erilaiset tulokset kuin minun kaltaiseni testausasiantuntija. Tai sitten etsit todella kokenutta gurua, joka haluaa ja on ehtinyt opetella molemmat puolet.

Tiedäthän mitä olet rekrytoimassa? Testaus paranee automaatio edellä vain jos automaation taustalla on vahva testauksen osaaminen. Ja monessa tiimissä aukko on siinä testauksen osaamisessa ja tiimit ovat täynnä kehittäjiä joiden erikoisosaaminen on automaatiossa. Testaus on yksi ohjelmistokehityksen sovellusalue.

Testauksen verkkokurssi tammikuussa, kouluttajina Cem Kaner ja Maaret Pyhäjärvi

Vuosikymmenien opetuksen ja tutkimuksen tuloksena Cem Kaner, amerikkalainen testauksen guru, on paketoitunut BBST (Black Box Software Testing) -verkkokurssisarjansa. Tammikuun alusta käynnistyy Altom Consulting Oy:n järjestämänä BBST Foundations -testauskurssi, joka on täysin verkkopohjainen. Kurssitoteutuksella on vahva paikallinen tukijalka Suomessa ja Romaniassa. Kurssin tallenteet ja harjoitukset ovat Cem Kanerin käsialaa, ja Cem itse nähdään kurssilla myös läsnäolevana opettajana. Kotimaista väriä palettiin tuo Maaret Pyhäjärvi, joka ohjaa tarvittaessa kotimaisellakin kielellä vaikeissa kohdissa ja tarjoaa myös läsnäolo-opetusta paikallisesti. Kokonaisuuteen kuuluu mahdollisuudet tavata silmäkkäin Helsingissä, Tampereella ja Oulussa ja verkostoitua sitä kautta myös paikallisesti.

Kuukauden mittainen kurssi on tunti-pari opiskelua päivässä, ja sopii muotonsa puolesta mainiosti projektityön oheen. Kurssi ei ole helppo - tiukkaa asiaa, oikeita harjoituksia ja pohdintaa ryhmissä sekä loppukoe jonka kysymykset ennakkoon annettuina ohjaavat opiskelua asian oppimiseen. Verkkokurssi ei suinkaan tarkoita että olisit itseksesi omaan tahtiin tekemässä asioita, vaan ohjaus ja kanssakurssilaiset toimivat samassa puolikkaiden viikkojen rytmissä. BBST Foundationsin jälkeen voi halutessaan jatkaa syvemmälle mainioihin BBST Bug Advocacy, BBST Test Design ja BBST Domain Testing -kursseihin.

Miksi tälle kurssille?
- sopii mainiosti projektityön oheen jaettuna kuukauden mittaiseksi jaksoksi ja käsittelee tosielämän testausasiaa, opettaa todella paljon
- etäopetus tällä kurssilla tuo mukanaan sekä paikallisen kohtaamisen (Helsinki, Tampere, Oulu) että kansainvälisyyden verkossa, ja kurssin kustannuksiin ei tarvitse laskea matkustamista ja majoittumista.
- kurssia opettaa itse Cem Kaner, joka on testauskentän arvostetuimpia hahmoja, kts: http://kaner.com/?page_id=11. Kotimaisena opettajana toimii Maaret Pyhäjärvi, jolla myös on jonkinlainen asema testauksen opettajana ja edistäjänä Suomessa
- Ensimmäiset 10 ilmoittautunutta saavat interaktiivisen koearvostelusession Cem Kanerin kanssa, jolloin on mahdollista saada syvempää opetusta ja oivalluksia asioihin joita jo osaa mutta ei ehkä ole osannut korostaa kirjoitetussa tekstissä. Omaa aikaa Cemin kanssa ei ole liiemmin tarjolla, joten tästä pitää olla innoissaan.
- idealistit voivat tätä kautta tukea Cemin tarvetta rahoittaa jatkokehittämistä kursseille palvelemaan testausyhteisöä yhä paremmin. Cemin tekstimateriaalit ovat Creative Commons Share Alike -lisensoituja ja tukevat myös niitä joilla ei kenties ole kurssille ollut mahdollisuutta osallistua

Mitä sisällön puolesta saa?
- Ymmärtää miten testaus on erilaista erilaisissa tilanteissa, miten tarkoitukset ja tavoitteet eroavat riippuen siitä millaisessa projektissa tehdään töitä. Laajentaa omaa ymmärrystään ja rakentaa osaamista oman projektin kannalta oikeanlaisen testauksen valintaan.
- Muodostaa hyvän kokonaiskuvan testauksen perusteisiin, tuntien testauksen mahdollisuudet ja rajat, testauksen roolin mittaamisessa ja laajentaa omaa kykyään ajatella monipuolisesti testausta varten
- Vahvan teorian ja omaksumisen tukikysymysten lisäksi oikeita testausongelmia ryhmätöinä sekä loppukokeen tavalla joka tukee sisällön omaksumista. Kurssi on varsin erilainen kuin muut tarjolla olevat testauskoulutukset ja ehdoton täydennys niin kokeneen kuin kokemattoman opintopakettiin testauksesta.

AST BBST vs. tämä?
Association for Software Testing on kansainvälinen testausyhdistys, joka on useita vuosia järjestänyt Cem Kanerin materiaaleihin pohjautuen BBST Foundations, Bug Advocacy ja Test Design -kursseja. Jokin aika sitten AST:n ja Cemin tiet erosivat, ja viimeisimmät kehitystuulet ovat luonnollisesti mukana Cemin ylläpitämässä kokonaisuudessa. Cem perusti vaimonsa kanssa Kaner&Fieldler Associatesin, joka tekee siis kursseja ihan kaupallisesti - kuten tämä meidän toteutuskertamme. Olen itse erityisesti sen kannalla että tämä malli olisi "financially sustainable" - eli rahaa tarvitaan perustekemiseen että kehitys ei pysähdy kun siihen ei voida resurssoida.

Cemin uusin kurssi BBST Domain Testing on juuri pilotointivaiheessa, ja tätä kurssia ei AST:n kautta tule olemaan tarjolla. Olen ollut todella vaikuttunut katselmoidessani ko. kurssin työkirjaa - konkreettista, monipuolista, esimerkein valotettua oppia siitä miten testaajana analysoidaan erilaisia arvoja, joita testatessa voi ja pitää käyttää, apuja siihen miten valinnat tehdään. Tätä osaamiskeskeistä tulevaisuutta haluan olla mukana rakentamassa.

Kadonnut linkki

Luulen että viestissäni oli linkki kurssin ilmoittautumissivulle, mutta huomaan että sen jonnekin kadotin. Lisättäköön siis loppuun, että lisätietoja ja mahdollisuus ilmoittautua löytyy: http://altom.fi/services/training/bbst-foundations

Terveiset EuroSTAR 2013 -konferenssista

EuroSTAR 2013 -konferenssissa edustettiin Suomea kuulemma yhdeksäntoista testaajan voimin, ja henkilökohtaisesti tiedän törmänneeni näistä ainakin kolmeentoista. Suomalaiset olivat tälläkin kertaa vähemmistöä 950 osallistujan joukossa, joten laitetaanpa jotain tapahtumasta muistiin kotimaisellakin kielellä.

Vaikka olinkin tällä kertaa järjestäjäporukkaa, sen käytännön merkitys konferenssissa oli pikaisia lähinnä pikaisia lavavisiittejä. Olin asettanut omaksi tavoitteeksi yhden tutoriaalin ja keynote-puheenvuorojen lisäksi ihmisiin tutustumista testilabran ympärillä, joten sillä mentiin.

KEYNOTE -puheenvuorot
Sarjan avasi Laurent Bossavit puheenvuorollaan 'Skeptical Self-Defense For The Serious Tester Or, How To Call A $37 Billion Bluff'. Laurent on mahtavan kirjan 'Leprechauns of Software Engineering' kirjoittaja, joka on erikoistunut selvittämään erilaisten suosittujen tutkimustulosten todellisuuspohjaa. Tältä pohjalta Laurent opetti meille, miten torjua testaustyöelämän koulukiusaajia tavoitteena erinomainen ja järkevä testaaminen sen sijaan että valitaan olemassaolevista tutkimustuloksista hienolta kalskahtava mutta ei omaan järkeen käypä toimintatapa. Matikkahörhö minussa hihitteli kun Laurent kertoi että analysoidessaan kolmatta esimerkkiään hän käytti ensi kertaa vihastuksissaan p-arvoa. Ja yleisesti arvostin muistutusta siitä että nykypäivän ammattilaisen perusselviämiskyky on Google-Fu, jolla voi ampua alas yliladattuja väitteitä 'Weaponized claims'.

Toisena kuultiin Harry Collinsin sijaisena Robert Evansia otsikolla 'Testing Machines As Social Prostheses'. Sosiologipuhuja otti kantaa testaukseen sosiaalitieteen muotona, ja kävi läpi esimerkkejä siitä miten sosiaalinen ympäristö vaikuttaa esimerkiksi oikean toiminnallisuuden arvottamiseen, mainiolla esimerkillä siitä miten jatkaa sarjaa 2, 4, 6, 8. Se voi olla matematiikan oletuksin moni muukin numero kuin 10, ja jos kontekstina on futismatsi, oikea jatko voikin olla "who do you appreciate". Hiljainen tieto ja sen muotona erityisesti "collective tacit knowledge" jäi minun pohdintalistoilleni - on asioita, joita oppii vain osallistumalla testaajien sosiaaliseen piiriin ja näkemällä muita testaajia. Ja puhuttiin siitä, että kaikkea ei voi muotoilla säännöiksi tietokoneelle, tai ainakaan nykyisen kaltaisille tietokoneille jollei hyväksytä korjaustarvetta - "repair" on ihmisen mukanaoloa. Tekojalat on siis hyviä ja mahtavia, mutta ei niiden ole tarkoituskaan olla alkuperäisen oikean jalan suoria kopioita vaan täyttää osaa keskeisimmistä tarkoituksista.

Kolmantena ääneen pääsi Keith Klain, joka vetää testausyksikköä Barclays -pankille, otsikkonaan 'Creating Dissonance: Overcoming Organizational Bias Toward Software Testing'. Keith puhui vinoutuneista käsityksistä, jotka perustuvat osittaiselle tiedolle ja ennakkoluuloista, jotka perustuvat sille että tietoa ei ole lainkaan.  Hihittelin eturivissä kun Keith siteerasi konferenssin expo-alueen mainoslauseita, jotka ovat kyllä tosiaan varsin selkeästi suunnattu ihmisille jotka eivät tiedä mistä testauksessa on kyse. Olen kirjannut muistiin lainauksena "They're  not selling that crap to you, they selling that to my COO". Keithin oppina oli, että C-tason (CxO-roolit) tyyppien kanssa kannattaa opetella puhumaan testauksesta liiketoiminnan silmälasein, esimerkiksi testauksesta kannattaa mainita enemmänkin vaikka uudelle markkinalle siirtymisen riskien kontekstissa kuin jaella testiraportteja testitapausten ja virhemäärien osalta. Ja että ei riitä että organisaatiossa testaustyyppien esimiehen esimies arvostaa testausta, vaan että tukea täytyy rakentaa laajemmalle pohjalle.

Neljäntenä taikuri Ian Rowland viihdytti meitä 'Every Think is Possible' puheenvuorollaan puhuen IT:stä, eli siis 'Impossible Thinking'. Ian kannusti ajattelemaan laatikon ulkopuolelle ja sitä kautta saavuttamaan asioita jotka tuntuvat mahdottomilta. Ja siinä sivussa huvitti yleisöään tempuilla, kuten ajatustenluvulla.

Viidentenä kuultiin Fiona Charlesin puheenvuoro '“Get In There And Argue!” – A Questioning Tester’s Personal Journey', jossa Fiona kävi läpi erilaisia asioita joita hän on kyseenalaistanut testausuransa aikana. Myös tässä puheenvuorossa kannustettiin aktiiviseen toimintaan ja pohdittiin hyviä tyylejä esittää vaikeita kysymyksiä. Keskustelun yhteydessä hymyilyä herätti Fionan vastaus
"Tact is something I *thought* I would acquire by the age of 50."

Viimeisenä sarjassa puhui Martin Pol otsikolla 'Questioning the Evolution of Testing: What's Next?'. Martin kävi läpi testauksen vaiheita liiallisesta vapaudesta liialliseen rakenteeseen ja tasapainoa näiden välillä, puhui siitä että jossain vaiheessa vaatimukset ulkopuolelle olivat niin suuria että välillä tuntui kuin otsaan olisi liimattu "ei"-lappu. Ja muistutteli muuttuvasta maailmasta ja teknologiatrendeistä. 

Muita oppeja
Maanantaina hengailin James Bachin Rapid Test Management -tutoriaalissa, josta pystyi poimimaan kivoja pointteja jos ei häiriintynyt siitä, että mielikuvaksi muodostui koko ajan että puhuttiin testaajille managereista, eikä managereille siitä että miten vaiheittain voisivat omaksua uudenlaista hallinnointityyliä. Paras poiminta oli ehdottomasti vapaasti kääntäen "Ohjelmistokehityksen vetäjät sietävät paljon epävarmuutta siinä, kuinka monta virhettä ohjelmiin laitetaan sisään, mutta hyvin vähän siinä kuinka kauan testaus vie" - James Bach.

Tiistai-aamupäivänä pääsin nauttimaan Robert Evansin ja James Bachin yhteissessiosta sosiologian ja testausasiantuntijuuden kanssa, joskin jouduin olemaan poissa juuri siinä välissä kun pelattiin matkimispeliä jossa piti tunnistaa kokeneempi testaaja anonyymien vastausten perusteella muodostaen hyviä kysymyksiä. Monelta osin puhuttiin paremmin, tarkemmin ja syvemmin vastaavista asioista kuin myöhemmin keynote-puheenvuorossa.

Vedin myös tiistaina testilabrassa sessiota paritestauksesta, joka oli todella hauskaa. Minun keskeinen pointtini tätä valmistellessa oli paridynamiikkaan vaikuttaminen lähestymistavan valinnalla ja muuntelun tarve silloin kun parityötä tekee enemmänkin. Testilabra kaikkiaan oli ihan mahtava, jonkin tehtävistä kävi tekemässä ainakin 130 erillistä henkilöä ja lisäksi joukossa oli paljon nopeampia visiittejä. Toivottavasti vastaava nähdään taas ensi vuonna testauspäivien yhteydessä täällä suunnalla. 

Ainoan suomalaisen puheenvuoron veti Pekka Marjamäki, joka kertomalla hyvin henkilökohtaista tarinaa väsähtämisestään sai yleisönsä kyyneliin. Katselin tätä itse ehkä vähän eri perspektiivistä ja koin vahvasti että oikeampi ajankohta esitykselle olisi ollut kenties vasta ensi vuonna. Mutta yleisö sai hyviä muistutuksia siitä että apua voi ja kannattaa hakea ja että suuret haaveet voivat saada putoamaan korkealta, ja että itseään oman jaksamisensa osalta täytyy oikeasti osata kuunnella.

Suuri ylpeydenaiheeni oli Alexandra Casapun esitys, joka valittiin uudelleen vedettäväksikin. Ylpeydenaihe siksi, että Alexandra on minun testaajani, ja veti esityksensä upeasti läpi kahteen kertaan niin että kaikkiaan kuulijoita oli puolikkaan konferenssin verran.

Konferenssin parasta antia ovat aina kuitenkin keskustelut. Tapasin paljon testaajia ympäri Eurooppaa, ja istuin enimmäkseen uusien tuttavuuksien seurana. Ja toisinaan tuli hengailtua nimitestaajien kanssa. Muistiinpanoissa on pari esitystä, joista ainakin toinen pitää muotolla tässä vielä pikaisesti aikaisemmin lupaamakseni 90 sekunnin esitykseksi Software Testing Clubille.

Ladattuna testaustöihin - yhteisössä on voimaa.

Särähdyksiä ja testattavia oletuksia

Kuuntelin eilen ihmisiä Tampere Goes Agile -tapahtumassa ja mietin. Useammassakin kohdassa testaajan korvaani särehteli se mitä luulin kuulevani: pohdintaa siitä miten "perinteisistä testaajista" saataisiin tehtyä testauksen automatisoijia, vaikka sellaisia jotka osaa "copypasteta keywordeja"; miten näistä saataisiin tehtyä määrittelijöitä - yleensäkin jotain mitä he eivät nyt ole.

Toinen särähtelevä viesti oli ajatus siitä että jos testaajat olisivat mukana tekemässä määrittelyä esimerkein, he pystyisivät ennakkoon kertomaan kaikki ne asiat jotka kertoisivat havaintoina testatessaan. Kuunnellessani tämän suunnan viestejä muistin, miksi ensi kertaa koin kykeneväni itse hyväksymään tätä kehitysmallia paremmin kun se sai Gojko Adjicin tekstien lueskelun myötä oikean nimensä: määrittely esimerkein. Ei tämä mitään hyväksymistestiohjattua kehitystä ole, korkeintaan esimerkkiohjattua. Ja esimerkit eivät ole kaikki mitä hyväksyntään vaaditaan. Tämä usko esimerkkien täydellisyyteen henki jotenkin monen toteuttajataustaisen agilistin viesteissä ja onhan se kivan vapauttava ajatus että toteutetaan mitä on määritelty ja muu jää muualle.

Juttelin pitkään erään arvostamani kolleegaan kanssa. Keskustelu muistutti, että osana kokeilujani tehdäksemme hyvää määrittelyä esimerkein, minulla on hypoteesi testattavana. Minä uskon, että ohjelmisto puhuu minulle testaajana, olen oppinut kuuntelemaan sitä tavoilla joita on välillä vaikea eritelläkin. Se vihjaa mihin kiinnittää huomiota, antaa vinkkejä siitä kuinka moneen kertaan asiaa kannattaa eri silmälasein tarkastella. Esitän sille kysymyksiä ja se vastaa. Vastausten perusteella opin jotain mitä en tiennyt ennestään, ja käytän oppimaani rajallisen ajan suuntaamiseen sellaisiin asioihin joilla on merkitystä.

Puhun toki myös ihmisille, ja hekin vastaavat minulle sillä suoralla vastauksella, mutta olen aina testaajana kuunnellut myös vastauksen sivuviestejä: epävarmuuksia, selittämisen vaikeutta, välttelyä, hienojakoisia eroja toisten sanomisiin. Näistäkin opin, ja tarkastelen mitä ne käytännössä tarkoittavat keskustellen jälleen sen ohjelmistoversion kanssa.

Esimerkein määrittelyssä uskon, että inkrementin pienuus auttaa monessa asiassa. Minulla on edelleen se tuotekonteksti, tämänhetkinen ohjelmistoversio. Puhumme esimerkein siitä, mitä siihen lisätään. Mutta oletan, ja tätä aion myös osaltani testata, että avainesimerkit vangitsevat joitain juttuja jotka nostaisin esiin normaalisti testatessani mutta jättävät osan vangitsematta. Määrittely ja mielikuvitus ilman konkreettista herätettä testattavasta ongelmasta ei vain ole yhtä monipuolinen lähde testaajan osaamisten pohjaksi. Uskon toki että se on riittävä. Mutta, korvaani tulee vielä pitkään särähtämään, kun tutkivan testauksen roolia kuviossa ei ymmärretä. Mikään ei estä meitä varaamasta aikaa tutkivalle testaukselle, oppimisille ja reagoinnille - paitsi me itse ja uskomuksemme siitä mitä sprinteissä pitää tapahtua.

Olin muutaman vuoden poissa agilekentältä, kun minusta aiheesta puhujan tulee harjoittaa jotain puhumisensa suuntaista: Ilmarinen ei juurikaan harjoittanut ja käsiteltäväksi jäi lähinnä perinteiseen paluun aikaansaamat opit. Eilinen muistutti, että testausmielessä tällä kentällä on ammattikuntani kannalta tärkeää työtä tehtävänä. On se sääli jos testaajien osaamista ei nimikkeen ja ymmärryksen puutteiden vuoksi osata hyödyntää ja ketterän kentän tarvitsee kantapään kautta oppia monimuotoisen palautteen tekokkaan tuottamisen asiat. Automaatio on osa, mutta se ei ole näin iso fokus. Ja tietystihän on helppoa sanoa että se tuoteomistaja tekee tän tyyppiset jutut, ja harjoittelee ne taidot joita testausihmiset ovat nk. perinteisessä maailmassa hioneet.

Ja muuten, testauskentällä on testaajia, jotka suorittavat muiden suunnittelemia testejä rutiininomaisesti tarkistellen "automaation korvikkeita". Niitä jotka uskovat että vastaukset tulevat spekseistä, ajattelematta, itse oppimatta ja yhdistelemättä. Laitan sen luokan työn samaan laariin sen avainsanojen leikkaa-liimaa -ajatuksen kanssa. Kummastakin voisi kokonaan luopua.

Määrittely esimerkein, ensiaskeleita

Olen pöytälaatikkoprojektinani - muun ollessa vielä korkeampaa prioriteettiä - tutustunut aktiivisesti määrittelyyn esimerkein, SBE - Specification by Example, ja siinä erityisesti Cucumber/Gherkin -tyyliseen määrittelemiseen. Elävän dokumentaation - määrittelyn ja testiautomaation - yhdistämisen konsepti on varsin houkutteleva nykyiseen projektien kuukausirytmiin.

Minulla on tähän tutustumiseen oikeastaan kaksi motivaatiotekijää. Toinen lähtee siitä, että tiimini kehittäjät voivottelevat aika usein tehtävänantojensa epämääräisyyttä, ja tämä voisi olla tapa määrittää tarkemmin mitä muutosta esimerkein tavoiteltiinkaan. Toinen lähtee siitä, että kuukausisyklissä sekoaa, jos ei jotenkin saa sitä testiautomaatiota kuvioon ja mikään "erillinen projekti" ei vielä tälläkään kertaa tule kestämään elossa tiimini kanssa. Niinpä siis mietin aktiivisesti määrittelyn ja testiautomaation yhdistämistä.

Kirjoitin ihan lähiaikoina ensimmäisen kokonaisen esimerkkini ominaisuudesta ja laadin yleensäkin listan ominaisuuksista joita kyseiseen alueeseen voisi liittyä. Ajatukseni on, että sen sijaan että vielä koittaisimme tuotepäälliköiden kanssa alkaa tehdä määrittelyä esimerkein kaikelle uudelle, luotaisiin ensin vähän keskustelun pohjaa nykyisestä toiminnallisuudesta.

Ensiesimerkkini osui ominaisuuteen, jota juuri opiskelin testatessani sitä. Tutkin ja selvittelin miten se käyttäytyy, ja selvitellessäni kyselin toteuttajalta tarkoituksesta. Ja kirjasin esimerkiksi sen mitä opin. Testausheuristiikkoja vasten - yhdenmukaisuus - ominaisuus toimii ilman logiikkaa. Kyseisessä ominaisuudessa seurataan muutoksia kokonaisuuteen, ja nykytoiminnallisuuden mukaan kokonaisuuden muuttamista seurataan, mutta osan muuttaminen ei ole kokonaisuuden muuttamista. Ja muuttaminen muuttamalla on eri asia kuin muuttaminen poistamalla.

Näytin esimerkkiä projektipäällikkö / tuotepäällikkötasolla. Ensireaktio oli kysymys siitä kenen tälläisiä pitäisi laatia ja ajatus siitä, että ei näin tarkkaan tarvitse ainakaan kertoa ominaisuuksista tuotepäälliköiden toimesta. Mutta, mahtaa olla tuskaista jos ei kerrota, ja sitten lopulta minä testatessani speksaan kaikenlaista, mitä speksissä olisi alkujaan pitänyt / voinut ottaa huomioon.Tuotepäälliköt luottavat tiimiin toteutuksen yksityiskohdissa, koska yksityiskohtainen keskustelu vaatisi aikaa jota ei ehkä olekaan varattuna. Joskus luottamus palkitaan hyvällä toteutuksella. Ja joskus saa jotain vähän sinne päin. Mutta onneksi kaikkea voi vähitellen sitten muuttaa ja korjata.

Toisaalta oma ensireaktioni oli, että nämä asiat itse pienemmällä työmäärällä nostaisin bugiraportteina siitä että mitä erilaisia heuristiikkoja sitten emme noudattaneet tai millä tapaa toiminnallisuus vaan on käyttäjän perspektiivistä käsittämätön. Toisaalta pelkään, että en olisi tarpeeksi hyvä osatakseni myöskään ajatella noita asioita ilman toteutettua tuoteversiota, joka inspiroi minua testaamaan ja tutkimaan käyttötilanteen kannalta.

Meitä on kehitystiimissä vähän ja edestakaisin kirnuaminen syö motivaatiota sekä vähäisiä voimavarojamme. Jatkan siis hetken pöytälaatikkoprojektina ja esimerkein selvittelyä sen osalta miten tätä meillä saadaan oikeasti käyttöön.

Lupaan julkaista lähiaikoina speksit "nykytoiminnallisuudesta" ja "tavoitellusta toiminnallisuudesta". Ja muutenkin pitäisi kirjoittaa enemmän siitä, mitä olen jo tähänkin mennessä oppinut siitä kuinka tälläisiä speksejä yleensäkään kirjoittaisi.

Onko buginen järjestelmä IT-toimittajalle tosiaan rahasampo?

Pääsin eilen juttelemaan puhelimessa Tietoviikon toimittajan kanssa, joka varsin ilahduttavasti poimikin kommenttejani artikkeliinsa:
http://www.tietoviikko.fi/cio/buginen+jarjestelma+on+ittoimittajalle+rahasampo/a831331

Suoranaisista asiavirheistä en suinkaan valita, mutta muutama asia keskustelussamme oli jäänyt vähän erilaiseen lopputulemaan:
1. En suosittelisi "kolmatta osapuolta" tarkoittaen testaukseen erikoistunut firma
2. Suosittelisin sopimusvaiheessa nk. relational contract -mallia, jossa muodostetaan yhteinen rahasumma toimittajan bonuksesta, muutospyyntö ja virherahasta, ei vain virheistä

Halusin kuitenkin hieman pidemmin kirjoittaa kokemuksistani IT-projektien ihmeellisessä maailmassa.

Nykyinen työni on nk. tuotekehitystä. Se tarkoittaa, että testaajana olen sen organisaation palveluksessa, josta löytyy suora asiakas sekä toimittaja samoilta palkkalistoilta. Toiselle testaamistani järjestelmistä on ulkoisia loppukäyttäjiä, joiden näkökulmaa ja sielunelämää sovelluksen käytössä koitan ymmärtää. Suurien käyttäjämäärien myötä lokeistakin näkee, että massa tosiaan tekee kaiken mitä suinkin vain sovelluksella voi tehdä, ei kulje sitä meidän suunnittelemaa polkua eikä meidän suunnittelemaan tahtiin. Toinen testaamistani järjestelmistä on sisäiseen käyttöön, jolloin samalta palkkalistalta löytyvät vielä kaikki käyttäjätkin. Palaute käytävillä on raakaa ja välitöntä, ja kolleegaa halutaan auttaa erityisen vahvasti kun jokaisella käyttäjällä on kasvot.

Aloitin nykyisessä työssäni vasta huhtikuun alusta. Ensin mainitsemani järjestelmä on ollut tuotannossa jo ennen kuin minä työni tiimieni ensimmäisenä ja ainoana testaajana aloitin. Olisi minun silmilläni loukkaavaa väittää, ettei sovellusta ole ennen testattu. Kuitenkin tulokset tekemästäni testauksesta puhuvat täydennyksistä, näkökulmista joita ei testaukseen ole ajallisesti mahtunut ennen lisäpanostusta, tai jota ei ole osattu niillä voimavaroilla tehdä joita tiimin käytössä ennen minun mukaantuloani oli.

Arkipäiviini kuuluu ongelmien löytämistä - bugeja, niinkuin ammattikielellä sanotaan. Bugi on mitä tahansa mikä käyttäjää ärsyttää, haittaa, estää tai hidastaa. Bugit voivat olla puuttuvia keskeisiä toiminnallisuuksia. Ne voivat olla koodivirheitä. Ne voivat olla virheitä siinä miten meidän koodi ja muilta hankkimamme koodi yrittävät ratkoa yhdessä käyttötilannetta. Ne voivat olla virheitä siinä miten käyttäjä ohjelmaa tulkitsee käyttävänsä, missä järjestyksessä tai kuinka nopeasti. Olemme ihastuttavan yksimielisiä tiimini toteuttajien ja projektipäällikön kanssa siitä että olisi ajan tuhlausta jäädä pohtimaan koska bugi on syntynyt (onko se jo nyt asiakkaiden riesana tuotannossa), onko bugi virhe vai muutospyyntö jos samalla rajallisella ajalla sen korjaamme, tai onko kukaan osannut juuri oikeaan aikaan oppia ja tajuta että tämäkin asia oikeasti haittaa käyttäjiä merkittävästi. Tosiasia kuitenkin on, että jos emme saa ongelmasta käsitystä  jonka pohjalta myös toteuttaja ihan käytännön tasolla ymmärtää mikä ei toimi ja millä tapaa, korjaus vähintään menee jollain tapaa metsään. Ja testaajana tuotan lisäarvoa tiimissäni auttaen kehittäjäkolleegoitani löytämään virheitä ajoissa, ennen kuin sekin asiakassekmentti ilmaantuu jolle tämä asia on maailman pysäyttävä, ennen kuin meidän uutta asiaa tarvitsee ensi kertaa käyttäjille näyttää tai ennen kuin löytyy se asiakas, jolla tämä ongelma ylittää ärsyyntymiskynnyksen tuotteen laadun kanssa.

Elämä tuotekehityksessä ei ole helppoa, kun meillä kaikilla on yhtälailla haasteena ajan rajallisuus ja toiveiden monimuotoisuus, ja yritys ymmärtää sitä käyttäjien massaa ja monipuolisuutta sekä usein arvattuja tarpeita. Mutta verraten siihen mitä tein aiemmin, elämä on suorastaan ruusuilla tanssimista.

Olin välissä nelisen vuoden jakson koittamassa ymmärtää asiakas-toimittaja -projekteja ja niihin liittyvää testausta. Tein keikkaa toimittajaorganisaatioiden projekteissa, kunnes siirryin päivätöihin asiakasorganisaatioon tukemaan hyväksymistestausta sekä toimittajilta tilattavan testauksen määrittelyä. Näissä projekteissa on kummallisia ilmiöitä, joista todella monia tunnistan varsin kärjistetysti kirjoitetussa artikkelissa http://ohjelmistotestaus.fi/2012/08/tarinoita-it-hankkeiden-ihmemaasta/.

• Paljon aikaa ja energiaa menee 'hukkaan' kun  asiakas- ja toimittajaorganisaatio kilpaa todistelevat että ehdottomasti korjattava ongelma on virhe eikä muutospyyntö. Virheet sopimusteknisesti kuuluvat usein toimittajan vastuulle, kun taas muutospyynnöt asiakas maksaa erillisestä rahapussista. Tuntuu varsin uskomattomalta, että voidaan rakentaa tilauksesta eläkkeen laskentajärjestelmä, joka ei osaa laskea eläkettä, mutta toimii "määrittelyjensä mukaan". Toimivuudesta tarkoitukseensa maksetaan erikseen, koska vastuu asiantuntijuudesta on sovittu asiakasorganisaatiolle eikä siitä ole siis toimittajalle maksettukaan. Myös riskin otto nostaa projektin hintalappua. 
• Asiakkaan testausvaihe, "hyväksymistestaus", on usein ensimmäinen tuloksellinen testaus ja tapahtuu hyväksymisnäkökulman vuoksi jo alkuperäisessä viivästymisten vuoksi tiukennetusta aikataulusta irrallaankin liian lyhyessä aikavälissä liian pitkän heikkolaatuisen palautteen jälkeen. Hyväksymistestauksen pitäisi olla testaus-, ei korjausvaihe. Jotta tämä olisi mahdollista, on oltava samanlaatuista ja sisältöistä testausta, tai laajempaakin, aikataulussa ennen tätä. Jos aiempien testausvaiheiden sisältöä vielä rytmittää edellisessä pointissani mainitsemani määrittelyjen ylipalvonta, huomaamme lopuksi ennen lakimuutoksen pakottamaa tuotantoonsiirtopäivämäärää, ettei koko järjestelmä tee mitä sen tarvitsee, vaikka tekeekin mitä on määritelty. Ohjelmistokehityksessä monet asiat konkretisoituvat vasta kun järjestelmää pääsee käyttämään - testaamaan. 
• Vaikka virheet kuuluvat ehkä sopimuksen mukaan perushintaan, sopimukset harvoin huomioivat että testaaminen tavalla jolla virheet raportoidaan selkeästi ja korjaukset mahdollistavasti, ei välttämättä kuulukaan. Testauksen vaatiminen / tilaaminen on taitolaji. On täysi myytti, että testaamaton tarkoittaisi toimimatonta. On todistettavasti järjestelmiä, joilla ei ole erillisiä testaajia, joiden laatu on näitä "ammattitestaajien" testaamia parempi - yleensä taustalta löytyy ammattiylpeyttä ja yrittäjähenkeä. Testaus - kenen tahansa aikaa ja osaamista käyttävän toimesta - kuitenkin opettaa yllättävistä reunaehdoista, joista kaikkia ei parhaimpiinkaan suunnitelmiin saada mukaan. Ei siis riitä, että vaaditaan toimittajaa testaamaan. Pitää pystyä kertomaan ja sopimaan mitä ja miten, ja missä laajuudessa ja laadussa. Testausta se on huonolaatuinenkin testaus, ja jotkut kutsuvat sitäkin testaukseksi että painelee samoja nappeja käsin samassa järjestyksessä kymmeniä kertoja ilmaan mitään perustetta epäillä että juuri tätä asiaa nyt tarvitsisi tarkkailla. Samalla ajankäytöllä voisi tehdä edes pieniä muutoksia tekemiseensä, ja sitä kautta merkittävästi lisätä tehdyn testauksen laatua. Lisäksi todella monet asiakkaat tietoisesti ja tarkoituksella tilaavat projektinsa ilman testausta laskien hintalappua tyypillisesti 20-30 %. Tällöin sovitaan että asiakas hoitaa testauksen ja "hyväksymistestaukseen" kuuluukin yllättäen mahdollisesti täysin toimimattomalla ja aiemmin tarkastelemattomalla ohjelmistokokonaisuudella testaaminen. 
• Hintakilpailu toimittajien välillä tuo erikoisia sivuilmiöitä. Tarjouksista on todella vaikeaa saada vertailukelpoiset sisältyvältä laajuudeltaan, ja toimittajat omien malliensa nimissä tarjoavat selkeästi alihintaan projekteja, joissa varsinainen lypsylehmä on virheiden ja muutosten toteutus ensitoimituksen jälkeen. Ensitoimituksen kokoa projektin kuluessa aktiivisesti minimoidaan tiedostaen, että seuraavan täydentävän toimituksen kanssa on haastavaa siirtää kehitystä seuraavalle, ja vaikka tuntihintaa ei ehkä voi ylös hilatakaan (moni asiakas pyytää tarjouksessaan alkuun jo sitovat ylläpitohinnatkin), mikään ei aseta rajoja sille kuinka monta tuntia asian tekemiseen toimittajaorganisaatiossa menee. Ja tuntimäärää saadaan helposti nostettua, kun on erikseen henkilö joka juttelee asiakkaan kanssa (vaatimukset), joka keksii miten asiakkaan tarve ratkaistaan (määrittelyt), joka miettii tekniset rakenteet ratkaisuille (arkkitehtuuri), joka mietii mitä osia koodista viime kädessä muutetaan (tekninen suunnittelu), joka toteuttaa muutokset (koodaaja), joka testaa teknisesti (integraatiotestaaja), joka testaa osana järjestelmää (järjestelmätestaaja) ja joka juttelee aikatauluista asiakkaan kanssa (projektipäällikkö). Ja jos tehdään isompia asioita, joka ryhmällähän pitää tietysti olla vielä erillinen vetäjä. Välillä tulee mielikuva että ei voi ajatellakaan, että yksi kaveri tekisi näitä kaikkia, sehän laskisi laskutettujen tuntien määrää.
• Pelon ja epäluottamuksen ilmapiiri maksaa asiakkaalle moninkertaisesti. Ei suinkaan kelpaa, että toimittajaorganisaatio valvoisi itse omaa tekemistään ja esimerkiksi vastaisi siitä, että toimitukseen sisältyy tulevaa tukeva testiautomaatio (sen ohittamisella ensiprojektissa saadaan muuten upea määrä ylläpitotunteja laskutettavaksi!) vaan kyllä tilaajan pitää ehdottomasti laittaa omat edustajansa asialle vahtimaan. Ja testausfirmat vielä propagandamaisesti mielellään nostavat ammattimaisen edunvalvojan näkökulman esiin. Tehdessäni töitä testausfirmalle testauskonsulttina silloinen myyntiorganisaatio myi edelliselle työnantajalleni useita kavereita täysipäiväisesti tekemään testiautomaatiota hyväksymistestauksen tueksi. Testiautomaatio ei koskaan tuottanut muuta kuin lämpimän tunteen, sen ylläpitäminen maksoi maltaita sillä se hajosi jatkuvasti. Se ei myöskään elänyt kovin kauaa. Ja tässä asiakasorganisaatiossa työtä tehneenä tiedän melkoisen varmasti, että suurin tekijä epäonnistumiselle on etäisyys. Samasta asiasta samalla rahalla samalle toimittajalle kuin joka teki hyväksyttävää järjestelmää olisi saanut merkittävästi enemmän onnistumisen eväitä. En todellakaan ymmärrä että miksi pitäisi maksaa kahdesta "samansisältöisestä" testauskerroksesta vain epäluottamuksen nimissä. Luottamusta voi rakentaa ja sitä tukevia rakenteita tuoda sopimuksiin. Viime kädessä kahdenkin organisaation välisissä projekteissa ihmiset ja yhteistyö ovat ne avainsanat. Organisaatioiden etäisyys vain vaatii sopimusta tueksi tiukkoihin tilanteisiin, joissa liiketoimintojen reunaehdot eivät ehkä olekaan synkassa.
• Ulkoiset testausorganisaatiot usein pahentavat tilannetta. Jos kahdella organisaatiolla on jo erilaisia tavoitteita, kolmas testaukseen keskittyvä organisaatio ei välttämättä mitenkään helpota tilannetta. Kun testaajalle maksetaan testaustuloksista ja järjestelmätoimittaja menettää rahaa korjatessaan ilman lisämaksua ja molemmat toimittajat koittavat optimoida itselleen mahdollisimman suuren ja merkittävän osuuden kokonaisuudesta, saadaan aikaan lähinnä kaaosta ja taistelua.

Pitkän vuodatuksen jälkeen haluan vielä kertoa, että olen kokenut myös jotain hyvää. Edellisen työnantajani palveluksessa yhdessä projektissa (ehdin tehdä 2,5 vuoteen viittä projektia tuotantoon saakka) teimme erittäin ammattimaisen 30 päivän hyväksymistestauksen ja teimme kaikkemme löytääksemme virheitä ja muutospyyntöjä. Emme onnistuneet. Järjestelmä meni tuotantoon edellä aikataulustaan ja alle sovitun budjettinsa. Avain onnistumiseen, väittäisin, oli erinomainen yhteistyö asiakkaan eri roolien sekä toimittajan eri roolien välillä. Testauksen yhteisissä viikkopalavereissa käytettiin 30 minuuttia viikossa erittäin avoimeen vuorovaikutukseen ja pieleen menevien asioiden veikkailuun, joilla asiakkaan tukemana toimittajan toteuttajat tekivät erinomaisen järjestelmämuutoksen, toimittajan testaajat testasivat ja korjauttivat rajoitteet suhteessa tarpeeseen ja viestivät erinomaisesti toteuttajien kanssa teknisellä tasolla. Taustalla onnistumisessa oli mielestäni puitteet: projekti myytiin meille hinnalla, joka ei ollut toimittajalle kuristuspanta. Rinnakkaisprojekti, joka oli laajuudeltaan karkeasti kaksinkertainen myytiin 2/3 tämän onnistuneen projektin hinnasta. Tarinasta lienee selvää, että tämä alihinnoiteltu projekti oli molemmin puolin paljon työllistävämpi ja työilmapiiri ei koskaan saavuttanut samaa hyvää tasoa. Testaustaidoissa ja neuvottelutaidoissa oli toimittajaorganisaation nimetyissä henkilöissä myös suuri ero.

Buginen järjestelmä voi olla toimittajalle rahasampo, ja minun silmiini monet suurien toimittajien menetelmistöistä optimoivat tätä. Mutta vikaa on myös asiakkaissa. Mitä jos asiakkaat tyytyisivät time-and-material -sopimukseen, siihen että riskiä ei lopulta voikaan siirtää ilman merkittävää omaa lisäkustannusta toimittajalle ja laittaisivat tarkistuspisteitä kalenteriin useammin. Ja se ei silti estä sopimasta tavoitehintaa ja palkkio/riskisummaa, jolla projektin joustot hoidetaan. Niin, kuulostaa uhkaavasti suositukselta ketterien menetelmien suuntaan - etenkin yhdistettynä tuohon roolipohjaisen siiloutumisen naurettavuuteen jossa kahden töihin tarvitaan kymmenen spesialistia välttelemään vastuita.

Joulukalenteritestausta muuttuvassa ympäristössä

Intouduin tänään testitapauksia kouluttaessani uuteen vertauskuvaan selittäessäni testauksen haasteita ja dynamiikkaa. Joulunajan uhkaavasti lähestyessä meidän perheessä on alettu kovasti himoitsemaan joulukalenteria hyvissä ajoin. Kokemus taas muistuttaa, että meidän perheessä on pahoja tapoja muuttaa hyvissä ajoin hankitun suklaajoulukalenterin tarkoitettua tilaa niin että jotenkin kummasti osasta luukkuja katoaa se suklaapala, luukku sulkeutuu mahdollisimman huomiota herättämättömästi ja pettymys kadonneesta suklaasta iskee sitten joinain joulukuun päivinä.

Tälläisen kevyesti rosmotun suklaakalenterin tilanteen selvittelyssä on paljon yhtymäkohtia testaukseen. Minua oikeastaan kiinnostaisi osua vain niihin luukkuihin joista suklaa on kadonnut, mutta kun sitä ei ulkopuolelle huomaa. Kun luukkuja on katettavaksi vain 24, kaikkien avaaminen on tietysti mahdollista. Asiaa kuitenkin voisi lähestyä myös riskipohjaisesti, koittaen tunnistaa vääntyneitä kulmia tai helposti avattavia luukkuja.

Kun luukkuja availee, luukun avaaminen vie sen oman lyhyen aikansa. Kun luukunavaustesti onnistuu löytämään bugin, setvimiseen liittyvät toimet vievät merkittävästi enempi. Korjauksen jälkeen pitää vielä vahdata että korjaus on toiminut ja pysyy toimineena - tilanne kun meidän kalentereissa on varsin dynaaminen.

Jos testauksessa varaa aikaa 24 * avaamisaika, taustaolettama on ettei setvittävää löydy tai toistotarvetta ole. Kuitenkin bugeja etsiessä testausbudjettiin on laskettava virheen raportointiaika (että muutkin tietää mistä se suklaa puuttui) ja uudelleentestaus virheen korjauksen jälkeen. Jos kaikki palat olisivat kadoksissa - näin pahaa tilannetta ei vielä ole tullut vastaan - testaus veisi 48 avaamisaikayksikköä ja 24 raportointiaikayksikköä.

Kun kattavuus näin yksiulotteisesti voidaan kuvata, elämä on vielä testausta paljon helpompaa. Niin että testaukseen verratessa voisi sitten vielä ajatella että kyseessä on monikerroksinen kalenteri, jossa suklaapala voi olla kadoksissa mistä vaan suunnalta, ja että aika kaikkien luukkujen avaamiseen ei vain riitä, joten jollain riskipohjaisella periaatteella asiaa voi haarukoida.

Poimimani opit IIR:n Testing Forumista

Jaoin erilaisten pienten porukoiden kanssa sähköpostilla poimintojani ja tulkintojani IIR:n Testing Forum -seminaarista viime viikolta. Pitkät piuhat, tajusin julkisissa liikennevälineissä ikkunasta tuijotellessani (luovia hetkiä...) että voisi sen tietysti ilman enempää selitystä jakaa näinkin.

Samat saatesanat kuin muillekin joille sen pienessä piirissä laitoin: saa kysyä että mitä ihmettä jollain tarkotan. Tulkintavirheet ovat omiani, saatan kuulla mitä sattuu kun sille päälle satun.

Pirkko Lankinen, TeliaSonera: Best in Class IT
- laitettu laatumenetelmistöä järjestykseen merkittävällä investoinnilla, erityisesti roolimäärittelyjä ja incident/problem/change management –rajapintoja.
- Accenture ollut arvioimassa kypsyyttä, mielenkiintoinen lähinnä esitetty vertailu jossa Banking & Finance –sektori oli varsin heikko organisaatiolleen tarjoaman tuen kypsyydessä
- merkittävänä motivaattorina kaukoulkoistus, josta saatu kustannussäästöjä

Vasco Duarte, Nokia: How Testing Can Revolutionize our R&D organizations?
- Hauskasti tuotu esiin suomen ja kiinan kustannusero: 9.4 kertaa kalliimpaa suomessa
- Tarvittava tuottavuusparannus (10x) mahdollinen paradigmamuutoksella --> ketterät menetelmät vaikkei sanaa kertaakaan mainittu esityksessä
- Havainnollisti hienosti hiljaisen tiedon siirtämisen tärkeyttä ohjelmistoprojekteissa - ”handover loses implicit knowledge”
- Perusteli ensimmäisen puhujan kumoon sanomatta sitä suoraan: roolipohjaisuus luo handovereita, kun jokainen hoitaa omaa tonttiaan.
- Testaus ei ole sama kuin tarkastaminen. Testaus tuottaa myös uutta tietoa, vaatimuksia.
- Määrittely ei ole tulos (output), se on muistin tuki (refresher)

Jani Haapio, NSN: Miten karsia turha testaus pois, ja löytää testauksen ydinkohdat?
- Siirrytty 1,5 vuotta sitten ketteriin menetelmiin, suuria muutoksia testauksen organisoinnille
- Lyhennetty, aikarajattu kokonaisuuden testaus pakottanut priorisointikäytäntöihin joita olisi tarvittu ennenkin. Priorisointi 3 kk välein yhdessä asiakkaan kanssa.
- 3000 toimintotestiä, 200 järjestelmätestiä. Priorisointi testitapauksille ja painotukset laatukriteereille.
- Tutkiva testitapaussuunnittelu: testit syntyvät lopuksi tulevalle muistin tueksi, motivaationa erityisesti työn siirtely useiden paikkakuntien/maiden välillä ja vastuu tukemisesta siirron jälkeen jos ei dokumentointia riittävästi. ”Kysymyksiä vanhasta työstä ei budjetoida”
- Valmiin määritelmälle Intian kehitystiimien kanssa vaadittu että dokumentaatio on sovitussa paikassa, helposti unohtunut levynkulmalle josta ei löydy pyydettäessä

Jouni Koivuneva, VR-yhtymä: Miten laadunvarmistus toimii, kun mukana on useita rajapintoja ja toimittajia
- Case, jossa kiinnitettynä lyhyt aikataulu suhteessa muutosten laajuuteen. Muutokset websivujen ulkoasuun: kuvat, värit, fontit, ei sisältömuutoksia.
- Oppeina tiukat rajaukset mitä ei saa tehdä ja yksilön sankarillinen suoritus
- Huvittavia tarinoita: Toimittajan suuresta työmäärästä katosi merkittävä osuus haastamalla että itse tekee jonkin osan. Puhujalla ajatus siitä että toimittajalla työmäärät määräytyvät asiakkaan maksukyvyn, eikä tehtävän työn perusteella
- Keskeisin oppi: aikataulua pitää laskea lopusta päin ja karsia laajuutta ajoissa.

Erkki Pöyhönen, Tieto: Hyväksymistestauksen haasteita
- Erilaisia organisointitapoja, joskus toimittaja hoitaa hyväksymistestauksen, joskus asiakas testaa toimittajan testitapauksilla.
- Keskusteltiin kovasti toimittajien etiikasta jos ei ohjaa asiakasta oikeaan ja tarkoituksenmukaiseen suuntaan

Tuula Pääkkönen, Nokia: Pohdintoja testaajan ammattitaidon kehittämisestä ja testausverkostoista
- Testaukseen päädytään monenlaisesta suunnasta, ja kasvutarpeet ovat yhtä moninaisia
- Sertifiointimalleja on paljon. Koulutustakin on saatavilla yhä enemmän, jopa osana perustutkintoja.

Olli-Pekka Puolitaival, VTT: Mallipohjainen testaus
- Piirretään kuvia siitä miten ohjelmistoa käytetään, ja luodaan automaattisesti testitapaukset, vältetään testien kirjoittaminen yksityiskohtaisesti
- Ylläpidon etuja korostettiin: mallin muuttaminen helpompaa kuin skriptien

Mika Katara, TTY: Älypuhelinsovellusten mallipohjainen käyttöliittymätestaus
- Testattu useita markkinoilla olevia puhelinsovelluksia, joista löydetty merkittäviä virheitä määrällisesti ja sisällöllisesti – testaus käyttöliittymän kautta
- Yhdistetty loki kameralla otettuun kuvaan tekstityksellä: pitkien ketjujen analysointi vaatii tukea joka ei pakota suorittamaan testiä uudelleen
- Löytää erityisesti toiminnallisuuksien rinnakkaisuuden ongelmia pitkäkestoisessa käytössä (luotettavuustestaus)
- Työkalusetti avoimen lähdekoodin tarttumattomalla lisenssillä saatavilla, hakevat myös yrityskumppaneita
- Omia pohdintoja:
o mallinnuksessa jatkokäytön arvon oltava hidastumista suurempi
--> dokumentointi, todisteet – tarvitaanko oikeasti?
--> bugien toistaminen
--> uudet virheet (pitkäkestoinen käyttö, rinnakkaisuus)
o mallinnuksen vaatima analysointi vaikuttaa eri tavalla eri ihmisiin
--> fokuksen supistuminen
--> kurinalaisuuden lisääntyminen, tavoitteellisuus
--> tekniikkaan ”hukkuminen”, ongelmat työkalujen kanssa

Tero Vuorenmaa, Softability & Matti Antila, Microsoft: Testaus ja laadunvarmistus osana tuotteen elinkaaren hallintaa Visual Studio ja Team Foundation Server –ratkaisussa
- Microsoftilla on nyt myös testaajan työkalut, vastaavat kuin Quality Center
- Elinkaaren hallinta tarkoittaa sitä että muistetaan että ensimmäinen projekti on vasta alku järjestelmän olemassaololle, kustannuksista suuri osa nk. ylläpitovaiheessa

Elina Partanen, Aktia: Tietoturvan huomioiminen verkkopalveluiden testausvaiheissa
- Hyödynnetty eri rooleja tietoturvatestaamiseen oman organisaation rajallisuus huomioiden: testaajat huomioivat toiminnallisuutta, toteuttajat rakentavat ja testaavat sovituin pelisäännöin tietoturvaa osana yksikkötestejä, ammattimainen tietoturva-auditointi kerran vuodessa
- haasteena ollut erityisesti ylläpito ja pienkehitys, joissa helposti unohtunut perushyökkäysten huomiointi
- Tykästyneet Burbsuiteen, pitäisi varmaan joskus huvikseen vilkuilla
- Vaadittua toimintaa tuetaan ohjein ja koulutuksin: asiakas tilaa toimittajan jokaisen kehittäjän kustannuksellaan koulutukseen ja maksaa koulutustunneista (4 h / hlö)

Blogin kirjoituksen haasteista

Kirjoitteluni aiheet tuntuvat pyörivän erilaisten kriisinpoikasten ympärillä... Tällä kertaa inspiraationa aiempaan kirjoitelmaani tullut kommentti siitä että eikös blogeja enää lueta ja kommentoida.

Keräsin alkuvuodesta listan suomenkielisiä testausblogeja. Olen säännöllisen epäsäännöllisesti surffailut näitä läpi, ja huomannut että enimmäksen trendi tuntuu olevan että alkuun jaksetaan ja sitten kadotaan. Toki löytyy ajatonta tekstiä, josta voisi jatkaa keskustelua vaikka kuinka pitkään alustuksen tai aloituksen jälkeen. Toisaalta taas asioista jotenkin ajattelee keskusteltavan tuoreeltaan.

Huvittavaa sinänsä, mutta minun bloggaamisestani hävisi sekin vähä energia ja aika kun ensin kirjoittelin hetken testausOSYn linkedin-palstalla ja sitten hurahdin kevyesti twitteriin. Tosiasia kuitenkin on että ajan ollessa rajallinen luonnonvara 160 merkkiä testauksesta päivässä on aika paljon helpompaa kuin oikeasti jonkin tarinan kirjoittaminen.

Lisäksi olisi yksinkertaisesti helpompaa, jos useampi kirjoittaisi samaan blogiin, niin ei tarttisi surffailla ihan niin moneen suuntaan.

Pienenä huvittavana yksityiskohtana: minulla on parikymmentä aloitettua blogijuttua, joita en ole suoriutunut kirjoittamaan otsikkoa ja paria riviä pidemmälle... Joskus vielä - ihan kohta. Mutta ensin, vielä muutama hyvä tiivistelmä testisuunnittelun erityispiirteistä uudelle lempitestaussektorilleni.

Testauspäällikkökriisi

Huomaan toistuvasti palaavani pienen turhautumisen tunteen kanssa nykyiseen titteliini: "testauspäällikkö". Kirjoittelin aiemmin siitä kuinka kierolta tuntuu, että testaajasta tulee testauspäällikkö ja toteuttajasta arkkitehti. Edelleen päällikkyys tuntuu tarpeettomalta ja väärään suuntaan ohjaavalta.

Muistan lukeneeni jotain trendilistaa lempiguruiltani, jossa yhtenä trendinä mainittiin että projektinhallinta ja testauksenhallinta yhdistyvät tulevaisuudessa. Testaus jää erikseen, eriytyy, ehkä jopa löytää paikkansa - näin ainakin itse ajattelen.

Testauspäällikkönä minun odotetaan - ulkopuolelta - olevan hallinnollisesti suuntautunut. Minun odotetaan suunnittelevan, ohjaavan, tuottavan mittareita. Ja joku muu onnekas saa tehdä lempityötäni, testausta. Voin mentoroida, opastaa, valmentaa ja kannustaa. Rohkaista ja antaa vinkkejä. Voin vähän tehdä itsekin, mutta odotukset ovat vahvasti muualla.

Sanojen ei pitäisi sitoa, eikä vaivata. Koen silti että jopa aivan samalla työkuvalla, olisin aina mieluummin "testausasiantuntija" kuin päällikkö.

Minun kolleegani, projektipäälliköt tiimissäni, ovat loistavia. Selviäisivät testausasioista siinä kuin mistä tahansa muustakin. Jostain syystä testauspäällikön olemassa olo vaikuttaa enemmän jopa itsetuntoa alentavasti, kun eivät sitten ihan samalla tasolla osaa jokaista detaljia testauksesta.

Odotan innolla ensi viikkoa - saan kolleegan, jolta odotan tukea pohdinnassa tulevasta testauspäällikköroolista.

Kuilu vaatimusten ja toimivan välillä

Vietin taas pari päivää opastaen mukavaa porukkaa testitapausten suunnittelussa. Tästä porukasta ja keskusteluista minulle jäi erityisesti pohdittavaksi, että kuinka yleistä lopulta on, että vaatimukset rajaavat testausta kohtuuttomalla tavalla.

Cem Kanerin materiaaleja muistinvaraisesti lainaten, vaatimukset ovat fiktiota. Parhaimmillaan ne ovat käyttökelpoisia, hyödyllisiä, avuksi.

Jäin pohtimaan, että onko tämä yksi niitä keskeisiä eroja tuoteliiketoiminnan ja projektiliiketoiminnan välillä. Suppealla otoksella kummastakin ei tietysti halua vetää liian pitkälle meneviä johtopäätöksiä, mutta tuntuma on, että projektien tilaamisessa ja toimittamisessa on jotain, joka ohjaa tarpeettomassa määrin siihen, että asiakkaan tarpeita ei koiteta täyttää, vaan vain asioita joita on "vaadittu". Testaajaa jopa kielletään testaamasta mitään muuta kuin vaatimuksissa mainittuja asioita. Muita asioita testataan sitten kun tämän toimituksen osalta ollaan turvassa (aikataulussa / luvatussa laajuudessa), ja asiakas tajuaa että ei saanutkaan täytettyä tarvettaan, mutta vielä uskoo siihen että oma vikahan se toki oli kun ei osannut vaatia.

Jokseenkin hahmotan, että tokihan jokaisesta tunnista pitää saada laskuttaa. Mitta sitä en hahmota, että voidaanko ihan vakavissaan lähteä siitä, että tehtäisiin projekti, joka täyttää vaatimukset ilman väliä siitä millaista tarvetta vaatimukset olivat kuvaavinaan. Kai se on sinänsä luonnollinen vastareaktio muodissa oleville kiinteähintaisille toimituksille.

Viksumman testaamisen hidasteita asiakas-toimittajamaailmassa

Olen viime aikoina miettinyt varsin paljon taas tutkivaa testausta, asiakas-toimittajaprojektien näkökulmasta. Matkalla voi olla muutamia hidasteita:

- suunnittelun ja testaamisen erilainen hinnoittelu. Jos sattuu olemaan tilanne, jossa testaustyötä hinnoitellaan eri lailla riippuen sen vaativuudesta ja on luokiteltu, että suunnittelu on vaativaa ja testaaminen ei, tiessä on kyllä pieni kuoppa. Osittain tämä luokittelu kerjää sitä että tehtävät annetaan eri henkilöille, osittain sitä että valmistaudutaan mahdollisimman paljon, jopa yli sen hyödyllisen ja oikeasti tarpeellisen. Erityisesti haasteelliseksi muodostuu se että haluaisin sen halvemmalla hinnalla tehtävän työn sisältävän merkittävässä määrin nk. kalliimman hinnan töitä. Oikeasti noissa tilanteissa kyllä sanotaan että 100 tuntia testaukseen liittyvää työtä olisi keskimäärin jotain kahden hinnan väliltä.

- vaatimukset. Elisabeth Hendricksonilla oli jossain esityksessään oivaltava kommentti siitä, että lähes jokainen bugi on lopulta - toteuttajansa näkökulmasta - muutos vaatimuksiin. Jos ei ole ajateltu yllättävää vuorovaikutusta käyttöliittymän kanssa, vääränlaista syötettä naapuriohjelmalta tai että joku voisi joskus käydä kahvilla kesken tekemisen ja ohjelma ei tässä tilanteessa toimi, onhan se jollain tapaa perusteltua sanoa, että pyydetään uusia asioita. Mitä tarkempaan vaatimusdetaljiin mennään - jopa pseudokoodaukseen - sitä sidotummaksi suhteessa vaatimuksiin muuttuvat myös testaajan kädet.

- suojautumistarve. Varsin monesti sopimukseen ja projektisuunnitelmiin on osattu kirjata, että testit toimitetaan ennakkoon, ja toimittaja varaa luonnollisesti itsekin aikaa varmistaakseen, että luovutuksen tai hyväksynnän testit läpäistään. Se on paljon helpompaa toimittajan näkökulmassa, jos kerrotaan mahdollisimman täsmällisesti mitä aiotaan kokeilla ja miten. Niinpä asiakkaita tulee helposti ohjattu pois tutkivasta testauksesta, enemmän ennakkoon kirjattuun tyyliin.

- ajoitukset. Kun jostain on sovittu hankinnan alkuun, tuntuu että muuttaminen on tuskallista. Prosesseja pitäisi kehittää projektien ulkopuolella, erillisissä projekteissa, etteivät sotkisi tämän suunnitelmia ja työmääriä. Ja kun testausta tupataan valmistelemaan vasta kun projektin puitteet muuten on sovittu, aika on harvoin suoraan oikea.

Hidasteita, ei esteitä. Taidan alkaa miettiä seuraavaksi hyväksymistestausprosessia, ja siihen rakenteita, jotka sallivat ja tukevat fiksua testaamista.

Hyväksymistestauksen dokumentaation jakaminen toimittajalle

Keväällä IIR:n seminaarissa muutamassakin puheenvuorossa pohdittiin hyväksymistestauspuheenvuorojen osalta periaatetta dokumentaation jakelussa toimittajalle.

Testitapausten osalta silloin taisi vallitseva käsitys olla, että parempi olla antamatta. Syyt olivat kaiketi:
- Huoli siitä että toimittaja testaa vain näillä testeillä ja kokonaisuutena saadaan huonompaa laatua
- Riippuvuudet asiakkaan materiaaleihin aikataulullisesti sovittuina aiheuttavat tarpeettomia paineita asiakaspäässä materiaalin viimeistelyyn
- Asiakkaan materiaalin odottaminen antaa epävirallisen luvan luovuttaa oman testauksen valmistelun yrityksen kanssa ja vähentää vastuunottoa

Testitapausten osalta olen edelleen eri mieltä. Minusta ne kannattaa antaa. Parempi että edes ne toimivat, kuin että viimeisen hyväksymistestin aikana tarvitsee niistäkin huomata etteivät toimi. Kun lähtökohtaisesti lähtee siitä että testi ei ole äärimmäisen toistettava vaan lähinnä muistilistan omainen, näkisin että riskiä siitä että toimittaja kuvittelee vastuun testisuunnittelusta siirtyneen asiakaspäähän olisi hallittavissa. Ja korostetusti kannattaa varata oikeus ja mahdollisuus tutkivaan testaukseen, joka vielä entisestään täydentää suunniteltua kokonaisuutta.

Testaussuunnitelmat ovat minusta paljon haastavampi kysymys. Erityisesti nykymaailmassa missä lähestulkoon järjestelmä kuin järjestelmä koostuu eri tekijöiden osista, en aina ole ihan vakuuttunut että haluaisin avata kaikille osapuolille kaikki näkökulmat riskeihin, mitä osana hyväksymistestausta pitää pohtia. Jotkut asiat kun ovat vaan meidän organisaatiolle. Ja ainakaan minua ei kiinnosta tästä syystä että kirjaan suunnitelmaani nk. arkaluonteisia asioita ja arvioita pohjana riskiarvioilleni, kirjoittaa toista "siistittyä" suunnitelmaa. Sen osalta minusta saa riittää, että testaamme. Jos siinä on jotain minkä kertominen auttaa viestintää, pidän aiheesta mielellään silmäkkäin session. Ja sekin on tietysti lähestulkoon aina.

Paljonko testauksen pitää tuottaa hyötyä?

Vuodet testaushommissa ovat opettaneet, että testaajan tuottama lisäarvo ei ole lainkaan niin suoraviivaista, että testitapausten suunnittelun, suorituksen tai virhemäärien mittaamisella saataisiin kiinni sen tuottamasta arvosta. Testausnäkökulmalla ja testauksella on arvoa, se on hyödyllistä - usein.

Tämä ei kuitenkaan ole itsestäänselvyys. Olen aistivinani että testaus on tullut muotiin erityisesti asiakas-toimittajasuhteissa jopa siinä määrin, että koen että näissä tilanteissa vastaan on osunut kohtia, joissa testausotsikon alla tehty työ ei ehkä tuotakaan kovasti lisäarvoa.

Jos testauksessa käytetään varsin mittava työmäärä, tuotetaan kertakäyttötestitapauksia ko. projektin näkökulmaan ja katselmoidaan niitä suurella panoksella ja lopulta ei juurikaan löydetä ongelmia, voi minusta jo perustellusti miettiä että olikohan panokset oikein asetetut. Etenkin, jos jälkeen tulevat testausvaiheet osoittavat, että löydettävää kuitenkin olisi ollut.

Jos kohdalle osuu projekti, jonka osalta on perusteltua sanoa ettei se testaamalla juurikaan parane erilaisten reunaehtojen vuoksi, onko enää järkevää suositella että kuitenkin testaukseen panostetaan, ja vielä suuremmassa määrin. Vai voisiko testausihminen suositella jopa testaajien poistamista ja muiden ratkaisijoiden lisäämistä? Voisiko otos olla kattavuutta parempi tavoite hyötyjä ajatellen?

Välillä jää sellainen fiilis kaivertamaan, että erityisesti testauspalveluja tarjoavat osaoptimoivat testauksen, eivätkä ajattele testausta osana arvoketjua. Samoja tavoitteita voisi edistää halvemmilla ja tehokkaammilla keinoilla. Vai onko testausasiantuntijan kädet tosiaan niin sidottu ettei lähimaailmaa saa nytkäytettyä lähemmäs raiteita? En usko.

Me ollaan testaajia kaikki

Jossain verkossa surffaillessani GoogleAds päätti näyttää minulle kohdistetusti mainoksen, jossa Reaktor etsi "koodaavaa pääarkkitehtiä". Paikka ei ole kyllä missään määrin minulle kohdistettu, mutta termiin liittyvä teema sattui olemaan testauspuolelta juuri pohdiskelun alla.

Jos mietitään karkeasti ohjelmistokehityksen rooleja, niitä olisi kaiketi kolme: vaatimuskaveri, toteutuskaveri ja testauskaveri. Näistä kuka vaan voisi nk. edetä urallaan hallintovaihteelle ja ryhtyä vaikka projektipäälliköksi. Toteutuskaverista tulee kuitenkin omalla vaihteellaan edetessään arkkitehti, ja testauskaverista testauspäällikkö.

Erityisesti olen ihmetellyt viime aikoina sitä, että toteuttaja joka pomppaa projektipäälliköksi ei yleensä enää kuvaa itseään koodaajana. Testaaja joka siirtyy testauspäälliköksi on hyvinkin vahvasti edelleen testaaja. Erityisesti tämä jäi minua mietityttämään sen vuoksi, että olen ollut huomaavinani, että varsin monet testausasiantuntijat eivät olekaan henkilökohtaisesti vuosikausiin testanneet. Toiset, kuten minä, testaavat kepoisasti silloin tällöin, nauttien pinnallisista mutta silti korjauskelpoisista virheistä joita rajatussa ajassa voi löytää. Koen tiettyä tuskaa, kun niin suuri osa ajasta kuluu ohjatessa, neuvotellessa, mittareita kehitellessä ja nauttien katsoessa kun toiset tekevät rakastamaani työtä hyvin. Kai se on jonkinasteista kateutta. :)

Olen vakuuttunut, että testaus on sekä taito että ajatusmalli. Taito katoaa jos työtä ei harjoita. Ajatusmalli säilyy. Taitopuolella etääntyminen on liian helppoa, kuvaten työtä edelleen kuitenkin samalla sanalla - me ollaan testaajia kaikki, nekin meistä jotka eivät ehdi muilta testaustöiltään testaamaan.

Testauksen opettaminen - onko kaikki vaan peruskursseja?

Tieturin testausseminaarissa Tieturin testauskouluttaja Teppo Heikurinen kertoi puheenvuorossaan testaajien erilaisista profiileista ja tarpeista. Osana puheenvuoroaan Teppo esitti myös varsin vahvan väitteen siitä että kaikki testauskoulutus Suomessa on vain peruskursseja, joka luonnollisesti särähti omaan testauskouluttajakorvaani. Mitä ovat perusasiat ja mikä on edistyneempää testauksessa.

James Bach on mielestäni upeasti kuvannut suuren osan testauskurssisisällöistä termillä "testing folklore" - testauksen kansantiedettä. Kerromme kursseilla tarinoita testauksesta, opimmekin tarinoiden perusteella. Itse näkisin että opimme sekä perusasioita, että syvemmälle meneviä.

Toinen suuntaus testauskursseissa on sitten yritys opettaa testaamaan, eikä vain sujuvasti puhumaan testauksesta. Tässä suuntauksessa yleensä lähdetään siitä että testaus ei tapahtu paperiopetuksella, vaan testaukselle tarvitaan asennettu kohde. Ja niiltä osin kuin opetus tapahtuu luokkahuoneessa ilman konetta, harjoituspainotteisuus kuvista ja teksteistä analysoiden on vahvoilla.

Mikä on siis peruskurssi? Mitä ovat "testauksen perusteet"? Uskoisin pääseväni ISTQB-sertifikaattia syvemmälle, ja tuntuu pahalta ajatella että koulutan 20 päivää perusteita silti asioita suuressa määrin toistamatta. Niinkin toki voi olla.

Luin Cem Kanerin materiaalia tutkivasta testausautomaatiosta (exploratory test automation). Materiaalissa johdantona oli erinomainen jäsennys siitä että lähtien taidottomasta, edeten pikkukikkojen kautta tuottavaan ja lopulta oikeasti testausta osaavaan vaatii aikalailla erilaista koulutusta. Suhteessa tähän tunnustan: opetukseni taso on edelleen pikkukikkojen (quicktests, techniques) tasolla. Kuten Cem Kaner asian muotoili: "There are generically useful approaches to test design, like quicktests and tours and other basic techniques, but I think we add our greatest value when we apply a deeper understanding of the application. Testing instructors don’t teach this well because it takes so long to build a classroom-wide understanding of an application that is complex enough to be interesting."

Perusteissa siis mennään. Ja perusteissakin on eroja. :)

Oppeja testitapauksia vastaan

Olin viime vuonna lukenut nopeasti James Bachin esitysmateriaalin testitapauksia vastaan, ja eksyin siihen enemmän ajatuksella siivotessani kirjanmerkkejäni. Alkuperäisteos jota jäin pohtimaan löytyy täältä:
http://www.satisfice.com/presentations/againsttestcases.pdf

Erityisen viehättävä osa materiaalissa oli testauspandemiasanaleikit, 3 * OCD:
- Obsessive Case Disorder. Pakonomainen tarve uskoa ja antaa muiden uskoa että testitapausten suunnittelu on niin keskeinen aktiviteetti, että se sisältää kaiken testausajattelun ja suoritus on sitten mekaanista. Yleensähän annamme uskoa, kun ei vaan joka kerta jaksa selittää. On helpompaa sanoa että aikaa on varattava testitapausten suunnittelulle, eikä koittaa selittää että aikaa on itse asiassa varattava siihen että ehditään perehtyä vaatimusdokumentaatioon kirjattuihin lupauksiin ja olettamiin.
- Obsessive Counting Disorder. Pakonomainen tarve laskea testitapauksia, joiden laskemisella ei oikeasti ole niin suurta merkitystä. Pieni määrä ei korreloi huonon testauksen kanssa. Mutta, itse ainakin taas tänään totesin, että testitapausten laskeminen suhteessa jonkinlaiseen ideaan kattavuuskriteeristä antaa edes jonkinlaisen tuntuman siihen minkä verran lisää pitäisi vielä suunnitella / kirjata. Tarpeellista ja hyödyllistä tällä tasolla vain kun ei ole oikein vakuuttunut tekemisen otteesta muutenkaan.
- Overspecified Cases Disease. Epäjohdonmukainen pakkomielle kohdella ihmisiä automaatiorobotteina aivan liian tarkan dokumentaation myötä. Muodostuu usein sitten myös itseään toteuttavaksi ennusteeksi, suunnittelu oli jonkun muun nakki ja minä vaan kliksuttelen ja katson mitä käskettiin...

Pandemia - maailmanlaajuinen vitsaus - sinänsä ainakin minulle kolkuttelee jotain tosi tuttua...

Erinomaisia korostuksia myös siitä miksi testitapausten lukumäärään pitäisi aina suhtautua varauksella:
- eri suoritusaika muuttaa testitapausta: jos samaa asiaa katsoo kolmatta kertaa, ei varmasti tee samaa testiä, saattaa tehdä suppeampaa tai laajempaa
- testien suunnittelu on subjektiivista: vaikka sovittaisiin yhteinen muoto ja määrä, silti on vaihtelua, koska testauksen kohteet ovat erilaisia
- testaajat eivät edes noudata testitapauksia: monestihan testitapauksia kuittaillaan suoritetuksi sitten kun "tähän liittyvät vapaat tarkastelut on ehkä jo riittävässä määrin tehty". Olen joskus itsekin ihmetellyt kun viiden minuutin tarkistus kesti testaajalla kaksi viikkoa, ympärillä oli vaan aika monta asiaa jotka tähän tehtävään piti mahduttaa.
- sama testi automaation ja ihmisen suorittamana ei ole sama testi. Ihmisen päässä tapahtuu asioita joita ei voida siirtää automaatioon, mutta joskus se ei haittaa - jos se vain tiedostetaan.

Itse kirjoitan testitapauksia, periaatteella muistilistaa testattavien asioiden monipuolisuudesta. Minua vaivaa ainakin aika vahvasti tuo OCD v.2 jossa lasketaan asioita, mutta laskemisesta haen puitteita enkä absoluuttista totuutta. Ja tilanteesta riippuen tulisi laskettua vähän eri asioita, riippuen paljolti siitä mitä voi laskea puitteiden vuoksi. Testitapaukset on helpoimmasta päästä laskettavia asioita testauksessa.

Kohtuulliset odotukset testaustoimittajalle

Tehtyäni takinkäännön - edelleen uskollisena testaukselle - ohjelmistotuoteliiketoiminnasta omiin räätälöitäviin tilaustyönä hankittaviin järjestelmiin, olen jäänyt monesti pohtimaan odotuksia kohtuulliselle testaukselle.

Päivän listani on asioita jotka ovat minusta kovin kohtuullisia, mutta jättävät silti miettimään:

- Testaaminen asiakasnäkökulmasta
Tuoteliiketoiminnassa oli selvää, että järjestelmätestausporukka epäonnistuu pahasti, jos hyvin tehdyt vaatimusmäärittelyt otetaan liian kirjaimellisesti, eikä edes koiteta merkittävässä määrin huomioida asiakkaan / käyttäjän hiljaisia vaatimuksia sekä kaikkea sitä teknistä nippelinappelitietoa, joka voi jäädä vaatimusten ja määrittelyjen väliin. Räätälöitävien järjestelmien peruselementti tuntuisi olevan "vaatimusmäärittely" joka kuvaa tilatun järjestelmän, jota tarkennetaan ja jonka rivien väliin jääneet yksityiskohdat ovat aina muutospyyntöjä. Ja eivät löydy toimittajan testauksissa. Niinpä asiakkaan testaajien ja toimittajan testaajien välillä on kuilu, joka korostuu kahdenlaisessa hyväksymistestauksessa: on aivan eri asia suorittaa sopimushyväksymistestausta kuin tuotantoonhyväksymistestausta - valitettavasti.

- Näkyvyys ja raportointi projektiin testauksen kautta
Tuoteliiketoiminnassa tuntui varsin selkeältä katsoa tehtävää testausta kokonaisuutena mittarein. Työmäärän kulumisen lisäksi kiinnosti testauksella saatu lisäarvo, niin kattavuuden kuin tulostenkin osalta. Räätälöityjen maailmassa en pidä itsestään selvänä että testauksesta saisi mitään muuta raporttia kuin että budjetoidut tunnit nyt tuli käytettyä. Aiemmassa elämässä tästä minulla onkin ollut tosi ikäviä kokemuksia, ja toivon että ne kokemukset eivät päätyisi värittämään tulevaisuutta toistuvin kaavoin.

- Mallipohjan täyttäminen ajatuksella
Kun testaussuunnitelmassa pitää miettiä mallipohjan ohjauksella jotain, sitä jotenkin ajattelisi ja kuvittelisi että viime kädessä sisällöllä on merkitystä. Muoto on tärkeä kun luetaan rutiininomaisesti toistuvia suunnitelmia ja halutaan katsoa vastaavat teemat vastaavassa järjestyksessä, mutta silloinkin hyvän ja heikon suunnitelman erottaa ajattelu ja asioiden huomioiminen eikä vaan vakioliturgian kirjaaminen.

- Riskienhallinta - testauksen edellytykset voivat olla projektin tuho
Tuoteliiketoiminnan jälkeen on vaikeaa myös nähdä syitä siihen että testauksen on arvostussyistä oltava oma organisaationosansa tai että testaus pitää ehdottomasti projektoida omana kokonaisuutenaan, että saadaan kertoa realistista tilannetta kokeilluista ja ei-toimivista asioista. Minua ei henkilökohtaisesti yhtään lohduta että olin oikeassa kun sanoin että testaus voi voi tapahtua kahdessa viikossa jos testausympäristö ei toimi, jos siinä vaiheessa projekti on myöhässä eikä ole tullut edes ehdotettua vaihtoehtoista jonkinasteista lisäkustannusta toipumissuunnitelmaksi niille keskeisimmille riskeille.

Listan viimeistä pidän jo vähän edistyneempänä kamana, mutta muita ihan peruskaurana. Saas nähdä miten mieli vielä muuttuu...