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.

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? ;)

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
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?