Friday 11 November 2011

Testausta SOA-maailmassa

Inspiroiduin tässä, oman projektini tiimoilta, jakamaan ajatuksia SOA maailman testauksesta. En ole vielä blogiini paljoakaan kirjoittanut puhtaasti testaukseen liittyvistä asioista, joten kokemuksien jakamiseksi voisin tässä hieman valottaa miten meillä SOA maailmassa on testattu. Tämä on siis puhtaasti minun näkökulmani oman testaustiimini toiminnasta eikä edusta koko yrityksen testausmalleja, jne jne. (Perinteinen "The following comments and statements are not the official..." -lakiteksti.) =) Lisäksi tämä ei ole projektikertomus vaan "testauskertomus", jossa paljon valonhohdetta kehitys ja projektiympäristöstä jää varmasti puuttumaan. Pahoittelut siitä: Te teette hyvää työtä, äijät ja gimmat! Jos olen jonkin yksityiskohdan tai muun unohtanut, vääristänyt tai kärjistänyt, niin pyydän syvästi anteeksi niiltä, joita se loukkaa. Tämä on minun näkemykseni tästä ko. projektista ja sisältää tunnelatauksella kirjoitettua kuvausta, josta kaikki ei ole 100% tarkkaa.

Hieman taustaa:

Kyseessä on siis monikansallinen SOA maailmaan toteutettu nelitasoarkkitehtuuripalvelu, jossa integroidaan puolisen tusinaa räätälöityä palvelua ja järjestelmää yhdeksi kokonaiskattavaksi palveluksi. Integraatioalustana toimii SonicESB ja SOA malli on webservice-pohjainen toteutus. Ohjelmoinnissa on käytetty pääasiassa C# ja Javaa (useita eri järjestelmiä). Palvelut ovat webbisovelluksia MySQL kannoilla. Tarkempaa tietoa en tässä lähde jakamaan, mutta perusperiaate on se, että meillä on integraatioputkia asiakkailta meille, jossa dataa puljataan ja tehdään sillä erilaisia temppuja, ja sitten putkea pitkin takaisin laitetaan jalostettua dataa. Simple, fun, "iz all good".

Vaan testaus tässä SOA-maailmassa osoittautui hieman erityyppiseksi kuin olin aiemmissa projekteissani testausta harrastanut. Projekti alkoi 2010 keväällä ja jatkuu vieläkin. Tuolloin keväällä luotiin kattavat testaussuunnitelmat sekä testitapaukset. Testausstrategia oli periytynyt aiemmasta php-MySQL-sovelluksesta, joten strategia oli kohtuu simppeli. Toiminnallista testausta, suorituskykytestausta integraatio ja systeemitestaustasolla. Yksikkötestit eivät juurikaan meikäläistä huolettaneet, olihan se kehittäjien peruskauraa. Testausautomaatiota ei juurikaan ollut, mutta toisessa yksikössä kehitetty CI-prosessi alkoi kiinnostamaan.

Jo alussa totesin, että ketterän kehityksen yhdistäminen SOA-maailmaan loi SUURIA kuoppia testaussuunnittelussa eikä IEEE-standardien mukainen testaussuunnittelu onnistunut sprinttimaailmassa. Siirryinkin testauksessa sulavasti "Definition of Done" -tyyppiseen testaukseen, jossa testitapaukset toimivat tukipilarina sekä "heuristiikkana" toiminnallisuuksien testaamisessa. Tämä malli oli toimiva jo toteutetuissa GUI:ssa ja perus bisneslogiikka toteutuksissa. Testejä tehtiin ja toiminnallisuuksia saatiin vietyä usein jopa asiakkaalle asti.

Ongelmat alkoivat kasaantua, kun SOA nosti rumaa päätään. Integroitiin pari järjestelmää ja liitettiin käyttöliittymä webserviceiden kautta taustalogiikkaan. Lisäksi integraatioputki asiakkaalta vaati testausta. Lähes kaikki integraatiotason testaus pamahti työpöydälle samaan aikaan ja testidataa ei ollut kenelläkään. Päivien työ kului konffatessa testidataa ja automatisoimalla integraatiotestejä - samalla koko toteutus muuttui pikkuhiljaa ja testit vanhentuivat. Päivitysrumbaan tuli kokoajan uutta testattavaa ja ylityöt alkoivat paukkua.

Syksyyn mennessä olimme saaneet ketterään tiimiimme toisen testaajan, joka samoin tein kiinnitettiin teknisempään testaukseen hänen ohjelmointitaustastaan johtuen. Työn määrä ei vaan mitenkään ottanut vähentyäkseen, kun mentiin kokoajan syvemmälle integraatio- ja järjestelmäintegraatiotasoille.

Joulun koittaessa 2010 olimme tilanteessa, jossa meillä oli kuusi järjestelmää, jotka kaikki käyttivät integraatioalustaa ja kommunikoivat toistensa kanssa ja releasepäivä lähestyi. Hain apua CI-porukalta ja aikaan saatiinkin Jenkinsillä kivasti ajettavat testisetit. Lisäksi yksikkötason ESB-prosessitestaaja saatiin refaktoroimaan prosesseja ja automatisoimaan testit. Lisäksi JMeterin suorituskykytestit sekä Soap-kuomitustestit saatiin (osittain) automatisoitua ja päästiin hieman lähemmäs hyvää testikattavuutta.

Joulu tuli ja Joulun alla piti olla suuri release, mutta vaikka testit menivät läpi, järjestelmä ei toiminut. Testiinluovutustilaisuudessa integraatiokerros lakkasi vastaamasta ja homma päättyi siihen. Testausta suovittiin ja ohjelmoijien kykyä tehdä toimivaa koodia. Jokainen taisi mennä itseensä ja silloinen tekninen projektipäällikkökin vaihtoi puljua. Kaaos oli taattu.

Saimme kuitenkin projektin urille hiomalla ja aikatauluja rukkaamalla, ja ennen kaikkea asiakkaan luottamuksen takaisin. Testaus tehtiin ketterämmin ja paremmassa yhteistyössä kehittäjien kanssa. Yksikkötestausta painotettiin ja suorituskykytestien perusteella tehtiin refaktorointia kiireen ohella. Ensimmäinen versio saatiin siis pilottiin vaikka meillä oli tiedossa X-määrä melko pahojakin vikoja. Pilotti oli kankeaa ja integraatiokerros takkuili. Ympäristöjen kanssa oli ongelmaa.

Toukokuu läheni ja siirryimme testauksessa jäykästä IEEE dokumentointimallista Boltonin kouluttamaan RST-malliin, jossa meillä oli sekä sessiopohjainen testauksen hallinta että tutkivan testauksen menetelmät käytössä. Saimme kymmenkertaistettua vian löytötahdin ja saimme pienennettyä testaussykliä kehittäjien kanssa. Tulosta saatiin! Lisäksi ympäristöongelmien kanssa päästiin eteenpäin ja stabiiliutta saatiin. Ensimmäinen KUNNON pilottiinsiirto saatiin toukokuussa ja pilotti ulkomailla eteni hyvin. Kiitosta tuli uuden testausprosessin myötä ja kehittäjiä kiiteltiin ja jopa koko projektiryhmä sai pienen kannustuspalkinnon.

Tässä vaiheessa alkoi kuitenkin pilvet kasaantua, kun päätettiin tehdä datamallin muutos integraatiokerrokseen. Asian piti olla kohtalaisen läpihuutojuttu: muutetaan kirjastot, rajapinnat, muutetaan arkkitehtuuria nopeuttamiseksi, refaktoroidaan komponentteja, yhdistellään... WHAT?! Tämä läpihuutojuttu osoittautuikin käytännössä KAIKKEEN vaikuttavaksi ("God bless that SOA!") ja testaus oli avainasemassa näiden muutosten läpiviennissä.

Kaikki testit jouduttiin päivittämään ja vielä yhtä aikaa. Kaikki ketjut piti uudelleensuunnitella, jokainen kanta-assertio tarkistaa. Kehittäjät olivat tehneet siis muutokset lokaalisti ja jokainen omat muutoksensa. Nyt niiden ollessa samassa korissa me testaajat olimme pulassa... Tai olemme. Tuo on tämänhetkinen tilanne.

--

Aiemmin sanoin "vähän taustaa", mutta tästä muodostuikin melko kattava kertomus. Mitä tästä jäi käteen? Paljon ylityötä? Kritiikkiä? Koloja asiakassuhteessa? Mitä me opimme (tai opimme edelleen)?

Illan pimeinä tunteina, kun muu testausporukka on jo lähetetty lataamaan akkuja, saatan istua koneella ja etsiä vastauksia kysymyksiin. Miten testaus on järkevä organisoida SOA maailmassa? Mihin sijoittaa se vähä määrä testauspanosta, joka meillä on antaa tälle projektille?

Mietin testauksen alihankintaa, jossa toteutamme testitapaukset ja alihankkijaryhmä saa testata softan etu- ja takaperin. Vaan sen verran olen oppinut, että SOA maailmassa täytyy olla ketterä ja liian skriptatut testitapaukset ja -ideat muodostuvat päivitystaakaksi, josta ei ole pakoa. Ketteryys on siis avain. Vaan miten ketteröitetään testausta?

Lähdimme hyväksi havaittua tutkivan testauksen lähestymistapaa hyväksikäyttäen kartoittamaan tilanteita ja riippuvuuksia. Saimme paremmin tietoa käyttämällä taitoamme ja tietoamme koostamaan järjestelmästä kokonaiskuvan kaikkine integraatioineen ja rajapintoineen. Päätimme pitää tiettyjä osa-alueita mustina laatikkoina ja kriittisiin solmukohtiin syvennyimme tarkemmin. Automaatiota parannettiin parametrisoimalla testitapauksia tehokkaammin ja jopa poistamalla päivityshelvetiksi muodostuneita tapauksia. Testasimme myös aikaisemmin kuin aiemmin, jolloin saimme tietää riippuvuuksia ennen niiden toteuttamista.

Testauspolitiikka alkoi muuttumaan "pass/fail" -tyyppisestä "kaikki testit menevät läpi, mutta ne löytävät/eivät löydä vikoja, poikkeamia, riskejä, huomioita, häiriöitä, jne." -tyyppiseen. Pyrimme tuomaan asoita esille enemmänkin tarinana kuin punainen/vihreä -periaatteella. Me halusimme antaa tietoa järjestelmästä kehittäjille ja projektin päättäjille.

Myös strategia päivittyi jäykästä ketterään. Tekniikat olivat testaajien kontekstiin sopiviksi valittavia ja työkaluja käytettiin parhaiden taitojen mukaisesti (ei parhaiden käytäntöjen). Saimme työkaluista irti sellaisia ominaisuuksia, joita emme olleen aiemmin käyttäneet johtuen käytänteistä. Pystyimme tekemään pidempiä ketjutuksia ja tarkempia assertioita ja kantatarkistuksia. Heuristinen lähestymistapa systeemitestaukseen vei meidän kauemmas ja lähemmäs testattavaa softaa (välillä rautaa) ja nosti aivan uudenlaisia vikoja ja puutteita järjestelmästä. Vaikka vikojen määrä on tähtitieteellinen verrattuna projektin aiempiin vaiheisiin, niin laatu on noussut - ihmiset ottavat opikseen huomioista, riskeistä, kysymyksistä. Testaus nostaa esiin asioita, joita kukaan ei ole ennen ajatellut. Testaus nostaa esiin asioita, mitä harva on aiemmin edes tajunnut! Testaajat eivät etsi vain bugeja vaan testaajat kertovat kaikesta, mitä havainnoivat.

Testaus tarjoaa enemmän tietoa kuin koskaan aiemmin ja se vie meitä eteenpäin. Ja nyt mennään taas eteenpäin, että saadaan tämä projektivaihe kunnialla maaliin!

Saturday 5 November 2011

Testausheuristiikat 7/7

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

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.

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ä.

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?

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.

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:

Teemu Vesala:
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
Testaus on verrattavissa taiteeseen, kyllä, johtuen kaikista nyansseista mitä testaus sisältää. Vaan mikä ei olisi verrattavissa taiteeseen? Mitä taide on?

Wikipedia (ah! tuo tiedon ehtymätön lähde!) sanoo taiteesta näin:

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

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.)

Testausheuristiikat 2/7

CIDTESTD

Tämä heuristiikka viittaa projektiin ja ympäristön tuomiin testausajatuksiin. C = Customer, I = Information, D = Developers, T = Test team, E = Equipment, S = Schedule, T = Test item, D = Deliverables. Näillä heuristiikoilla on tarkoitus suunnitella ja priorisoida tulevaa testausta. Näillä heuristiikoilla helpotetaan kontekstin havaitsemista, ja tuotteen ja testaajien sijoittumista ympäristöönsä.

Asiakkaan tapauksessa testi-ideointi tapahtuu lähinnä sellaisella tasolla, että "mitä tietoa asiakas voi meille tarjota ko. asiasta, jota emme jo tiedä tai ole huomanneet kysyä". Tämä ei siis tarkoita, että asiakas on testausidea itsessään, mutta asiakkaan huomioiminen testausta ideoitaessa voidaan löytää asioita, joita projekti tai projektiryhmä itsessään ei pystyisi tarjoamaan. Asiakasta kannattaa ja pitääkin kyseenalaistaa, koska usein on niin, että asiakas ei itsekään aivan tarkkaan tiedä mitä haluaa. Kyseenalaistamalla voidaan parantaa asiakkaan tietämystä omista haluistaan ja vaatimuksistaan. Testaajalla on suuri rooli parantaa kaikkien sidosryhmien tietämystä ja ymmärrystä tuotteesta.

Informaation toimii heuristiikkaana käytännössä asettamalla fokuksen dokumentteihin. Tässä kohtaa painota, että dokumentteihin luottaminen ei saa olla testauksen pääasia. Dokumentit ovat vanhentuneita, viallisia, saavuttamattomissa, jne. Ne saattavat kuitenkin sisältää sellaista tietoa, mitä testauksessa tarvitaan. Ne ovat yksi heuristiikka eli ne "voivat olla päteviä ko. kontekstissa". Dokumentit ovat kuitenkin hyödyllisiä ja niiden olemassaoloon on usein syy. Ne tapaavat tuoda lisää tietoa asioihin, mutta niihin ei kannata sokeasti luottaa. Dokumentteihin pätee samat kyseenalaistamisen säännöt kuin ihmisiinkin!

Kehittäkät ja testaustiimi tuovat oman panoksensa testien ideoinnissa. Testausryhmän sisäinen dynamiikka yleensa johtaa tiettyihin painotuksiin ja jokaisen panos on tärkeä testi-ideoita mietittäessä. Jokainen nimittäin testaa eri lailla ja jokaiselle eri asiat ovat tärkeämpiä kuin toiselle. Kehittäjien mielipiteet, taidot, mieltymykset antavat myös omat ideansa testaukseen. Jonkin kehittäjän tuotteista saattaa löytyä tietynlaisia vikoja, joten kehittäjän passiivinen mukanaolo saattaa tuoda ideoita testaukseen. Tämän takia kannattaa aina käyttää ideoinnissa mukana eritasoisia ja jopa eri ryhmien asiantuntijoita. Taas kerran: käytetään hyväksi kyseenalaistamista ja kysymistä, jotta saadaan esille ne asiat, jotka pitää saada esille.

Työkalut, välineet, ympristöt vaikuttavat omalta osaltaan testaukseen. Voidaan miettiä asioita työkalujen kannalta ottamalla huomioon käytössä olevat työkalut ja niiden hyväksikäyttäminen testauksessa sekä tarpeet työkaluille, joita mahdollisesti tarvitaan. Esimerkiksi testausryhmässä on kokemusta suorituskykytestaustyökaluista, mutta integraatiotyökalut ovat vähemmän käytettyjä. Voisiko heuristiikkana olla tehdä tutkivaa testausta integraatiotyökalulla? Olisiko yrityksessä joku integraatioasiantuntija? Aikataulu saattaa myös herättää testausaiheisia kysymyksiä priorisoinnista ja testausryhmän kokoonpanosta. Aikataulu tuo yleensä oman leimansa testauksen suorittamiseen. Esimerkiksi aikataulun yhdistäminen vaikkapa asiakkaan vaatimiin suorituskykytesteihin määrittää tiettyjen alueiden testaamisen ennen toisia. Tai jos toteutus on pilkottu releaseihin, joissa testaus pitää kohdistaa tiettyihin osa-alueisiin, koska toisia ei ehkä vielä ole toteutettu.

Testauksen kohde on aina hyvä herättämään kysymyksiä: "Mikä tämä on? Mitä se tekee?" Se herättää todennäköisesti jatkokysymyksiä ja nostaa muita heuristiikkoja esiin. Jamesbachmainen heuristiikka "Huh? Really? So?" (HRS) pätee hyvin usein, kun kysytään ihmisiltä juuri noita kysymyksiä. Kyseenalaistamalla saamasi vastauksen testauksen kohteesta voi nousta uusi kysymyksiä ja ehkä juuri ne kysymykset ovat niitä, mitkä pitää kysyä.

Testaustuotteet voivat myös nostaa ideoita, esimerkiksi bugilistoista voi löytyä ideoita. Kaikki testauksen tuottama materiaali, opitut asiat, raportit, jne. voivat nostaa asioita esiin, joita täytyy miettiä tässä kyseisessä testausprojektissa. Testaustuotteena on tietenkin myös taitopääoma, joten käytännössä kaikki testausmateriaali ja taito, mitä yrityksessä on saatavilla kannatta jollakin tasolla hyödyntää.

Heuristiikan käyttäminen toimii myös muussa kuin dynaamisessa testauksessa. Kyseenalaistaminen ja katselmointi hyödyntävät myös näitä heuristiikkoja. Jokainen kehittäjä pystyy parantamaan omaa työtään kyseenalaistamalla määrittelyitä tai suunnitelmia hyväksykäyttäen testaukseen käytettäviä heuristiikkoja. Eikä pelkästään projektin alkuvaiheessa vaan pitkin toteutusta ja lopulta koodin valmistuttua koodikatselmoinneissa ja korjaus/muutospyynnöissä.

Testausheuristiikat 1/7

Kuten jo taannoin mainitsin, olin Rapid (vai oliko re rabid) Software Testing -kurssilla Suomen kauniissa pääkaupungissa. Kurssi veti testausalan kirkkaimpiin tähtiin kuuluva Michael Bolton. Kurssilla käytiin läpi asia jos toinenkin, mutta yhtenä osa-alueena siellä oli heuristiikkojen käyttö tutkivassa testauksessa.

Heuristiikkojen käyttö ei tarkoita sitä, että sinulla on checklist, jonka sitä tarkistat läpi softassa ja sen jälkeen softa on testattu. Heuristiikan voivat olla päteviä ko. kontekstissa tai olla olematta. Niiden tehtävä on tarjota ajattelulle lähteitä jotta itse testi-ideoiden luominen olisi helpompaa. RST-kurssilla heuristiikat oli niputettu listoiksi, joista tuli anagrammeja tai muistisääntöjä muistamisen helpottamiseksi. Näiden heuristiikkojen muistaminen voisi varmistaa sen, että kuljen koko ajan päässäsi satoja testi-ideoita mistä tahansa testattavasta aiheesta.

Muistisäännöt ovat lontoonkielellä seuraavaa: CIDTESTD (kid tested) , HICCUPPSS (hickups) SFDPOT (San Fransisnco Depot), CRUSSPIC STMPL (Crosspick Stample), FDSFSCURA (Fed-Jeff's Curae).

Jaan nämä heuristiikkamöhkäleet lukemisen helpottamiseksi omiksi blogimerkinnöiksi, joten näitä tulee tippumaan tänne sitä mukaa, kun saan näitä hiottua.

Wednesday 8 June 2011

Täh?! Oikeesti?! Mitä sitten?!

Michael Bolton mainitsi kollegansa James Bachin käyttävän äärimmäisen tehokasta kyseenalaistamisen heuristiikkaa: Huh? Really? So? (aiemmin viittamani HRS-heuristiikka) Päätin ottaa itsekin tuon heuristiikan käyttöön ja olen nyt kokeillut sitä erinäisissä tilanteissa, jopa testannut omia puheitani ja kirjoituksiani tuon heuristiikan kautta.

Huh? Täh? Siis mitä?

Oletko koskaan istunut neukkarissa, kun joku "sankari" esittää kuninkaan elkein hienoja prosessimalleja tai pitää yhteenvetoa asiasta, josta et ole kuullutkaan? Sinut on kutsuttu paikalle, koska se ehkä liippaa sinun asiantuntemusaluetta jollakin tasolla (normaali kriteeri palaverikutsulle). Mies tai nainen edessä selittää, osoittelee graafeja ja vuokaavioita, ja jokatoinen neukkarissa oleva henkilö piirtelee tikku-ukkoja paperin reunaan tai näpyttelee puhelintaan. Osa saattaa jopa tuijottaa taululle, koska luulee ymmärtävänsä jotakin, mutta silmissä on tyhjä katse.

Tässä vaiheessa taitava testaaja kysyy: "Täh?" Kaikki tuijottavat testaajaa kuin tämä olisi sanonut jotakin tyhmää - varsinkin "sankari". "Niin mitä tämä tarkoitti? Voitko selittää tämän niin, että testaajakin ymmärtää? En ehkä ole käynyt kaikkia kouluja enkä ole tehnyt kehitystä vuosia, mutta tiedän kuitenkin että en ymmärrä kaikkea, mitä sanot. Onko minun tarpeellista siis edes ymmärtää tätä (ja päätellen paikallaolostani ON)? Mielestäni on. Voitko siis kertoa, mitä tuo tarkoittaa?" Tässä vaiheessa kynät lopettavat tuhertelun ja kännykät menevät taskuun.

Muut ajattelevat ehkä: "Olipas fiksu testaaja. Vitsi, kun olis itse ymmärtänyt kysyä asiaa hetki sitten, niin en olisi niin pihalla." Kukaan tuskin ajattelee, että "onpa tyhmä kaveri kun ei ymmärrä, mistä puhutaan". Todennäköisesti tässä vaiheessa "sankari" selittää hieman matalammalla tai korkeammalla tasolla (riippuen kumpi on selkeämpi tai hänen mielestään selkeämpi). Tämän jälkeen suurin osa kallistuu tuolissaan taaksepäin ja alkaa taas tuhertelemaan. "Anteeksi, en kyllä vielä ymmärtänyt. Meneekö se oikeesti niin?"

Really? Oikeesti? Ootko ihan varma?


"Sankari" tuijottaa ja toteaa, että näinhän se menee. Esimerkkiä pyydettäessä taas kaikkien mielenkiinto palautuu. Nyt "sankari" esittää prosessimallia hieman käytännön tasolta tai raporttia henkilönäkökulmasta. Tässä vaiheessa testaajalla nousee useita kysymyksiä käytännön asioita. "Entäs tapaus 1? Entäs tapaus 1a?"

Tässä vaiheessa muut ajattelevat, että "olisiko minun pitänyt tietää kysyä näitä asioita? Olenko niin fiksu, kun luulen olevani?" Sankari kysyy tätä varmasti itseltään. Kun sankari on joko "oikeesti" pystynyt selittämään asian tai todennut, että ei ole miettinyt asiaa tuolta kantilta vaikka olisi ehkä pitänyt. Taas porukka rentoutuu... "Mitä tällä siis haetaan? Miksi näitä asoita esitellään?"

So? Mihin se johtaa? Mitä sitten?

... ja taas porukan mielenkiinto nousee taas. "Tämä saattaa koskea minua. Tämä seuraava lause voi vaikuttaa minun tulevaisuuteeni tai työntekooni."

Testaajan tehtävä on nostaa esille asoita, mitä muut eivät ole vielä osanneet miettiä. Testaajan tehtävä on tarjota tietoa asiayhteydestä siitä kiinnostuneille sidosryhmille. Testaaja itse on osa yhtä sidosryhmää, joten hänen tehtävänsä on vaatia se tieto, mikä hänelle kuuluu. Ei ole olemassa tyhmiä kysymyksiä - on olemassa kysymyksiä, joita pidetään tyhminä kunnes ne kysytään. Usein on tyhmää olla kysymättä. Näiden "tyhmien" kysymysten tarkoitus on herättää uusia kysymyksiä - kysymyksiä, joita kukaan ei ole vielä kysynyt. Käyttäkää tätä heuristiikkaa tulevissa palavereissa ja olkaa kriittisiä. Kyseenalaistakaa oma toimintanne siinä missä muidenkin.

Todennäköisesti palaverin jälkeen muu porukka kyselee asioita testaajalta eikä "sankarilta".

Monday 23 May 2011

Tunteet pinnassa

Nyt on 23. Toukokuuta ja istun Hotelli Haagan huoneessa. Olen Michael Boltonin vetämällä Rabid Software Testing -kurssilla. Kurssi on huikea ja palaan siihen vielä kattavammin myöhemmin.

Antti Niittyviita Provelta kommentoi minulle kirjoittamistekniikastani hotellin aulassa. Hänen mielipteensä kirjoittamistyylistäni oli se, että annan kerralla liikaa... Hmmmm... On totta että kirjoitan tunteella ja tunnin, mutta tämänkertainen kirjoitelmani ei ole tunnin mittainen. Tunteet ovat siinä kuitenkin mukana.

Hah! Tunteet eivät kuulu projektimaailmaan! Meillä pitää olla faktoja eikä tunteita! Mittarit kertovat meillä tarvittavat asiat ja muu on turhaa nyyhkytystä! Vai onko?

Suomessa ei ole kovin paljoa puhuttu testauksesta tunteiden pohjalta, mutta Michaelin mukaan nopean ja tehokkaan tutkivan testauksen yksi kulmakivistä on tunteiden liittäminen testaukseen. Tunteet toimivat toiminnan laukasijana. Usein viitataan intuitioon, perstuntumaan, jne. tapauksissa, joissa meillä ei ole suoranaista faktaa tai mittareita kertomaan asioista. Mittarina toimii siis henkilö itse. Esimerkkinä Michael käytti autolla ajamista: "Jos mietit, että ajanko liian lujaa, ajat liian lujaa." Ihminen saa tuntemuksia erilaisten tapahtumien johdosta, esimerkiksi hämmennys testatessa tarkoittaa, että jokin testauksen kohde on hämmentävä. Tämä toimii mittarina sille, että kaikki ei välttämättä ole kohdallaan.

Tämä siis puhtaasti sitä, mitä kurssilla opetettiin... Miten tämä siis kääntyy esimerkiksi meidän yrityksemme testausprosessiin? Kun prosessi on määritelty sellaiseksi, että automaatio näyttelee (tai tulee näyttelemään) suurta osaa, täytyy testauksen hallinnan luovia itselleen väylä tuonne. BDD tyyppisen prosessin johtaminen tunteella ei välttämättä ole se, mitä johtoporras tai asiakas haluaa kuulla. Voidaanko tunteen pohjalta kuitenkin tehdä bisnespäätöksiä? Tarvitseeko kaikki päätökset tehdä mittareiden pohjalta?

Jos testaaja saa tunteen, että "tässä on jokin vialla", eikö se ole maailman paras mittari? Jos jokin toiminnallisuus herättää epäluuloa, eikös se ole vahvempi mittari kuin "3 minor defectiä, joista kaksi korjataan 9. sprintissä"? Jos testaaja tuntee turhautumista siitä, että ei löydä toiminnallisuudesta enempää vikoja, kertooko se enemmän kuin "S-käyrän taittuminen toiminnallisuuden vikakertymää tarkasteltaessa"?

Kuinka siis esittää liiketoiminnalle arvio järjestelmään liittyvistä riskeistä, jos ne pohjataan mittareihin? Voidaanko testausprosessiin liittää tutkivan testauksen tuoma reaktiokyvyn kasvattaminen sekä tunteiden "kuunteleminen", mutta säilyttää iteraatiomallin automatisoitu regressiotestaus? Testausprosessiin tulisi liittää vaihe, joka on rinnan muun testauksen kanssa, joka käsittelee testattavaa tuotetta tutkivan testauksen näkökantilta, mutta joka tapahtuu rinnan kaiken muun testauksen kanssa. Heuristiset menetelmät ja sessiopohjainen testauksen hallinta voivat vapauttaa resursseja kankeista manuaalisista testausprosesseista ilman että manuaalisesta testauksesta luovutaan (ja tätäkin ajatusta maailmalla viedään eteen- ja taaksepäin). Tämä prosessimalli mahdollistaisi automaation tuoman jatkuvan ja nopeatempoisen raportoinnin etujen liittämisen tutkivaan testaukseen ja älykkääseen päätöksentekoon.

Mutta Antin mielipidettä kunnioittaakseni aion pitäytyä nyt lyhyessä pohdiskelussa ja vielä tämän viikon aikana aion avata sanaisaa arkkuani toisen merkinnän puitteissa. Siihen asti... tunteella mukana.

Tuesday 10 May 2011

Manuaalisen testauksen profiilin nostaminen

Testauksen automatisointi on manuaalisen testauksen suorittamista koneellisesti, jonkin testausohjelman avulla. Automaatio onkin muodostunut suureksi osaksi nykypäivän testausta ja sillä on vankkaa kannatusta läpi testaus-skenen. Lähes kaikki testaajat ovat vakuuttuneita automaation hyödyistä - myös minä. Kuinka moni enää kuitenkaan uskoo manuaalisen testauksen voimaan testauksessa?

Automaatiota arvostetaan suhteessa enemmän kuin manuaalista testausta: kun etsin manuaalisesta testauksesta kertovaa materiaalia, jokaisessa oli vähintään ohjeistus kuinka automatisoida nuo manuaaliset testit. On ilman muuta totta, että automatisoidut testit vievät vähemmän aikaa ajaa, kunhan ne on toteutettu. Onko kuitenkin jokin kuitenkin pudonnut kelkasta matkan varrella, koska manuaalinen testaus testauksena on maailman hienoin asia (puhtaasti oma mielipide eikä minulla ole tieteellistä faktaa tukemaan tätä väitettä)?

Testauksen automaation helppoutta korostetaan monessa paikassa (mm. Bhavian Turakhia esityksessään), vaikka helposti automaation toteuttaminen on huomattavasti vaikeampaa kuin manuaalinen testaaminen. Testausautomaation edut eivät siis suinkaan ole testit toteuttamisen helppoudessa, ainakaan kaikissa tapauksissa. Pentti Pohjolainen kirjoitta gradussaan:
Ennen kuin voidaan automatisoida, täytyy toimiva manuaalinen testausjärjestelmä olla olemassa. Sen täytyy sisältää vähintään seuraavat piirteet: Ensinnäkin yksityiskohtaiset testitapaukset sekä odotetut tulokset, jotka perustuvat vaatimusmäärittelyihin ja suunnitteludokumentteihin.

Tämä tarkoittaa käytännössä sitä, että sen lisäksi että pitää olla hyvä määrittely- ja suunnitteludokumentaatio, tulee tapaus pystyä testaamaan ylipäänsä. Lisäksi Pohjolainen viittaa siihen, että järjestelmän toiminta tulee olla ennustettavissa tarkkaan, että tiedetään mikä loppu tulema tulee tarkalleen olemaan. Automaatiota ei kannata tehdä ilman tarkistuksia. Manuaalisessa testauksessa tarkistuksen tulevat automaattisesti, kun tulosta tarkistetaan! (No menipähän saivarteluksi..)

Testausautomaatio on äärimmäisen kannattavaa silloin, kun samaa tapausta ajetaan useita kertoja. Jos puhutaan ketteristä menetelmistä, joissa iteraatioita on paljon, yönylitestit tuovat lisäarvoa ja ennustettavuutta, jne., testausautomaatio on tehokas työkalu. Jos verrataan manuaalisen testauksen kustannuksia iteraatiotilanteissa, ei manuaalisen testauksen kustannustehokkuus yllä lähellekään automaatiossa säästettäviä summia. Mitä tapahtuu, kun määrittely muuttuu? Mitä tapahtuu, kun muutetaan komponenttien nimeämispolitiikkaa? Mitä tapahtuu muutoksen yhteydessä? Jotain muuttuu! Kun testiautomaation kohteena oleva järjestelmä muuttuu, täytyy testi päivittää. Kun testi päivitetään, sen toiminta tulee ensin varmistaa jollakin tapaa että testi itse ei jää vialliseksi -> manuaalinen testaus. Kun tehdään automatisoitua testausta ketterissä menetelmissä, voidaan olla varmoja, että testien päivitystä tapahtuu. Kuinka suuret kustannukset aiheutuvat testien päivittämisestä, koestamisesta, uudelleenajamisesta? Kuinka "hauskaa" (lainatakseni herra Turakhiaa) testien päivittäminen on, kun koko sovelluslogiikka muuttuu?

Manuaalisen testauksen ollessa pääasiallinen lähestymistapa edellä mainitussa tapauksessa, voidaan manuaalisesti saada palaute nopeammin kuin automatisoiduissa testeissä. Automaation kannattava voimahan on sen "palautteen nopeus". Jos tämä voima katoaa, onko automaatiosta mitään hyötyä? Toki joitakin testitapauksia on vaan puhtaasti viisaampi testata automaattisesti, mutta näissäkään tapauksissa ei puhuta puhtaasta automaatiosta vaan manuaalisen testauksen tukena käytettävästä työkalusta, jossa testausta helpotetaan työkalun ominaisuuksilla. Hyvänä esimerkkinä on suorituskykytestaus, joka ei luonnistu ihan helposti manuaalisesti... vaikkakin mm. Sokoksen verkkokaupan case-esittelyssään kerrottiin koko kehittäjätiimin (noin 100 henkeä) tehneen viiden minuutin aikana pikaisen suorituskykytestin, jossa kaikki kirjautuivat verkkokauppaan, jne. Pointti on kuitenkin se, että manuaalinen testaus sitä tukevin työkaluin on usein tehokkaampaa kuin puhtaasti automaattinen testaus.

F-secure on yksi testauksen edelläkävijöitä Suomessa ja heidän automaation toteutustavat herättävät minussakin kateutta. Voiko kuitenkaan samaa mallia soveltaa kaikkialle? Onko järkevää toteuttaa automaatiota sellaisiin projekteihin, joissa kalenteriajassa on viikko testausaikaa ja määrittelyt ovat powerpoint-tasolla (onko kenellekkään tuttu malli?) tai toteutus on niin paljon myöhässä, että vesiputousmallinen projekti karsii taas testauksesta? Ei heilläkään kuitenkaan ole hylätty automaatiota vaan se tukee heidän manuaalista testaustaan ja toimii "takaporttina", jolla mahdollistetaan regression poissulkeminen mahdollisimman pian. Heidän testausprosessinsa on sen mallinen, että automaatio mahdollistaa kypsän softan pääsyn manuaaliseen testaukseen.

No, kaikki tämä puhe automaation ongelmista ei tarkoita sitä, että automaatio pitäisi karsia kokonaan pois. Ei suinkaan! Päämääränä on tuoda älykkyys takaisin testaukseen (oliko se se, mikä taannoin putosi kelkasta?). Älykkyydellä en suinkaan tarkoita teknistä tietämystä tai taitoa, vaan sellaista älykkyyttä, mikä testaajalla pitää olla: kyseenalaistava älykkyys. Voidaanko puhua älykkyydestä, jos työkalujen tarjoajat mainostavat manuaalista testausta vanhentuneeksi? Voidaanko puhua älykkyydestä, kun koko laadun pohjaksi muodostetaan yönylitestien vihreänä pitäminen? Voidaanko puhua älykkyydestä, kun mottona on testauksen automatisointi, jolloin myös testauksen suunnittelu on automaattista? Jos kaikki on automaattista, niin mihin sitä älykkyyttä itse asiassa tarvitaan edes? (Onnistuinko puhumaan itseni pussiin...)

Sivusin aiemmin manuaalisen testauksen palautteen "hitautta" verrattuna automaatioon. Minulle on itselleni tuputettu teesiä "automaatiolla palaute on sekunteja, kun manuaalisella se on päiviä". Mitä tapahtuu, kun automaattista testisettiä pitää päivittää ja kyseinen setti voidaan ajaa vasta seuraavana päivänä? Testataan se manuaalisesti, kun kerran samoilla spekseillä se automatisoidaankin. Palaute on jopa nopeampi. "Automaattiset raportit", joku sanoo. Muun muassa Quality Center, Microsoftin Test Manager ja Test Runner ovat yksi keino palautteen nopeuttamisessa. Eikös se vähän niin kuin syö automaatiolta sen pääteesin? Tokihan pitkissä iteraatioissa automaatio on kustannustehokkaampi ja se huomaa regression nopeammin. Näissä tilanteissa se tulee kuitenkin ajatella työkaluna, jolla annetaan enemmän aikaa manuaaliseen testaukseen. Manuaalinen testaus huomaa erilaisia vikoja kuin automaatio, ja yleensä automatisoidaan ne tapaukset, missä manuaalisesti vikoja huomataan.

Ei manuaalinen testaus tietenkään mikään ihmelääke ole. Se ei ole idioottivarma, mutta ei sen pidäkään olla! Jos olisi olemassa idioottivarma testausmenetelmä, niin ei asiasta kiisteltäisi! Manuaalisen testauksen kompastuskiviä on (ja tulee aina olemaan) sen kustannustehokkuus iteratiivisessa projektimallissa. Älykkäällä manuaalisella testauksella voidaan kuitenkin löytää paljon enemmän kuin automaatiolla. Ei-älykäs testaus on usein se, mitä vasten automaatiota verrataan: testitapauksissa harpotaan, testien tarkistaminen unohtuu, jne. Tilastollinen tosiasia on (en pysty löytämään tämän julkaisijaa, mutta muistaakseni löytyy James Bachin webinaarista, en kuitenkaan mene oikeuteen tästä lainauksesta ;) ), että

80% kaikista automaatiotestitapauksista on kuraa eivätkä todellisuudessa testaa mitään.

Voiko manuaalisesta testauksesta sanoa kuitenkaan samaa? Jos järjestelmä on alhaalla, niin näyttääkö manuaaliset testit vihreää, koska tarkistus puuttuu?

Jos siis saataisiin manuaaliseen testaukseen integroitua joitakin automaation peruspiirteitä (eli nopea vaste ja raportoinnin helppous), voitaisiin manuaalista testausta nostaa voimakkaammin automaation rinnalle. Ehkä tällä tavoin manuaalisen testauksen piiriin saataisiin lisää huippuosaajia, jotka kehittäisivät testaustekniikoita ja -metodeita manuaalisen testauksen piirissä. Totta kai nykyiset testingdojot ja testingweekendit ovat nostaneet profiilia, mutta miten se saadaan nostettua samalle tasolle automaation tekniikan kehityksen kanssa? Miten voidaan tehdä manuaalisesta testauksesta seuraava ISO JUTTU? Miten saadaan ihmiset ymmärtämään, että testauksen tehokkuus ja eritoten kustannustehokkuus riippuu puhtaasti testaajien älykkyydestä eikä automaatiotyökalun käytettävyydestä?

Tuesday 12 April 2011

Murdering your darlings

eli "kullanmurujen murhaaminen"

Olen innokas miniatyyrifiguuri- ja peliharrastaja. Luen mielelläni alan julkaisuja. Tilaan White Dwarf -nimistä miniatyyrilehteä, jossa eräs tuon alan konkari kirjoittaa artikkeleita milloin mistäkin aiheesta. Tuon artikkelisarjan nimi on "Standard bearer" ja sitä kirjoittaa Jervis Johnson, kymmeniä vuosia miniatyyripelien maailmaa luonut ja tutkinut veteraani. Hän kirjoitti huhtikuun artikkelissaan (White Dwarf 376, April 2011) mantroista, joita hän viljelee töissä ja työn ulkopuolella. Eräs mantra oli "Murdering your darlings" eli "kullanmurujen murhaaminen".

"Murdering your darlings" tarkoittaa käytännössä sitä, että jos teet jotakin, josta olet erityisen ylpeä ja pidät sitä nokkelana tai nerokkaana; yliviivaa se ja tee se uudelleen. Suurin osa asioista, joista olemme erityisen ylpeitä eivät todellisuudessa ole muuta kuin oman itsetuntomme kohottamista eikä tuo tekele vie sitä todellista asiaa eteenpäin. Jervis kirjoittaa (vapaasti käänneetynä):
"jos kirjoitat huikein sanankääntein nokkelan lausahduksen, se todennäköisesti on olemassa vain sen takia että tuntisit itsesi nokkelaksi".
Sillä ei pyritä muokkaamaan asioita muokkamisen tähden vaan pyritää luomaan yksinkertaisin mahdollinen tuote, jolla asiaa voidaan viedä eteenpäin. Kun huomaat tehneesi jotakin, josta olet äärimmäisen ylpeä, sinun tulee miettiä kyseinen asia uudelleen ja tarkastella, viekö tuo tekele kohti sitä päämäärää johon olet pyrkimässä. Jos ei, niin "kullanmuru hengiltä".

Tämä teksti on tuon murhaamisen tulos. Jotta pystyn kirjoittamaan hyvän testin, minun täytyy päättää mistä kirjoitan ja miksi kirjoitan. Päämääränä on luoda laatua parantava ajatusmalli. Mistä pitää lähteä liikkeelle?

Lähtökohta on se, että itseään ylentävästi kirjoitettu tekninen teksti ei palvele ketään eikä se vie tavoitteeseen. Tämä laadunparantaminen ei kuitenkaan koske pelkästään teknistä kirjoittamista vaan kaikkea julkaistavaa asiaa. Se pätee sekä ohjelmistokoodiin, testitapauksiin, raportteihin, itse sovellukseen, järjestelmiin, patsaisiin, taloihin, yms. Käytännössä "kullanmurujen murhaaminen" pätee kaikkeen mitä voi tehdä. Lähtökohdan ja tavoitteen välillä tulee olla suora viiva ja kaikki tuon viivan ulkopuolella oleva turhaa informaatiota. Jokainen palanen tulee siis arvioida, jotta voidaan tietää palveleeko tuo kyseinen asia lopputulemaa. Jos näin ei ole, se heikentää laatua.
Onko kyseinen asia välttämätön lopputuleman kannalta? Mitkä ovat kaikessa yksinkertaisuudessaan ne asiat, jotka tarvitsee tietää, tehdä, ratkaista, jne, jotta päästään päämäärään? Kuinka voidaan tehdä mahdollisimman tehokasta työtä, jotta voidaan saavuttaa parasta mahdollista laatua.

Kun nämä vähimmäisvaatimukset on löydetty, tulee jokaiseen vaatimukseen luoda sisältö, joka palvelee ainoastaan tuota tarkoitusta. Jos se täyttää tuon määrityksen, se vie kohti päämäärää. Jos tuo sisältö on lisäksi jotain muuta kuin pelkkää eteenpäinvievää informaatiota tms., se tulee muokata sellaiseksi, että se ei sisällä muuta. Eli otetaan punakynä käteen ja vedetään yli ne asiat jotka eivät täysin ja kokonaisuudessaan vie kohti lopputulemaa. Kun päämäärä on kaikkien näiden kullanmurujen murhaamisen jälkeen saavutettu, lopputulema on laadukkain ja tehokkain, mitä voi olla. Kaiken sisällön tulee palvella lopputulemaa ja tehokkaimmalla mahdollisella tavalla. Näin päästään korkeimpaan mahdolliseen laatuun.

Tämä on siis mahdollista kysymällä kaikessa tekemisessä "Mitä haluan saavuttaa?" ja "Viekö tämä tuotos minua lähemmäs valittua päämäärää?". Tämä pätee myös testaamiseen.

Testaus on kustannustehokkuusmielessä äärimmäisen huonoa - testaus ei tuota mitään, mistä voisi saada rahaa. Sen tähden testauksen tehokkuus on äärimmäisen tärkeää, jotta se asia, mitä testauksella pyritään saavuttamaan, saataisiin mahdollisimman kustannustehokkaasti saavutettua ja työn laatu olisi korkeinta mahdollista. Tämä ei tarkoita ylilaatua, koska se jos jokin on rahan hukkaan heittämistä. Työn tarkoituksen tulee palvella tarvetta niin, että voidaan saavuttaa haluttu tulos niin tehokkaasti kuin mahdollista.

Kun otetaan "kullanmurujen murhaaminen" käytäntöön vaikka testitapauksia luodessa, pystytään luomaan tehokkaasti selkeitä ja laadukkaita testitapauksia, jotka palvelevat tarkoitusta. Niiden tarkoitus ei ole kasvattaa testitapauksen kirjoittajan egoa tai statusta tiimissään. Paras testitapaus on sellainen, että päämäärään päästään suorinta reittiä tehokkaasti ja laadukkaasti.

Eli nyt jokainen tulostaa itselleen A4-kokoisen muistilapun "TODO: Murder your darlings!" ja odota, että joku tulee ihmettelemään, että oletko ajatellut käydä työterveydessä kertomassa näistä murha-aikestasi... ;)