SUOMEKSI?
Lupailin kääntää nämä heuristiikat suomeksi jossakin vaiheessa. Näistä voisi siis muodostaa musitisääntöinä:
CIDTESTD voisi olla KATTIVAT eli Kehittäjä, Asiakas, Testaustiimi, Testauksen kohde, Informaatio, Välineet, Aikataulu, Testaustuotteet. "Kattivat, tuo kissojen kuningas!"
SFDPOT voisi olla RADKAT eli Rakenne, Alusta, Data, Käyttö, Aika, Toiminnallisuus. "Radkat, tuo kissojen radioaktiivinen supersankari!"
HICCUPPS voisi olla HYVLOTTA eli Historia, Yrityskuva, Verrokkituotteet, Lupaukset, Odotukset, Tarkoitus, Tuote ja Asetukset. "Hyvä Lotta!"
CRUSSPICSTMPL voisi olla KASTLLTSYKSYT eli Kykynevyys, Asennettavuus, Suorituskyky, Turvallisuus, Luotettavuus, Lokalisointi, Testattavuus, Siirrettävyys, Ylläpidettävyys, Käytettävyys, Skaalautuvuus, Yhteensopivuus ja Tuettavuus. "Sade on kastellut syksyt"
FDSFSCURA voisi sitten olla KATSTSKVR eli Ketjutestaus, Automaatiotestaus, Toiminnallinen testaus, Skenaariotestaus, Toimialakohtainen testaus, Stressitestaus, Käyttäjätestaus, Väitetestaus ja Riskitestaus. "Katsastuskaveri"
Tämä on viimeinen ns. heuristiikkablogaus, jonka teen osittain työn puolesta. Jatkossa pyrin kertomaan heuristiikoista miten itse niitä käytän ja miten saan niistä mahdollisimman paljon irti. Tässä kuitenkin niille, jotka "kinusivat" noita RST-heuristiikkoja suomeksi. ;)
Saturday, 5 November 2011
Monday, 17 October 2011
Testausheuristiikat 6/7
FDSFSCURA
Tekniikkoihin ja lähestymistapoihin pureutuva FDSFSCURA tarjoaa on omiaan kertomaan MITEN ja MITÄ kannattaa testata. Tekniikoita ovat siis: F = Function Testing, D = Domain Testing, S = Stress Testing, F = Flow Testing, S = Scenario Testing, C = Claims Testing, U = User Testing, R = Risk Testing, A = Automatic Testing. Tällä pyritään valottamaan sitä, että on useampiakin tapoja tehdä testausta kyseiseen tuotteeseen.
Toiminnallinen testaus on käytännössä sitä, että testataan "mitä voi tehdä". Tunnistetaan funktioiden ja toiminnallisuuksien tarkoamat ominaisuudet ja testataan niihin liittyviä asioita. Hyvä mittaamaan kykyä luotettavuuden sijaan. Toiminnallinen testaus on yleensä mukana muissakin heuristiikoissa tavalla tai toisella, mutta tässä tarkoitetaan nimenomaan toiminnallisuuden tarkastamista, että "se toimii oikein".
Toimialakohtainen testaus liittyy yleensä dataan. Kattamalla erilaisia datakombinaatioilla voidaan löytää asioita, joita puhtaasti toiminnallinen testaus ei löydä. Esimerkiksi vakuutusalalla on useita testaustekniikoita, testi-ideoita ja variaatioita, jotka koskevat vain ko. alaa. Myös logistiikka-ala, pankkiala, jne. sisältävät oman toimialan erikoistapauksia.
Stressitestauksella pyritään kyykyttämään järjestelmää parhaalla mahdollisella tavalla. Näin saadaan esiin muistivuotoja, validointivirheitä ym. jotka nousevat esiin vain paineen alla. Tietokantatasolla saadaan massatestauksella aikaan mahdolliset lukkotilanteet sekä datan ylikirjautuminen tai kirjautumatta jääminen.
Ketjuttamisella voidaan testata toimintoja toisen perään. Voidaan myös testata prosessia niin, että jätetään pakollisia toimintoja välistä tai tullaan prosessiin keskeltä mukaan. Näin löydetään ongelmia, jotka eivät ole riippuvaisia yhden toiminnallisuuden asioista. Mallipohjaisessa testauksessa testausautomaatiolla voidaan toteuttaa helpostikin pitkiäkin ketjuja sekä niiden variaatioita.
Skenaariotestauksella testataan asioita tuotteen ympäriltä sekä liittymistä. Skenaario on eräänlainen käyttötapaus, mutta joka on lähemmin yhteydessä todelliseen käyttöön ja ympäröiviin asioihin. Käyttötapauksia hyväksikäyttäen voidaan luoda sellaisia skenaarioita, missä on muuttujina esimerkiksi alusta, käyttäjän taito, aika, data ja/tai muut muuttujat.
Väitetestauksella tarkoitetaan siis määrityksiä, lupauksia, vaateita. Niitä testataan sekä tuotetta vasten ja tuotetta testataan niitä vasten. Tarkoitus on sekä tarkentaa "väitettä" ja tuotetta. Väitteet voidaan myös poimia asiakkaan tai tuotteen omistajan puheesta ja testata, josko "luvataan liikoja".
Käyttäjätestaus liittyy usein käyttäjän kykyihin käyttää järjestelmää. Miten punavihersokea pystyy aistimaan dashboradin elementit? Miten ummikko pystyy käyttämään kompleksista toiminnanohjausjärjestelmää? Entä käyttäjät, jotka käyttävät suoraan ohjeesta? Entä käyttäjät, jotka kokeilevat ja testailevat tuotetta?
Riskitestauksella pyritään tunnistamaan riskejä ja yrittämään toteuttaa ne. Voiko riskin toteuttaa järjestelmällä? Voiko siitä seurata ongelmia? Tässä kannattaa käyttää hyväksi asiantuntemusta myös liiketoiminnasta ja kehittäjiltä, jotta voidaan löytää ne suurimmat rsikit omaavat osa-alueet. Riskitestauksella voidaan myös mitigoida riskejä tai nostaa esiin uusia riskejä.
Automaatiotestaus tarkoittaa käytännössä testi ajamista tuhanisa kertoja tai automatisoimalla testin muuttumaan hieman. Näin voidaan nopeasti kehittää suuri määrä testejä joilla voidaan löytää ongelmia, joita manuaalinen testaus ei löydä. Esimerkiksi Brute force -tietoturvatestaus löytää helpommin aukkoja tietoturvasta kuin manuaalisesta samojen testien ajaminen. Lisäksi tietoturvatestausta harvemmin kannattaa toteuttaa manuaalisesti, sillä usein tietoturva-aukkoja etsitään koneitse.
Tekniikkoihin ja lähestymistapoihin pureutuva FDSFSCURA tarjoaa on omiaan kertomaan MITEN ja MITÄ kannattaa testata. Tekniikoita ovat siis: F = Function Testing, D = Domain Testing, S = Stress Testing, F = Flow Testing, S = Scenario Testing, C = Claims Testing, U = User Testing, R = Risk Testing, A = Automatic Testing. Tällä pyritään valottamaan sitä, että on useampiakin tapoja tehdä testausta kyseiseen tuotteeseen.
Toiminnallinen testaus on käytännössä sitä, että testataan "mitä voi tehdä". Tunnistetaan funktioiden ja toiminnallisuuksien tarkoamat ominaisuudet ja testataan niihin liittyviä asioita. Hyvä mittaamaan kykyä luotettavuuden sijaan. Toiminnallinen testaus on yleensä mukana muissakin heuristiikoissa tavalla tai toisella, mutta tässä tarkoitetaan nimenomaan toiminnallisuuden tarkastamista, että "se toimii oikein".
Toimialakohtainen testaus liittyy yleensä dataan. Kattamalla erilaisia datakombinaatioilla voidaan löytää asioita, joita puhtaasti toiminnallinen testaus ei löydä. Esimerkiksi vakuutusalalla on useita testaustekniikoita, testi-ideoita ja variaatioita, jotka koskevat vain ko. alaa. Myös logistiikka-ala, pankkiala, jne. sisältävät oman toimialan erikoistapauksia.
Stressitestauksella pyritään kyykyttämään järjestelmää parhaalla mahdollisella tavalla. Näin saadaan esiin muistivuotoja, validointivirheitä ym. jotka nousevat esiin vain paineen alla. Tietokantatasolla saadaan massatestauksella aikaan mahdolliset lukkotilanteet sekä datan ylikirjautuminen tai kirjautumatta jääminen.
Ketjuttamisella voidaan testata toimintoja toisen perään. Voidaan myös testata prosessia niin, että jätetään pakollisia toimintoja välistä tai tullaan prosessiin keskeltä mukaan. Näin löydetään ongelmia, jotka eivät ole riippuvaisia yhden toiminnallisuuden asioista. Mallipohjaisessa testauksessa testausautomaatiolla voidaan toteuttaa helpostikin pitkiäkin ketjuja sekä niiden variaatioita.
Skenaariotestauksella testataan asioita tuotteen ympäriltä sekä liittymistä. Skenaario on eräänlainen käyttötapaus, mutta joka on lähemmin yhteydessä todelliseen käyttöön ja ympäröiviin asioihin. Käyttötapauksia hyväksikäyttäen voidaan luoda sellaisia skenaarioita, missä on muuttujina esimerkiksi alusta, käyttäjän taito, aika, data ja/tai muut muuttujat.
Väitetestauksella tarkoitetaan siis määrityksiä, lupauksia, vaateita. Niitä testataan sekä tuotetta vasten ja tuotetta testataan niitä vasten. Tarkoitus on sekä tarkentaa "väitettä" ja tuotetta. Väitteet voidaan myös poimia asiakkaan tai tuotteen omistajan puheesta ja testata, josko "luvataan liikoja".
Käyttäjätestaus liittyy usein käyttäjän kykyihin käyttää järjestelmää. Miten punavihersokea pystyy aistimaan dashboradin elementit? Miten ummikko pystyy käyttämään kompleksista toiminnanohjausjärjestelmää? Entä käyttäjät, jotka käyttävät suoraan ohjeesta? Entä käyttäjät, jotka kokeilevat ja testailevat tuotetta?
Riskitestauksella pyritään tunnistamaan riskejä ja yrittämään toteuttaa ne. Voiko riskin toteuttaa järjestelmällä? Voiko siitä seurata ongelmia? Tässä kannattaa käyttää hyväksi asiantuntemusta myös liiketoiminnasta ja kehittäjiltä, jotta voidaan löytää ne suurimmat rsikit omaavat osa-alueet. Riskitestauksella voidaan myös mitigoida riskejä tai nostaa esiin uusia riskejä.
Automaatiotestaus tarkoittaa käytännössä testi ajamista tuhanisa kertoja tai automatisoimalla testin muuttumaan hieman. Näin voidaan nopeasti kehittää suuri määrä testejä joilla voidaan löytää ongelmia, joita manuaalinen testaus ei löydä. Esimerkiksi Brute force -tietoturvatestaus löytää helpommin aukkoja tietoturvasta kuin manuaalisesta samojen testien ajaminen. Lisäksi tietoturvatestausta harvemmin kannattaa toteuttaa manuaalisesti, sillä usein tietoturva-aukkoja etsitään koneitse.
Wednesday, 12 October 2011
Testaajat eivät ehdi testata
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ä.
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ä.
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.
Subscribe to:
Posts (Atom)