Category: Ohjelmistotestaus

Suurella todennäköisyydellä sinullakin on ongelma itämässä. Sellainen sokeaan pisteeseen piiloutunut virhe, jota on kovin vaikea huomata näin läheltä.

Mutta miten sellaisen saisi vältettyä?

Kaikki alkaa meille testaajille tutusta taidosta. Uteliaisuus. Kun on kyselyikä päällä päivittäin, voi vältää monta monttua. Toki seuraavaksi on osattava se vaikeampi taito. Kuuntelu.

Oppia ja oivalluksia on kyllä jaossa niitä etsivälle. Esimerkiksi Kollegat, kaverit ja google tarjoilevat sellaisia päivittäin, jos vain osaamme kysyä ja käsitellä vastauksia viisaudella.

Ensisijainen pulmamme ei tietenkään ole tiedon saatavuudessa, sillä sitä ei ole koskaan ihmiskunnan tallennetussa historiassa ollut enempää saatavilla.

Tsekkaan Appstoren top-200 suosituinta appsia säännöllisesti ja joskus käyn Googlen kaupassakin. Uusin tulokas yhteisöpalveluissa oli Sarahah. Tänään se oli yhteisöpalveluissa toiseksi suosituin lataus. Sovelluksen idea on tarjota ystäville rehellinen palautekanava asioihin, jotka he huomaavat etäältä.

Kyse on enimmäkseen rohkeudesta antautua tosiasioille.

En minä osaa kaikkea. Tuntuu etten tiedä työstäni riittävästi, etten osaa oikeita asioita. Pelkään päivittäin, että toistaitoisuuteni paljastuu. Entä antamani asiat ovat yhdentekeviä. Olen yhä niin kovin kesken.

Vasta, kun oppii myöntämään sen maailmalle, pelikenttä alkaa avautua parannuksille.

Kysymisen taito on hyödytön ilman rohkeutta osua oikeisiin kysymyksiin ja kykyä kuunnella.

Esimies heittää pallon Leenalle. ”Muistatko miten tämä ongelma ratkaistiin aiemmin?” Leena muistaa. ”Palastelemalla ongelma näin, ja keskittymällä kokonaisuuden sijaan yksityiskohtiin.”

Vuotta myöhemmin Leena on jo johtaja, ja jakaa muistamaansa ratkaisua eteenpäin firman uudelle ukolle, Jarkolle.

Jarkko saa tietämättään maistiaisen yrityksen kulttuurista. Aamujen karttuessa hän huomaa: iso lafka – iso kääntösäde. Kulttuurin kuuluu pysyä lestissään, luomatta uusia muistijälkiä.

On toki totta, että rutiini ei ole huono asia. Se luo turvallisuutta ja viisaissa käsissä myös laadukkaita lopputuloksia. Vaarana on kuitenkin pölyn kasautuminen ja rutiinien rakentaminen vääriin asioihin. Tupakkakin on puoliksi tapa-addiktio.

Kokemukseta voin kertoa, että uusi silmäpari löytää uusia bugeja poikkeuksetta paikoista, missä tottumus on alkanut tehdä testaajan työtä.

Tuloksellinen testaustyö edellyttää muistista tulvivien ehdollistettujen rutiinien pistämistä päreiksi. Tottumuksella on tuhoisa vaikutus, sillä sokeat pisteesi piilottavat parhaat bugit taitavasti.

Siksi kysynkin. Olisiko joskus paikallaan sekoittaa tiimiisi dynamiikka? Ihan vaikka red alert ei olisikaan päällä?

Rikkokaa rutiineja. Jalostakaa muistijälkiä oikealla ajattelua. Yhdistäkää tuttuja asioita toisiinsa tuoreilla tavoilla ja myöhemmin saatatte vastata vieläkin viisaammin tähän.

Onko Pavlovin koira tiiminne työjuhta vai toimari?

Tuttu tunnari ja Janne Kataja. Priceless.

A:n paikalle istuu luotettava, toimintavarma mutta räätälöintiä karttava IT-järjestelmätoimittaja. B:n jakkaralle tulee rinta kaarella kaiken mahdollistava rajapintojen kunkku. C:n toinen nimi on ERP.

Sermin takana jännityksestä hikoaa ostaja-X. Unelmana on liitto, joka olisi pelkkää yläpystyn hyppelyä. Vain riemua onnistumisesta. Ei ensikohtaamisen vaivaantunutta hapuilua tai ujoja katseita. Kuka sellaista haluaa, kun voi hypätä suoraan 2. pesälle?!

Testaaminen ja koekäyttö on työlästä ja kallistakin.

A, B ja C ovat jokainen ammattilaisia alallaan, ja kukin hyviä valintoja heidän kaistallaan kulkeville. Mutta osuuko X:n valinta hänelle parhaaseen vaihtoehtoon? Voiko sitä tietää, ennen kuin yhteiseloa on eletty lounaittein ja peruuttamattoman Napakymppi-matkan verran?

1. Kanadan valtion palkanmaksujärjestelmän uusiminen 3 miljoonasta 126 miljoonaan.
2. Kajaanin kaupungin IT-hanke miljoonasta 3,5 miljoonaan.
3. Oriola: SAP sakkasi, hintalappu tuntematon (ainakin toistaiseksi).

Onko niin, että rajapintaa ja palikkaa alkaa löytyä jo niin paljon, että on mahdotonta saada aikaan liiketoimintaa palveleva paketti? Wiseguy voisi osoitella sormella syyllisiä. Mutta olisiko kuitenkin niin, että vika ei ole IT-hankkeiden tuottajassa eikä edes tilaajassa? Vuosien saatossa järjestelmiin on kelattu kerroksia kerrosten päälle. Kukin toimija tekee parhaansa mahdottomassa tilanteessa.

Ei ole vahinko, että törmään yhä useammin tuotekehitystiimeihin, jotka ovat päättäneet jättää vuosikymmenen painolastin taakseen ja koodata tuotteensa uudestaan. Se on paitsi halvin, myös nopein ratkaisu.

Uuden järjestelmän sovitus ja käyttöönotto vaatii paljon. Se vaatii asiaan vihkiytymistä ja jämäkkää otetta erityisesti ostajalta.

Entä, jos testaaja olisi X:n oljenkorsi matkalla miljonääriksi? 50-50, ja kilauta kaverille 😀

Istuin kahvilassa Lontoossa keväällä, ja seurasin kadun toisella puolella hääräävää ravintolan sisäänheittäjää. Ilmeisesti ranskalainen kaveri. Vekkulia porukkaa sanon minä, ja tarkkasilmäistä työssään.

Nainen askeleen edellä: Seurana oikea herrasmies. Tai lapanen. Vaikea sanoa. Mutta sisäänheittäjä oli tilanteen tasalla. Hän astui askelen edelle pariskunnasta ja heitti vasemman olkansa yli naiselle jotain, mikä nauratti kaikkia. Kaksi askelta ja stoppi. Pariskunta tsekkaa menua ja suostuu sisään. The game is on!

Kolmestaan: Isä asteli autotien puolella, äiti näyteikkunoiden ja lapsi määräsi tahdin vanhempien välissä. Sujuva sisäänheittäjä polvistui lapsen kohdalle. Pudotti kai taskussa odottaneen pallon avatakseen leikkisästi keskustelun perheen pikkupomon kanssa. And he scores once more!

Grande finale: Viimeinen se vasta vaikea pala olikin. Nainen näytti sitruunan syöneeltä. Mies tyrkyttäjiin kyllästyneeltä. Molemmat hiplasivat kännykkää ja tallustivat tasatahtia eteenpäin. Pettämätön pelisilmä ja keskustelunavaus houkuttivat parin kadun varressa komeilevan menun äärelle “ihan vaan vilkaisemaan”.

Hämmästelin suu auki, kun tarkkasilmäinen asiakastuntija kaivoi myös kännykän esiin ja lähti leikkiin mukaan. TripAdvisor taisi tehdä tehtävänsä. Kolme maalia kolmessa minuutissa. Olin vaikuttunut.

Ranskalainen sisäänheittäjä menestyy, sillä hän ei pelaa peliä päästäkseen vetämään omaa myyntipuhetta. Hän keskittyy kahteen asiaan ohi itsensä. Lopputulokseen ja vastaantulijaan.

Ketä sinä palvelet? Tunnetko jo asiakkaasi ja tavoitteesi, kuin ranskalainen sisäänheittäjä?

Näytä minulle miten saadaan muna pystyyn tähän pöydälle.

Tarina kertoo Kolumbuksen sanoneen nuo sanat tuodessaan kananmunan rahoittajatapaamiseen. Rahoittajat eivät nimittäin uskoneet miehen visioon uusien maailmojen löytämisestä. Pitivät mahdottomana.

Kukin rahoittaja vuorollaan sai yrittää munan pystyttämistä pöydälle. Mutta turhaan. Kananmuna kaatui kyljelleen joka kerta.

Lopulta tuli Kolumbuksen vuoro. Ukko kopautti munan napakasti pöydän pintaan. Siihen se jäi. Pystyyn, kuten Kolumbus oli luvannut. Jälkikäteen tarkasteltuna on tietysti aivan ilmeistä, miten temppu tehdään. Tämän Kolumbuskin teki rahoittajille selväksi yhdellä ranneliikkeellä.

Perässä hiihtäminen on helppoa ja riskitöntä. Vaikutusta on vaikea luoda toisen varjossa piileskelemällä.

Todellisen gurun tehtävä on kulkea se polku, jota tuskin kukaan on vielä tallannut. Hänen tehtävänsä on näyttää tie tiheikön läpi, jotta muut saisivat seurata. Mutta mitä se vaatisi, että ehkä ensikerralla sinä kulkisit edeltä?

Etsi oma munasi.

Tietysti testaus on työ, joka perustuu vasteeseen.

Testaus on jatkuva tanssi kekseliästä tutkimusta ja sitä seuraavaa vastetta. Meille testaajille se on vain luonnollista, sillä olemmehan aika teknisesti painottunutta väkeä.

Löytämämme bugit ja tuottamamme tieto ovat vastetta jota eniten etsimme. Johon kiinnitämme huomiomme aina, kun se on mahdollista.

Mutta entä, jos kukaan ei välitä? Entä, jos työmme tulokset ovat upeita, mutta kenenkään viisari ei värähdä niiden äärellä?

Tuloksemme joutavat romukoppaan, jos kukaan ei ole valmis muutamaan ajatuksiaan tai toimintaansa niiden perusteella?

Tuohon tuskalliseen tulokseen on kaksi todennäköistä syytä.

1. Työn tulokset ovat niin turhanpäiväisiä, että ketään ei ihan oikeasti kiinnosta.
2. Työn tulokset ovat tärkeitä, mutta me emme vielä osaa kertoa niistä tarttuvalla tavalla.

Kummassakin tapauksessa kannattaa ensin lopettaa ja sitten katsoa mitä tai miten tekemällä vastetta alkaa syntyä. Vasteperusteinen testaus ei keskity vasteeseen tuotteessa, siinä keskitymme vasteeseen ihmisissä, ketä saamme palvella. Ole utelias. Kiinnitä huomiota vasteeseen ympärilläsi ei edessäsi.

Työsi on vain niin hyvää kuin sen tuottama vaste kollegoissa, asiakkaissa ja esimiehissä.

Aloitan aamuni toivottamalla Sirille hyvää huomenta. Siri tietää, että silloin on aika kytkeä makkariin heräämisvalo ja laittaa kirkkaat keittiöön. Siri osaa myös napsauttaa energiset aamubiisit pyörimään telkusta.

Tunnen oloni ihan Tony Starkiksi, vaikka Jarvis yhä onkin pikkuisen viisaampi apuri niissä Avengers -elokuvissa.

Televisio löi peruuttamattomasti radion mainosinvestoinneissa jo vuonna 1950. Printtimedia on ollut pulassa jo 10 vuotta, kiitos digitalisaation. Patsaaksi kivettyneiden perinteiden palvonta ei ole juuri koskaan johtanut menestymiseen. Se on johtanut murtumiseen.

Tapaan säännöllisesti testaajia konferensseissa ja koulutuksissa, jotka ilmoittavat, miten tuo automaatio ei vain oikein ole oma juttu.

Tulen vähän surulliseksi. He ovat jo hypänneet junasta. Jääneet auringonlaskun alalle töihin. He ovat taatulla tiellä tarpeettomuuteen samalla tavalla kuin romanttisesti radiomainoksissa roikkuvat brandit olivat jo 50-luvulla

En sano, että riski realisoituisi vielä huomenna. Ja kuitenkin viiden vuoden päästä jäljelle jää vain yksi kysymys.

Kuka valitaan aina ensin? Ajatteleva testaaja, joka tuntee työkalunsa VAI ajatteleva testaaja, jolle automaatio ei vain oikein tunnu omalta?

Törmäsin vasta kiinnostavaan Twitter-keskusteluun. Kaksi johtavassa roolissa olevaa testausgurua pohtivat sitä, miten järjestää testaukseen liittyviä suorituskykymittareita(KPI) organisaatiolle, sillä organisaatio vaatii sellaisia.

Ihan ensimmäisenä mieleen tuli kysymys. Jos organisaatio vaatii sellaisia, niin tosiasiassa organisaatiossa on yksi tai muutamia ihmisiä, jotka niitä vaativat. Minua kiinnostaisi kovasti tavata heidät. Ketä he ovat?

KPI-mittareita toivovilla ihmisillä aika usein on jo olemassa valmis käsitys siitä, mitä he haluaisivat mitata ja miksi. Helpointa olisi kysyä.

Jos mitään muuta ei ole tehtävissä kuin rakentaa esitys aiheesta, suosittelen jotain yksinkertaista ja konkreettista. Esimerkiksi voisin aloittaa tekemällä kirjanpidon asioista, joiden parissa vietän enimmäkseen aikani. Tuntitason resoluutio voi olla aivan hyvä tähän tarkoitukseen.

• Valmistelen: Viritän ympäristöjä, tuotan dataa tai dokumentoin.
• Testaan: Metsästän bugeja tähän tarkoitukseen sopivalla tavalla.
• Tutkin: Havaintojeni perusteella tutkin ja raportoi virheitä.
• Aivokuolen: Istun palavereissa. Osassa minua saatetaan tarvita. Useimmissa oikeasti ei. Keräilen KPI -dataa sieltä täältä ja louhin sitä Excelissä näyttävämpään muotoon jne.

Viikon lopussa alkaa kuva hahmottua. Missä työlajissa vietän eniten ajastani ja missä sitä tulisi viettää, jotta kollegat, esimehet ja asiakkaat saisivat enemmän hyötyä irti testauksestani?

Jos enimmäkseen valmistelen ja säädän, se voi tarkoittaa että kehittäjien kanssa on syytä panostaa seuraavaksi testattavuuteen. Jos enimmäkseen tutkin ja raportoin bugeja, se voi tarkoittaa että softa ei ole kovin kypsällä tasolla. Jos istun enimmäkseen palavereissa ja kerään KPI-dataa, se voi tarkoittaa että organisaation vaatimukset eivät ole linjassa todellisten tavoitteiden kanssa.

Tiedon kerääminen voi tuntua aluksi tarpeettomalta. Mutta kuvitellaanpa tilanne, missä joudut perustelemaan työsi tulokset pomolle? Mikä olisi mittaustuloksia parempi tapa iskeä faktat tiskiin?

Haastan sinut. Mitä touhusit tämän viikon?

Minulla lyö aina tyhjää kun näen testauksesta laaditun prosessikaavion. Erityisesti siinä tilanteessa, kun kaavio on ensin laadittu ja sitten se pitäisi saada toteutumaan.

Tämä pitäisi nyt viedä käytäntöön

Ei onnistu. Yleensä kaavio on laadittu arjesta vieraantuneesta ajattelusta tai testaukseen ostetun työkalun rajoitteista käsin. Testauksen työtapojen virittäminen tapahtuu vaarallisen usein mallilla “ylhäältä alas”.

Käsikirjoitin toimivamman tavan.

1. Valitse projekti.
2. Tee hypoteesi paremmista työtavoista yhdessä projektin kanssa.
3. Tehkää lyhyt testi. Todista teoria käytännössä.
4. Jos toimii, monista muihinkin projekteihin.
5. Jos ei toimi, tuunatkaa teoriaa ja testaa uudestaan.

Alhaalta ylös -malli toimii lähes poikkeuksetta paremmin ja lisäksi jengikin on mukana muutoksessa.

Wänkkäys on aina mukavampaa, kun käärii hihat ja alkaa hommiin. Visiointi on vain vaatimaton korvike.

NOTE: For the english version. See below.

Olen pinttynyt Mäkkimies. Myynyt sieluni jo vuosia sitten, voisi joku sanoa.

Halusin Robot Frameworkin ja asensin ohjeen mukaan. Mutta RIDE toimii helposti vain wxPythonin versiolla 2.8.12.1. Turhauduin, sillä virallinen wxPythonin paketti ei OSX:llä edes asennu. Sanoo, että paketti on vahingoittunut. ARGH!

Kävi ilmi, että OSX:n pakettimanageri on muuttunut eikä tue enää vanhoja filejä. Onneksi pgk -filen voi paketoida uudestaan. Oheisella videolla pääsin purkamaan tuntojani ja lupasin laittaa blogiin ohjeen homman hoitamiseksi komentoriviltä, joten here we go.

In case you’d prefer english: Robot Framework paired up with RIDE is easy to install on OSX by following the original installation instructions. There is just one problem that has not been documented. wxPython 2.8.12.1 is a component that is a must to run RIDE. New versions won’t do.

Latest OSX does not support old .pkg packages to install the necessary wxPython and the file needs to be repackaged to succeed. You can either download a file I have re-packaged or do it yourself by following these instructions.

DOWNLOAD HERE

This is how you repack a .pkg file on command line with OSX:

#Find your way into a directory of your choosing and follow these steps.
$ mkdir repack_wxpython
$ cd repack_wxpython

#Now you place the original .pkg -file of your choosing into the repack_wxpython directory on your computer.
$ mkdir pkg_root
$ cd pkg_root
$ pax -f ../wxPython2.8-osx-unicode-universal-py2.7.pkg/Contents/Resources/wxPython2.8-osx-unicode-universal-py2.7.pax.gz -z -r
$ cd ..
$ mkdir scripts
$ cp wxPython2.8-osx-unicode-universal-py2.7.pkg/Contents/Resources/preflight scripts/preinstall
$ cp wxPython2.8-osx-unicode-universal-py2.7.pkg/Contents/Resources/postflight scripts/postinstall
$ rm -r wxPython2.8-osx-unicode-universal-py2.7.pkg
$ pkgbuild --root ./pkg_root --scripts ./scripts --identifier com.wxwidgets.wxpython wxPython2.8-osx-unicode-universal-py2.7.pkg

#And this is what you should see as an output from the terminal.
pkgbuild: Inferring bundle components from contents of ./pkg_root
pkgbuild: Adding top-level preinstall script
pkgbuild: Adding top-level postinstall script
pkgbuild: Wrote package to wxPython2.8-osx-unicode-universal-py2.7.pkg