perjantai 23. lokakuuta 2009

Se pieni ero: testaus ja laatutietoon reagointi

Päivitin ulkoasun ja sisällön osalta websivujani http://www.testauskirja.com/. Laitoin tietoa päivityksistä jonkinlaiselle kohderyhmälle, ja ensimmäisenä päivänä sain postilla viestin:

"Sivuilla eivät ääkköset näy oikein... olisikohan pitänyt testata / testauttaa jossain ennen julkaisemista..."

Testaajana viesti oli minusta äärimmäisen inspiroiva. Olen kuullut vastaavan kommentin lukemattomia kertoja ohjelmistoprojekteissa, ja lähestulkoon aina pitänyt sitä jonkinasteisen testauksen ymmärtämättömyyden osoituksena. Ymmärtämättömyyttä voi kuitenkin aina koittaa korjata.

Itse ajattelen jotakuinkin näin:

Testaus / testaamattomuus on aivan eri asia kuin laatutietoon reagointi
Testauksella löydetään virheitä. Testaamattomuudella voidaan jäädä ilman laatutietoa. Testauksen osalta mikään ei suoraan lupaa, että tietoon virheestä reagoidaan "toivotusti" korjauksella. Tietoon voidaan reagoida myös päättämällä elää virheen kanssa - pidempään tai lyhyemmän aikaa.

Korjauspäätöksissä pitää miettiä kustannusta suhteessa hyötyihin - kokonaisuutena
Testaajana pitäisin kovasti moitteettomasta laadusta, mutta olen oppinut olemaan ylpeä tunnetusta laadusta. Suorien kustannusten lisäksi pitää miettiä vaihtoehtoiskustannukset: mitä muuta, mahdollisesti tärkeämpää, jää saavuttamatta kun aika päätetään kiinnittää tähän. Virheen korjaaminen on aikaa pois joltain muulta. Uuden palvelun lisäarvo alkaa toteutua vasta kun se on käyttäjillä.

Korjauspäätöksien virheet ovat yleisempiä kuin testaamattomuus
Tiesin ennestään että sivujen osalta skandit eivät toimi tietyillä selaimien ja asetusten yhdistelmällä. Voin piiloutua sen taakse että olen itse asiassa laiska ja surkea kehittäjä, jopa websivuille, ja en osannut tehokkaasti arpoa oikeaa merkistökoodia sivuilleni niin että merkit näkyisivät kaikilla oikein. Voin myös piiloutua sen taakse että aivan sama merkistö-ongelma on ollut vuosikausia testausOSY:n sivuilla, koska nekin minä olen laiskana kehittäjänä tehnyt.
Sen sijaan että piiloutuisin, ottaisin mieluummin ajattelutavaksi sen että tein päätöksen korjaamattomuudesta. Päätös voi olla väärä, mutta päätös kuitenkin.
Sen sijaan että pohditaan että olisiko pitänyt testata, voidaan puida teinkö oikean päätöksen asiakkaideni palvelemisen kannalta priorisoidessani korjauksen ulos "julkaisusta".

Laatupalautteeseen reagointi
Laatupalautteen saaminen (virheraportit) on itse asiassa kivaa. Se käynnistää pohdinnan siitä että olisiko jotain opittavaa, ja jos olisi, mitä.
Testausopeista (tai markkinoinnin opeista) voisi kerätä sen että vain joka kymmenes tyytymätön valittaa. Tämäkin tosin taitaa päteä vain sovelluksiin/palveluihin joilla on merkitystä - ja voisin kyseenalaistaa minun websiteni merkityksen käyttäjäkunnalle valituskynnyksen osalta. Voisin myös ajatella, että ongelma ei ole joko yleinen tai niin häiritsevä että olisi muuttanut asioita minun kannaltani, koska mittareita (näen sivuittain osumien määrän) näyttäisi siltä että aika moni on jaksanut ainakin klikkailla useampia sivuja auki. Testaajana kuitenkin ehkä olettaisi, että ihmiset eivät vaan valita...

Aidosti mielenkiintoinen kysymys onkin: vaikuttaako skandien rikkinäisyys / sivujeni rumuus siihen että joku ei enää uskoisi että osaan testata ja opettaa testausta, koska en osaa korjata?

Kuinkas noiden isojen julkisten epäonnistumisten kanssa saisi kirjoittelijat tajuamaan että kysymys ei ole siitä että olisi pitänyt testata / testauttaa, vaan että olisi pitänyt korjata / korjauttaa. Ja sitä ennen, päättää oikein korjaustarpeen tärkeydestä.

sunnuntai 11. lokakuuta 2009

Virheetön järjestelmä tuotannossa

Järjestelen parhaillaan ketterän testauksen työpajaa marraskuun alkuun, ja osallistujia läpi käydessäni koin monta vau-tunnetta katsellessani millaista porukkaa Suomesta löytyykään. Sen sijaan yksi erityinen lause jossain ilmoittautumisien perusteissa pisti silmään: jollakulla oli kokemuksia useista peräkkäisistä järjestelmäversioista jotka olivat virheettömiä tuotannossa.

Olen vuosien varrella ollut jokusessa projektissa mukana vaihtelevissa rooleissa, ja joudun tunnustamaan että minun kohdalleni tuollaista tilannetta ei ole osunut. Varsin vähävirheisiä järjestelmiä tuotantoon on viety, mutta virheetön - ei todellakaan. Ketterien menetelmien mukanaan tuoma stop-and-fix -periaate auttaa todella paljon laadun kanssa, mutta ainakin minun kokemuksissani vielä varsin usein tulee kaksi virheraporttia, joista vain toisen voi korjata kun suurten käyttäjämäärien ja vaihtelevien profiilien kanssa ihmiset eivät vain koe laatua ja virheettömyyttä samalla tapaa.

Asiaa hetken hauduteltuani jään odottamaan innolla määritelmää virheettömyydelle. Mieleeni tuli nimittäin montakin projektia, jossa virhe määritellään varsin suppeasti suhteessa tarkoitettuun toiminnallisuuteen, ja yleensä vielä dokumentaatioon. Sitä ei ketterän projektin osalta määritelmäksi nopeasti leimaisi.

Järjestelmiä, joista ei ole löytynyt yhtään tuotantokorjaustarvetta ennen ympäristön muuttumista on kohdalle kyllä tullut. Nekin tapaukset ovat kyllä kaukana virheettömistä.

lauantai 10. lokakuuta 2009

Miten testaus kehittyy?

Olen viettänyt iltaa lukien arvostamieni testausgurujen blogeja, pyrkien päivittämään tietojani siitä mitä maailmassa oikeastaan tapahtuukaan. Erityisen inspiraation pohdiskelulle löysin jälleen James Bachin blogista.

Olen viime aikoina kokenut jonkinasteista epämukavuutta lukiessani Jamesin kirjoituksia. James on pitkään ollut yksi ehdottomista testausidoleistani, ehdottoman taitava testaaja, joka myös kuvailee tekemisiään ja antaa sitä kautta muille mahdollisuuden ottaa valitsemiaan oppeja. Kokemani epämukavuus johti siihen että lähes raukkamaisesti päätin kirjoittaa suomeksi, kunnes uskallan asetella sanani niin etten päädy väärään keskusteluun.

James Bachin blogin viimeisin kirjoitus käsitteli James Whittakerin uusinta kirjaa, jota jokunen varsin merkittävä testausihminen, James Bach mukaanlukien, on pitänyt jonkinasteisena huijauksena. Varsinaista otsikon perusteella odotettavaa asiaa koettiin jossain arvostelussa olevan sivumäärällisesti liian vähän, ja viittausten puute tutkivan testauksen keskeisiin hahmoihin ei myöskään saanut suitsutusta. Ilmeisesti lisäksi koettiin että koko termiä käytettiin väärin.

Olen viime aikoina lukenut James Whittakerin kirjaa, ja edes luettuani toisten gurujen kommentteja, ei mielipiteeni kirjasta muuttunut. Minua ei haitannut että varsinainen sisältö oli ehkä lyhyessä osassa kirjaa, koska muukin sisältö oli minulle oleellista. Olen kahlannut läpi puolet, ja pitänyt siitä mitä olen lukenut. Olen lukiessa jäsentänyt omia ajatuksiani ja saanut uusia ideoita - myös rivien välistä lukien.

Palatakseni kirjoitukseni otsikkoon: miten testaus kehittyy? Jäin pohtimaan sitä että jos tutkivan testauksen jäsentämiseen liittyy pelko siitä että päätyy melko kovan kritiikin kohteeksi, uskaltaako sitä oikeasti asioita yrittää viedä eteenpäin? Kirjoittelin yhdellä listalla jokunen viikko takaperin tutkivan testauksen hallinnoinnin ajatuskehikostani, jonka huomasin olevan erilainen kuin sessiopohjainen testauksen hallinta, vaikka paljon samaa onkin. En vielä säikähtänyt, mutta muistissa on tuoreesti että kun keskustelun avaa, siinä saa samalla sitoutua mahdollisesti aikamoiseen pyöritykseen ja selittelyyn. Ehkä kyse on osittain siitä että englanti ei ole äidinkieleni, mutta ennen kaikkea kuitenkin kirjallisen viestinnän haastavuudesta.

Jos keskustelu käy liian kuumana ja ilmaisut vahvoina, aika iso osa ihmisistä vieraantuu keskustelusta. Aikaa ei vain ole riittävästi, ja oma luottamus taitoihin ja tietoihin horjuu, kokemuksista huolimatta. Auttaakohan tämä uudenoloinen ilmapiiri testausta kehittymään? Nakuttava tuntuma jossain vihjailee, että kohta on valittava gurunsa että ei saa aikaan keskusteluissa vahvoja torjumisreaktioita puolin ja toisin.

Lukijat

Osallistujat