Oli taas yksi niistä päivistä eilen, että aloin miettimään ammattivalintaani. Rakastan testausta ja kaikkea siihen liittyvää, mutta erityisesti pidän testaamisesta (ei testauksesta). Meillä oli miesvajausta ja päätin heittää hallinnollisen viittani naulakkoon ja kääriä hihat.
Istuttuani testauspenkkiin ajattelin nopeasti ajaa savutestisetit läpi ja aloittaa kunnon testauksen. Kopeana ja ylpeänä aloin ajamaan rajapintatestejä, jotka kaikki napsahtivat punaiselle. "Pannahinen" sanoin. Oletin ensimmäisenä, että vika on järjestelmässä. Tarkistin tilanteen ja totesin, että systeemi käy ja kukkuu. Olin ampunut testit väärään endpointiin.
Korjasin testit ja ajoin ne uudelleen. Noin 40% meni punaiselle. "Pannahinen" sanoin. "Eipäs tämä järjestelmä toimi yhtään niinkuin pitäisi!" Sitten tarkistelin virheilmoituksia ja assertioita. Näemmä olin innostuksissani päivittänyt testejä niin, että testit sisälsivät tyhjiä elementtejä, jotka rikkoivat testit.
Korjasin taas testit ja nyt sain kaikki paitsi 10 vihreiksi. "Pannahinen" sanoin ja pyyrin toisen testaajan katsomaan tuloksia. Hän vain totesi, että "toimiihan tuo. Olen sitä käyttöliittymän läpi testannut jo puoli tuntia."
--
Kun on pidemmän aikaa tekemättä jotakin, niin taidot ruostuvat - faktahan se on. Ne vaan eivät ruostu meidän päässämme. Me olemme omasta mielestämme edelleen niitä "huipputestaajia" ja "buginmetsästäjiä", mitä olimme puoli vuotta sitten. Kun pääsee sorvin ääreen uudelleen, niin hetki siinä menee palautellessa niitä taitoja taas sormenpäihin.
Tämän aion välttää jatkossa tekemällä harjoitteita, joita itse annan testaajilleni. Esimerkiksi ParkCalc-tyyppisiä testausrupeamia (kiitos plyytinen), joilla pystytään harjoittamaan kriittistä ajattelua ja testi-ideoiden kehittämistä.
Wednesday, 12 October 2011
Tuesday, 30 August 2011
Testausheuristiikat 5/7
CRUSSPICSTMPL
Tämä heuristiikka pureutuu laatuun. Tämä kattaa käytännössä kaikki "itility"-asiat (plus pari muuta). En käy tässä läpi muuta kuin englanninkielisen sisällön: C = Capability, R = Reliability, U = Usability, S = Security, S = Scalability, P = Performance, I = Installability, C = Compatibility, S = Supportability, T = Testability, M = Maintainability, P = Portability, L = Localizability. Jokainen laatukriteeri saattaa nostaa tai laskea toisen kriteerin tärkeyttä, ja puutteet yhdessä voivat johtaa puutteeseen toisessa. Kaikesta huolimatta laadulliset puutteet johtavat tuotteen arvon vähenemiseen.
Kyvykkyys tai kykenevyys (näiden "itilyjen" suomentaminen on melko hankalaa joskus) viittaa siihen, että onko järjestelmällä kyky käsitellä tiettyjä asioita. Onko järjestelmällä oikeuksia suorittaa sisäisiä tai ulkoisia toimintoja. Hyvänä esimerkkinä luku ja kirjoitusoikeudet. Tämä voisi ehkä liipata läheltä "auhtorizability"-sanaa (vaikka se ei ehkä sana olekaan).
Luotettavuus on periaatteessa itseään selittävä asia, jolla mitataan järjestelmän kykyä suorittaa prosesseja pitkällä ajalla virheettä.
Käytettävyys on oma tieteenalansa sellaisenaan, joten en tässä puutu käytettävyyteen sen kummemmin. Käytettävyys saattaa kuitenkin vähentää esimerkiksi turvallisuutta, jos käyttäjälle näytetään käytettävyyden nimissä näytetään käyttäjälle tietoja, joita hänen ei ole pakko nähdä. Turvallisuus tuo omalta osaltaan ristiriitaa monen laatukriteerin tarkasteluun. Voidaanko luoda esimerkiksi käytettävyyttä ilman että turvallisuus kärsii? Voidaanko luoda turvallisuutta ilman että suorituskyky tai asennettavuus kärsii? Turvallisuusaspekteja on lisäksi lukematon määrä, joten laatukriteerien keskenäinen priorisointi turvallisuutta vasten on joskus vaikeaa.
Skaalautuvuus tarkoittaa järjestelmän kykyä tukea kasvua. Suorituskyky tarkoittaa järjestelmän kykyä suoriutua tietomääristä, jotka järjestelmää tällä hetkellä kuormittaa (tai oletetuista raja-arvoista).
Asennettavuus on käytännössä kykyä tulla asennetuksi eri alustoille. Tämä ei ole validi esimerkiksi webbisoftissa muuten kuin selaimen yhteydessä tarkasteltaessa. Yhteensopivuus liittyy myös selaimiin, mutta myös kaikkiin järjestelmiin jotka kommunikoivat toistensa kanssa. Siirrettävyys koskee osittain asennettavuutta, mutta tämä liittyy siis softan siirtämistä uuteen rautaan, tms.
Tuettavuus, ylläpidettävyys ja testattavuus ovat ominaisuuksia, joitka tukevat laatua vaikka eivät sellaisenaan suoraan heikennä tai vahvista laatua. Ylläpidettävyydellä voidaan helpottaa jatkokehitystä, debugausta, jne. kun taas tuettavuudella tarkoitetaan kykyä jatkaa elinkaarta matalalilla kuluilla. Eli tukeminen ei tule kalliimmaksi kuin uuden softan tekeminen alusta.
Lokalisointi on maakohtaistamista eli kilisyyksiä tai aikavyöhykkeitä. Lokalisaatio tulee erityisen tärkeäksi, kun palvelua käytetään ympäri maailmaa, valtiota.
Tämä heuristiikka pureutuu laatuun. Tämä kattaa käytännössä kaikki "itility"-asiat (plus pari muuta). En käy tässä läpi muuta kuin englanninkielisen sisällön: C = Capability, R = Reliability, U = Usability, S = Security, S = Scalability, P = Performance, I = Installability, C = Compatibility, S = Supportability, T = Testability, M = Maintainability, P = Portability, L = Localizability. Jokainen laatukriteeri saattaa nostaa tai laskea toisen kriteerin tärkeyttä, ja puutteet yhdessä voivat johtaa puutteeseen toisessa. Kaikesta huolimatta laadulliset puutteet johtavat tuotteen arvon vähenemiseen.
Kyvykkyys tai kykenevyys (näiden "itilyjen" suomentaminen on melko hankalaa joskus) viittaa siihen, että onko järjestelmällä kyky käsitellä tiettyjä asioita. Onko järjestelmällä oikeuksia suorittaa sisäisiä tai ulkoisia toimintoja. Hyvänä esimerkkinä luku ja kirjoitusoikeudet. Tämä voisi ehkä liipata läheltä "auhtorizability"-sanaa (vaikka se ei ehkä sana olekaan).
Luotettavuus on periaatteessa itseään selittävä asia, jolla mitataan järjestelmän kykyä suorittaa prosesseja pitkällä ajalla virheettä.
Käytettävyys on oma tieteenalansa sellaisenaan, joten en tässä puutu käytettävyyteen sen kummemmin. Käytettävyys saattaa kuitenkin vähentää esimerkiksi turvallisuutta, jos käyttäjälle näytetään käytettävyyden nimissä näytetään käyttäjälle tietoja, joita hänen ei ole pakko nähdä. Turvallisuus tuo omalta osaltaan ristiriitaa monen laatukriteerin tarkasteluun. Voidaanko luoda esimerkiksi käytettävyyttä ilman että turvallisuus kärsii? Voidaanko luoda turvallisuutta ilman että suorituskyky tai asennettavuus kärsii? Turvallisuusaspekteja on lisäksi lukematon määrä, joten laatukriteerien keskenäinen priorisointi turvallisuutta vasten on joskus vaikeaa.
Skaalautuvuus tarkoittaa järjestelmän kykyä tukea kasvua. Suorituskyky tarkoittaa järjestelmän kykyä suoriutua tietomääristä, jotka järjestelmää tällä hetkellä kuormittaa (tai oletetuista raja-arvoista).
Asennettavuus on käytännössä kykyä tulla asennetuksi eri alustoille. Tämä ei ole validi esimerkiksi webbisoftissa muuten kuin selaimen yhteydessä tarkasteltaessa. Yhteensopivuus liittyy myös selaimiin, mutta myös kaikkiin järjestelmiin jotka kommunikoivat toistensa kanssa. Siirrettävyys koskee osittain asennettavuutta, mutta tämä liittyy siis softan siirtämistä uuteen rautaan, tms.
Tuettavuus, ylläpidettävyys ja testattavuus ovat ominaisuuksia, joitka tukevat laatua vaikka eivät sellaisenaan suoraan heikennä tai vahvista laatua. Ylläpidettävyydellä voidaan helpottaa jatkokehitystä, debugausta, jne. kun taas tuettavuudella tarkoitetaan kykyä jatkaa elinkaarta matalalilla kuluilla. Eli tukeminen ei tule kalliimmaksi kuin uuden softan tekeminen alusta.
Lokalisointi on maakohtaistamista eli kilisyyksiä tai aikavyöhykkeitä. Lokalisaatio tulee erityisen tärkeäksi, kun palvelua käytetään ympäri maailmaa, valtiota.
Tuesday, 16 August 2011
Miten saada lisää ääntä Suomen "testausskeneen"?
Haa! Taas kunnianhimoa pursuava otsake! =) Tänään selailin suomalaisia testausblogeja (ohjelmistotestaus.fi, Pro-Testing, Testausko Turhaa?, jne.) ja kuten eräässä kommentissani tuolle kokeneelle testaajalle (ja hänen kristallipallolleen) avauduin, rupesi korpeamaan se, että suomalaisessa testausskenessä ei kuulu tarpeeksi ääntä. Voipi olla, että olen väärässä paikassa väärään aikaan (eli Twitterissä ym. liian harvoin), mutta testausblogit kumisevat kommentittomuuttaan. Toki vakkarikommentoijia on ("ammattitestaaja", oopee, jne.), mutta kommentoinnista puuttuu haastaminen. Yleensä kommentointi on joko "hei, hyvä teksti" tai "joo, ajattelin samaa ja tulin tulokseen X".
Jos joku aktiivisesti lukee Bachin tai Boltonin blogeja, niin siellä on joskus hyvinkin äärimmäistä haastamista. Teesit jyrätään ja kirjoittaja puolustaa niitä. Sami Söderblom pistikin meikäläiselle hyvin kapulaa rattaisiin, mutta jotenkin juttu kuivui kokoon vaikka langanpätkiä jäikin ilman tarttujaa. Pelkäävätkö ihmiset mielipiteitään?
Minä, blogaajana ja kommentoijana, en ole kovinkaan kaunisteleva: pyrin tuomaan esiin ne ristiriidat, mitä minun korvaani (silmääni) kalskahtaa. Harvemmin haluan pahoittaa kenenkään mielen, mutta astumalla varpaille, haastamalla, kyseenalaistamalla saan ihmisistä enemmän irti! Ihmiset tekevät työnsä paremmin ja ajattelevat asoita syvemmältä ja laajemmalta, kun tietävät irtoinaisiin lankoihin tartuttavan. Toki suodatan pahimmat pois, mutta kovia (engl. harsh) sanoja saattaa jäädä tekstiin. Usein olen samaa mieltä kirjoittajan/puhujan kanssa, mutta olen periaatteesta eri mieltä ja tuon vastakkaiset näkökulmat esiin.
Testausala on huikea ja rikas ala! Ihmiset ovat poikkeuksetta lahjakkaita ja äärimmäisen älykkäitä. Onko linja kuitenkin se, että on parempi pitää mielipiteensä itsellään kuin tuoda ne julki ja tulla ehkä jopa lytätyksi? Eikö ala tulisi huomattavasti paremmaksi, jos jokaista ajatuksensa julkituovaa kunnioitettaisiin keskustelemalla/väittelemällä hänen esilletuomastaan aiheesta? Vai tulisiko? Tuntisimmeko me olomme epämukavaksi, kun joutuisimme puolustamaan sanomisiamme/tekemisiämme? Eikös jokaisen testaajan perustaitoihin kuulu kyky pystyä todistamaan oman työnsä tulokset?
No miten sitä ääntä saataisiin lisää? Keskustelemalla! Kommentoimalla ja keskustelemalla! Vaikka kaiken maailman seminaareja ja kokoontumisia järjestetään, niin niissä keskustelu on usein yksipuolista ja/tai haastamista ei juurikaan ole. Itse en työni puolesta pysty osallistumaan kuin murto-osaan näistä julkisista tapaamisista, mutta käytän ääntäni verkossa (onko tämä ääntä, kun tämä on tekstiä)! Pystytkö... ei... Uskallatko avata äänesi ja kantaa kortesi kekoon testauksen äänen kasvattamiseksi? ;)
Jos joku aktiivisesti lukee Bachin tai Boltonin blogeja, niin siellä on joskus hyvinkin äärimmäistä haastamista. Teesit jyrätään ja kirjoittaja puolustaa niitä. Sami Söderblom pistikin meikäläiselle hyvin kapulaa rattaisiin, mutta jotenkin juttu kuivui kokoon vaikka langanpätkiä jäikin ilman tarttujaa. Pelkäävätkö ihmiset mielipiteitään?
Minä, blogaajana ja kommentoijana, en ole kovinkaan kaunisteleva: pyrin tuomaan esiin ne ristiriidat, mitä minun korvaani (silmääni) kalskahtaa. Harvemmin haluan pahoittaa kenenkään mielen, mutta astumalla varpaille, haastamalla, kyseenalaistamalla saan ihmisistä enemmän irti! Ihmiset tekevät työnsä paremmin ja ajattelevat asoita syvemmältä ja laajemmalta, kun tietävät irtoinaisiin lankoihin tartuttavan. Toki suodatan pahimmat pois, mutta kovia (engl. harsh) sanoja saattaa jäädä tekstiin. Usein olen samaa mieltä kirjoittajan/puhujan kanssa, mutta olen periaatteesta eri mieltä ja tuon vastakkaiset näkökulmat esiin.
Testausala on huikea ja rikas ala! Ihmiset ovat poikkeuksetta lahjakkaita ja äärimmäisen älykkäitä. Onko linja kuitenkin se, että on parempi pitää mielipiteensä itsellään kuin tuoda ne julki ja tulla ehkä jopa lytätyksi? Eikö ala tulisi huomattavasti paremmaksi, jos jokaista ajatuksensa julkituovaa kunnioitettaisiin keskustelemalla/väittelemällä hänen esilletuomastaan aiheesta? Vai tulisiko? Tuntisimmeko me olomme epämukavaksi, kun joutuisimme puolustamaan sanomisiamme/tekemisiämme? Eikös jokaisen testaajan perustaitoihin kuulu kyky pystyä todistamaan oman työnsä tulokset?
No miten sitä ääntä saataisiin lisää? Keskustelemalla! Kommentoimalla ja keskustelemalla! Vaikka kaiken maailman seminaareja ja kokoontumisia järjestetään, niin niissä keskustelu on usein yksipuolista ja/tai haastamista ei juurikaan ole. Itse en työni puolesta pysty osallistumaan kuin murto-osaan näistä julkisista tapaamisista, mutta käytän ääntäni verkossa (onko tämä ääntä, kun tämä on tekstiä)! Pystytkö... ei... Uskallatko avata äänesi ja kantaa kortesi kekoon testauksen äänen kasvattamiseksi? ;)
Wednesday, 10 August 2011
Best Practices (NOT!)
Jostakin syystä eksyin taas kerran JMB:n blogille ja tarrauduin maturiteettimallien arvosteluun. Siellä oli linkki No Best Practices -tekstiin. Olen tässä kesän mittaan miettinyt miten testausorganisaatiotamme pitäisi uudistaa, jotta se saadaan tehokkaaksi koko yrityksen läpi. Pähkäilyn tuloksena oli mm. testausprosessin uudistaminen, roolien selkeyttäminen, testaustaidon parantaminen sekä näkyvyyden kasvattaminen. Näiden mahdollistamiseksi tarvataan kutienkin ryhmä, joka hallitsee testauksen nyanssit ja eri organisaatiotahojen tarpeet testaukselle.
Näin syntyi idea testausarkkitehdista ja testaus steering groupista. Meillä organisaatiossa on olemassa steering grouppeja jos jonkinmoisia ja niiden pääasiallinen sisältö on suurinpiirtein
Itse pyrin kohti jatkuvaa kehitystä testauksen suhteen. Lisäksi on hienoinen kontekstitestausintoilija ja sitä kautta mielelläni kuuntelen JMB:n oppeja. Jokainen toimintamalli ja käytäntö on siis aina kiinnitetty kontekstiin ja aikaan. Kun molemmat muuttuvat, voidaanko sanoa että jokin ratkaisumalli on paras? Onko olemassa toista mallia joka on parempi kuin "paras käytäntö"? Voiko silloin sanoa, että on olemassa paras käytäntö?
Onko niin, että ihmiset laiskuudessaan ja aikataulupaineessa nojaavat näihin käytänteisiin? Joku saattaa käyttää tiettyä mallia jatkuvasti omassa työssään ja jättää huomiotta tehokkaammat, järkevämmät mallit. Joku kaavoihinkangistunut nojaa vain ".Net Best Practises" -ohjenuoraan ja tekee samanlaista koodia koko elämänsä. Sitten on niitä, jotka tekevät huikeaa innovaatiota, rikkovat rajoja ja haastavat auktoriteetteja! Nämä "betterpraktisistit" ovat mielestäni se voima joka vie eri aloja eteenpäin: he eivät jää vatvomaan "parhaita käytäntöjä" vaan he puskevat eteenpäin ja vievät oman työnsä uudelle tasolle! Muut matkivat ja tekevät hänen malleistaan "parhaita", jolloin innovaattori jatkaa työtään ja etenee taas korkeammalle.
Kumpi sinä olet: Best Practice -mies (/-nainen) vai Better Practice -tyyppi?
Näin syntyi idea testausarkkitehdista ja testaus steering groupista. Meillä organisaatiossa on olemassa steering grouppeja jos jonkinmoisia ja niiden pääasiallinen sisältö on suurinpiirtein
jakaa "best practicet" eli parhaat käytännöt koskien koodia, työkaluja, ympäristöjä ja palveluita.Hip-kivaa! Parhaita käytäntöjä! Ja kun kaikki noudattavat parhaita käytäntöjä ei mikään voi mennä vikaan! Eihän! Eihän?
Itse pyrin kohti jatkuvaa kehitystä testauksen suhteen. Lisäksi on hienoinen kontekstitestausintoilija ja sitä kautta mielelläni kuuntelen JMB:n oppeja. Jokainen toimintamalli ja käytäntö on siis aina kiinnitetty kontekstiin ja aikaan. Kun molemmat muuttuvat, voidaanko sanoa että jokin ratkaisumalli on paras? Onko olemassa toista mallia joka on parempi kuin "paras käytäntö"? Voiko silloin sanoa, että on olemassa paras käytäntö?
Onko niin, että ihmiset laiskuudessaan ja aikataulupaineessa nojaavat näihin käytänteisiin? Joku saattaa käyttää tiettyä mallia jatkuvasti omassa työssään ja jättää huomiotta tehokkaammat, järkevämmät mallit. Joku kaavoihinkangistunut nojaa vain ".Net Best Practises" -ohjenuoraan ja tekee samanlaista koodia koko elämänsä. Sitten on niitä, jotka tekevät huikeaa innovaatiota, rikkovat rajoja ja haastavat auktoriteetteja! Nämä "betterpraktisistit" ovat mielestäni se voima joka vie eri aloja eteenpäin: he eivät jää vatvomaan "parhaita käytäntöjä" vaan he puskevat eteenpäin ja vievät oman työnsä uudelle tasolle! Muut matkivat ja tekevät hänen malleistaan "parhaita", jolloin innovaattori jatkaa työtään ja etenee taas korkeammalle.
Kumpi sinä olet: Best Practice -mies (/-nainen) vai Better Practice -tyyppi?
Monday, 25 July 2011
Testausheuristiikat 4/7
SFDPOT
Mallit ja mitattavat asiat. Jokaisessa tuotteessa on mitattavia asioita: pituus, leveys, kestävyys paineen alla, suorituskyky, jne. SFDPOT pureutuu näihin mitattaviin asioihin. S = Stucture, F = Functions, D = Data, P = Platform, O = Operations, T = Time. Mitattavia asoita voi siis olla sekä tuotteessa itsessään että asioissa, jotka vaikuttavat tuotteeseen.
Rakennetta käytettäessä heuristiikkana voidaan testata rakenteesta nousevia asioita. Käyttöliittymässä on syötekenttiä, painikkeita, tausta, kehykset. Kaikissa näissä on ominaisia testattavia asioita. Rakenteeseen liityvät asiat ovat usein helpoiten mitattavia ja niihin löytyy yleensä valmiita malleja.
Toiminta on sitä, minkälaista toiminnallisuutta tuote tarjoaa. Tämä voi olla laskentalogiikkaa, datan käsittelyä, jne. Tämä pitää kuitenkin pitää erossa käytöstä, koska tuotetta voidaan käyttää eri tavalla kuin sen toiminnallisuus on tarkoitettu. Hyvänä esimerkkinä exceliä voi käyttää vaikkapa pohjapiirrustuksen piirtoon vaikka sen toiminnallisuus on laskentalogiikkaa, jne.
Dataan liittyviä mitattavia asoita voivat olla kaikki sisääntulevan datan, ulosmenevän, järjestelmän sisällä käsiteltävän tai tulkittavan tiedon käsittelyä, määrää, yms. kuvaavat asiat. Data toimii myös lähteenä kaikelle tiedon käsittelynopeuteen, jne. liittyviin asioihin.
Alustasta löytyy myös mitattavia asioita käyttöjärjestelmästä rautaan, selaimiin, nettiyhteyksiin, jne. Alusta on kuten rakennekin, mutta tuotteen ulkopuolelta vaikuttavia voimia. Aika tulee kuvioon mukaan mittaamalla sovelluksen käyttäytymisenä suhteessa aikaan. Miten softa käyttäytyy vuoden yhtämittaisen käytön jälkeen? Jne.
Mallit ja mitattavat asiat. Jokaisessa tuotteessa on mitattavia asioita: pituus, leveys, kestävyys paineen alla, suorituskyky, jne. SFDPOT pureutuu näihin mitattaviin asioihin. S = Stucture, F = Functions, D = Data, P = Platform, O = Operations, T = Time. Mitattavia asoita voi siis olla sekä tuotteessa itsessään että asioissa, jotka vaikuttavat tuotteeseen.
Rakennetta käytettäessä heuristiikkana voidaan testata rakenteesta nousevia asioita. Käyttöliittymässä on syötekenttiä, painikkeita, tausta, kehykset. Kaikissa näissä on ominaisia testattavia asioita. Rakenteeseen liityvät asiat ovat usein helpoiten mitattavia ja niihin löytyy yleensä valmiita malleja.
Toiminta on sitä, minkälaista toiminnallisuutta tuote tarjoaa. Tämä voi olla laskentalogiikkaa, datan käsittelyä, jne. Tämä pitää kuitenkin pitää erossa käytöstä, koska tuotetta voidaan käyttää eri tavalla kuin sen toiminnallisuus on tarkoitettu. Hyvänä esimerkkinä exceliä voi käyttää vaikkapa pohjapiirrustuksen piirtoon vaikka sen toiminnallisuus on laskentalogiikkaa, jne.
Dataan liittyviä mitattavia asoita voivat olla kaikki sisääntulevan datan, ulosmenevän, järjestelmän sisällä käsiteltävän tai tulkittavan tiedon käsittelyä, määrää, yms. kuvaavat asiat. Data toimii myös lähteenä kaikelle tiedon käsittelynopeuteen, jne. liittyviin asioihin.
Alustasta löytyy myös mitattavia asioita käyttöjärjestelmästä rautaan, selaimiin, nettiyhteyksiin, jne. Alusta on kuten rakennekin, mutta tuotteen ulkopuolelta vaikuttavia voimia. Aika tulee kuvioon mukaan mittaamalla sovelluksen käyttäytymisenä suhteessa aikaan. Miten softa käyttäytyy vuoden yhtämittaisen käytön jälkeen? Jne.
Tuesday, 21 June 2011
Testaajat ovat rokkitähtiä!
Teemu Vesala kirjoitti STC:n blogissa testauksesta verraten sitä runoiluun. Se polkaisi käyntiin ajatuslennon, jossa huomasin vertaavani testausta (substantiivina) klassiseen musiikkiin. "Testaustyö on kuin klassisen musiikin säveltämistä kaikkine nyansseineen" oli hyvin pitkälti oman kommenttini sanoma ko. blogissa. Tästä alkoi kuitenkin twittaus, joka meni näin:
Wikipedia (ah! tuo tiedon ehtymätön lähde!) sanoo taiteesta näin:
Testaus, kuten taidekin, on erilaisten osasten (tekniikoiden, lähestymistapojen, työvälineiden, strategioiden) tarkoituksellisen järjestelyn tulosta. Kuten sanottu, testausta voidaan suorittaa adhoc, mutta kuten taide, se ei aina vastaa niitä tarkoitusperiä, mitä sillä haetaan. Prosessi (ajattelu- tai kehitys-), johon testaus pyrkii vaikuttamaan, voi hyvinkin olla ainakin osittain subjektiivinen, koska se on mielipide ja tulkinta. Poistamalla subjektiivisuuden taiteesta saadaan aikaan pakotettuja kauneusihanteita, ei-älykkäitä tulkintoja asioita. Subjektiivisuus on taiteessa voima, joka tekee taiteesta taiteen. Testauksessa subjektiivisuus on testauksen itsensä kannalta ehdottomasti voimavara, sillä erilaiset ihmiset tulkitsevat erilaisia asioita eri tavalla. Me voimme aina sanoa että "joku asia on X. Piste!", mutta se ei välttämättä ole oikein jossakin kontekstissa. Subjektiivisuus tulee siis kontekstien myötä tärkeäksi.
Tunteisiin vaikuttamisesta olen jo aiemmin muutaman sanan ylös kirjannut. Ei siis voida vähätellä sitä merkitystä, mikä tunteilla on testaukseen ja testauksella tunteisiin. Molemmat näistä ovat toisiaan ohjaavia tekijöitä. Taiteessa säveltäjän, maalarin, koreografin, kuvanveistäjän tunteet ovat eteenpäinvieviä voimia, jotka saavat taiteen aikaan. Toki on olemassa tunteetontakin taidetta, mutta onko se taidetta? Lisäksi on olemassa taidetta, joka ei vaikuta tunteisiin (tietyssä kontekstissa ja subjektiivisesti). Onko kaikki oleva jollakin tasolla taidetta? Taide pyrkii siis olemaan kaksisuuntainen tunteiden kanssa. Testaus myös: tuntemukset (käsitys riskeistä, priorisointi, jne) ohjaavat testausta ja testauksen herättämät tunteet ohjaavat päätöksentekoa.
Taide on ilmaisua, viestintää, kannanottoa ja mielihyvän/-pahan tuottamista. Tämä pätee testaukseen sanasta sanaan! Testaus on ilmaisua: me ilmaisemme järjestelmän sen hetkistä laatua testaamalla. Testaus on viestintää. Mitään muuta keinoa osoittaa ja viestiä laatua ei ole. Onko? Voidaanko koodaamalla ilmaista laatua? Ei koodaamalla luodaan se laatu, joka testaamalla ilmaistaan. Testaus ei tee laatua. Lisäksi kun puhutaan puhtaasti viestinnästä, testaus on sosiaalinen laji, jossa viestintä on tärkeä! Miten me voimme ilmaista laatua, jos emme viesti sitä viestikanavia pitkin sidosryhmille? Ja testaus ottaa kantaa! Michael Bolton sanoi hyvin: "Testin is defending the quality of the product." Testaus ottaa kantaa laatuun, testaus puolustaa tuotteen laatua. Jos testaus ei ota kantaa laatuun, kuka ottaa?
Mitä mielihyvään tulee, niin minulle jokainen testauspäivä tuottaa suurta mielihyvää (testaajani ovat sen varmaankin panneet merkille). Jokainen päivä, jona voin edistää testauksen voittokulkua sekä organisaatiossa että genrenä yleensä tuottaa mielihyvää. Jokainen päivä, jona opin lisää testauksesta, tuottaa mielihyvää. Joka kerta, kun löydän uuden vian järjestelmästä, se tuottaa mielihyvää (vaan mielipahaa projektipäällikölle ;) ).
Summa summarum: Testaus on taidetta. Testausta tulee arvostaa taiteena. Muistaakseni on olemassa matemaatikkoja, jotka ylistävät matematiikkaa suurimpana taiteena (fibonaccin lukuihin perustuvat graafit, kaaosteoreettiset kuvaajat ja fraktaalitaide). Testaajat ovat siis taiteilijoita. Me itseämme kunnioittavat, taitavat testaajat voimme pitää itseämme IT-maailman rocktähtinä (tai Leonardo da Vinceina). Me tuomme iloja ja suruja, viestimme tunteita, jopa kauneutta. Minulle, testaus on se suurin taide.
Teemu Vesala:Testaus on verrattavissa taiteeseen, kyllä, johtuen kaikista nyansseista mitä testaus sisältää. Vaan mikä ei olisi verrattavissa taiteeseen? Mitä taide on?
Poem writing and #testing has plenty of common. See my blog entry @ #stc http://ning.it/jF60aR
Pekka Marjamäki:
@teemuvesala #Testing is more like composing classical #music: even the tiniest sounds change the feel to it. And testing tells a story.
Teemu Vesala:
@pekkamarjamaki Acctually #testing is much like any art. No matter if it's poetry, music or painting. All have same properties.I love'em all
Wikipedia (ah! tuo tiedon ehtymätön lähde!) sanoo taiteesta näin:
Voiko testaus olla kulttuuria? Hyvä kysymys. Voiko testaus olla olematta osa projektikontekstuaalista (onkohan tuo edes sana?) kulttuuria? Testaus on se elementti, millä tarjotaan tietoa asioista, sillä testausta ilmenee niin monella tasolla tiedostamattomasta kyseenalaistamisesta systemaattiseen järjestelmien kokonaisuuden koestamiseen dynaamisesti ja staattisesti. Eli kyllä, testaus on osa kulttuuria (kontekstia) jossa testausta tehdään.
Taide on yksi kulttuurin peruskäsitteistä. Se koostuu erilaisten elementtien tarkoituksellisen järjestelyn tuloksista ja prosesseista, joilla pyritään vaikuttamaan tunteisiin tai ajatteluun subjektiivisella tasolla. Taide on ilmaisun, viestinnän, kannanoton ja mielihyvän tuottamisen väline.
Testaus, kuten taidekin, on erilaisten osasten (tekniikoiden, lähestymistapojen, työvälineiden, strategioiden) tarkoituksellisen järjestelyn tulosta. Kuten sanottu, testausta voidaan suorittaa adhoc, mutta kuten taide, se ei aina vastaa niitä tarkoitusperiä, mitä sillä haetaan. Prosessi (ajattelu- tai kehitys-), johon testaus pyrkii vaikuttamaan, voi hyvinkin olla ainakin osittain subjektiivinen, koska se on mielipide ja tulkinta. Poistamalla subjektiivisuuden taiteesta saadaan aikaan pakotettuja kauneusihanteita, ei-älykkäitä tulkintoja asioita. Subjektiivisuus on taiteessa voima, joka tekee taiteesta taiteen. Testauksessa subjektiivisuus on testauksen itsensä kannalta ehdottomasti voimavara, sillä erilaiset ihmiset tulkitsevat erilaisia asioita eri tavalla. Me voimme aina sanoa että "joku asia on X. Piste!", mutta se ei välttämättä ole oikein jossakin kontekstissa. Subjektiivisuus tulee siis kontekstien myötä tärkeäksi.
Tunteisiin vaikuttamisesta olen jo aiemmin muutaman sanan ylös kirjannut. Ei siis voida vähätellä sitä merkitystä, mikä tunteilla on testaukseen ja testauksella tunteisiin. Molemmat näistä ovat toisiaan ohjaavia tekijöitä. Taiteessa säveltäjän, maalarin, koreografin, kuvanveistäjän tunteet ovat eteenpäinvieviä voimia, jotka saavat taiteen aikaan. Toki on olemassa tunteetontakin taidetta, mutta onko se taidetta? Lisäksi on olemassa taidetta, joka ei vaikuta tunteisiin (tietyssä kontekstissa ja subjektiivisesti). Onko kaikki oleva jollakin tasolla taidetta? Taide pyrkii siis olemaan kaksisuuntainen tunteiden kanssa. Testaus myös: tuntemukset (käsitys riskeistä, priorisointi, jne) ohjaavat testausta ja testauksen herättämät tunteet ohjaavat päätöksentekoa.
Taide on ilmaisua, viestintää, kannanottoa ja mielihyvän/-pahan tuottamista. Tämä pätee testaukseen sanasta sanaan! Testaus on ilmaisua: me ilmaisemme järjestelmän sen hetkistä laatua testaamalla. Testaus on viestintää. Mitään muuta keinoa osoittaa ja viestiä laatua ei ole. Onko? Voidaanko koodaamalla ilmaista laatua? Ei koodaamalla luodaan se laatu, joka testaamalla ilmaistaan. Testaus ei tee laatua. Lisäksi kun puhutaan puhtaasti viestinnästä, testaus on sosiaalinen laji, jossa viestintä on tärkeä! Miten me voimme ilmaista laatua, jos emme viesti sitä viestikanavia pitkin sidosryhmille? Ja testaus ottaa kantaa! Michael Bolton sanoi hyvin: "Testin is defending the quality of the product." Testaus ottaa kantaa laatuun, testaus puolustaa tuotteen laatua. Jos testaus ei ota kantaa laatuun, kuka ottaa?
Mitä mielihyvään tulee, niin minulle jokainen testauspäivä tuottaa suurta mielihyvää (testaajani ovat sen varmaankin panneet merkille). Jokainen päivä, jona voin edistää testauksen voittokulkua sekä organisaatiossa että genrenä yleensä tuottaa mielihyvää. Jokainen päivä, jona opin lisää testauksesta, tuottaa mielihyvää. Joka kerta, kun löydän uuden vian järjestelmästä, se tuottaa mielihyvää (vaan mielipahaa projektipäällikölle ;) ).
Summa summarum: Testaus on taidetta. Testausta tulee arvostaa taiteena. Muistaakseni on olemassa matemaatikkoja, jotka ylistävät matematiikkaa suurimpana taiteena (fibonaccin lukuihin perustuvat graafit, kaaosteoreettiset kuvaajat ja fraktaalitaide). Testaajat ovat siis taiteilijoita. Me itseämme kunnioittavat, taitavat testaajat voimme pitää itseämme IT-maailman rocktähtinä (tai Leonardo da Vinceina). Me tuomme iloja ja suruja, viestimme tunteita, jopa kauneutta. Minulle, testaus on se suurin taide.
Sunday, 19 June 2011
Testausheuristiikat 3/7
HICCUPPS
Tämä viittaa tuotteen testauksessa oraakkeleihin. Eli mihin voit perustaa havaintojen oikeellisuuden. Oraakkeli on kuten heuristiikan yleensä "ehkä päteviä omassa kontekstissaan". Oraakkeli siis kertoo /mielipiteen/, joka ohjaa toimintaa tavalla tai toisella. Oraakkelit koostuvat seuraavista: H = History, I = Image, C = Comparable products, C = Claims, U = User expectations, P = Purpose, P = Product itsef, S = Standards. Nämä ovat ylseensä jo testauksen aikana tapahtuvia heuristisia ajatusmalleja. Näillä voidaan mitata tuotteen yhteneväisyyttä jonkin oraakkein kanssa. Onko se yhteneväinen asiakkaan esittämien lupausten kanssa? Onko se yhteneväinen itsensä kanssa?
Historia antaa aina ideoita testaukseen. Miten tuote käyttäytyi edellisissä versioissa, eilen, jne. Tämä osittain sisältää myös bugilistat.
Yrityksen antama kuva toimii heuristiikkana silloin, kun testauksen kohde on räikeästi tai hienovaraisesti pois yrityksen antamasta linjasta. Esimerkiksi Officetuotteissa on samantyyppinen ulkoasu, joten linjasta poikkavien asioiden huomaaminen on helppoa. Toisaalta esimerkiksi vakavarainen vakuutustoimija saattaa haluta ilmaista järjestelmillään luotettavuutta, jota kirjoitusvirheet sivuilla eivät edusta.
Verrokkituotteet ovat äärimmäisen hyvä oraakkeli. Jos on olemassa esimerkiksi tuotantoversio, johon tehdään päivitys, voidaan alkuperäisestä varmistaa toimintojen käyttäytymistä. Jos kilpailijalla on saman tyyppinen tuote, sitä voidaan käyttää vertailuun.
Lupaukset ja julkaisut ovat omiaan tuottamaan testausideoita. Manuaalit, helppi-tiedostot, mainokset, jne. voivat tarjota ideoita, jotka käyttäjän näkökulmasta sotisivat lupauksia vastaan. Lisäksi käyttöohjeiden testaaminen sovellusta vasten voi olla hyödyllistä myös käyttöohjeen itsensä kannalta.
Käyttäjän odotuksien kanssa yhteneväisyydessä saatta olla ongelmia. Jos olettaa esimerkiksi, että ohjelma käynnistyy automaattisesti ja se vaatiikin pääkäyttäjäoikeudet, saattaa virheilmoitus aiheuttaa närää käyttäjällä. Odotukset ylipäänsä ovat vahva oraakkeli, koska ne viittaavat siihen miten oikeasti tuotetta käytetään.
Tarkoituksen vastaan sotivien asioiden testaus saattaa herättää mielenkiintoisia kysymyksiä. Onko tarkoitus, että sääennustussovellus täyttää veroilmoituksesi? Onko tarkoituksenmukaista kaksoisklikata linkkiä, jos yksi painallus selvästi riittää?
Tuote itsessään voi olla ristiriidassa itsensä kanssa. Esimerkiksi saman tiedon näyttäminen samassa järjestelmässä eri tavalla. Tämä saattaa horjuttaa luottamusta tietojen oikeellisuuteen ("Älä pidä kahta kelloa laivassa. Jos toinen on väärässä, niin mistä tietää kumpi on oikeassa."). Ongelmia voi tulla eri näkymien erilaisuudesta tai vaikkapa virheilmoitusten yhteneväisyydestä.
Lait, asetukset, standardit tuovat oman mausteensa testaukseen ja yhtenevyys lakeihin esimerkiksi vakuutus- tai ilmailuhallintajärjestelmissä voi aiheuttaa jopa vaaratilanteita. (Se että turvallisuuskriittisten järjestelmien testaus ei aina ole viisasta pelkästää heuristiikkoja hyväksikäyttäen, on aivan toinen lukunsa.)
Tämä viittaa tuotteen testauksessa oraakkeleihin. Eli mihin voit perustaa havaintojen oikeellisuuden. Oraakkeli on kuten heuristiikan yleensä "ehkä päteviä omassa kontekstissaan". Oraakkeli siis kertoo /mielipiteen/, joka ohjaa toimintaa tavalla tai toisella. Oraakkelit koostuvat seuraavista: H = History, I = Image, C = Comparable products, C = Claims, U = User expectations, P = Purpose, P = Product itsef, S = Standards. Nämä ovat ylseensä jo testauksen aikana tapahtuvia heuristisia ajatusmalleja. Näillä voidaan mitata tuotteen yhteneväisyyttä jonkin oraakkein kanssa. Onko se yhteneväinen asiakkaan esittämien lupausten kanssa? Onko se yhteneväinen itsensä kanssa?
Historia antaa aina ideoita testaukseen. Miten tuote käyttäytyi edellisissä versioissa, eilen, jne. Tämä osittain sisältää myös bugilistat.
Yrityksen antama kuva toimii heuristiikkana silloin, kun testauksen kohde on räikeästi tai hienovaraisesti pois yrityksen antamasta linjasta. Esimerkiksi Officetuotteissa on samantyyppinen ulkoasu, joten linjasta poikkavien asioiden huomaaminen on helppoa. Toisaalta esimerkiksi vakavarainen vakuutustoimija saattaa haluta ilmaista järjestelmillään luotettavuutta, jota kirjoitusvirheet sivuilla eivät edusta.
Verrokkituotteet ovat äärimmäisen hyvä oraakkeli. Jos on olemassa esimerkiksi tuotantoversio, johon tehdään päivitys, voidaan alkuperäisestä varmistaa toimintojen käyttäytymistä. Jos kilpailijalla on saman tyyppinen tuote, sitä voidaan käyttää vertailuun.
Lupaukset ja julkaisut ovat omiaan tuottamaan testausideoita. Manuaalit, helppi-tiedostot, mainokset, jne. voivat tarjota ideoita, jotka käyttäjän näkökulmasta sotisivat lupauksia vastaan. Lisäksi käyttöohjeiden testaaminen sovellusta vasten voi olla hyödyllistä myös käyttöohjeen itsensä kannalta.
Käyttäjän odotuksien kanssa yhteneväisyydessä saatta olla ongelmia. Jos olettaa esimerkiksi, että ohjelma käynnistyy automaattisesti ja se vaatiikin pääkäyttäjäoikeudet, saattaa virheilmoitus aiheuttaa närää käyttäjällä. Odotukset ylipäänsä ovat vahva oraakkeli, koska ne viittaavat siihen miten oikeasti tuotetta käytetään.
Tarkoituksen vastaan sotivien asioiden testaus saattaa herättää mielenkiintoisia kysymyksiä. Onko tarkoitus, että sääennustussovellus täyttää veroilmoituksesi? Onko tarkoituksenmukaista kaksoisklikata linkkiä, jos yksi painallus selvästi riittää?
Tuote itsessään voi olla ristiriidassa itsensä kanssa. Esimerkiksi saman tiedon näyttäminen samassa järjestelmässä eri tavalla. Tämä saattaa horjuttaa luottamusta tietojen oikeellisuuteen ("Älä pidä kahta kelloa laivassa. Jos toinen on väärässä, niin mistä tietää kumpi on oikeassa."). Ongelmia voi tulla eri näkymien erilaisuudesta tai vaikkapa virheilmoitusten yhteneväisyydestä.
Lait, asetukset, standardit tuovat oman mausteensa testaukseen ja yhtenevyys lakeihin esimerkiksi vakuutus- tai ilmailuhallintajärjestelmissä voi aiheuttaa jopa vaaratilanteita. (Se että turvallisuuskriittisten järjestelmien testaus ei aina ole viisasta pelkästää heuristiikkoja hyväksikäyttäen, on aivan toinen lukunsa.)
Subscribe to:
Posts (Atom)