Virhe on huono sana – osallistu!
Edellisen blogi-tekstin keskustelussa pyöriteltiin jälleen testaajien ja kehittäjien välisen kommunikaation haasteita. Testaaja testaa ja raportoi Virheet koodareille. Periaatteessa kyse on softamaailmassa neutraalista termistä, mutta missä tahansa muualla Virheellä on negatiivinen sävy. Hoitovirhe, mittausvirhe tai virkavirhe sisältävät kaikki oletuksen siitä, että joku on tehnyt jotakin väärin.
Vaikka Virheen sävyn softa-alan ammattilaiset ymmärtävätkin, voisiko omasta koodista löydetty Virhe kaivaa alitajunnasta esille ne kouluaikojen laskuoppi- ja kielivirheet, joista opettaja antoi yleensä negatiivista palautetta. Hoitovirheen aiheuttajaksi ei meistä halua kukaan. Virheen tekeminen vitut… harmittaa.
Koska testaajan löytämä Virhe ei ole millään muotoa negatiivinen tai moittiva, niin miksi sillä pitäisi olla muilla elämänalueilla negatiiviseksi ja moittivaksi koettu termi. Jos Virhettä kutsuttaisiin joksikin muuksi, voisi koodarit tehdä rauhassa töitä ilman alitajunnasta puskevia epämiellyttäviä assosiaatioita.
LEIKKIMIELINEN TEHTÄVÄ: Keksi neutraali (tai peräti positiivinen) termi testaajan löytämälle vaatimusten vastaiselle toiminnalle, jota tällä hetkellä virheeksi kutsutaan. Kirjoita ehdotuksesi kommenttikenttään!
Katsotaan mitä saadaan aikaan.
Mielestäni HASSI on ollut oikein toimiva nykyisessä projektissa. HASSIa käyttämällä olemme onnistuneet käsittelemään useita kovinkin kriittistä Virheitä sopivalla määrällä huumoria ja positiivisuutta.
Ite tykkään bugista, koska se on varmasti aito tietokonetermi 🙂 Epätäsmällisyys tai heikkous vois olla kans mutta ei oikein kivoja käyttää suomen kielessä.
Toiminallinen poikkeama suunnitellusta olettamuksesta
😀
issueta on käytetty myöskin korvaamaan ikävä Error-sana. Vastakysymys: Lieventääkö korvaava sana virheen vakavuutta vai pelkästään helpottaa ongelmasta puhumista?
Hoitovirhe = Joku on tehnyt valinnan toteuttaa jokin hoitotoimenpide tietyllä tavalla ja se johtaa epätoivottuihin tuloksiin – potilaan vammautumiseen, kuolemaan, yms. Päätös on tehty joko epäpätevyydestä tai olosuhteista johtuen. Negatiivinen kyllä, mutta tätä ei ”kommunikoinnin helpottamiseksi” tulla muuttamaan. ”Mittausvirhe” ja ”virkavirhe” noudattavat samaa linjaa (mittausvirhe kontekstista riippuen ei kovin kriittinen tai äärimmäisen kriittinen). Jokainen ”virhe” tehdään joko sen takia, että emme osaa tai olosuhteet ovat ko. tilanteessa pakottaneet siihen. Näillä virheillä on kuitenkin aina seuraukset. Eikös se tietty negatiivinen sävy jopa johda siihen, että kehittäjät haluavat tehdä niitä vähemmän? Jos teet päivässä 100 hassia, niin kyllä projektijohtoa naurattaa… paitsi release-päivänä. 😉
”Koska testaajan löytämä Virhe ei ole millään muotoa negatiivinen–” Otetaan esimerkkinä Virhe, jota EI löydetä. Onko se negatiivinen? Jos (ja usein kun) testaaja löytää Virheen (Ai että pidän tästä, että saa kutsua noita herkkupaloja isolla alkukirjaimella!) sen pitäisi olla aina kehittäjälle muistutus pyrkiä parempaan. Jos testaaja tekee virheen, josta aiheutuu ongelmia (tekee testin, jonka vaikutukset valuvat tuotantoon, jne.), Virhe on aina negatiivinen sävyltään. Jos kehittäjä tekee virhee, joka vaikuttaa tuotantoon, niin se ei saisi olla negatiivinen, vai?
”Keksi neutraali (tai peräti positiivinen) termi testaajan löytämälle vaatimusten vastaiselle toiminnalle, jota tällä hetkellä virheeksi kutsutaan.” Onko kaikki vaatimusten vastainen toiminta virheellistä? Voiko Virhe olla vaatimusten mukaista toimintaa? Onko joku miettinyt ISQTB:n termistöä virheille? Vika, häiriö, poikkeama, jne. Onko Virheiden sävytyksellä eroa? Tottakai on hauska keksiä vaihtoehtoisia sanoja Virheelle (rakkaalla lapsella on monta nimeä), mutta eikös tuo Virhe jo itsessään ole virheellinen? Eikös kyseessä ole Vika? Vika on kohtuu neutraali, koska Vika on testauksen kohteessa eikä tekijässä (joka on tehnyt Virheen).
Niin… ja turha edes aloittaa englanninkielisistä termeistä.. 😉
Pekka lähestyi aihetta mielenkiintoiselta kantilta, joka johtaa jälleen uusiin pohdiskeluhin. Aihe sivuaa myös Jannen esittämää vastakysymystä.
Onko virheen (hassin, bugin, vian) löytymisen ajankohdalla, ts. projektin vaiheella, merkitystä sen sävyllä?
Aktiviisen kehityksen aikana testaaja voi parhaimmillaan toimia softakehitystä selkeästi rytmittävänä ja nopeuttavana tekijänä. Silloin kehittäjä voi keskittyä uuden tuottamiseen luottaen siihen, että testaaja napsii virheet kiinni. Tästä on kirjoitettu blogimerkintä ”Työ, tarkoitus ja kommunikaatio”. Silloin virherapsa ei ole negatiivinen palaute, vaan normaalia kommunikointia.
Onko tilanne eri, jos hyväksyntätestivaiheessa jää kiinni sellaisia vikoja, jotka olisi pitänyt saada kiinni jo projektin alkuvaiheessa?
Päivän Iltalehden kaksosten horoskooppi antaa keskusteluun myös oman kontribuutionsa:
”Näet eräässä negatiivisessa asiassa positiivisen puolen, jota kukaan muu ei tunnu huomaavan. Voit ollakin tilanteeseen tyytyväinen, vaikka muut mutisisivat mielipahaa.”
Tämä voisi olla testaajan horoskooppi, ympäri vuoden 🙂
@Jaakko: Taas kerran siis keskustelu vaati kontekstin, jotta se voisi olla pätevä! 😉 Tuohon horoskooppiin muuten meikäläinen voi yhtyä. Eihän testaajan PIDÄ olla paski… ööö.. ilkeä, vaan asiasta kuin asiasta voi löytää positiivisen puolen. Kontekstista pitäisi vaan käydä ilmi tuoko positiivisuus lisäarvoa kommnikaatiolle? Saako positiivisuus tekijän suoriutumaan paremmin käsilläolevasta asiasta?
@Pekka: Mitä mieltä itse olet positiivisuuden merkityksestä suoritukselle?
Sanoisin, että virheestä käytetään erilaista kieltä eri yhteyksistä. Kun raportti toimitetaan ns. virallisen protokollan mukaan projektijohdolle, on tapana käyttää selkeää ammattikieltä ilman tunnelatauksia. Tilanne on toinen kun testaaja toimii yhteistyössä koodareiden kanssa päivittäisessä työssä. Silloin voidaan käyttää reilusti huumoria ja suhtautua rennon positiivisesti löydettyihin hasseihin. Positiivinen voidaan olla sen vuoksi, että tiimi onnistui jälleen kerran löytämään virheen jo kehitysvaiheessa ennen kuin tuotosta edes tarjottiin release-testeihin. Se on itseasiassa hymyn paikka sekä testaajalle että koodarille.
Korostan siis, että peliä pitää lukea tilanne kerrallaan ja toiseen tilanteeseen istuu paremmin toinen tyyli kuin toiseen. Itse olen kokenut positiivisen lähestymisen johtava poikkeuksetta positiivisiin tuloksiin.
@Jaakko: Positiivisuus on aina paikallaan, ei kukaan jaksa päivästä toiseen negatiivisella meiningillä tai täällä aukeaisi ranteita harva-se-päivä. positiivisuus on kommunikaatioväline. Suoritukseen vaikutus on ”porkkanamainen”: positiivisella saa yleensä tuettua asioita niinkuin aasille tarjotaan porkkanaa (ja ei ne kehittäjät ole aaseja kuin metaforisesti 😉 ), mutta paikoin suorituksen parantamiseksi tarvitaan negaatiota. Useimmiten se negatiivinen palaute annetaan rauhassa ja kahdenkesken. Positiivinen ilmapiiri luodaan kaikkien läsnäollessa! =) Perus johtamista… Jos nyt testaaja voi ”johtaa” kehittäjiä. Kaikki riippuu kunnoituksesta, molemmin puolin.
@Ammmattitestaaja: Kun kyseessä on pienkehitysprojekti tai skrum-projekti, jossa kaikki ovat tiiviisti kasassa, niin huumori on yleensä eteenpäinvievä voima. Kyllä meitä nauratti, kun sain *rikottua* lokaalisti Firefoxini ja softa pysyi taustalla kunnossa! Entä Off-shore? Entä konsulttimaailma? Konsultti voi olla yhteistyössä koodarin kanssa… Kuinka konsultti kommunikoi kehittäjälle, että tämän tuotoksesta löytyi … hmmm… ”löydös”? (Kävisikö tuo termiksi?)
Pekka, olet oikeassa. Pienemmissä piireissa on helppoa ja luontevaa käyttää huumoria työkaluna. Isommissa paketeissa tulee haasteita, koska usein et ole edes tehnyt sinun-kauppoja vastapään kanssa, joten huumori voi joskus olla arpapeliä kun ei tiedä kenen kanssa työskentelee (Off-shore). Toiset kulttuurit myös ymmärtävät huumorin joskus erilailla kuin me täällä Pohjolassa.
Kun sitä virhettä lähdetään kommunikoimaan maapallon toiselle puolelle, niin rauhallisen neutraali lähestyminen lienee paikallaan. Kun peli on saatu auki, niin sananvalinnat voi helposti asettaa siten, että viestistä on havaittavissa positiivinen tunnelma, kaikesta huolimatta.
Positiiviseen asenteeseen ja ilmaisuun kannustan monestakin syystä joista yksi syy on se, että negatiivinen tai jopa hyökkäävä asenne laukaiseen vastaanottajassa helposti puolustusreaktion ja silloin soppa on valmis. Vastaanottaja saattaa äityä puolustautumaan siinä määrin, että virhe ei tule korjatuksi tai kun se viimein korjataan, on aikaa ja energiaa palanut tolkuttomasti ja kenelläkään ei ole hyvä fiilis.
Eli ei muuta kuin niitä hasseja vain sitten löytämään. Hassimisiin 🙂
Tuo on mielenkiintoista, mitä ammattitestaaja kirjoitaa kulttuurieroista. Itselläni ei ole kokemusta Itä-Euroopassa töiden tekemisestä, mutta yksi kaveri on Varsovassa töissä. Seuraava on hänen kokemustaan.
Se kertoi, että mikäli oman asiansa haluaa saada perille ja että oikeasti jotakin tapahtuu, kommunikoinnin täytyy tapahtua suurinpiirtein huutamalla. Normaalit äänenpainot menevät täysin ohi korvien. Se on vain jutustelua, johon ei tarvitse reagoida. Alussa tilanteeseen oli hankala suhtautua mitenkään, mutta nyt karjuminen kuulemma onnistuu jo luontevasti 🙂
Vastaavanlainen toimintatapa esimerkiksi Japanissa todennäköisesti katkoisi yhteistyön välittömästi.
Mielenkiintoinen keskustelu käynnissä!
James Marcus Bach kirjoitti blogissaan (http://www.satisfice.com/blog/archives/605) kommunikoinnin tärkeydestä. Kyseessä oli kilpailu, jossa oli myös mahdollisuus koetella rajoja, joten muutama niitä kokeilikin. Tuossa kilpailussa tuli esiin huumori.
Kun puhutaan huumorista työynpäristössä, niin molempien osapuolten täytyy olla valmistautuneita huumorin käyttöön. Huumorin avulla voi /kuvitella/ olevansa positiivinen tai hauska, mutta vastaanotettu syöte, ilmaisu, tms. voikin tuntua negatiiviselta. Joskus negatiiviseltä kalskahtava ilmaisu saattaa kuitenkin huumorin keinoin heijastua positiiviseksi ja yhteistyö toimii. Kyseessä on molemminpuolinen kunnioitus ja positiivisuus ei auta, jos kunnioitusta ei ole. Kunnioituksen puutteessa toimitaan toisella tapaa.
Itse puhun aina erskoista (yks. erska). Vaikkakin on kieliväännös englannin errorista Kempeleen kielelle, niin on neutraali, mielipahaa aiheuttamaton sana, joka testausuupumuksen syvyydestä riippuen saattaa tuoda jopa hymyn huulille.
Mainioita ideoita porukalla!
Minäkin tunnustan tykkääväni Bugi -sanasta. Minusta tuntuu, että se on erinomainen yleisnimitys asioille, jotka aiheuttavat päänvaivaa. Ne voivat olla oikeita vikoja, ärsyttäviä ominaisuuksia, käytettävyyskämmejä jne..
Minusta Bolton tiivisti asian mainiosti: ”A Bug is something that keeps bugging you”